ตรวจสอบแอปพลิเคชัน C ++

เรากำลังใช้โซลูชันการติดตามแบบรวมศูนย์ใหม่ (Zenoss) การรวมเซิร์ฟเวอร์ระบบเครือข่ายและโปรแกรม Java นั้นตรงไปตรงมากับ SNMP และ JMX

อย่างไรก็ตามคำถามคือวิธีปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบและจัดการแอปพลิเคชัน C ++ แบบกำหนดเองในสภาพแวดล้อมขนาดใหญ่ที่ต่างกัน (Solaris x86, RHEL Linux, Windows) คืออะไร

ความเป็นไปได้ที่ฉันเห็นคือ:

1. Net SNMP

• ข้อดี

1. single daemon ส่วนกลางบนแต่ละเซิร์ฟเวอร์
2. มาตรฐานที่รู้จักกันดี
3. รวมเข้ากับโซลูชันการตรวจสอบได้ง่าย
4. เรารัน Net SNMP daemons บนเซิร์ฟเวอร์ของเราแล้ว

1. การใช้งานที่ซับซ้อน (MIBs, ไลบรารี Net SNMP)
2. เทคโนโลยีใหม่ที่จะแนะนำสำหรับนักพัฒนา C ++

• ข้อดี

1. single daemon ส่วนกลางบนแต่ละเซิร์ฟเวอร์
2. มาตรฐานที่รู้จักกันดี
3. การรวมที่ไม่รู้จักในโซลูชันการตรวจสอบ (ฉันรู้ว่าพวกเขาสามารถทำการแจ้งเตือนตามข้อความ แต่มันทำงานได้ดีเพียงใดในการส่ง telemetry เช่นการใช้หน่วยความจำความลึกคิวความจุเธรด ฯลฯ )
4. ใช้งานง่าย

1. ปัญหาการรวมที่เป็นไปได้
2. เทคโนโลยีใหม่สำหรับนักพัฒนา C ++
3. ปัญหาการย้ายที่เป็นไปได้ถ้าเราสลับผู้ขายที่ตรวจสอบ
4. อาจเกี่ยวข้องกับการเกิดขึ้นกับโปรโตคอลการสื่อสารแบบเฉพาะกิจ (หรือใช้ข้อมูลที่มีโครงสร้าง RFC5424; ฉันไม่ทราบว่า Zenoss สนับสนุนสิ่งนั้นโดยไม่ต้องเข้ารหัส Zenpack แบบกำหนดเอง)

• ข้อดี

1. อินเตอร์เฟสการจัดการที่สอดคล้องกันสำหรับทั้ง Java และ C ++
2. มาตรฐานที่รู้จักกันดี
3. รวมเข้ากับโซลูชันการตรวจสอบได้ง่าย
4. การใช้งานค่อนข้างง่าย (เราได้ทำไปแล้วในวันนี้เพื่อวัตถุประสงค์อื่น)

1. ความซับซ้อน (JNI, thunking layer ระหว่าง native C ++ และ Java, โดยทั่วไปเขียนโค้ดการจัดการสองครั้ง)
2. ปัญหาเสถียรภาพที่เป็นไปได้
3. ต้องใช้ JVM ในแต่ละกระบวนการโดยใช้หน่วยความจำมากขึ้น
4. JMX เป็นเทคโนโลยีใหม่สำหรับนักพัฒนา C ++
5. แต่ละกระบวนการมีพอร์ต JMX ของตัวเอง (เราเรียกใช้กระบวนการจำนวนมากในแต่ละเครื่อง)

• ข้อดี

1. single daemon ส่วนกลางบนแต่ละเซิร์ฟเวอร์
2. อินเตอร์เฟสการจัดการที่สอดคล้องกันสำหรับทั้ง Java และ C ++
3. มาตรฐานที่รู้จักกันดี
4. รวมเข้ากับโซลูชันการตรวจสอบได้ง่าย

1. ความซับซ้อน (โดยทั่วไปการเขียนรหัสการจัดการสองครั้ง)
2. จำเป็นต้องค้นหาหรือเขียน daemon ดังกล่าว
3. ต้องการโปรโตคอลระหว่าง JMX daemon และกระบวนการ C ++
4. JMX เป็นเทคโนโลยีใหม่สำหรับนักพัฒนา C ++

