Viel­seiter OpenNMS: Effi­zi­entes Moni­to­ring auf verschie­denen Ebenen

Im Bereich des Moni­to­ring stellt sich immer wieder die Frage, welche Menge an Infor­ma­tion man tatsäch­lich über ein System oder eine Anwen­dung benö­tigt. Zwar scheint es auf den ersten Blick am sinn­vollsten, alle verfüg­baren Infor­ma­tionen zu sammeln und aufzu­be­reiten - dies erfor­dert aller­dings Ressourcen auf dem Moni­tor­ring­system, dem über­wachten System und auch in dem verbin­denden Netz­werk. Um dieser Proble­matik zu begegnen, verfügen Moni­to­ring­sys­teme über einen Satz von Über­wa­chungs­me­thoden, die die häufigsten Fälle in einer möglichst allge­meinen Form des Moni­to­rings abde­cken. Das Open­So­urce-Tool OpenNMS bietet für die Über­wa­chung eines Webser­vers stan­dard­mäßig Poller für ICMP, HTTP und HTTPS an.
Diese Poller sind in der Regel sehr gene­risch gehalten, damit sie auf die verschie­densten Vari­anten eines Dienstes ange­wendet werden können. Ein Beispiel: Der in OpenNMS bereits vorde­fi­nierte Poller für HTTP prüft ausschließlich, ob auf eine Anfrage auf Port 80 ein posi­tiver HTTP-Response-Code zurück­ge­geben wird. Dass die Konfi­gu­ra­tion der Poller ange­passt werden kann, ist vielen bewusst. So erscheint es nur logisch, dass auch ein anderer Port für HTTP konfi­gu­riert werden kann, da manche Server und vor allem die WebUIs einiger Netz­werk-Appli­ances auf anderen Ports betrieben werden. Aller­dings bietet OpenNMS noch weitere Möglich­keiten der Über­wa­chung: So kann - um beim Beispiel des Webser­vers zu bleiben - exakt fest­ge­legt werden, welche Response Codes gültige Werte darstellen, um beispiels­weise ein Redi­rect auf eine Fehler­seite zu erkennen. Weiterhin kann auch der Inhalt der Antwort­seite ausge­wertet werden - unter anderem, um zu prüfen, ob ein bestimmter Text enthalten ist. Zudem ist es auch möglich, Authen­ti­fi­zie­rungs­daten zu über­geben, falls der Webserver diese anfor­dert. Diese beispiel­haften Konfi­gu­ra­ti­ons­mög­lich­keiten zeigen, dass bereits mit dem einfa­chen HTTP-Poller eine Über­wa­chung im Bereich von einer belie­bigen Antwort eines Webser­vers bis hin zum Login und der Prüfung des Inhaltes einer Antwort­seite möglich ist.

Moni­to­ring auf verschie­denen Ebenen

Bereits durch die Konfi­gu­ra­tion eines einzelnen Pollers wird die Über­wa­chung eines Dienstes auf verschie­denen Ebenen (allge­mein und ober­fläch­lich bis hin zu speziell und tief­ge­hend) ermög­licht. Teil­weise exis­tieren zudem Poller für spezi­fi­sche Aufgaben, die eine bessere Eingren­zung oder sogar erst die Erken­nung einer Störung ermög­li­chen. So kann beispiels­weise ein Polling des SMTP-, POP- und IMAP–Services anzeigen, dass ein Mail­server korrekt funk­tio­niert. Wurde zusätz­lich ein Mail–Transport–Poller einge­richtet, stellt man plötz­lich fest, dass der Versand von E-Mails nicht mehr funk­tio­niert. Nach kurzer Recherche zeigt sich, dass der Mail­server auf einer Black­list gelandet ist. Wie an diesem Beispiel zu erkennen ist, können einige Poller die Aussa­ge­kraft von Störungs­mel­dungen deut­lich erhöhen. Dazu ist aller­dings meist ein Mehr­auf­wand an Konfi­gu­ra­tion und ein erhöhter Ressour­cen­be­darf in Kauf zu nehmen. In diesem Beispiel müsste mindes­tens ein Mail-Trans­port-Poller einge­richtet werden, der mit Hilfe einer externen Mail­adresse den Versand prüft. Gegen­über steht aller­dings ein deut­li­cher Gewinn an Infor­ma­tion, der unter anderem auch durch die Kombi­na­tion von Pollern erreicht wird.

Wie man an diesem Beispiel auch erkennen kann, benö­tigen einige Poller Zugriff auf den zu über­wa­chenden Dienst. So braucht der Mail–Transport–Poller einen gültigen Account, um Versand und Empfang von E-Mails zu prüfen, während ein SMTP–Poller in der Regel keine Zugriffs­be­rech­ti­gung benötigt.

Indi­rekte Überwachung

Neben den direkten Über­wa­chungs­me­thoden stehen auch noch indi­rekte Moni­to­ring-Vari­anten zur Verfü­gung. Im Bezug auf OpenNMS gibt es verschie­dene Möglich­keiten an System­in­for­ma­tionen zu gelangen - die gängigste ist SNMP. Sofern SNMP auf dem zu über­wa­chenden Gerät einge­richtet ist, stehen verschie­dene Über­wa­chungs­mög­lich­keiten zur Verfü­gung. Ein Beispiel: OpenNMS kann prüfen, ob ein spezi­eller Prozess - wie unter anderem ein Apache–Webserver - aktiv ist. Hierzu ist die Einrich­tung eines Host­Re­sour­ceS­WR­un­Mo­nitor für Unix-Systeme oder ein Win32ServiceMonitor für Windows erfor­der­lich. Zusätz­lich ermög­licht es SNMP OpenNMS, Perfor­mance­daten zu sammeln, so dass die Auslas­tung der Prozes­soren, des Arbeits­spei­chers und die Bele­gung der Fest­platten eines Servers über­wacht werden können. Die Perfor­mance­daten bringen gleich doppelten Nutzen mit sich, da sie zum einen in einem Störungs­fall genutzt werden können, um den Fehler einzu­grenzen, und zum anderen auch eine gute Grundlage zur Einschät­zung bieten, ob ein Server seine Dienste perfor­mant anbieten kann oder neu ausge­legt werden muss.
Also: Das Moni­to­ring von Diensten kann auf unter­schied­li­chen Ebenen erfolgen, wobei immer der Zuge­winn an Infor­ma­tion gegen die dafür benö­tigten Ressourcen gewogen werden muss.  Die Einrich­tung eines erwei­terten Moni­to­rings wird von OpenNMS durch die Bereit­stel­lung von Konfi­gu­ra­ti­ons­op­tionen und spezi­ellen Pollern unter­stützt. Glück­li­cher­weise hält sich der Ressour­cen­be­darf für die einzelnen spezi­ellen Poller in Grenzen, so dass eine über­schau­bare Anzahl ohne größere Probleme einge­richtet werden kann.
Ihre weiter­ge­henden Fragen zu OpenNMS allge­mein, einer tief­grei­fenden Über­wa­chung oder deren Einrich­tung beant­worten wir gerne persön­lich. Spre­chen Sie uns einfach an!
 
Autor: Andreas Fuchs

Schreibe einen Kommentar

Cookie Einstellungen
Diese Website verwendet Cookies, um die bestmögliche Funktionalität zu gewährleisten. Mehr lesen

Akzeptiere alle Cookies Speichern