Nagios(3): WebFrontends …

Nagios3 ist schon eine tolle Software und ich habe die letzten Tage wiedereinmal damit zugebracht, die eine od. andere Zeile ins Wiki zu überführen. Wozu hat man schließlich Urlaub in Polen, wenn es dann noch regnet? Richtig! Zum schreiben. Nächste Woche steht die Überführung von einer Testinstallation auf die Produktionsumgebung an und dabei gibt es eine Sache, die mir Bauchschmerzen bereitet: Die GUI. Ich meine damit nicht unbedingt das Frontend von Nagios (was bekanntlich nicht der Höhe der Zeit entspricht und erst mit Nagios4 ein neues Gesicht erhält), sondern vielmehr das Anlegen von neuen Hosts- und Service-Checks und allem, was damit zusammenhängt. Dank der Templates lassen sich zwar viele Textzeilen einsparen, doch ein Webfrontend ist dann immer noch bequemer.

Im Augenblick gibt es genau zwei, welche Erwähnenswert sind:

NagiosQL:

NagiosQL ist auf den Ersten Blick wirklich nett und ermöglicht ein schnelles Hinzufügen von Kontakten, Hosts, Services etc. Auf dem zweiten Blick jedoch offenbaren sich jedoch nicht zu verachtende Mängel. Dass NagiosQL2 noch kein Nagios3 unterstützt, ist nebensächlich, da Nagios selbst ja zu 100% abwärtskompatibel ist, schwer wiegender ist der komplette Verzicht auf Templates. Das kann einem bei einigen Dingen gehörig in die Suppe spucken. Da wären z.B. ActionLinks. ein ActionLink ist ein Link auf der Nagios Weboberfläche neben dem Service od. Dienst, der dann zu einer anderen Seite führt. In sehr häufigen Fällen zu grafischen Performancewerten.

Per Template wäre diese Aufgabe genau einmal zu erledigen, so muss für jeden Eintrag ein Neuer her.

NagiosQL3 befindet sich in der Entwicklung und es werden Ideen gesammelt. Doch bis sich die erste Version zeigt, dürften noch einige Monate ins Land vergehen.

  • Centreon Centron ist derzeit für mich das interessanteste Projekt. Es ist ein wenig schwierig da durchzuschauen, da es ein französisches Projekt ist. Viele Supportanfragen die auf englisch gestellt werden, bekommen dann häufig eine französische Antwort. Wie auch immer, die 2’er version habe ich noch nicht getestet, aber die Demo von der Version3 lässt mein Herz höher schlagen, insbesondere die Einbindung von SNMP und Grafiken, die jetzige Kombinationen aus mehreren Programmen wie Cacti “’vermutlich“‘ überflüssig machen. Ob dem so sein wird, lässt sich wohl erst sagen, wenn die erste Version zum Download bereit steht. Damit hapert es noch ein wenig und der Termin wird hier und da aufgeschoben.

Nun werde ich in meiner Anleitung wohl vorerst auf eine GUI verzichten und den Vim als GUI verwenden. Ich denke aber, das ich das später nachtragen werde, da ab einer gewissen Anzahl das Handling nicht mehr tragbar sein würde.

Update:

Seit dem März ist ein neuer Stern am Nagios Frontend Himmel erschienen: Nagiosadmin. Ich habe schon über das Nagiosportal.de davon Wind bekommen und es mir mal flüchtig angeschaut. Für ein Projekt habe ich es verworfen, da es sich noch in starker Entwicklung befindet. Für meine Anleitung die hoffentlich demnächst veröffentlicht wird, habe ich sie schon einmal eingebunden. Sie macht auf jedenfall einen soliden Eindruck, zumal auch meine gewünschte Template Funktion unterstützt wird.

Ich werde sie auf weiter im Blick behalten und selbst verwenden.

Einziges Manko welches derzeit ins Auge sticht, ist der Mangel an einer Import Funktion. Wer also nicht seine hunderte von Hosts und Services erneut einpflegen möchte, muss sich noch in Geduld üben. Für all diejenigen, die das System frisch aufsetzen, ist sie einen Blick wert.

DB2 (v8) mit Nagios überwachen?

Hat einer von euch schonmal eine DB2 (v8) mit Nagios überwacht? Es gibt zwar ein Howto von IBM, was aber kompletter Schrott ist, da es kein klassisches Plugin darstellt, sondern sich in die Nagios Weboberfläche einbindet und zu Fuß erkundet werden muss. Ich will eigentlich nur so Sachen prüfen wie „DB2 läuft; Reagiert in einem angemessenem Zeitraum …“ Oracle ist zwar nicht viel prickelnder, lässt sich aber wohl einfacher überwachen.

