PRTG und Nagios/Icinga

Als Windows Admin bin ich mit PRTG bislang recht gut gefahren. Allerdings ist ein Blick über den eigenen Arbeitsbereich immer sinnvoll, um andere Ansätze kennen zu lernen. Gerade im Bereich "Open Source" gibt es auch schöne Produkte wie Nagios, icinga und noch mehr kommerzielle Tools. Mich hat interessiert, wie diese Systeme arbeiten und ob eine Integration in PRTG möglich oder sogar sinnvoll ist. Dies kann insbesondere mit Plattformen interessant sein, die PRTG eher eingeschränkt unterstützt.

Also 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/icinga/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 gerade 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.

Agent und Agentless

Da die meisten Programme einen Background im Netzwerk Monitoring haben, gehören SNMP-Abfragen natürlich zum guten Ton. Aber damit kommen wir bei Servern nur bedingt weiter. Hier sind andere Schnittstellen erforderlich und damit auch die Frage der Ansprache.

  • Agentless
    d.h. auf dem zu überwachenden Server gibt es keine weitere Software der Monitoring-Lösung und das überwachende System fragt aus der Ferne den Status per SNMP, WMI, WBEM o.ä., ab. Dazu muss eine Verbindung von der Überwachung zum überwachenden System möglich sein und bei vielen zu überwachenden Systemen muss das aktive System gut skalieren.
    Agentless ist schnell und einfach eingerichtet aber ein Zentralsystem mit so vielen Berechtigungen ist kritisch.
  • Agentbasiert
    All diese Probleme lösen Sie, durch einen Agent auf dem dem zu überwachenden System. Der Agent prüft lokal und stellt die Ergebnisse bereit. Dazu muss er aber erst einmal installiert und konfiguriert werden. und dann stellt sich noch die Frage der Richtung
    • Passiv mit Meldung an Reporting-System
      Der Agent macht lokal seine Checks und verbindet sich dann an das Zentralsystem um die Daten abzuliefern. Der Agent selbst ist quasi "unsichtbar" im Netzwerk und das zentrale System kann maximal erkennen, wenn Meldungen ausbleiben. Ein Sonderfall wäre, wenn der Agent eine Verbindung aufrecht erhält, um aktiv angesprochen werden kann.
    • Aktiv und getriggert
      Es gibt aber auch Agenten, die auf dem Zielsystem als Service aktiv sind und Verbindungen annimmt. Nagios NCPA lauscht z.B. auf Port 5693 auf eingehende Anfragen

Interessant wird es wenn Produkte von sich aus auch schon einen Agenten zur Überwachung mitbringen und sich z.B. "Selbst" überwachen. Als Beispiel nenne ich hier oft die Funktion Exchange 2013 Managed Availability, mit der eine Monitoring-Lösung einfach nur die Ergebnisse einsammeln muss.

Schnittstellen und Module

Ich habe mich für die Schnittstellen der verschiedenen Produkte interessiert und inwieweit diese für meine eigenen Überwachungsaufgaben geeignet sind. Dies betrifft sowohl die mögliche Integration in PRTG als auch die Integration eigener Skripte in diese Lösungen.

Schnittstelle PRTG-Eignung

NCPA (Nagios)

Der Agent kann auf kompatiblen Systeme installiert und konfiguriert werden. Umfangreiche Skripte in einer Library erlauben die Erweiterung durch Checks. Die Kommunikation mit dem Zentralsystem erfolgt über eine HTTPS-Schnittstelle oder per NRDP. Die Webschnittstelle ist dahingehend interessant, das Sie sowohl per Browser als auch per Skript, z.B. check_ncpa, angesprochen werden kann.

check_ncpa -t 'TokenDesAgent' -P 5693 -M cpu/percent -w 70 -c 90 -q 'aggregate=avg'

Wenn Sie den Agent per HTTPS erreichen können und das passende Zugriffs-Token kennen, erhalten Sie die Ergebnisse als JSON-Format.

Allerdings ist genau die Webseite natürlich eine kritische Komponente, da auf dem System damit ein Webserver auf einem "bekannten" Port erreichbar ist. Zumindest DoS-Attacken wären denkbar und das SSL-Zertifikat muss auch verwaltet werden. Wenn man hier nicht "streng" ist, dann könnte ein Angreifer den Zugriff des Management-Systems umleiten und damit das Token abgreifen.

Es sollte sehr einfach sein, per PowerShell oder JSON-Abfrage direkt den Agenten durch PRTG abzufragen.

NRDP (Nagios)

Der Nagios-Server kann über die NRDP-Schnittstelle Daten und Befehle von anderen Systemen annehmen. Ein Skript oder System muss daher gar keinen "dicken" NCPA-Agent starten, sondern könnte einfach nur seine Ergebnisse an Nagios übergeben. Auch hier muss der Client ein Token zur Authentifizierung mitliefert und in Nagios konfiguriert sein. Aber das ist einfacher machbar, da nur der Nagios-Server per HTTPS erreichbar sein muss. Auch der NCPA-Agent kann diesen Weg zur Meldung nutzen.

