Die einfachste Konfiguration tritt auf, wenn in Ihrem Netzwerk eine einzelne Icinga-Instanz läuft. In diesem Fall ist die Installation und Konfiguration der einzelnen Komponenten ziemlich geradeaus.
Das folgende Schaubild zeigt, wie die einzelnen Komponenten in diesem Einzelserver, Einzel-Icinga-Instanz-Aufbau zusammenspielen...
Hier eine Beschreibung, was an jedem Punkt des Schaubilds passiert:
Das IDOMOD-Modul wird mit einem Instanznamen "default" konfiguriert, weil es lediglich eine Icinga-Instanz im Netzwerk gibt.
Während der Icinga-Daemon läuft und die üblichen Aufgaben zur Überwachung des Netzwerks ausführt, sendet das IDOMOD-Modul Konfigurationsdaten und Ereignisinformationen an den TCP- oder Unix-Domain-Socket, der durch den IDO2DB-Daemon angelegt wurde.
Der IDO2DB-Daemon liest die Daten, die durch den Socket vom IDOMOD-Modul kommen.
Der IDO2DB-Daemon verarbeitet und überträgt die Daten, die vom IDOMOD-Modul empfanden wurden.
Die verarbeiteten Daten werden für spätere Abfragen und Verarbeitung in einer Datenbank gespeichert.
Dieses Beispiel setzt voraus, dass:
Icinga konfiguriert wurde, um das IDOMOD-Modul beim Start zu laden.
Der IDO2DB-Daemon läuft (der ein separater, vom Icinga-Daemon unabhängiger, Prozess ist).
Eine weitere einfache Konfiguration kann genutzt werden, wenn Sie mehrere Icinga-Instanzen haben, die auf einem einzigen Server laufen. Installation und Konfiguration der verschiedenen Komponenten des IDOUtils-Addons ist ähnlich zum vorigen Beispiel.
Das folgende Schaubild zeigt, wie die verschiedenen Komponenten in diesem "einzelner Server, mehrere Icinga-Instanzen"-Aufbau zusammenspielen...
Sie werden bemerken, dass das obige Schaubild ähnlich zu dem "einzelner Server, einzelne Instanz"-Aufbau ist. Der Hauptunterschied besteht darin, dass es nun drei (3) verschiedene Icinga-Daemons statt eines einzelnen gibt.
Jeder Icinga-Daemon lädt das IDOMOD-Modul beim Start mit einem eindeutigen Instanznamen. In diesem Beispiel werden die Instanzen einfach "Icinga1", "Icinga2" und "Icinga3" benannt.
Jedes IDOMOD-Modul sendet Konfigurationsdaten und Ereignisinformationen seiner Instanz des Icinga-Daemons an den TCP- oder Unix-Domain-Sockets, der vom IDO2DB-Daemon angelegt wurde.
Der IDO2DB-Daemon liest die Daten, die durch den Socket von den drei IDOMOD-Modulen kommen.
Der IDO2DB-Daemon verarbeitet und überträgt die Daten, die von den IDOMOD-Modules empfangen wurden.
Die verarbeiteten Daten werden für spätere Abfragen und Verarbeitung in einer Datenbank gespeichert. Die Daten jeder Icinga-Instanz werden (mit Hilfe des eindeutigen Instanznamens) in der Datenbank getrennt voneinander gehalten.
Es gibt zwei Gründe, warum Sie vielleicht Ihre Icinga-Log-Dateien in die gleiche Datenbank importieren möchte, die Icinga-Konfigurations- und Ereignisdaten enthält:
Historische Log-Datei-Daten werden nicht automatisch in die Datenbank importiert und möglicherweise ist es wünschenswert, Einträge von Ereignisse zu haben, die vor der Implementierung des IDOUtils-Addon eintraten.
Das IDOMOD-Modul ist nicht in der Lage, Echtzeit-Log-Einträge von direkt nach dem Start des Icinga-Daemon bis zum Zeitpunkt des Ladens des IDOMOD-Moduls durch den Icinga-Daemon zu verarbeiten. Diese "Blackout-Periode" ist unvermeidbar und führt zu Log-Einträgen wie "Icinga 1.0 starting...", die das IDOMOD-Modul nicht mitbekommt. Daher wird das Importieren der Logdateien des vorangegangenen Tages auf täglicher Basis (über einen cron-Job) empfohlen.
Hier eine Beschreibung, was an jedem Punkt des Schaubilds passiert:
Historische Icinga-Log-Dateien werden vom LOG2IDO-Utility gelesen.
Das LOG2IDO-Utility verarbeitet den Inhalt der Log-Dateien und versieht sie mit dem Instanznamen "default". Dieser Instanzname muss mit dem Instanznamen übereinstimmen, der vom IDOMOD-Modul im Icinga-Daemon verwendet wird.
Historische Log-Datei-Daten werden in einem Format an den TCP- oder Unix-Domain-Socket geschickt, das der IDO2DB-Daemon verstehen kann.
Der IDO2DB-Daemon liest die Log-Datei-Daten vom TCP- oder Unix-Domani-Socket.
Der IDO2DB-Daemon verarbeitet die Log-Datei-Daten.
Historische Log-Datei-Daten werden für spätere Abfragen und Verarbeitung in einer Datenbank gespeichert. Der IDO2DB-Daemon wird einige Prüfungen durchführen, um das mehrfache importieren der gleichen historischen Log-Einträge zu verhindern, so dass der Aufruf des LOG2IDO-Utilitys mit den gleichen Dateien keine negativen Auswirkungen haben sollte.
Das war's! Ziemlich einfach.
© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com
