Funktionsprinzip der Java ES-Überwachung

Unter Überwachung versteht man den Prozess des Erfassens von Laufzeitdaten, Zugänglichmachens dieser Daten und anschließendem Berechnen von Servicekriterien, sodass Systemadministratoren die Leistung bewerten und im Alarmfall entsprechend benachrichtigt werden können. Während des Betriebs müssen Administratoren nur mit der Monitoring Console interagieren, um Leistungsstatistiken anzuzeigen, Regeln zur automatischen Überwachung zu erstellen und Alarme zu quittieren. Für die Konfiguration, Fehlerbehebung und fortgeschrittene Überwachung ist das Verständnis des Aufbaus des Monitoring Framework und seiner Kommunikation mit der Monitoring Console jedoch von großem Vorteil.

Die Überwachung in Java ES beruht auf den folgenden Prinzipien:

• Das Common Monitoring Model (CMM) gewährleistet, dass alle Java ES-Komponenten für die Überwachung gleichartige Objekte und Werte vergleichbarer Attribute zur Verfügung stellen.

• Von den CMM-Schnittstellen definierte Java-Objekte bieten standardisierte Instrumentierungen für Produktkomponenten.

• Knotenagenten machen alle überwachten Objekte für alle auf einem System installierten Komponenten zugänglich und verwalten die Statistik, Regeln und Alarme für diese Objekte.

• Ein auf einem eigenen Host-Rechner installierter Master-Agent sammelt die Daten aller überwachten Objekte von den Knotenagenten und leitet diese Daten an die Monitoring Console weiter.

In den folgenden Abschnitten werden die einzelnen Konzepte der Überwachungsarchitektur ausführlicher erläutert.

Das Common Monitoring Model (CMM)

Die Grundlage eines standardisierten Überwachungsmechanismus bildet die Definition, welche Objekte überwacht werden sollen und die Übernahme dieser Objekte für alle überwachten Komponenten. Zu diesem Zweck definiert die Überwachungsarchitektur das Common Monitoring Model (CMM) als Erweiterung des Common Information Model (CIM), das von der Distributed Management Task Force (DMTF) unterhalten wird. CMM ist ein Informationsmodell, das überwachte Objekte wie z. B. Computer, Anwendungen usw. sowie ein Datenmodell für gleichartige Werte wie z. B. Betriebsstatuswerte definiert. Im Rahmen des Informationsmodells definiert CMM darüber hinaus die Attribute eines Objekts, z. B. die von einem Dienst zu bearbeitenden Anforderungen, sowie die Beziehungen zwischen Objekten wie z. B. die Tatsache, dass ein Dienst auf einem bestimmten Computer installiert ist.

Dank des CMM sind Konzepte wie z. B: Anwendungen, Dienste, Zugriffspunkte usw. für alle Produktkomponenten gleich, auch wenn die zugrunde liegende Implementierung unterschiedlich ist. So kann Web Server beispielsweise einen Dienst zur Behandlung von HTTP-Anforderungen zugänglich machen, während Directory Server einen Dienst zur Behandlung von LDAP-Anforderungen bietet. Ein diesem Standard entsprechendes Objekt erfasst jedoch nur das Gemeinsame dieser Funktionen, so z. B. die Anzahl der behandelten Anforderungen oder die Zeit, die innerhalb eines bestimmten Zeitraums im Durchschnitt zur Behandlung einer Anforderung notwendig ist usw.

Darüber hinaus sind einige Datenwerte standardisiert, sodass ihre Bedeutung im gesamten System gleichartig ist. Der Betriebssstatus DEGRADED bedeutet beispielsweise stets, dass ein Dienst zwar noch verfügbar, seine Leistung jedoch beträchtlich abgefallen ist. Dabei spielt es keine Rolle, welche Produktkomponente überwacht wird.

Die CMM-Spezifikation ist in die für die Instrumentierung verwendeten Java-Schnittstellen und Klassen integriert. Diese sind in Anhang A, CMM-Objektreferenz, beschrieben.

