PRTG und Nagios/Icinga

Warum das Rad mehrfach erfinden. PRTG ist ein effektives und leistungsstarkes Überwachungswerkzeug mit ganz vielen Sensoren. Allerdings gibt es für viele Aufgaben noch keine vorgefertigten Sensoren von Paessler oder dem Hersteller. Es gibt aber andere Überwachungslösungen wie z.B. Nagios/Incinga/CheckMK, die auf einem ähnlichen Ansatz aufsetzen und Systeme über Skripte direkt oder lokale Agenten überwachen. Über öffentliche Repositories sind solche Skripte für jeden erreichbar.

Die Nagios-Skripte sind zwar nicht immer von einer hohen Güte aber die Community ist groß und gerate für Umsteiger ist ein Recycling dieser Skripte interessant. Über die neuen HTTPPush-Sensoren kann man aber auch ohne Skripte auf der PRTG-Probe die Server lokal überwachen. Die Details dazu finden Sie auf PRTG:HTTPPush-Sensoren Diese Seite beschreibt nun ein Framework, um diese Option mit einem Skript zu kombinieren.

Ich würde immer genau die Skripte betrachten und ein Umschreiben auf PRTG vorziehen. Diese Seite zeigt aber, dass mit wenig Aufwand eine Brücke geschlagen werden kann.

Diese Seite beschreibt nicht, wie sie einen Server mit NSCLient++ an PRTG anbinden. für UNIX-System sollten Sie vielleicht ein PRTG SSH-Remote Sensor nutzen, um die UNIX-basierten Nagios/Icinga-Skripte aufzurufen und die Ausgaben für PRTG zu konvertieren. Sie können ja von meinem Powershell-Skript und der Beschreibung lernen, wie es geht.

NSClient++,

Eine Installation von Nagios/Incinga besteht in der Regel aus einem zentralen Server, der bestimmte Tests selbst ausführt aber in größeren Umgebungen und bei anspruchsvolleren Tests wird auf den zu überwachenden Servern ein Agent installiert, der auf einem Port lauscht und Befehle von Nagios Befehle annimmt.

Gerade bei einem Umstieg macht es aber keinen Sinn, auf einem Server den NSClient++ weiter zu betreiben. Wer so etwas vor hat, sollte auf dem Server besser gleich die PRTG-Probe installieren, die dann durch den zentralen Server auch verwaltbar ist, aktualisiert wird und verschlüsselt kommuniziert.

Theoretisch wäre es aber schon denkbar, auf Servern den NSClient++ zu nutzen, um von PRTG aus über diesen Agenten die bestehenden Skripte zu starten. Über einen Custom Sensor könnte man sich ein Tool zur Kommunikation mit dem NSClient einbinden. Aber diesen Weg verfolge ich nicht weiter.

Incinga/Nagios Skripte

Aber interessanter sind doch die Skripte, die bisher von Nagios und NSClient++ aufgerufen werden. Von den ein oder anderen kann man sich schon Ideen und Anregungen holen. Schaut man sich die Skripte genauer an, dann folgende Sie einem ganz einfachen Prinzip:

  • NSCientl lauscht auf Port
    Der NSClient läuft auf dem Server vergleichbar zur PRTG Probe. Und er kann per IP vom Server angesprochen werden. Die PRTG Probe ist das nicht, was ich als sicherer ansehe. Die PRTG-Probe verbindet sich mit PRTG Server und hält die Verbindung als Rückkanal.
  • Ausführbarer Code
    Die Skripte sind einfach ausführbarer Code. Also EXE, COM aber auch BAT, VBS, PS1, JS oder was der Host noch alles starten kann. Das Monitoring System steuert über den NSClient den Aufruf. Der NSClient kann einige dinge aber auch alleine machen
  • Parameter per Kommandozeile
    Die Steuerung erfolgt einfach über Parameter der Kommandozeile, die übergeben werden.

Alle Skripte die Nagios/INcinga mittels NSClient++ o.ä. auf einem Server starten, geben über zwei Wege ihre Daten zurück.

  • Daten per STDOUT
    Die Ausgaben ein oder mehrere Zeilen, die all dem gleichen Aufbau folgen. Sie besteht aus vier Werten, die durch ein Leerzeichen getrennt werden. Eine Ausgabe könnte wie folgt aussehen:
