นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับซอฟต์แวร์การตรวจสอบ
สิ่งที่เกี่ยวข้องด้วย: คุณใช้เครื่องมืออะไรในการตรวจสอบเซิร์ฟเวอร์ของคุณ
ฉันต้องตรวจสอบเซิร์ฟเวอร์ของฉัน ฉันต้องพิจารณาอะไรเมื่อตัดสินใจเลือกโซลูชันการตรวจสอบ
คำตอบ:
มีโซลูชั่นการตรวจสอบจำนวนมากออกมี ทุกคนมีความชอบและแต่ละธุรกิจมีความต้องการของตนเองดังนั้นจึงไม่มีคำตอบที่ถูกต้อง อย่างไรก็ตามฉันสามารถช่วยคุณค้นหาสิ่งที่คุณต้องการค้นหาในการเลือกโซลูชันการตรวจสอบ
โดยทั่วไประบบการตรวจสอบนั้นมีจุดประสงค์หลักสองประการ สิ่งแรกคือการรวบรวมและจัดเก็บข้อมูลเมื่อเวลาผ่านไป ตัวอย่างเช่นคุณอาจต้องการรวบรวมการใช้งาน CPU และสร้างกราฟเมื่อเวลาผ่านไป วัตถุประสงค์ที่สองคือการแจ้งเตือนเมื่อสิ่งต่าง ๆ ไม่ตอบสนองหรือไม่อยู่ในเกณฑ์ที่กำหนด ตัวอย่างเช่นคุณอาจต้องการการแจ้งเตือนหากเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้ด้วยการส่ง Ping หรือหากการใช้งาน CPU สูงกว่าเปอร์เซ็นต์ที่แน่นอน นอกจากนี้ยังมีระบบตรวจสอบบันทึกเช่น Splunk แต่ฉันกำลังจัดการสิ่งเหล่านี้แยกจากกันสำหรับเรื่องนี้
บทบาทหลักทั้งสองนี้บางครั้งมาในผลิตภัณฑ์เดียวเวลาอื่นและร่วมกันมากขึ้นคือการมีผลิตภัณฑ์ที่อุทิศให้กับแต่ละวัตถุประสงค์
Pollers :
ระบบการตรวจสอบทั้งหมดจำเป็นต้องมี poller เพื่อรวบรวมข้อมูล มีการรวบรวมข้อมูลบางอย่างในลักษณะเดียวกัน คุณควรตรวจสอบสภาพแวดล้อมของคุณและตัดสินใจว่าคุณต้องการข้อมูลใดและมีวิธีการรวบรวมอย่างไร จากนั้นตรวจสอบให้แน่ใจว่าระบบการตรวจสอบที่คุณเลือกรองรับสิ่งที่คุณต้องการ วิธีการทั่วไปบางอย่างรวมถึง:
หากคุณมีระบบปฏิบัติการเดียวส่วนใหญ่ในสภาพแวดล้อมของคุณหรือระบบปฏิบัติการหลักระบบบางระบบอาจมีตัวเลือกเพิ่มเติมที่คนอื่น ๆ
การกำหนดค่า :
ในระบบการตรวจสอบมีแนวโน้มที่จะนำวัตถุจำนวนมากมาใช้ซ้ำ ตัวอย่างเช่นคุณต้องการตรวจสอบแอปพลิเคชันบางอย่างเช่น Apache หรือ IIS บนเซิร์ฟเวอร์จำนวนมาก หรือคุณต้องการให้เกณฑ์บางอย่างใช้กับกลุ่มของเซิร์ฟเวอร์ คุณอาจมีคนบางกลุ่มที่จะ "โทร" ดังนั้นระบบ templating ที่ดีจึงมีความสำคัญต่อระบบตรวจสอบ
โดยทั่วไปแล้วการกำหนดค่าจะทำผ่านส่วนต่อประสานผู้ใช้หรือไฟล์ข้อความ ตัวเลือกส่วนต่อประสานผู้ใช้โดยทั่วไปจะง่ายขึ้น แต่ไฟล์ข้อความมักจะดีกว่าสำหรับการใช้ซ้ำและตัวแปร ดังนั้นขึ้นอยู่กับพนักงานไอทีของคุณคุณอาจต้องการความเรียบง่ายมากกว่าพลัง
ส่วนต่อประสานผู้ใช้ : ส่วนต่อประสานที่พบบ่อยที่สุดสำหรับระบบตรวจสอบในปัจจุบันคือเว็บส่วนต่อประสาน สิ่งที่ควรประเมินเกี่ยวกับเว็บอินเตอร์เฟสคือ:
Alerting Engine : เอ็น
จิ้นการแจ้งเตือนจะต้องมีความยืดหยุ่นและเชื่อถือได้ มีวิธีการแจ้งเตือนที่หลากหลายรวมถึง:
คุณสมบัติอื่น ๆ ที่จะมองหาคือ:
สิ่งสำคัญคือต้องเชื่อว่าเมื่อมีสิ่งผิดปกติเกิดขึ้นคุณจะได้รับการแจ้งเตือน สองสิ่งนี้ลงมา:
ที่เก็บข้อมูล :
หากระบบรวบรวมและจัดเก็บข้อมูล (เช่นระบบที่มีกราฟ) กว่าที่ระบบจัดเก็บข้อมูล การใช้งานทั่วไปสำหรับทั้งร้านค้าและการสร้างกราฟคือ RRD
คุณลักษณะบางอย่างที่มองหาจากแหล่งข้อมูลคือ:
Graphing Library :
กราฟสามารถเป็นประโยชน์ในการระบุแนวโน้มอย่างรวดเร็วและให้บริบทกับสถานะปัจจุบันของบางสิ่งตามประวัติของมัน บางคนรวมถึงแนวโน้มที่จะเป็นประโยชน์ในการทำนายสิ่งต่าง ๆ ก่อนที่จะเกิดขึ้น (เช่นพื้นที่ดิสก์ไม่เพียงพอ) ตรวจสอบให้แน่ใจว่ากราฟจะให้ข้อมูลที่คุณคิดว่าคุณต้องการอย่างชัดเจน
การควบคุมการเข้าถึง :
หากคุณมีองค์กรขนาดใหญ่คุณอาจต้องการการควบคุมการเข้าถึงเนื่องจากผู้ดูแลระบบบางรายควรปรับเปลี่ยนบางอย่างได้เท่านั้น คุณอาจต้องการแดชบอร์ดสาธารณะหันหน้าไปทาง หากเป็นสิ่งสำคัญคุณควรตรวจสอบให้แน่ใจว่าระบบการตรวจสอบนั้นมีการควบคุมที่คุณต้องการ
การรายงาน :
ระบบที่จัดทำรายงานที่ดีสามารถช่วยคุณระบุสิ่งที่ต้องปรับปรุงในระยะเวลานาน ตัวอย่างเช่นมันสามารถให้คำตอบที่ดีกับสิ่งต่าง ๆ เช่น "ระบบใดที่ลงไปมากที่สุด" สิ่งนี้อาจมีความสำคัญเมื่อคุณพยายามโน้มน้าวให้ฝ่ายบริหารใช้จ่ายเงินในบางสิ่งซึ่งเป็นหลักฐานที่ชัดเจน
คุณสมบัติพิเศษ :
ระบบตรวจสอบบางระบบมีการกำหนดเป้าหมายที่ผลิตภัณฑ์เฉพาะหรือมีการสนับสนุนมากกว่าระบบอื่น ๆ ตัวอย่างเช่นหากสิ่งสำคัญที่คุณต้องตรวจสอบคือเซิร์ฟเวอร์ SQL หรือถ้าคุณใช้ผลิตภัณฑ์ VMWare อย่างหนักคุณควรดูว่าระบบเหล่านี้รองรับได้ดีเพียงใด
เทมเพลตการตรวจสอบที่กำหนดไว้ล่วงหน้า :
ระบบที่มาพร้อมกับเทมเพลตที่กำหนดไว้ล่วงหน้าจำนวนมาก (หรือมีฐานผู้ใช้ที่สร้างเทมเพลตจำนวนมาก) สามารถประหยัดเวลาได้มาก
การค้นพบ :
หากคุณมีสภาพแวดล้อมขนาดใหญ่หรือเปลี่ยนแปลง บางระบบมีความสามารถในการเพิ่มระบบใหม่ผ่าน API หรือเรียกใช้การสแกนเพื่อค้นหาเซิร์ฟเวอร์หรือส่วนประกอบใหม่
การตรวจสอบแบบกระจาย:
หากคุณมีสถานที่หลายแห่งที่จะตรวจสอบมันจะมีประโยชน์มากถ้าคุณมีตัวตรวจสอบสถานะในแต่ละตำแหน่งแทนที่จะเป็นระบบอิสระจำนวนมากกำลังตรวจสอบผ่านทาง WAN
มีระบบตรวจสอบจำนวนมากออกมี เรามีรายการพร้อมบทสรุปสำหรับคำถามเก่านี้ สำหรับการอ้างอิงอย่างรวดเร็วบางอย่างที่ฉันได้ยินมากที่สุดคือ:
เหตุผลที่ฉันไม่สามารถบอกคุณได้ว่าต้องใช้อะไรเพราะทุกองค์กรมีความต้องการของตัวเอง หากคุณต้องการเลือกอย่างถูกต้องคุณควรคำนึงถึงองค์ประกอบข้างต้นทั้งหมดและค้นหาว่าคุณลักษณะใดมีความสำคัญต่อองค์กรของคุณ จากนั้นค้นหาระบบหรือระบบที่อ้างว่าให้สิ่งที่คุณต้องการและลองใช้งาน บางส่วนของค่าใช้จ่ายเล็กน้อยมากหรือฟรี การพิจารณาทั้งหมดนั้นคุณสามารถเลือกได้ จากสิ่งที่ฉันใช้พวกเขาอยู่ไกลจากความสมบูรณ์แบบ แต่อย่างน้อยคุณก็สามารถลองบางสิ่งที่เหมาะสม
การแยกแยะระหว่างการตรวจสอบและการแจ้งเตือนมีประโยชน์มาก การตรวจสอบหมายถึงการรวบรวมข้อมูลและสร้างกราฟ การแจ้งเตือนหมายถึงส่ง SMS ถึงฉันเมื่อเซิร์ฟเวอร์หยุดทำงานกลางดึก
Nagios ใช้สำหรับแจ้งเตือน Cacti และ Munin ใช้สำหรับตรวจสอบ ผลิตภัณฑ์อื่น ๆ รวมฟังก์ชั่นทั้งสอง Zenoss และ Zabbix เป็นตัวอย่าง
ฉันจะเริ่มด้วยการตอบคำถาม:
คุณต้องการตรวจสอบเซิร์ฟเวอร์อุปกรณ์เครือข่ายแอพพลิเคชั่นหรือทั้งสามอย่างหรือไม่?
มีข้อ จำกัด เกี่ยวกับวิธีการที่คุณสามารถใช้ในการตรวจสอบหรือไม่ คุณสามารถติดตั้งไคลเอ็นต์การมอนิเตอร์เช่น NRPE บนเซิร์ฟเวอร์หรือคุณจะใช้ SNMP หรือทั้งสองอย่างได้ไหม
ใครจะใช้กราฟและใครจะใช้การแจ้งเตือน? คุณต้องการให้ผลลัพธ์สุดท้ายเป็นอย่างไร รูปลักษณ์ของอินเทอร์เฟซมีความสำคัญหรือไม่ (นักธุรกิจจะใช้สิ่งนี้หรือพนักงานเทคโนโลยีเท่านั้น)
ทรัพยากรของคุณคืออะไรในแง่ของเวลาทักษะและฮาร์ดแวร์? คุณมีความสามารถในการสคริปต์อย่างน้อยที่สุด? คุณต้องการวิธีแก้ปัญหาแบบใหม่หรือไม่?
ในความคิดของฉันกฎข้อแรกของทั้งการแจ้งเตือนและการตรวจสอบควรเป็นเรื่องง่าย ๆ ! องค์กรสามารถอยู่หรือตายได้ว่าจะแจ้งเตือนและรวบรวมข้อมูลอย่างไรและส่วนใหญ่แล้วมันจะซับซ้อนด้วยตัวเองอยู่แล้ว เริ่มต้นด้วยพื้นฐานและสร้างจากที่นั่น
คิดถึงบริการที่ซอฟต์แวร์ของคุณมีให้ส่งการแจ้งเตือนเมื่อบริการเหล่านี้ล้มเหลวหรือเมื่อความเสี่ยงต่อความล้มเหลวของบริการเหล่านี้เพิ่มขึ้น
ทฤษฎีที่อยู่เบื้องหลังกลยุทธ์การตรวจสอบคือการผูกการตรวจสอบและแจ้งเตือนการจัดเรียงของบางข้อตกลงระดับบริการ ท้ายที่สุดคุณต้องการได้รับการแจ้งเตือนถึงความจริงที่ว่าคุณกำลังสูญเสียเงินไม่จำเป็นว่าจะมีจำนวนการเชื่อมต่อ TCP ถึง nji0019.myserver.com มีเครื่องมือหลายอย่างที่จะให้การแจ้งเตือนเป็นตันกำหนดการพึ่งพาระหว่างการแจ้งเตือน แต่เช็คจำนวนมากเหล่านี้ไม่เกี่ยวข้องโดยตรงกับบริการที่คุณให้กับใครบางคน
ระบุบริการที่สำคัญที่คุณให้เช่นความสามารถในการให้บริการเว็บไซต์และความสามารถในการปรับเปลี่ยนเว็บไซต์นั้น (เช่น CMS บางประเภท) ควรตรวจสอบสิ่งเหล่านั้น (เช่นโดยการตรวจสอบว่าคุณสามารถรับเว็บเพจและสามารถทำได้) ความล้มเหลวของบริการทั้งสองนี้ (ใช้ที่นี่พร้อมตัวพิมพ์ใหญ่ S) ควรเปิดการแจ้งเตือนเพื่อแจ้งให้คุณทราบ
หากเป็นสิ่งสำคัญที่ไซต์ตอบสนองภายในระยะเวลาที่เหมาะสมก็ควรเรียกใช้การแจ้งเตือน เรียงจาก "ฝ่าฝืน SLA" ถ้าคุณต้องการ
มักจะมีความเสี่ยงโดยธรรมชาติของการบริการที่ล้มเหลวและบ่อยครั้งที่ความเสี่ยงนั้นลดลงเนื่องจากข้อเท็จจริงที่ว่าคุณแนะนำความซ้ำซ้อนเช่นเซิร์ฟเวอร์ที่สองหรือฐานข้อมูลทาสหรือการ์ดเครือข่ายเพิ่มเติม ...
เมื่อความซ้ำซ้อนนั้นหายไปบริการยังคงดีอยู่ แต่ความเสี่ยงของการบริการล้มเหลวก็เพิ่มขึ้น
นี่คือเหตุผลหลักที่สองในการทริกเกอร์การแจ้งเตือน ความซ้ำซ้อนนั้นหายไป (เช่นเซิร์ฟเวอร์ตัวที่สองเสียชีวิต) หรือมีอันตรายที่ความเสี่ยงจะเพิ่มขึ้น (เช่นดิสก์เหลือเพียง 500Mb หรือแนวโน้มของดิสก์บ่งชี้ว่าดิสก์จะเต็มในเวลาประมาณ 5 ชั่วโมง)
แต่ check_mk ให้การตรวจสอบ 50-60 รายการต่อโฮสต์สิ่งเหล่านี้ไร้ค่าไหม
ไม่ทั้งหมดนี้ไม่ได้หมายความว่าคุณต้องการทิ้งการตรวจสอบอัตโนมัติที่คุณได้รับเช่น check_mk แต่นั่นหมายความว่าคุณควรพยายามจัดประเภทการตรวจสอบแต่ละรายการให้เป็นบริการที่อาจได้รับผลกระทบหากมีบางอย่างล้มเหลว
บริการใดบ้างที่จะได้รับผลกระทบหาก / var / พาร์ติชันเต็ม บริการใดจะได้รับผลกระทบหากส่วนต่อประสาน eth0 ไม่ทำงาน ... หากการเชื่อมต่อ TCP ขาออกถูกบล็อกโดยไฟร์วอลล์บางส่วน ... ถ้าจำนวนเธรดเกิน 800? ... ถ้าฐานข้อมูลล่มหรือไม่
คุณมีเว็บเซิร์ฟเวอร์ 2 แห่งและเซิร์ฟเวอร์ฐานข้อมูลที่ให้บริการเว็บไซต์ที่อยู่เบื้องหลัง load balancer ที่คุณไม่ได้เป็นเจ้าของ (เช่น ISP) บริการที่คุณให้คือพอร์ต 80 บนเซิร์ฟเวอร์สองเครื่องและมีแคชจำนวนมากที่สามารถอยู่รอดได้เช่นการหยุดทำงานของฐานข้อมูล (ฐานข้อมูลบนเซิร์ฟเวอร์ที่สาม)
ในสถานการณ์สมมตินี้ความล้มเหลวทั้งหมดของเว็บเซิร์ฟเวอร์จะไม่ทำให้ไซต์หยุดทำงาน สิ่งที่เกิดขึ้นคือความซ้ำซ้อนได้หายไปดังนั้นความเสี่ยงของความล้มเหลวก็เพิ่มขึ้น ที่ควรเปิดการแจ้งเตือน
ความล้มเหลวที่สมบูรณ์ของฐานข้อมูลอาจไม่ส่งผลกระทบต่อความสามารถในการให้บริการไซต์เลยเนื่องจากแคชที่ได้รับการปรับตามตำแหน่ง สิ่งนี้จะไม่ส่งผลกระทบต่อบริการในการให้บริการเว็บไซต์ แต่อาจส่งผลกระทบต่อบริการอื่นเช่นการอัปเดตเว็บไซต์หรือการยอมรับคำสั่งซื้อ ...
แต่ละบริการจะมีระดับการบริการของตนเองที่กำหนดความสำคัญในการคืนค่าบริการหรือเพื่อหลีกเลี่ยงการหยุดทำงาน
ทุกครั้งที่คุณได้รับการแจ้งเตือนคุณควรดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้: - เปลี่ยนระบบที่ถูกตรวจสอบเพื่อแก้ไขปัญหาที่ทำให้เกิดการแจ้งเตือน (เช่นเปลี่ยนไดรฟ์หรือกำหนดค่า logrotate ใหม่หรือบางอย่าง) - เปลี่ยนระบบการตรวจสอบ ส่งออกไปในครั้งต่อไปที่เกิดสถานการณ์ (เช่นเปลี่ยนระดับสำหรับ "ดิสก์ฟรี" เพื่อให้ดิสก์สามารถเติมได้ถึง 90% แทนที่จะเป็นเพียง 80%)
ฉันส่วนใหญ่คุ้นเคยกับ Nagios และการกำหนดค่า verbose ของมันและหลังจากนั้นได้ถูกติดตั้งบนเว็บไซต์หลายรายการของ Check-mk ฉันเพิ่งเรียนรู้ว่า check_mk มีแนวคิดของ Business Intelligence (ตั้งแต่ 1.11) ซึ่งดูเหมือนจะตรงกับความคิดนี้ดี คุณสามารถกำหนดว่าการตรวจสอบใน nagios เป็นส่วนหนึ่งของการบริการที่มีขนาดใหญ่และมีกฎระเบียบที่กำหนดสถานะของ "บริการ" ในฐานะที่เป็นฟังก์ชั่นของรัฐของการตรวจสอบหลายที่รวมกับที่เลวร้ายที่สุดหรือดีที่สุดของรัฐ
หนึ่งในจุดที่สำคัญที่สุดที่ บริษัท ลืมเมื่อเลือกโซลูชันการตรวจสอบคือไม่ได้เกี่ยวกับการแก้ไขปัญหาการดำเนินงานในทันทีมันเป็นเรื่องของปัญหาที่ไม่คาดฝันในวันพรุ่งนี้! ฉันหมายถึงแน่นอนว่าการแก้ปัญหาเฉพาะหน้าเป็นสิ่งสำคัญ แต่เชื่อฉันในหลาย ๆ กรณีกลยุทธ์ระยะสั้นนี้จะไม่รับประกันความอยู่รอดของ บริษัท
มีโซลูชั่นการตรวจสอบที่ยอดเยี่ยมมากมายในตลาด การเลือกชุดโซลูชันขนาดเล็กที่ตอบสนองความต้องการของคุณนั้นเป็นงานที่ยากและยาวนานยิ่งไปกว่านั้นการหาโซลูชันที่เหมาะกับงบประมาณของคุณนั้นเป็นเรื่องยากยิ่งขึ้น ส่วนที่น่าสนใจคือการหาคนที่สอดคล้องกับปัจจุบันและอนาคตของคุณ และไม่มีการประเมินผลในการตรวจสอบว่ามันเป็นเรื่องของประสบการณ์ + + สัญชาตญาณเป็นปัจจัยที่สำคัญมาก: ความน่าเชื่อถือซึ่งไม่ได้เป็นเรื่องง่ายที่จะตัด
ตามกฎทั่วไปแล้วค้นหาและขุดหาเรื่องราวความสำเร็จของชุดการตรวจสอบสั้น ๆ ของคุณโดยเฉพาะหากมีผลกระทบต่อ บริษัท จากภาคธุรกิจของคุณ ถามผู้ขายเกี่ยวกับเรื่องราวความสำเร็จของพวกเขาและขออนุญาตจากพวกเขาเพื่อพูดคุยกับลูกค้ารายใดรายหนึ่ง บริษัท ที่ไม่กลัวการแสดงนี้พวกเขามีความสัมพันธ์ที่แท้จริงกับลูกค้าของพวกเขาและพวกเขาไม่ปิดบังและนี่เป็นสิ่งที่หาได้ยากมากในปัจจุบัน
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... พวกเขาทั้งหมดมีอัพและดาวน์ แต่ปัญหาที่แท้จริงคือการค้นหาว่าสิ่งใดที่ปรับให้เหมาะกับอนาคตของคุณ
หากคุณกำลังพิจารณาการตรวจสอบระบบระยะไกลอาจเป็นความคิดที่ดีที่จะค้นหาการทดสอบตำแหน่งจริง ปัญหาการเชื่อมต่อไม่ใช่เรื่องที่ผ่านมาและหากฮาร์ดแวร์ของคุณให้บริการกลุ่มในภูมิภาคใดภูมิภาคหนึ่งคุณอาจต้องการตรวจสอบให้แน่ใจว่าทรัพยากรของคุณมีอยู่ในสถานที่นั้น ๆ