Hardwareüberwachung mit BMC PATROL Teil II:

... und es geht auch ohne Agent

Im zweiten Teil der Hardwareüberwachung gehen wir besonders auf die Möglichkeit der Überwachung von Hardware-Komponenten ein, auf denen per se kein PATROL Agent installiert werden kann. Solche Komponenten sind normalerweise mit Standard-PATROL-Methoden nicht zu überwachen. Die Abfrage von Variableninhalten mittels SNMP bietet hierbei eine interessante Alternative.

Überblick

Komplexe IT-Landschaften verlangen eigentlich zwingend ein entsprechendes Monitoring, um die gewünschte Verfügbarkeit zu garantieren. Nun gut, Sie, als verantwortlicher Administrator, haben bereits mit PATROL ein ausgefeiltes System-Monitoring implementiert und können (die meisten) Probleme rechtzeitig erkennen und abfangen. Was tun Sie aber, wenn z. B. schlicht der Strom ausfällt? Unerwartet aber nicht unvorhersehbar.

Dazu werden in den meisten Firmen mehr oder weniger stark Finanzmittel in eine unterbrechungsfreie Stromversorgung (USV) investiert. Aber woher wissen Sie, ob diese überhaupt funktioniert? Wie und wie oft überprüfen Sie deren Funktion tatsächlich? Schalten Sie etwa stündlich den Strom ab, um zu überprüfen ob die USV funktioniert? Sicher nicht - und unsinnig wäre es außerdem.

Wir wollen Ihnen hier eine Methode vorstellen, mit der dieses Problem mit PATROL einfacher zu lösen ist. An dieser Stelle möchten wir erwähnen, dass Administratoren, die bereits ein Netzwerkmanagement betreiben und mit Werkzeugen wie z. B. HP OpenView Network Node Manager oder IBM Netview arbeiten, im Folgenden prinzipiell nicht mehr viel Neues erfahren. Es sei denn, sie sind dennoch an einer (zusätzlichen) SNMP-Überwachung durch PATROL oder einer speziellen Integration in PATROL interessiert.

Im ersten Teil dieser Serie wurde Ihnen eine Individualprogrammierung eines Knowledge Moduls (KMs) zur Hardwareüberwachung vorgestellt. Dazu musste ein Programm ausgewählt werden, das in der Lage ist, entsprechende Hardwareinformationen zu generieren. Mittels eines individuell programmierten KMs werden die Ergebnisse des Abfrageprogramms ausgewertet und interpretiert. Für SNMP-fähige Hardware-Devices gibt es die Möglichkeit, sich ein KM mittels des Programms „mib2km.exe" (NT) bzw. „mib2km" (Unix-Binary) mit Hilfe eines Wizards auf einfache Weise selbst zu erstellen.

SNMP Integration in PATROL

Das Monitoring von Objekt-Informationen, die via SNMP erhalten werden, ist dabei nicht neu. Im Gegenteil, viele Tools können SNMP Informationen bearbeiten und der PATROL-Agent beinhaltet schon seit jeher einen SNMP-Subagenten.

Dabei basiert das von PATROL verwendete SNMP auf dem Industrie-Standard SMUX. Die Kommunikation erfolgt über einen TCP SMUX Port (Default: TCP 199). Das Zusammenspiel der PATROL SNMP-Komponenten sehen Sie in Abb. 1.

Abb. 1: Zusammenspiel der PATROL SNMP-Komponenten.

Jeder PATROL-Agent wird zusammen mit einem SNMP-Master-Agenten und einem SNMP-Sub-Agenten installiert. Der Master-Agent kann mit
den SNMP-Sub-Agenten kommunizieren. Der Master-Agent ist die zentrale Verteilstelle für GET- und SET-Operationen an andere Sub-Agenten. Standardmäßig werden SNMP-Master- und -Sub-Agent beim Starten des PATROL-Agenten mitgestartet.

Abweichende Einstellungen können in einer entsprechenden Konfigurationsdatei vorgenommen werden. Dort können auch einzelne Befehle (z. B. SET) abgeschaltet werden. PATROL unterstützt die SNMPv1-Befehle, eingeschränkt auch SNMPv2.

SNMP stellt ein einfaches Request-Response-Verfahren dar, bei dem das Netzwerk-Managementsystem (NMS) einen Request auslöst und das verwaltete Gerät den entsprechenden Response liefert. Der PATROL-Agent stellt alle notwendigen SNMP-Befehle zur Verfügung: Zum Lesen und Ändern von Variablen die PSL-Funktionen snmp_get(), snmp_get_next(), snmp_walk() und snmp_set(); zum Empfangen bzw. Verschicken von SNMP-Traps gibt es snmp_trap_[ignore|listen|receive|register|send]. Außerdem gibt es dann noch einige Verwaltungsbefehle, z. B. zum Starten oder Stoppen des SNMP-Sub-Agenten.

Die Management Information Base (MIB)