Status OK 1116 - postmaster@msxfaq.org(3) - frank@example.com (258) 
CPU OK : user=13% system=11% iowait=5% idle=71% | cpu_user=13%;70;90; cpu_sys=11%;70;90; cpu_iowait=5%;70;90; cpu_idle=71%;
Feld Beschreibung

Status

Der erste String ist eine einstellige Zahl und meldet an Nagios den Status und kann folgende Werte annehmen.

  • 0 = OK
    Das Skript ist erfolgreich gelaufen und konfigurierte Grenzwerte wurden nicht überschritten
  • 1 = WARNING
    Das Skript ist erfolgreich gelaufen aber Werte sind im „Warning State
  • 2 = CRITICAL
    Das Skript ist erfolgreich gelaufen aber der Werte sind im „Critical State“
  • 3 = UNKNOWN
    In der Regel sind das Skript-Fehler

Name des Checks

Die ist ein pro Host "eindeutiger" Name für diese Prüfung. Er darf keine Leerzeichen enthalten, da

Performance Daten

Optional können hier numerische Ergebnisse zurück geliefert werden. Die Nagios-Konvention ist wie folgt:

varname=value;warn;crit;min;max
varname=value;warn;crit
varname=value

Wer mehrere Variablen übergeben will, muss diese mit einem "Pipe"-Zeichen (|) voneinander trennen Leerzeichen sind nicht erlaubt

Freitext

Alles danach kommt ist Freitext, de von Nagios einfach übernommen und angezeigt wird.

  • Errorlevel
    Analog zum Status in der Textrückgabe sollte das Skript auch einen ErrorLevel senden. möglich sind:
    • 0 = OK
      Das Skript ist erfolgreich gelaufen und konfigurierte Grenzwerte wurden nicht überschritten
    • 1 = WARNING
      Das Skript ist erfolgreich gelaufen aber Werte sind im „Warning State
    • 2 = CRITICAL
      Das Skript ist erfolgreich gelaufen aber der Werte sind im „Critical State“
    • 3 = UNKNOWN
      In der Regel sind das Skript-Fehler

Dieses Format ist zwar nicht 1:1 mit PRTG zu vergleichen, aber doch sehr ähnlich. Es sollte also gar kein Problem sein, solche Skripte entsprechend zu recyclen.

Weitere Skripte

Sowohl die Nagios als auch die Incinga Portale bieten entsprechende Skripte als Repository an.

Hier ist für viele Anwendungen schon eine Lösung dabei oder zumindest ein Ansatz, wie diese zu überwachen sind.

Nagios-Skripte mit PRTG nutzen

PRTG kann aktuell nicht direkt mit einem NSClient++ kommunizieren oder die Rückmeldungen eines Nagios-Skripts auslesen. Das ist aber auch nicht zu erwarten und kann Paessler nicht angekreidet werden. Zum Glück liefert PRTG gleich mehrere Schnittstellen, um Daten von Skripten einzulesen. Seit Ende 2015 gibt es z.B. die PRTG:HTTPPush-Sensoren, welche sehr einfach eine Rückmeldung an PRTG zulassen. Zudem gibt es die PRTG:Custom Sensor, die auf einer Probe beliebige Skripte starten können.

Damit gibt es einige Lösungswege:

  • PRTG-Probe startet Nagios Script über Custom Sensor
    Bei Nagios startet der NSClient das lokale Skript. Sie könnten nun einfach statt des NSClient eine PRTG-Probe installieren, die in Kombination mit dem passenden Custom Sensor das Nagios-Skript startet und die Rückmeldung auswertet
  • MSTask startet lokal Nagios-Script und meldet per HTTPPush
    Wenn Sie nicht auf jedem Server eine PRTG-Probe installieren wollen, dann können sie auch einfach per Taskplaner regelmäßig den Check laufen lassen. Wir müssen das Skript zum Aufruf nur um die Funktion erweitern, dass es am Ende die Daten per HTTPPush an den PRTG-Server sendet
  • PRTG-Probe startet "RemoteCMD" auf Windows
    PRTG kann mit Sysinternals PSEXE oder per Powershell natürlich auch auf anderen Systemen ein Skript starten. Auch hier muss die Rückgabe und Parametrisierung umgesetzt werden.
  • PRTG und Unix
    Schon mit Bordmitteln kann PRTG auch Linux/Unix und MacOS überwachen, denn SNMP, WBEM und SSH sind eingebaut. Über den SSH-Sensor kann auf jedem Server auch ein Skript gestartet und die Ausgabe eingesammelt werden, die dann aber schon "PRTG-Konform" sein muss.
    Dieser Weg ist auch interessant, wenn die zu überwachende Plattform ein UNIX-System ist.