Nagios: check_by_ssh mit nrpe kombinieren für DMZ

Das Problem: $KUNDE hat einen Nagios welcher außerhalb einer DMZ steht. Um diese zu erreichen zu können, gibt es ein Tor, welches nur SSH durchlässt, nach innen, wie nach außen.

Damit er die Rechner innerhalb der DMZ prüfen kann, wird derzeit ein Sammelsurium aus Skripten und NSCA verwendet, für passive Checks.

Dieses Konstrukt lässt sich vereinfachen, wenn die Rechner innerhalb der DMZ Ports verwenden dürfen. Das folgendende, neben- stehende und spontan entstandene Bild, soll dies verdeutlichen:

Das Wunderbare an den Nagios Plugins besteht darin, dass sie kein Nagios benötigen. Genau dieses Verhalten machen wir uns zu nutze. Nagios setzt einen aktiven Check mittels

check_by_ssh

ab und führt als Befehl eben den

check_nrpe

mit den entsprechenden Parametern ab, welcher wiederum einen NRPE Deamon abfragt, der auf den Rechner innerhalb der DMZ installiert wurde. Damit haben wir vieles vereinfacht:

  • Aktive Checks sind besser als passive 😉
  • Der »freshness« Parameter muss nicht bemüht werden, da die Checks immer dem aktuellen Stand entsprechen
  • Es wunderbar erweiterbar und dank SSH sowie SSL sicher.
  • Es ließen sich auch nicht definierte Argumente vom Nagios aus mitgeben, sofern NRPE mit der Option übersetzt wurde
  • … und bestimmt noch viele mehr

Wie sieht nun eine entsprechende Konfiguration aus?

In der commands.cfg definieren wir zuerst zwei neue Kommandos:

[…]

define command{ command_name ssh_check_dmz_icmp command_line $USER1$/check_by_ssh -H ssh-tor \ -C “$USER1$/check_icmp -H $ARG1$” }

define command{ command_name ssh_check_dmz_rootdisk command_line $USER1$/check_by_ssh -H ssh-tor \ -C “$USER1$/check_nrpe -H $ARG1$ -c check_hda5” }

Ersterer sorgt ohne noch NRPE dafür, dass wir einen Ping absetzen können, mittels

check_icmp

, dem Nachfolger des alten

check_ping

und zwar von unserem (SSH)Tor zu einem der Rechner in der Burg DMZ. Als Argument wird einfach der Rechnername/IP mitgegeben.

Zweites Kommando prüft den Datenträger »/dev/hda5« und zwar mittels

check_nrpe

. Das bedeutet,

check_hda5

ist also ein Kommando, welches in der nrpe.cfg Daemon Konfig definiert wurde. Ich hätte es also auch genauso gut

check_rootdisk

nennen können.

Nun folgt die host.cfg, in der der DMZ Rechner definiert wird:

define host{ use linux-server host_name dmzpc01 address 192.168.198.101 check_command ssh_check_dmz_icmp!dmzpc01 }

define service{ use generic-service host_name dmzpc01 service_description Check rootdisk check_command ssh_check_dmz_rootdisk!dmzpc01 }

Unser Rechner innerhalb der DMZ hat hier also den Namen »dmzpc01«. Um den Status des jeweiligen zu überprüfen, loggt sich Nagios über SSH ein und ruft von dort das NRPE Plugin auf und schon erhält Nagios einen frischen Status.

Statt »dmzpc01« als Argument, täte es auch eine IP Adresse (was im allgemeinen besser wäre) od. vermutlich auch

$HOSTADDRESS$

. Dann holt er sich die IP direkt aus der Hostconfig.

Überhaupt, ob die Wahl von IP oder Hostname ist nicht so einfach zu lösen, wenn die Systeme Redundant ausgelegt sind. Verlässt sich der Admin auf DNS, kann man die IP schnell per DNS umschalten, auf unser Ersatz Tor. Fällt DNS aus, hat Admin ein Problem, wobei sich dies mit einer /etc/hosts lösen ließe, dann aber wiederum statisch wäre (eventuell in der nsswitch die Reihenfolge ändern »dhcp file«).

Wird dagegen die IP umgezogen, ist IP definitiv zu bevorzugen.