• ข้อดี

1. อินเตอร์เฟสการจัดการที่สอดคล้องกันสำหรับทั้ง Java และ C ++
2. มาตรฐานที่รู้จักกันดี
3. รวมเข้ากับโซลูชันการตรวจสอบได้ง่าย
4. single daemon ส่วนกลางบนแต่ละเซิร์ฟเวอร์เมื่อรันในโหมด JVM ที่แบ่งใช้
5. การติดตั้งค่อนข้างง่าย (ต้องมีการสร้างรหัส)

1. ความซับซ้อน (การสร้างรหัสต้องใช้ GUI และการปรับแต่งหลายรอบเพื่อสร้างรหัสพร็อกซี)
2. ปัญหาความมั่นคงของ JNI ที่เป็นไปได้
3. ต้องใช้ JVM ในแต่ละกระบวนการโดยใช้หน่วยความจำมากขึ้น (ในโหมดฝังตัว)
4. ไม่รองรับ Solaris x86 (ดีลเบรกเกอร์)
5. แม้ว่าจะรองรับ Solaris x86 แต่ก็มีปัญหาความเข้ากันได้ของคอมไพเลอร์ (เราใช้ STLPort และ Forte บน Solaris ร่วมกัน
6. แต่ละกระบวนการมีพอร์ต JMX ของตัวเองเมื่อทำงานในโหมดฝังตัว (เราเรียกใช้กระบวนการจำนวนมากในแต่ละเครื่อง)
7. อาจทำให้เซิร์ฟเวอร์ JMX ที่ใช้ร่วมกันสำหรับกระบวนการที่ไม่ใช่ C ++ (?)

มีวิธีง่ายๆที่ฉันได้มาตรฐานหรือเปล่า?

ไม่มีโซลูชันที่สมเหตุสมผลอื่น ๆ โดยทั่วไปโซลูชันเหล่านี้จะใช้สำหรับโปรแกรม C ++ แบบกำหนดเองหรือไม่

ความรู้สึกของฉันคือ Net SNMP เป็นวิธีที่ผู้คนทำสิ่งนี้ แต่ฉันต้องการความคิดเห็นและประสบการณ์ของผู้อื่นก่อนที่จะตัดสินใจ

ฉันไม่คุ้นเคยกับ Zenoss มากนัก แต่เมื่อฉันเคยใช้nagiosสำหรับสิ่งนี้เราจะทำให้กระบวนการ c / c ++ ฟังบนซ็อกเก็ตและเขียนปลั๊กอิน nagios ที่กำหนดเองซึ่งจะมอบข้อมูลการวินิจฉัยและสถานะ

ขั้นแรกคือการเลือก lib ที่คุณต้องการใช้เพื่อทำให้กระบวนการของคุณฟัง .. บางสิ่งเช่นC ++ Socket Libraryจะทำเช่นนั้น ไม่มีอะไรซับซ้อนที่นั่น .. แค่ทำให้กระบวนการฟัง

จากนั้นคุณต้องกำหนดคำตอบที่กระบวนการของคุณจะส่งให้เป็นสิ่งกระตุ้น นี่หมายถึงจริงๆ (อย่างน้อยกับ nagios) กำหนด 'บริการ' แล้วส่งสัญญาณที่สอดคล้องกับบริการนั้น สิ่งที่ง่ายที่สุดที่คุณสามารถทำได้คือสร้าง 'ping กระบวนการ' เพียงแค่ดูว่าคุณสามารถเชื่อมต่อกับกระบวนการทำงาน หากคุณทำมากกว่าปลั๊กอิน nagios ที่กำหนดเองอย่างน้อยก็รู้ว่ากระบวนการยังมีชีวิตอยู่

มีสิ่งที่ซับซ้อนกว่าที่คุณสามารถทำได้ แต่ความคิดนั้นง่ายพอ คุณสามารถเขียนรหัสการฟังกระบวนการเล็ก ๆ น้อย ๆ ของคุณเองที่ห่อหุ้มอยู่ภายในวัตถุและดึงมันเข้าไปในสิ่ง c ++ ที่กำหนดเองของคุณในลักษณะที่เป็นมาตรฐานเมื่อใดก็ตามที่คุณสร้างหนึ่ง (หรือทั้งหมด) executables ของคุณ

ความเข้าใจของฉันคือ Zenoss ก็สามารถทำได้เช่นกัน

อาจเป็นเพราะ Zenoss เป็นงูหลามแล้วคุณจะเขียนปลั๊กอินที่คุณกำหนดเองโดยใช้สิ่งที่คล้ายกับTwistedสำหรับเชื่อมต่อกับ c ++ executable

ฉันไม่คุ้นเคยกับผลิตภัณฑ์เหล่านี้ที่คุณตั้งชื่อ แต่สำหรับ windows i ตรวจสอบปริมาณการใช้หน่วยความจำโดยใช้ perfmon มีเคาน์เตอร์พิเศษบางอย่างเช่นข้อบกพร่องที่ไม่สามารถทำเพจได้ซึ่งแสดงให้คุณเห็นว่าโปรแกรมของคุณมีการรั่วไหลของหน่วยความจำ เวลาในการตรวจสอบ แต่ในความเห็นของฉันนี่เป็นวิธีการตรวจสอบที่ง่าย

บน windows คุณสามารถทำได้หลายอย่างโดยใช้ perfmon แม้จะอยู่ในระยะไกลหรือใช้ WMI เพื่อเชื่อมต่อกับเคาน์เตอร์เดียวกันและดำเนินการอัตโนมัติบางอย่างกับมัน (เป็น wmi) เพื่อดำเนินการ

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

SNMP มาใกล้ที่สุด แต่การรวมเข้ากับแหล่งที่มาและระบบการตรวจสอบเป็นความเจ็บปวดและไม่เหมาะสำหรับกระบวนการแบบเรียลไทม์ของเรา

ในที่สุดเราตัดสินใจที่จะพัฒนาโซลูชั่นใหม่ที่เรียกว่าCMXซึ่งใช้เทคโนโลยีหน่วยความจำที่ใช้ร่วมกันและทำให้มันเป็นโอเพ่นซอร์ส คุณสามารถตรวจสอบได้ที่นี่: www.cern.ch/cmx

ผมไม่คุ้นเคยกับซุปเปอร์ค ++ ด้านข้างของสิ่ง แต่ในชวาเราอย่างกว้างขวางใช้CodaHaleตัวชี้วัดร่วมกับกราไฟท์ CodaHale จัดเก็บการวัดตามแต่ละอินสแตนซ์ในหน่วยความจำภายในของอินสแตนซ์จากนั้นใช้เธรดพื้นหลังเพื่อล้างการวัดไปยังเซิร์ฟเวอร์ไฟท์ทุกนาที (กำหนดค่าได้) ในกราไฟท์เราสามารถรวมข้ามอินสแตนซ์รวมทั้งระบุอินสแตนซ์ที่ผิดพลาดได้ หากคุณไม่ต้องการที่ซับซ้อนของการรักษาไฟท์คลัสเตอร์คุณสามารถใช้ที่HostedGraphite

การตั้งค่านี้หมายถึงไม่มีความล้มเหลวในจุดเดียวสำหรับการรวมตัวชี้วัดหรือการรายงานว่า (การรวมตามเวลาเกิดขึ้นบนโหนดเองและการรวมการรายงานข้ามเกิดขึ้นในคลัสเตอร์ไฟท์แบบกระจาย (หรือกราไฟท์ที่โฮสต์)

สุดท้ายคุณสามารถใช้Seyrenเพื่อให้การแจ้งเตือนด้านบนของข้อมูลการตรวจสอบ

หากคุณใช้ Windows คุณมักจะเขียนลงในบันทึกเหตุการณ์จากนั้นใช้ WMI หรือกระบวนการที่คล้ายกันเพื่ออ่านเหตุการณ์ หากคุณต้องการการตรวจสอบคุณเพิ่มเคาน์เตอร์การตรวจสอบประสิทธิภาพให้กับแอพของคุณและให้ perfmon อ่าน ทั้งคู่เป็นบริการระบบใน Windows

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

ทุกคนพูดว่าฉันเคยเห็นหลายแห่งที่ใช้SMNPและตรงไปตรงมาฉันไม่เห็นเหตุผลที่คุณจะไม่ใช้มันโดยเฉพาะถ้าคุณใช้สภาพแวดล้อมที่แตกต่างกันโดยสิ้นเชิง