การกระจายทางภูมิศาสตร์ทนต่อความผิดพลาดและระบบตรวจสอบแอปพลิเคชัน / โฮสต์ที่“ ชาญฉลาด”

ทักทาย,

ฉันต้องการถามความคิดเห็นของกลุ่มและมุมมองเกี่ยวกับระบบการตรวจสอบแบบกระจายคุณใช้อะไรและคุณตระหนักถึงสิ่งใดที่อาจทำเครื่องหมายในช่องของฉัน

ความต้องการค่อนข้างซับซ้อน

• ไม่มีจุดล้มเหลวเดียว จริงๆ. ฉันตายไปแล้ว! ต้องสามารถทนต่อความล้มเหลวของโหนดเดี่ยว / หลายโหนดได้ทั้ง 'ต้นแบบ' และ 'ผู้ปฏิบัติงาน' และคุณอาจคิดว่าไม่มีตำแหน่งการตรวจสอบ ("ไซต์") ที่มีหลายโหนดอยู่ในนั้นหรืออยู่ในเครือข่ายเดียวกัน ดังนั้นสิ่งนี้อาจเป็นกฎของเทคนิค HA ดั้งเดิมเช่น DRBD หรือ Keepalive

• ตรรกะการกระจายฉันต้องการที่จะปรับใช้ 5+ โหนดในหลายเครือข่ายภายในหลายศูนย์ข้อมูลและในหลายทวีป ฉันต้องการมุมมอง "Birds Eye" ของเครือข่ายและแอปพลิเคชันของฉันจากมุมมองของลูกค้าของฉันคะแนนโบนัสสำหรับตรรกะการตรวจสอบจะไม่จมเมื่อคุณมี 50+ โหนดหรือแม้กระทั่ง 500+ โหนด

• ต้องมีความสามารถในการจัดการเช็คโฮสต์ / บริการจำนวนพอสมควรพอสมควรลากานิโอสำหรับตัวเลขของ ballpark ถือว่ามีโฮสต์ 1,500-2500 โฮสต์และบริการ 30 รายการต่อโฮสต์ มันจะดีมากถ้าเพิ่มโหนดการตรวจสอบมากขึ้นช่วยให้คุณสามารถขยายขนาดเชิงเส้นบางทีในเวลา 5 ปีฉันอาจมองตรวจสอบโฮสต์ 5000 และ 40 บริการต่อโฮสต์! เพิ่มในจากบันทึกของฉันข้างต้นเกี่ยวกับ 'ตรรกะกระจาย' มันจะดีที่จะพูดว่า:

  • ในสถานการณ์ปกติการตรวจสอบเหล่านี้จะต้องทำงานบน $ n หรือ n% ของโหนดการตรวจสอบ
  • หากตรวจพบความล้มเหลวให้รันการตรวจสอบในโหนดอื่น $ n หรือ n% ของโหนดเชื่อมโยงผลลัพธ์จากนั้นใช้เพื่อตัดสินใจว่าตรงตามเกณฑ์ที่จะออกการแจ้งเตือนหรือไม่

• กราฟและคุณสมบัติการจัดการที่เป็นมิตร เราจำเป็นต้องติดตาม SLA ของเราและรู้ว่าแอปพลิเคชัน 'ที่พร้อมใช้งานสูง' ของเราเพิ่มขึ้น 24x7 หรือไม่นั้นมีประโยชน์บ้างไหม วิธีที่ดีที่สุดที่โซลูชันของคุณเสนอควรรายงาน "ออกนอกกรอบ" ด้วยคำสั่งน้อยที่สุด

• ต้องมี API หรือระบบปลั๊กอินที่มั่นคงสำหรับการพัฒนาการตรวจสอบตามความต้องการ

