Nagios - die Idee und Implementierung (auch Konfigurationsübersicht genannt)
Die Konfiguration von nagios ist durchaus komplex, aber wenn man es richtiig anstellt ist es einfach, nach und nach alles einzurichten.
Es gibt verschiedene Sektionen die wichtig sind:
Es gibt noch mehr, aber davon erzähle ich später.
Hosts: das sind die Geräte die überwacht werden sollen - das können Rechner sein (PCs, Unix, Windows...) aber auch Router oder Switche; oder auch Thermometer, sofern sie via tcp/ip abfragbar sind; eventuell snmp sprechen oder etwas ähnliches. Bei der Host-Konfiguration muss man mindestens eine IP-Adresse und/oder Hostnamen angeben, damit eindeutig geklärt ist welcher Rechner da gemonitored wird.
Dienste: sind die Programme oder Prozesse die von nagios überprüft werden. Jeder Dienst braucht als Mindestangabe den Host auf dem er laufen soll - sonst hätte die Definition auch keinen Sinn. Innerhalb eines Dienstes wird der Name (und Alias) definiert und auch welches Check-Kommando ausgeführt werden soll um den Dienst zu überprüfen.
Check-Kommandos: Das sind die Kommandos die ausgeführt werden um den Dienst zu überprüfen. Während beim Dienst noch nach Nagiosart Variablen übergeben werden (wie der Hostname des zu prüfenden Rechners) wird hier das Kommando definiert, inklusive dem Aufruf. Quasi eine Übersetzung von Nagios-Konfiguration in Überprüfungs-Konfiguration.
Zeitperioden: Manche Dienste sollen nur zu einer bestimmten Zeit oder an bestimmten Tagen überhaupt geprüft werden. Diese können definiert werden - zum Beispiel kann gesagt werden dass es unkritisch ist, wenn die Temperatur am Wochenende auf 40°C steigt; das könnte ja in Ordnung sein.
Kontakte: Falls es mal Probleme gibt, muss natürlich auch jemand benachrichtigt werden. Diese Personen werden in den Kontakten definiert - inklusive der Möglichkeit, wie die Nachrichten weitergegeben werden.
Für Recher, Dienste und Kontakte gibt es auch noch Gruppierungsmöglichkeiten; so dass man zum Beispiel 10 verschiedene Rechner zu einer Gruppe zusammenfassen kann (Kunde A, Kunde B...). Genauso kann man Dienste in einer Gruppe zusammenfassen - Dienste, die nicht gleich sind bzw. nicht dieselben Checks haben, aber dasselbe Ziel. Und Kontaktgruppen ermöglichen es, Nutzer zusammenzufassen, wenn jemand benachrichtigt werden soll.
Für alle diese Konfigurationsmöglichkeiten gibt es sogenannte Templates - Vorlagen. In den von Nagios mitglieferten Vorlagen sind alle möglichen Parameter bereits gesetzt und meistens auch sinnvoll. Ich habe allerdings festgestellt dass es für mich sinnvoller ist zusätzliche Gruppen (zum Beispiel bei den Diensten) zu bauen. Ich habe dann für den Dienst ein Template gebaut und musste dann pro Schnitstelle die ich überwachen wollte nur noch sagen wie sie heisst und welcher Port überwacht werden soll. Alles andere wurde durch den Gebrauch einer Vorlage dann standardsiert.
Ganz wichtig: in der Konfiguration kommt immer wieder der Parameter "Alias" vor. Das ist nicht nur der Alias für den Dienst/Rechner/wasauchimmer, sondern die Kurzerklärung des Dienstes wie er auf der Webseite angezeigt wird.
Wie hängt das nun miteinander alles zusammen? Ich fange mal oben an.
Ich habe eine Anzahl von Rechnern, von denen will ich einerseits wissen ob sie leben und ob sie Webserver spielen. Diese Überprüfung ist für mich aber nur inden Standard-Arbeitsstunden (9-17 Uhr) wichtig. Und auch nur ich soll dabei erstmal informiert werden.
Die ganzen Konfigurationen habe ich mal ins Wiki gelegt; das ist übersichtlicher.
Generell gilt: Wo die einzelnen Definitionen stehen ist fast unabhängig; in der nagios.cfg kann man ganze Verzeichnisse angeben in dem die Konfigurationsdateien zu finden sind. Diese müssen nur die Endung .cfg haben. Ob man jetzt sich das ganze nach Diensten, Rechnern oder anderer Logik folgend strukturiert bleibt jedem Selbst überlassen.
Ich habe für einige Applikationen einzelne Config-Dateien weil ich genau weiss dass ich nur dort dann ändern muss. Andere dienste (Web) sind bei den Hosts selbst definiert.
Was muss ich also definieren? Wenn ich ganz von vorne anfangen will: Eine Vorlage für die Rechner. in dem schreibe ich (weil ich faul bin
nur hinein, wie er heisst (host_name und alias) und die IP-Adresse (address).
Ich kann noch viel mehr definieren, aber anfangs will ich das gar nicht - ich will ja erstmal sehen was daraus entsteht.
Als nächstes frage ich mich: Was will ich auf den Rechner eigentlich monitoren? Also, erst einmal will ich generell ein Ping absetzen können, dann will ich einmal Web und einmal Mail testen können. Also muss ich dafür jeweils ein Kommando definieren - pro Rechner kann ich dann einen Dienst generieren der dieses Kommando nutzt. Wenn man sich die commands.cfg im Wiki genauer anschaut, sieht man das es dort Variablen gibt - $HOSTADDRESS$ zum Beispiel. Genau deswegen gibt es die Trennung zwischen Dienste und Check-Kommandos: beim Aufruf des Dienstes wird die Variable $HOSTADDRESS$ mit Inhalt gefüllt. Damit kann dieselbe Check-Kommandodefinition für verschiedene Dienste genommen werden; bei Pings zum Beispiel kann es interessanter sein; LAN-Strecken anders zu monitoren als WAN-Strecken.
Als nächstes definiere ich die Dienste (Services) pro Rechner, die ich abfragen will. Wie man in der Beschreibung sieht, soll serverA nur Web machen, serverB Web und Mail, serverC nur Mail.
Da mehr als ein Rechner die Dienste hat baue ich Service-Gruppen. In diesen Gruppen definiere ich den Namen der Gruppe und die Mitglieder - wenn ich weitere Rechner dazunehme zu dem Dienst, muss ich sie nur der Gruppe hinzufügen, mehr nicht.
Dementsprechend müssen auch die Dienste geschrieben werden. Wobei ich hier nur Beispiele mache und deswegen die eigene service.cfg dafür nehme.
Jetzt könnte auch klarwerden, wie bei den Checks das $HOSTADDRESS$ gefüllt wird und wie dann die Checks aufgerufen werden. $USER1$ ist übrigens ein Makro das vorher definiert wurde - da muss man den langen Pfad bis zum Check-Kommando nicht immer ausschreiben.
Zu guter Letzt habe ich ja gesagt die Dienste sollen nur zu bestimmten Zeiten getestet werden. das mache ich in der timeperiod.cfg
Auch wenn es unübersichtlich aussieht anfangs - wenn man sich einmal klargemacht hat wie man monitoren muss und wie, ist diese Konfiguration recht übersichtlich.
Es gibt verschiedene Sektionen die wichtig sind:
- Hosts
- Dienste(Services)
- Check-Kommandos
- Zeitperioden
- Kontakte, an den Benachrichtigungen gehen sollen.
Es gibt noch mehr, aber davon erzähle ich später.
Hosts: das sind die Geräte die überwacht werden sollen - das können Rechner sein (PCs, Unix, Windows...) aber auch Router oder Switche; oder auch Thermometer, sofern sie via tcp/ip abfragbar sind; eventuell snmp sprechen oder etwas ähnliches. Bei der Host-Konfiguration muss man mindestens eine IP-Adresse und/oder Hostnamen angeben, damit eindeutig geklärt ist welcher Rechner da gemonitored wird.
Dienste: sind die Programme oder Prozesse die von nagios überprüft werden. Jeder Dienst braucht als Mindestangabe den Host auf dem er laufen soll - sonst hätte die Definition auch keinen Sinn. Innerhalb eines Dienstes wird der Name (und Alias) definiert und auch welches Check-Kommando ausgeführt werden soll um den Dienst zu überprüfen.
Check-Kommandos: Das sind die Kommandos die ausgeführt werden um den Dienst zu überprüfen. Während beim Dienst noch nach Nagiosart Variablen übergeben werden (wie der Hostname des zu prüfenden Rechners) wird hier das Kommando definiert, inklusive dem Aufruf. Quasi eine Übersetzung von Nagios-Konfiguration in Überprüfungs-Konfiguration.
Zeitperioden: Manche Dienste sollen nur zu einer bestimmten Zeit oder an bestimmten Tagen überhaupt geprüft werden. Diese können definiert werden - zum Beispiel kann gesagt werden dass es unkritisch ist, wenn die Temperatur am Wochenende auf 40°C steigt; das könnte ja in Ordnung sein.
Kontakte: Falls es mal Probleme gibt, muss natürlich auch jemand benachrichtigt werden. Diese Personen werden in den Kontakten definiert - inklusive der Möglichkeit, wie die Nachrichten weitergegeben werden.
Für Recher, Dienste und Kontakte gibt es auch noch Gruppierungsmöglichkeiten; so dass man zum Beispiel 10 verschiedene Rechner zu einer Gruppe zusammenfassen kann (Kunde A, Kunde B...). Genauso kann man Dienste in einer Gruppe zusammenfassen - Dienste, die nicht gleich sind bzw. nicht dieselben Checks haben, aber dasselbe Ziel. Und Kontaktgruppen ermöglichen es, Nutzer zusammenzufassen, wenn jemand benachrichtigt werden soll.
Für alle diese Konfigurationsmöglichkeiten gibt es sogenannte Templates - Vorlagen. In den von Nagios mitglieferten Vorlagen sind alle möglichen Parameter bereits gesetzt und meistens auch sinnvoll. Ich habe allerdings festgestellt dass es für mich sinnvoller ist zusätzliche Gruppen (zum Beispiel bei den Diensten) zu bauen. Ich habe dann für den Dienst ein Template gebaut und musste dann pro Schnitstelle die ich überwachen wollte nur noch sagen wie sie heisst und welcher Port überwacht werden soll. Alles andere wurde durch den Gebrauch einer Vorlage dann standardsiert.
Ganz wichtig: in der Konfiguration kommt immer wieder der Parameter "Alias" vor. Das ist nicht nur der Alias für den Dienst/Rechner/wasauchimmer, sondern die Kurzerklärung des Dienstes wie er auf der Webseite angezeigt wird.
Wie hängt das nun miteinander alles zusammen? Ich fange mal oben an.
Ich habe eine Anzahl von Rechnern, von denen will ich einerseits wissen ob sie leben und ob sie Webserver spielen. Diese Überprüfung ist für mich aber nur inden Standard-Arbeitsstunden (9-17 Uhr) wichtig. Und auch nur ich soll dabei erstmal informiert werden.
Die ganzen Konfigurationen habe ich mal ins Wiki gelegt; das ist übersichtlicher.
Generell gilt: Wo die einzelnen Definitionen stehen ist fast unabhängig; in der nagios.cfg kann man ganze Verzeichnisse angeben in dem die Konfigurationsdateien zu finden sind. Diese müssen nur die Endung .cfg haben. Ob man jetzt sich das ganze nach Diensten, Rechnern oder anderer Logik folgend strukturiert bleibt jedem Selbst überlassen.
Ich habe für einige Applikationen einzelne Config-Dateien weil ich genau weiss dass ich nur dort dann ändern muss. Andere dienste (Web) sind bei den Hosts selbst definiert.
Was muss ich also definieren? Wenn ich ganz von vorne anfangen will: Eine Vorlage für die Rechner. in dem schreibe ich (weil ich faul bin
nur hinein, wie er heisst (host_name und alias) und die IP-Adresse (address).Ich kann noch viel mehr definieren, aber anfangs will ich das gar nicht - ich will ja erstmal sehen was daraus entsteht.
Als nächstes frage ich mich: Was will ich auf den Rechner eigentlich monitoren? Also, erst einmal will ich generell ein Ping absetzen können, dann will ich einmal Web und einmal Mail testen können. Also muss ich dafür jeweils ein Kommando definieren - pro Rechner kann ich dann einen Dienst generieren der dieses Kommando nutzt. Wenn man sich die commands.cfg im Wiki genauer anschaut, sieht man das es dort Variablen gibt - $HOSTADDRESS$ zum Beispiel. Genau deswegen gibt es die Trennung zwischen Dienste und Check-Kommandos: beim Aufruf des Dienstes wird die Variable $HOSTADDRESS$ mit Inhalt gefüllt. Damit kann dieselbe Check-Kommandodefinition für verschiedene Dienste genommen werden; bei Pings zum Beispiel kann es interessanter sein; LAN-Strecken anders zu monitoren als WAN-Strecken.
Als nächstes definiere ich die Dienste (Services) pro Rechner, die ich abfragen will. Wie man in der Beschreibung sieht, soll serverA nur Web machen, serverB Web und Mail, serverC nur Mail.
Da mehr als ein Rechner die Dienste hat baue ich Service-Gruppen. In diesen Gruppen definiere ich den Namen der Gruppe und die Mitglieder - wenn ich weitere Rechner dazunehme zu dem Dienst, muss ich sie nur der Gruppe hinzufügen, mehr nicht.
Dementsprechend müssen auch die Dienste geschrieben werden. Wobei ich hier nur Beispiele mache und deswegen die eigene service.cfg dafür nehme.
Jetzt könnte auch klarwerden, wie bei den Checks das $HOSTADDRESS$ gefüllt wird und wie dann die Checks aufgerufen werden. $USER1$ ist übrigens ein Makro das vorher definiert wurde - da muss man den langen Pfad bis zum Check-Kommando nicht immer ausschreiben.
Zu guter Letzt habe ich ja gesagt die Dienste sollen nur zu bestimmten Zeiten getestet werden. das mache ich in der timeperiod.cfg
Auch wenn es unübersichtlich aussieht anfangs - wenn man sich einmal klargemacht hat wie man monitoren muss und wie, ist diese Konfiguration recht übersichtlich.
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt