- ข้อมูลที่เกี่ยวข้องกับ Critical network event ที่ถูกส่งมาให้โดยอุปกรณ์ network ในขณะที่เกิด fault ขึ้น เช่น Link fail, การที่อุปกรณ์ restart หรือการที่ host ทำการตอบสนองช้า โดยส่วนใหญ่การเชื่อถือข้อมูลเพียงบางเหตุการณ์จะไม่เพียงพอที่นำมาใช้สำหรับการทำFault management ที่มีประสิทธิภาพ ตัวอย่าง เช่น ถ้าอุปกรณ์ network ไม่สามารถทำงานต่อได้อย่างสมบรูณ์ ก็ไม่สามารถส่ง event ต่างๆได้ดังนั้น Fault management tool ที่ใช้ เพียงบาง critical network event ก็อาจจะไม่ update กับสถานะของอุปกรณ์ network
- การ polling ไปยังอุปกรณ์ network เป็นช่วงๆ จะช่วยทำให้พบปัญหาที่เกิดขึ้นได้ขึ้นอยู่กับช่วงเวลาที่ใช้ polling อย่างไรก็ตามต้องยอมรับผลของการใช้วิธีนี้ ความเร็วของการตรวจพบ ขึ้นอยู่กับความถี่ของการ polling ซึ่งขึ้นกับการเปรียบเทียบความถี่ของการ polling แล้วทำให้พบปัญหาได้เร็วกับ bandwidth ที่ถูกใช้ไป ดังนั้นถ้าต้องการให้พบปัญหาได้เร็วที่สุดต้องใช้ bandwidth ที่มาก ซึ่งปัจจัยอื่นที่ใช้พิจารณาเมื่อทำการตัดสินในการกำหนดค่าช่วงเวลา polling time คือจำนวนของอุปกรณ์ที่ทำการ poll และ bandwidth ของ link นั้นๆ
ตัวอย่าง เช่นถ้าสมมติว่าในแต่ละ query และ response มีความยาวของข้อมูลเฉลี่ย 100 bytes ดังนั้นสำหรับ network ที่ประกอบด้วยอุปกรณ์ 30 ชุด ข้อมูลที่ส่งและรับทั้งหมดของอุปกรณ์ 30 ชุดเท่ากับ 6,000 bytes(2*100 bytes*30 unit) หรือเท่ากับ 48,000 bits(6,000 bytes*8 bit/byte)
การ poll ทุกๆ 60 วินาที จะทำให้เกิดปริมาณข้อมูลเฉลี่ยเท่ากับ 800 bit/sec(48,000bits/60 sec)ของ bandwidth และทำให้สามารถทราบถึงสถานะของอุปกรณ์ในทุกๆนาที ซึ่งขึ้นอยู่กับ ปริมาณ bandwidth ที่มีในระบบ network ว่าใช้ bandwidth ในการ polling เป็นส่วนใหญ่หรือไม่
Protocol ที่ใช้ในการตรวจสอบการทำงานของอุปกรณ์และสามารถใช้ poll ไปยังอุปกรณ์ ได้แก่ ICMP Echo และ Echo Reply(ping), AppleTalk Echo, Banyan Vine Echo และ SDLC Receiver Ready(RR) frame ซึ่ง protocol เหล่านี้จะมีข้อมูลที่ช่วยในการแยกแยะ fault ได้ในตัวเอง
การเลือกว่าจะ Manage fault อะไรบ้าง
ไม่จำเป็นที่จะกำหนดให้ fault แต่ละอันมีความสำคัญที่เท่ากัน บาง fault เป็นสิ่งที่เราต้องการที่รู้ ส่วนบาง fault เราต้องการให้ระบบจัดการให้โดยไม่ต้องบอกให้ทราบหรือไม่ต้องสนใจเลย ซึ่งเราต้องทำการตัดสินใจว่า fault ไหนที่ต้องการ Manage ซึ่งควรจะเป็น fault ที่สำคัญเฉพาะสำหรับ network ของเรา
ซึ่งเรามีเหตุผลที่ต้องทำอย่างนี้อยู่ 2 อย่าง คือ
- ถ้าจำนวนของ fault มีหลายค่า ทำให้อาจจัดการได้ไม่หมด
- เนื่องจากปัญหาของขีดจำกัดของ bandwidth ของ event เราจึงต้องทำการลดข้อมูล event ที่ซ้ำซ้อนหรือไม่มีประโยชน์ และลดการสูญเสีย bandwidth
การตัดสินใจที่จะจัดการ fault ค่าไหน จะดูจากคุณสมบัติดังนี้
- ขอบเขตของการควบคุมที่ทำกับ network ซึ่งมีผลต่อจำนวนข้อมูล event ที่สามารถเก็บได้จากอุปกรณ์ network
- ขนาดของ network
บนหลายๆ network มีการทำ Centralize organize management กับ network backbone ดังแสดงในรูปที่ 2 โดย backbone จะประกอบไปด้วยอุปกรณ์ต่างๆ เช่น X25 Switch, IP router , IP switch ซึ่งการทำ Centralize organization management จะจัดการกับ Critical network event ของอุปกรณ์ backbone network ซึ่งมีผลกับ network ทั้งหมด การที่มีการปล่อยให้ทำ Local administration บ้าง เพื่อ manage fault ของอุปกรณ์ network ของตัวเอง และลด Load ของ Centralize Organization management ลง
ขนาดของ data network ซึ่งปกติจะเป็นเงื่อนไขในการตัดสินใจ ใน network ขนาดเล็ก(อุปกรณ์น้อยกว่า 50 อุปกรณ์) วิศวกรอาจเลือก manage fault ทุกชนิด รวมถึง host และอุปกรณ์ network ต่างๆ ใน network ขนาดกลาง วิศวกรอาจเลือก manage เฉพาะ fault ที่เป็น Critical network event สำหรับอุปกรณ์ network เท่านั้น สำหรับ network ขนาดใหญ่ วิศวกรอาจเลือก manage เฉพาะ fault ที่เป็น Critical network event เฉพาะ host และอุปกรณ์ network ที่สำคัญเท่านั้น