Überwachen von C ++ - Anwendungen

Wir implementieren eine neue zentralisierte Überwachungslösung (Zenoss). Das Einbinden von Servern, Netzwerken und Java-Programmen ist mit SNMP und JMX unkompliziert.

Die Frage ist jedoch, welche Best Practices für die Überwachung und Verwaltung benutzerdefinierter C ++ - Anwendungen in großen, heterogenen Umgebungen (Solaris x86, RHEL Linux, Windows) gelten.

Möglichkeiten, die ich sehe, sind:

1. Net SNMP

• Vorteile

1. einzelner zentraler Daemon auf jedem Server
2. bekannter Standard
3. einfache Integration in Überwachungslösungen
4. Wir führen bereits Net SNMP-Daemons auf unseren Servern aus

Nachteile:

1. komplexe Implementierung (MIBs, Net SNMP-Bibliothek)
2. Neue Technologie für die C ++ - Entwickler

rsyslog

• Vorteile

1. einzelner zentraler Daemon auf jedem Server
2. bekannter Standard
3. Unbekannte Integration in Überwachungslösungen (Ich weiß, dass sie Warnungen basierend auf Text ausführen können, aber wie gut würde es für das Senden von Telemetrie wie Speichernutzung, Warteschlangentiefe, Thread-Kapazität usw. funktionieren?)
4. einfache Implementierung

Nachteile:

1. mögliche Integrationsprobleme
2. etwas neue Technologie für C ++ - Entwickler
3. Mögliche Portierungsprobleme, wenn wir den Überwachungsanbieter wechseln
4. Wahrscheinlich müssen Sie ein Ad-hoc-Kommunikationsprotokoll erstellen (oder strukturierte RFC5424-Daten verwenden; ich weiß nicht, ob Zenoss dies ohne benutzerdefinierte Zenpack-Codierung unterstützt).

Eingebettetes JMX (JVM einbetten und JNI verwenden)

• Vorteile

1. konsistente Verwaltungsoberfläche für Java und C ++
2. bekannter Standard
3. einfache Integration in Überwachungslösungen
4. etwas einfache Implementierung (wir tun dies bereits heute für andere Zwecke)

Nachteile:

1. Komplexität (JNI, Thunking-Schicht zwischen nativem C ++ und Java, grundsätzlich zweimaliges Schreiben des Verwaltungscodes)
2. mögliche Stabilitätsprobleme
3. erfordert in jedem Prozess eine JVM, die erheblich mehr Speicher benötigt
4. JMX ist eine neue Technologie für C ++ - Entwickler
5. Jeder Prozess hat einen eigenen JMX-Port (wir führen viele Prozesse auf jedem Computer aus).

Lokaler JMX-Daemon, Prozesse stellen eine Verbindung her

• Vorteile

1. einzelner zentraler Daemon auf jedem Server
2. konsistente Verwaltungsoberfläche für Java und C ++
3. bekannter Standard
4. einfache Integration in Überwachungslösungen

Nachteile:

1. Komplexität (im Grunde zweimal den Management-Code schreiben)
2. müssen einen solchen Daemon finden oder schreiben
3. benötigen ein Protokoll zwischen dem JMX-Daemon und dem C ++ - Prozess
4. JMX ist eine neue Technologie für C ++ - Entwickler

CodeMesh JunC ++ ion

• Vorteile

1. konsistente Verwaltungsoberfläche für Java und C ++
2. bekannter Standard
3. einfache Integration in Überwachungslösungen
4. einzelner zentraler Daemon auf jedem Server, wenn er im gemeinsam genutzten JVM-Modus ausgeführt wird
5. etwas einfache Implementierung (erfordert Codegenerierung)

Nachteile:

1. Komplexität (Codegenerierung, erfordert eine grafische Benutzeroberfläche und mehrere Optimierungsrunden, um den Proxy-Code zu erstellen)
2. mögliche JNI-Stabilitätsprobleme
3. erfordert in jedem Prozess eine JVM, die erheblich mehr Speicher benötigt (im eingebetteten Modus)
4. Unterstützt Solaris x86 (Deal Breaker) nicht
5. Selbst wenn Solaris x86 unterstützt wurde, gibt es mögliche Compilerkompatibilitätsprobleme (wir verwenden eine ungerade Kombination aus STLPort und Forte unter Solaris
6. Jeder Prozess hat einen eigenen JMX-Port, wenn er im eingebetteten Modus ausgeführt wird (wir führen viele Prozesse auf jedem Computer aus).
7. schließt möglicherweise einen gemeinsam genutzten JMX-Server für Nicht-C ++ - Prozesse aus (?)

Gibt es eine einigermaßen standardisierte, einfache Lösung, die mir fehlt?

Welche dieser Lösungen wird normalerweise für benutzerdefinierte C ++ - Programme verwendet, da keine anderen vernünftigen Lösungen vorhanden sind?

Mein Bauchgefühl ist, dass Net SNMP so ist, wie die Leute dies tun, aber ich möchte den Input und die Erfahrung anderer, bevor ich eine Entscheidung treffe.

Ich bin mit Zenoss nicht besonders vertraut, aber wenn ich Nagios für solche Dinge verwendet habe, haben wir den c / c ++ - Prozess dazu gebracht, einen Socket abzuhören und ein benutzerdefiniertes Nagios-Plugin zu schreiben, das Diagnose- und Statusinformationen weitergibt .

Der erste Schritt besteht darin, die Bibliothek auszuwählen, die Sie verwenden möchten, damit Ihr Prozess abhört. Etwas wie die C ++ - Socket-Bibliothek reicht dafür aus. Da ist nichts kompliziertes. Lass den Prozess einfach zuhören.

Dann müssen Sie die Antwort definieren, die Ihr Prozess bei einem bestimmten Stimulus sendet. Dies bedeutete wirklich (zumindest bei Nagios), den "Dienst" zu definieren und dem Prozess dann das Signal zu senden, das diesem Dienst entsprach. Am einfachsten können Sie einen "Prozess-Ping" erstellen, um festzustellen, ob Sie erfolgreich eine Verbindung zum laufenden Prozess herstellen können. Wenn Sie dies tun, weiß das benutzerdefinierte Nagios-Plugin zumindest, dass der Prozess noch am Leben ist.

Es gibt viel anspruchsvollere Dinge, die Sie tun können, aber die Idee ist einfach genug. Sie können Ihre eigene kleine Bibliothek von Prozess-Listening-Code schreiben, der in Objekten gekapselt ist, und ihn auf standardisierte Weise in Ihre benutzerdefinierten C ++ - Inhalte ziehen, wenn Sie eine (oder alle) Ihrer ausführbaren Dateien erstellen

Mein Verständnis ist, dass Zenoss dies auch kann .

Da Zenoss Python ist, schreiben Sie wahrscheinlich Ihr benutzerdefiniertes Plugin dafür, indem Sie Twisted verwenden, um eine Verbindung zu Ihrer ausführbaren C ++ - Datei herzustellen.

Ich bin nicht mit diesen Produkten vertraut, die Sie benennen, aber für Windows, das ich den Speicherverbrauch mithilfe von Perfmon überwache, gibt es einige spezielle Leistungsindikatoren, wie z. B. nicht ausgelagerte Poolfehler, die Ihnen anzeigen, ob Ihr Programm Speicherlecks enthält, diese möglicherweise gering sind und daher lange dauern Zeit zu überwachen, aber meiner Meinung nach ist dies eine einfache Überprüfungsmethode.

Unter Windows können Sie mit perfmon viel tun, auch aus der Ferne. Oder Sie können WMI verwenden, um eine Verbindung zu denselben Zählern herzustellen, und eine gewisse Automatisierung (in wmi) durchführen, um Aktionen auszuführen.

Ich greife dies auf, als wir kürzlich denselben Prozess wie Sie durchlaufen haben: Wir suchten nach einer leichten, nicht blockierenden Open-Source-Lösung, mit der Metriken innerhalb von C / C ++ - Diensten verfügbar gemacht und anschließend fernüberwacht werden können ( wir haben ungefähr ~ 3000).

SNMP kam am nächsten, aber die Integration in die Quelle und das Überwachungssystem ist mühsam und nicht für unsere Echtzeitprozesse geeignet.

Am Ende haben wir uns entschlossen, eine neue Lösung namens CMX zu entwickeln, die Shared Memory-Technologie verwendet und Open Source macht. Sie können es hier überprüfen: www.cern.ch/cmx .

Ich bin nicht besonders vertraut mit der C ++ - Seite, aber in Java verwenden wir häufig CodaHale- Metriken in Verbindung mit Graphite . CodaHale speichert Metriken pro Instanz im lokalen Speicher der Instanz und verwendet dann einen Hintergrund-Thread, um Metriken jede Minute auf einen Graphitserver zu übertragen (konfigurierbar). In Graphit können wir instanzübergreifend aggregieren und fehlerhafte Instanzen identifizieren. Wenn Sie die Komplexität der Wartung eines Graphitclusters nicht möchten, können Sie HostedGraphite verwenden .

Dieses Setup bedeutet keinen einzelnen Fehlerpunkt für die Metrikaggregation oder Berichterstellung, da (die zeitbasierte Aggregation erfolgt auf den Knoten selbst und die Berichtsaggregation über einen verteilten Graphitcluster (oder gehosteten Graphit).

Zuletzt können Sie Seyren verwenden , um zusätzlich zu den Überwachungsdaten Warnungen bereitzustellen.

Wenn Sie unter Windows arbeiten, schreiben Sie in der Regel in das Ereignisprotokoll und verwenden dann eine WMI oder einen ähnlichen Prozess, um die Ereignisse zu lesen. Wenn Sie eine Überwachung wünschen, fügen Sie Ihrer App Leistungsüberwachungszähler hinzu und lassen diese von perfmon lesen. Beide sind Systemdienste in Windows.

Unter Linux ist es offensichtlich flexibler, aber ich habe immer Monitore im Nagios-Stil implementiert gesehen, bei denen ein benutzerdefinierter Socket Daten an einen Server im Nagios-Stil sendet.

Trotzdem habe ich mehrere Orte gesehen, an denen SMNP verwendet wird, und ehrlich gesagt kann ich keinen Grund erkennen, warum Sie es nicht verwenden würden - insbesondere, wenn Sie eine vollständig heterogene Umgebung verwenden.