PRTG hat aktuell leider keine zu NRDP kompatible Schnittstelle sondern eine eigene Rest-API. Man könnte aber natürlich ein Gateway schreiben, welches die Daten er NRPD annimmt und an PRTG weiter gibt.

NRPE

Der "Nagios Remote Plug-in Executor" ist eigentlich ein Dienst, der auf dem zu überwachenden System installiert und von dem Überwachungssystem angesprochen wird um Befehle auszuführen. Quasi wie ein RCMD. In der Konfiguration wird hinterlegt, welche IP-Adresse den NRPE-Service ansprechen darf und welche Checks ausgeführt werden dürfen.

Technisch könnte PRTG auch die NRPE-Abfragen einbinden und so auch Linux Systeme einbinden.

NSClient+

Wenn ich es recht weiß, dann wurde NSClient als Agent für Nagios gestartet aber ist nun offen für ganz viele andere Systeme. Dazu gehört auch ein Support der unterschiedlichen APIs (z.B. NRPE, NSCA, Syslog, SMTP etc.).

NSClient is an  agent designed originally to work with Nagios but has since evolved into a fully fledged monitoring agent which can be used with numerous monitoring tools (like Icinga, Naemon, OP5, NetEye Opsview etc)
NSClient++ is a free (as in both beer and speech) program which is NOT backed by a big corporation. We don't believe in opencore instead we really believe in opensource
Quelle: https://www.nsclient.org/

Insofern könnte NSClient durchaus ein interessanter "universal-Agent" sein, den auch PRTG nutzen kann, sei es per PRTG-AdOn für die PRTG - HTTP Push-Sensoren oder indem PRTG selbst eine Schnittstelle wie NSCA unterstützt. NSClient ist aber wie der Nagios-Client auch als "Webseite" (Port 8443) erreichbar.

Auch hier könnte PRTG sehr schnell direkt die Funktion des Agenten nutzen.

Denkbar wäre aber auch ein AddOn. damit NSClient direkt die PRTG - HTTP Push-Sensoren von PRTG bedient.

icinga

Ursprünglich als Fork von Nagios nach unklarer Roadmap des Nagios-Teams gestartet, ist icinga mittlerweile weiter entwickelt. Auch hier kann ein Agent verschiedene Befehle ausführen oder auf Plugins zurückgreifen oder sogar NSClient++Service einbinden, der sogar Bestandteil der Installation ist. Der icinga Agent kann auf Port 5665 (Default) lauschen als auch seine Daten selbst an den Satellit/Master senden.

Ich habe auf die Schnelle nicht ermittelt, wie die Kommunikation zwischen icinga Master/Satellite und Agent erfolgt und wie man PRTG damit koppeln könnte. Das Protokoll ist wohl etwas aufwändiger, da laut Beschreibung auch Konfigurationsdaten mit übertragen werden können

 

Auf ein Monitoring mit "Linux-Hintergrund" funktioniert in Prinzip nicht andere, als ein Monitoring unter Windows, bei dem per Agent oder eben Agentless ein System durch einen Master (=PRTG Server) und einem Satelliten (=PRTG Probe) überwacht und das Ergebnis erfasst wird. Bei den Agenten auf dem Server haben wir dann die Wahl, ob sie vom überwachenden System aktiv angesprochen werden oder ihrerseits selbständig Checks durchführen und diese melden.

Mir gefällt der Ansatz besser, dass das System sich selbst überwacht und den Status an eine höher liegende Schicht meldet. Nur "dumme" Systeme, die keine eigene Funktion der Überwachung mitbringen, müssen halt "erreichbar" sein und per SNMP,SSH; RCMD o.ä. abgefragt werden.

Für die Kopplung mit PRTG könnten beide Wege interessant sein, d.h. PRTG könnte die Agenten wie NSClient++ selbst abfragen oder Daten von Agenten annehmen.

Icinga/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:

  • Ausführbarer Code
    Die Skripte sind einfach ausführbarer Code. Also PL, PHP, EXE, COM aber auch BAT, VBS, PS1, JS oder was der Host noch alles starten kann. Das Monitoring System steuert über den Agenten (NSClient++, NCPA) den Aufruf oder der Agent agiert autark und sendet die Daten per NRDP o.ä.
  • Parameter per Kommandozeile
    Die Steuerung erfolgt einfach über Parameter der Kommandozeile, die übergeben werden.
  • Scheduler
    Wenn die Aktion nicht aktiv vom überwachenden System gestartet wird, startet ein lokaler Scheduler die Checks.

Die Skripte die auf einem Server starten, geben nach meinem Wissen ihre Daten über zwei Wege 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 in PRTG zu nutzen.

Weitere Skripte

Sowohl die Nagios als auch die icinga 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