Welche Objekt-Variablen können nun in der Praxis per Request-Response abgefragt und z. B. in der PATROL-Konsole dargestellt werden? Prinzipiell können alle Objekte, die in der MIB beschrieben sind, angesprochen werden. Die MIB ist eine hierarchisch organisierte Sammlung von Informationen, bei der jedes MIB-Objekt eine definierte Eigenschaft des verwalteten Geräts darstellt. Auf die einzelnen Objekte kann via MIB-Objekt-ID zugegriffen werden. Die MIB-Definitionen werden in den entsprechenden RFCs genauer beschrieben, sollen aber hier nicht weiter ausgeführt werden.

Die MIB-Objekte können über eine ASCII-Konvertierung in den PATROL-Namespace übertragen werden. Eine uns bekannte „Variable", nämlich - 1.3.6.1.4.1.1031.1.1.1.5.1.4.25.47.67.80.85.47.67.80. 85.47.67.80.85.67.112.117.85.116.105.108.47.118.97.108.117. - entspricht dem Wert des Parameters „/CPU/CPU/CPUCpuUtil" im PATROL-Namensraum und kann mit „snmp_h_get" problemlos verarbeitet werden. Dass dieser doch unhandliche Ausdruck dem uns bekannten CPU-Parameter entspricht, ist natürlich nicht ohne weiteres zu erkennen, sondern nur aus der MIB-Hierarchie zu erfahren.

Die Ziffern „.1.3.6.1.4.1.1031" stellen dabei die normierte Darstellung des MIB-Objektbaumes für den Einstieg in die BMC-Hierarchie dar (siehe Abb. 2).

Abb. 2: Baumstruktur der MIB-Objekte.

Um die CPU-Parameter (oder andere „bekannte" Objekte) zu überwachen, wird sicher auch weiterhin der klassische PATROL-Agent eingesetzt. Zur Überwachung einer USV, eines Druckers oder einer Netzkomponente (wie z. B. Switch oder Router), auf der kein Agent laufen kann, wird dann aber prinzipiell lediglich seine MIB benötigt. Für die meisten Netzkomponenten der bekannten Hersteller wird die MIB mitgeliefert.

Um sich das teilweise mühsame Abfragen der Variablen mittels MIB O-ID zu ersparen, stellt BMC im SDK-Kit das Tool „MIB2KM" zur Verfügung. In einer grafischen Oberfläche können sehr leicht KMs generiert werden. Dabei handelt es sich um eine selbstentpackende Datei, die eine Struktur mit weiteren ausführbaren Dateien, KM- und PSL-Dateien, sowie einer Reihe bereits vordefinierter MIBs liefert. Die Datei mib2km muss im %PATROL_HOME-Verzeichnis entpackt werden. Dabei entsteht das Verzeichnis „PAK", das u. a. eine Reihe von Standard-MIBs enthält.

Lädt man die neuen WIZ_CUSTOM.km und WIZ_mib2km.km mit der PATROL Entwicklerkonsole, kann der Wizard als zusätzliches KM-Kommando aufgerufen werden. Es erscheint das Eingangsbild. Die nötigen Schritte können sehr leicht mittels eines selbsterklärenden Wizards durchgeführt werden.

Wählt man dazu die passende MIB aus, gibt den SNMP-Port und den Community-Name ein, so generiert das Tool automatisch ein KM, beispielsweise mit dem
Namen ROUTER-XY_ 161.km (<IP-Adresse/Name>_<Portnummer>.km), das dem bekannten „klassischen" KM entspricht. Dies kann wie gewohnt in der PATROL-Konsole geladen und dargestellt werden.

Abb. 3: Beispiel-KM zur Überwachung der Netzwerk-Aktivitäten, generiert durch mib2km und <Default>-MIB (patrol.mib).

Fazit

Mittels SNMP können auch Netzwerkkomponenten oder andere SNMP-fähige Geräte, auf denen kein eigener Agent läuft, ins gewohnte PATROL-Monitoring einbezogen werden. Dies bedeutet eine signifikante Erweiterung des herkömmlichen Monitoring.

Die Konfiguration eines zusätzlichen Monitoring via SNMP ist zwar nicht ganz so trivial und mit einigem Arbeitsaufwand behaftet, aber da diese Komponenten teilweise essentiell für die Performance bzw. Verfügbarkeit einer ganzen IT-Landschaft sind, sollte man diese Möglichkeit, sich einen Zustandsbericht über die Komponenten seines Netzwerkes zu verschaffen, durchaus nutzen - insbesondere, wenn die MIB der Komponente vorhanden ist und der Wizard genutzt werden kann.

Durch den Einsatz des Tools MIB2KM erhält man ein KM, das sich nahtlos in die bisherige PATROL-Überwachung einfügt. Darüber hinaus gibt es bereits eine Reihe vorgefertigter Monitoring-Lösungen in der BMC-SNMP-Usergroup (über die BMC-Developer-Site zugänglich).

Der Einstieg in diesen Informationspool ist anfangs zwar gewöhnungsbedürftig, hat man diesen aber erst einmal geschafft, erhält man eine Fülle weiterer, nützlicher Informationen zur Überwachung eines komplexen und heterogenen Netzwerkes.

Dr. Ulrich Schwanke (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen