Die NDO Utils sind in der Lage, alle Events und Konfigurationsdaten in einer Datenbank zu speichern.

Die NDO Utils dienen NICHT zur Konfiguration von Nagios und ersetzen NICHT die Konfigurationsdateien.

In einer späteren Version von Nagios (>3.0) sollen die CGIs durch ein neues PHP Frontend ersetzt werden. Die NDO Utils sollen die Grundlage dafür schaffen.

Die Version 1.3 der NDO Utils unterstützt nur MySQL als Datenbank, in den nächsten Versionen soll die Unterstützung für Postgres-Datenbanken hinzukommen.

ACHTUNG: Die NDO Utils Version 1.3 funktionieren nur mit Nagios 2.0rc2 oder höher.

Die Installation, Konfiguration und Fehlersuche wird auf extra Seiten beschrieben.

Die NDO Utils sind für folgende Nagios-Installationen einsetzbar.

• Eine einzelne Nagios-Instanz.
• Mehrere einzelne Nagios-Instanzen auf einem Server.
• Mehrere Nagios-Instanzen als redundant, failover oder distributed Installationen.

Die Daten jeder einzelnen Nagios-Instanz können entweder in einer oder in mehreren Datenbanken gespeichert werden.

Zukünfig soll es möglich sein, Daten einer Nagios-Instanz gleichzeitig in mehreren Datenbanken zu speichern. Die Version 1.2 unterstützt diese Funktion jedoch noch nicht.

Jedem Nagios-Prozess muss ein eindeutiger „Instanz-Name“ zugeordnet werden, wenn die Daten mehrerer Nagios Instanzen in einer Datenbank gespeichert werden sollen. Nur so ist es möglich, die Daten voneinander zu trennen.

Die Namen der Instanzen können frei gewählt werden. Man kann z.B. die Namen der Standorte verwenden.

Oder man wählt den Namen anhand des Einsatzzwecks.

Wie die Namen der Instanzen gewählt werden bleibt also jedem selbst überlassen. Wichtig ist nur, dass die Instanzen innerhalb einer Datenbank eindeutig benannt werden.

Die NDO Utils bestehen aus vier Komponenten

1. NDOMOD Event Broker Module
2. LOG2NDO Utility
3. FILE2SOCK Utility
4. NDO2DB Daemon

Die NDO-Utils beinhalten ein Nagios Event Broker Modul (ndomod.o). Diese NEB Modil exportiert zur Laufzeit die Daten des Nagios Daemons.

Davon ausgehend, dass Nagios mit der Unterstützung für Event Broker compiliert wurde ¹⁾, kann Nagios das NDOMOD Modul zu Laufzeit laden. Ist das Modul geladen, so hat es Zugriff auf alle Daten, die dem Nagios-Daemon zur Verfügung stehen.

Das NDOMOD-Modul ist so konzipiert, dass es Konfigurations-Daten, sowie alle zu Laufzeit auftretenden Events verarbeiten kann. Das Modul kann die Daten in eine Datei schreiben, in ein Unix Domain Socket ( pipe ) oder einen TCP Socket.

Mit dem LOG2NDO Utility lassen sich Nagios- oder Netsaint-Logfiles in die Datenbank importieren. LOG2NDO bereitet die Daten so auf, dass NDO2DB sie verarbeiten kann. LOG2NDO sogt dafür, dass Daten nicht doppelt importiert werden. Das gleiche Logfile kann also mehrfach verarbeitet werden.

FILE2SOCK ist wirklich simpel. Mit diesem Utility können Daten, die von NDOMOD erstellt wurden, an NDO2DB übergeben werden. Die Daten werden nicht umgewandelt, werden also RAW in die Pipe geschrieben.

Der NDO2DB Daemon verarbeitet die Daten, die von NDOMOD oder LOG2NDO erstellt wurden, in die Datenbank.

Wenn der Daemon gestartet wird, erzeugt er ein Unix Domain oder TCP Socket, je nachdem, was in der ndo2db.conf eingestellt wurde.

Mehrere Clients ( NDOMOD ) können sich zum gleichen NDO2DB-Daemon verbinden und die Daten gleichzeitig senden. Für jeden verbundenen Client wird ein eigener NDO2DB-Prozess gestartet.

Das einfachste Szenario ist eine Nagios-Instanz auf einem Server mit nur einer Datenbank.

Was passiert genau ?

1. NDOMOD ist mit dem Instanz-Namen „default“ konfiguriert.
2. Während Nagios seiner eigentlichen Arbeit nachgeht, werden alle ermittelten Daten von NDOMOD in ein UNIX Domain oder TCP Socket geschrieben.
3. NDO2DB liest die eingehenden Daten.
4. NDO2DB verarbeitet die Daten.
5. Die Daten werden in der Datenbank gespeichert.

Eine weitere einfache Konfiguration.
Auf einem Server laufen drei Nagios-Instanzen, deren Daten alle in einer Datenbank gespeichert werden sollen. Jede Nagios -Instanz bekommt einen eindeutigen Namen.

Eigentlich der gleiche Ablauf wie im ersten Beispiel, nur dass drei Nagios-Instanzen laufen.

1. Jede Nagios-Instanz hat NDOMOD mit einem eigenen Instanz Namen geladen.
2. Jedes NDOMOD-Modul sendet Daten zum gleichen Unix Domain oder TCP Socket.
3. NDO2DB liest die Daten.
4. NDO2DB verarbeitet die Daten.
5. NDO2DB schreibt die Daten in die Datenbank, wobei die Daten der einzelnen Instanzen durch den Instanz-Namen voneinander getrennt werden.

Es gibt zwei Gründe, warum man die Nagios-Logfiles in die Datenbank einlesen möchte.

1. Historische Daten, also Daten, die angefallen sind, bevor es die NDO-Utils gab, sollen importiert werden.
2. NDOMOD kann keine Daten verarbeiten, die zwischen dem Nagios-Programmstart und dem Laden von NDOMOD liegen. In dieser kurzen Zeitspanne fehlen also Daten. Es wird empfohlen nach den Nagios-Start die Logfiles zu importieren.

1. Nagios-Logfiles werden mit LOG2NDO eingelesen.
2. LOG2NDO verarbeitet den Inhalt der Logfiles, so dass NDO2DB die Daten verarbeiten kann. Dabei ist darauf zu achten, dass der gleiche Instanz-Name wie bei NDOMOD zum Einsatz kommt.
3. Die Daten werden in ein Unix Domain oder TCP Socket geschrieben.
4. NDO2DB liest die Daten ein.
5. NDO2DB verarbeitet die Daten.
6. NDO2DB schreibt die Daten in die Datenbank. Dabei wird verhindert, dass Daten doppelt importiert werden.

Die Informationen und Bilder stammen aus der Dokumentation die den NDO Utils beiliegt.

Tipps zur Problembehebung rund um den Einsatz von NDO sind auf der Seite Troubleshooting zu finden.