Wenn Sie nun den Weg gehen, dass eine PRTG-Probe direkt oder per SSH oder per PSExec ein Nagios-Script startet, dann müssen Sie das Skript anpassen, damit die Rückgabe nicht mehr im Nagios-Format sondern PRTG-Format erfolgt.

Hallo Paessler: Wäre das nicht eine Leichtigkeit für euch auch das Nagios-Format als Rückgabe zu akzeptieren ? Dann wäre der SSH-Sensor quasi prädestiniert direkt die Nagios-Skripte ganz ohne NSClient++ oder PRTG-Probe auf dem Zielsystem auszuführen.

Solange PRTG aber das Rückgabeformat nicht versteht, müssen wir es eben selbst konvertieren und zurück melden. Da die Skripte aber sowieso schon auf dem zu überwachenden Server liegen, ist es auch kein Problem dort noch ein kleines Skript abzulegen und dann die Daten an PRTG zu senden oder von PRTG abholen zu lassen.

Nagios2PRTG

Ich habe mich erst mal auf Windows Systeme beschränkt und nutze Powershell. Ein einfaches Powershell-Script ruft das angegebene Nagios-Script samt Parametern auf, wartet auf die Rückmeldung und konvertiert diese dann: Das Format der Nagios-Meldung erlaubt auch die Rückgabe mehrerer Werte. Entsprechend sollte das Skript die XML-Version der Rückgabe nutzen und den Status als Errorlevel übermitteln.

Das Skript ist vorbelegt mit einem einfachen Test, der über eine CMD.EXE einfach ein OK zurück meldet. Sie müssen also die per Default hinterlegten Parameter einfach über die PRTG-Parameterfunktion überschreiben, damit ihr Skript gestartet wird

prtg-nagios.ps1.txt

Zum Test können Sie das Skript natürlich auch problemlos einfach auf einer Powershell aufrufen. Es gibt ein paar Debug-Ausgaben, ehe dann ganz am Ende über STDOUT eine XML-Struktur ausgegeben wird.

Beachten Sie, dass ein direkter Aufruf von bestimmten Skripten in der Regel einen Editor starten und nicht immer der Skriptinterpreter

Einschränkungen

Für einige Inforationen, die so ein Nagios Sensor zurückliefern kann. So können Nagios-Rückmeldungen auch Werte für die Warnschwelle, Kritische Grenze, Minimum und Maximum liefert. für die gibt es in PRTG so erst mal keine Entsprechung bzw. die Grenzwerte kann der Administrator auf dem PRTG-Server setzen und mit Aktionen verbinden. Der Sensor selbst kann diese Werte aber nicht vorgeben.

Dafür liefert die Skripte keine Information, ob das nun ein Integer oder Float ist und ob es sich um absolute oder relative Werte handelt. Insofern können diese Parameter nicht in der XML mit übergeben werden. Sie müssen vom PRTG-Administrator am Sensor verwaltet werden.

Soweit ich gesehen habe, zeigt Nagios diese Werte dann aber auch einfach nur im Text mit an. Insofern könnte man diese Daten in einen String verwandeln und über den Text an PRTG übergeben., Leider ist der Text aber nur für den kompletten Sensor nicht für den einzelnen Kanal.

Der NSClient++ kann natürlich von Nagios auch aktiv angesprochen werden. Das geht mit PRTG nur, wenn eine PRTG-Probe aktiv den Test ausführt und das Skript nicht passiv durch den Taskplaner anhand eines Zeitplans gestartet wird.

Der NSClient++ kann mit einem eigenen Scheduler auch Tests durchführen und an Nagios melden. Ich habe es selbst noch nicht gesehen aber das soll wohl auch fremd getriggert möglich sein, also wenn ein gewisser Event (Performancecounter, Eventlog, Syslog) eintrifft, dann startet NSClient++ den Test autark

All diese Mehrwertfunktionen sind mit PRTG natürlich auch möglich, wenn die Kontrolle bei der PRTG-Probe ist.

Weitere Links