• จำเป็นต้องมีเหตุผลเกี่ยวกับการแจ้งเตือน ฉันไม่ต้องการรู้อย่างแน่นอน (ผ่านทาง SMS เวลาตี 3!) ว่าโหนดการตรวจสอบหนึ่งรายการคิดว่าเราเตอร์หลักของฉันไม่ทำงาน ฉันไม่ต้องการที่จะทราบว่าร้อยละที่กำหนดของพวกเขาเห็นว่าสิ่งที่ขี้ขลาดที่เกิดขึ้น;) เป็นหลักสิ่งที่ผมพูดเกี่ยวกับที่นี่คือ "องค์ประชุม" ตรรกะหรือการใช้สติที่จะบ้ากระจาย!

ฉันยินดีที่จะพิจารณาตัวเลือกทั้งในเชิงพาณิชย์และโอเพนซอร์สแม้ว่าฉันต้องการหลีกเลี่ยงซอฟต์แวร์ที่มีราคาหลายล้านปอนด์ :-) ฉันก็ยินดีที่จะยอมรับว่าอาจไม่มีอะไรออกมาซึ่งทำเครื่องหมายในช่องเหล่านั้นทั้งหมด แต่ อยากถามกลุ่มที่

เมื่อคิดถึงการตรวจสอบโหนดและการวางตำแหน่งให้ระลึกไว้ว่าส่วนใหญ่จะเป็นเซิร์ฟเวอร์เฉพาะบนเครือข่าย ISP แบบสุ่มและส่วนใหญ่อยู่นอกขอบเขตการควบคุมของฉัน โซลูชันที่ใช้ฟีด BGP และการแสดงตลกเครือข่ายที่ซับซ้อนอื่น ๆ อาจไม่เหมาะสม

ฉันควรจะชี้ให้เห็นว่าฉันได้ทำการประเมินปรับใช้หรือใช้อย่างหนัก / ปรับแต่งส่วนใหญ่ของโอเพ่นซอร์สรสชาติในอดีตรวมถึง Nagios, Zabbix และเพื่อน ๆ - พวกเขาไม่ใช่เครื่องมือที่เลวร้ายจริงๆ กระจาย "ด้านโดยเฉพาะอย่างยิ่งเกี่ยวกับตรรกะที่กล่าวถึงในคำถามของฉันและ 'อัจฉริยะ' การแจ้งเตือน

ยินดีที่จะชี้แจงจุดที่ต้องการ ไชโยพวกและ gals :-)

ไม่ใช่คำตอบจริงๆ แต่ตัวชี้บางอย่าง:

• definitivly ดูที่นำเสนอเกี่ยวกับnagios @ Goldman Sachs พวกเขาประสบปัญหาที่คุณพูดถึง - ความซ้ำซ้อนความสามารถในการปรับขยาย: โฮสต์นับพันและการสร้างการกำหนดค่าอัตโนมัติ

• ฉันมีการตั้งค่า nagios ซ้ำซ้อน แต่มีขนาดเล็กกว่า - เซิร์ฟเวอร์ 80 เครื่อง ~ บริการทั้งหมด 1k เซิร์ฟเวอร์หลักหนึ่งตัวโดยเฉพาะหนึ่งเซิร์ฟเวอร์ทาสจะดึงการกำหนดค่าจากต้นแบบในช่วงเวลาปกติสองสามครั้งต่อวัน เซิร์ฟเวอร์ทั้งสองครอบคลุมการตรวจสอบเครื่องเดียวกันพวกเขามีการตรวจสอบข้ามสุขภาพระหว่างกัน ฉันใช้ nagios ส่วนใหญ่เป็นกรอบสำหรับการเรียกใช้การตรวจสอบเฉพาะผลิตภัณฑ์ที่กำหนดเอง [กลุ่มงาน cron ที่เรียกใช้สคริปต์ที่ทำ 'การควบคุมโฟลว์เทียม' เครื่องผลลัพธ์จะบันทึกลงใน sql, การตรวจสอบปลั๊กอินปลั๊กอินของ nrpe ทุกอย่างทำงานได้ดีมาก

• ตรรกะควอรัมของคุณฟังดูดี - คล้ายกับ 'โฟลวเทียม' ของฉัน - โดยทั่วไปแล้วไปทำ ipmplement ด้วยตัวคุณเอง -] และให้ nrpe ตรวจสอบการตั้งค่าสถานะบางอย่าง [หรือ sql db ที่มีการประทับเวลาสถานะ] วิธีการทำงาน

• คุณอาจต้องการสร้างลำดับชั้นเพื่อปรับขนาด - คุณมีบางโหนดที่รวบรวมภาพรวมของโหนดอื่น ๆ ดูที่การนำเสนอจากจุดแรก nagios ที่เป็นค่าเริ่มต้นสำหรับการตรวจสอบทุกครั้งจะมีค่าใช้จ่ายเกินจำนวนของบริการที่ได้รับการตรวจสอบ

เพื่อตอบคำถาม:

• ในสภาพแวดล้อมเคสของฉันถูกตรวจสอบคือการตั้งค่า master-slave ทั่วไป [sql หลักหรือเซิร์ฟเวอร์แอพ + สแตนด์บายร้อน], ไม่มี master-master
• การตั้งค่าของฉันเกี่ยวข้องกับ 'ปัจจัยการกรองของมนุษย์' - กลุ่มผู้แก้ไขซึ่งเป็น 'สำรอง' สำหรับการแจ้งเตือนทาง SMS มีกลุ่มช่างเทคนิคที่จ่ายเงินไปแล้วด้วยเหตุผลอื่นที่มีการเปลี่ยนแปลง 24/5 กะทันหันพวกเขาได้รับ 'การตรวจสอบอีเมล nagios' เนื่องจากงานเพิ่มเติมไม่ทำให้ภาระงานหนักเกินไป และพวกเขาจะรับผิดชอบในการทำให้แน่ใจว่า db-admins / it-ops / app-admins ware ได้รับการแก้ไขและแก้ไขปัญหาจริง ๆ - -]
• ฉันเคยได้ยินสิ่งที่ดีมากมายเกี่ยวกับzabbix - สำหรับการแจ้งเตือนและการวางแผนแนวโน้ม แต่ไม่เคยใช้ สำหรับฉันแล้วmuninทำเคล็ดลับฉันได้แฮ็กปลั๊กอิน nagios ง่าย ๆ ในการตรวจสอบว่ามีสี 'สีแดงใด ๆ ' ที่สำคัญ 'ในรายการเซิร์ฟเวอร์ของ munin - เพียงแค่การตรวจสอบเพิ่มเติม คุณสามารถอ่านค่าจากไฟล์ munin rrd เพื่อลดจำนวนข้อความค้นหาที่คุณส่งไปยังเครื่องที่ตรวจสอบได้

สิ่งที่คุณถามหาฟังดูเหมือนกับสิ่งที่ Shinken ทำเพื่อ Nagios

Shinken เป็น Nagios rewrite

• ภาษาสมัยใหม่ (Python)
• กรอบการเขียนโปรแกรมสมัยใหม่กระจาย (Pyro)
• การตรวจสอบขอบเขต (หลายการครอบครอง), HA, อะไหล่
• Livestatus API
• ปลั๊กอิน Nagios เข้ากันได้
• การประมวลผล NRPE แบบเนทีฟ
• ความสำคัญทางธุรกิจของวัตถุ
• กฎธุรกิจสามารถนำไปใช้กับสถานะของวัตถุ (การจัดการความพร้อมของคลัสเตอร์หรือพูล)
• การสร้างกราฟสามารถใช้ Graphite หรือ RRDtool ตาม PNP4nagios
• มีความเสถียรและปรับใช้ในสภาพแวดล้อมขนาดใหญ่
• การปรับใช้ขนาดใหญ่สามารถพิจารณาการจับคู่กับ Splunk สำหรับการรายงานหรือดูใน Graphite โดยที่ RRDtool ไม่เหมาะ

นี่ควรเป็นอาหารสำหรับความคิด

ไชโย