CMM-Instrumentierung

Im Monitoring Framework, wird die Instrumentierung von bestimmten Java-Schnittstellen und -Klassen bereitgestellt, die die CMM-Definitionen implementieren. Für die neue Überwachungsfunktionalität von Java ES wurde der Code von Produktkomponenten entsprechend instrumentiert, damit Instanzen von CMM-Objekten erstellt und Laufzeitwerte über die Attribute überwachter Objekte zugänglich gemacht werden können . Die von jeder Komponente implementierten CMM-Objekte legen fest, was überwacht werden kann. Deswegen ist die Anzahl der für die Überwachung zugänglichen Attribute je nach Komponente unterschiedlich. Die Liste der Objekte und Attribute, die von jeder Produktkomponente zugänglich gemacht werden, finden Sie in Anhang B, Objekte, die bei jeder Komponente zur Überwachung vorgesehen sind.

Knotenagenten

In der Begriffswelt der Überwachung versteht man unter einem Knoten einen einzelnen logischen Host, der durch einen vollständigen Domänennamen bzw. eine IP-Adresse eindeutig identifiziert werden kann. Ein Knoten kann entweder ein gesamtes System oder eine als virtuelles System konfigurierte Solaris Zone sein. Der Knotenagent kommuniziert mit allen instrumentierten Komponenten auf diesem Host und macht alle ihre überwachten Objekte zugänglich. Darüber hinaus verwalten Knotenagenten die gesamte Logik zum Erfassen von Leistungsdaten, überwachen in Regeln definierte Schwellenwerte und generieren Alarme für die in ihnen enthaltenen überwachten Objekte.

Das folgende Schema veranschaulicht den Inhalt eines Knotenagenten auf einem einzelnen Host mit Instanzen von drei Java ES-Produktkomponenten. Es zeigt außerdem, wie die Instrumentierung im Knotenagenten instanziiert wird, um die von den Produktkomponenten bereitgestellten Werte für die Überwachung zugänglich zu machen.

Abbildung 1–1 Schematische Darstellung eines Knotenagenten

Ein Knotenagent ist als Modul implementiert, das in den Common Agent Container (der eine Java Virtual Machine darstellt) geladen wird . Die Implementierung von Knotenagenten beruht auf den Java Management Extensions (JMX), des Java-Standarderweiterungspakets für die Überwachung und Fernverwaltung. Alle JMX-fähigen und CMM-kompatiblen Überwachungsanwendungen können auf die überwachten Objekte im Knotenagent zugreifen. Mithilfe der JMX-Funktionalität kann der Knotenagent darüber hinaus über das Simple Network Monitoring Protocol (SNMP) bestimmte überwachte Objekte zugänglich machen.

Der Master-Agent

Der Master-Agent wird als Teil der Monitoring Console-Installation auf einem eigenen Rechner bereitgestellt. Der Master-Agent wird mit dem Namen und der Adresse aller Knoten konfiguriert, sodass die überwachten Objekte von allen Knotenagenten zusammengefasst werden können. Der Master-Agent ist ebenfalls JMX-basiert und nutzt JMX zur Kommunikation mit den Knotenagenten. Er befindet sich in seinem lokalen Common Agent Container.

Die folgende Abbildung zeigt einen mit zwei Knoten verbundenen Master-Agenten. Die Monitoring Console stellt zum Überwachen der drei Komponenten auf jedem Knoten zum Master-Agent eine Verbindung her. Wenn Sie zur Überwachung SNMP verwenden möchten, müssen Sie zu jedem einzelnen Knoten getrennt eine Verbindung herstellen, da der Master-Agent keine SNMP-Attribute zusammenfasst. Der Master-Agent ist nur zur Verwendung mit der Monitoring Console gedacht und für andere Überwachungsanwendungen nicht zugänglich.

Abbildung 1–2 Schematische Darstellung der gesamten Überwachungsarchitektur