Nagios Installation

Navigation

• Teil 1 - Einführung
• Teil 2 - Installation
• Teil 3 - Konfiguration
• Teil 4 - Grafische Visualisierung
• Teil 5 - Einbindung des OTRS
• Verschiedenes - Quellen und toDo Liste
• Plugins und Erweiterungen - AddOns

Danke

Wie es sich gehört, darf der Dank an all diejenigen nicht fehlen, die mir geholfen haben, Nagios ein wenig mehr zu verstehen, damit diese Anleitung geschrieben werden konnte. Auslöser war ein Projekt von meiner Firma ausgehend, in dem ich eine Menge lernen konnte. Dieses Projekt ist zwar noch nicht abgeschlossen, aber das wird sicher nicht mehr lang dauern ;-)

Da diese Einleitung nur einen Einblick geben kann, empfiehlt es sich in jedem Fall zu dem Buch Nagios System- und Netzwerk Monitoring von Wolfgang Barth zu greifen. Es ist wirklich sehr ausführlich geschrieben worden und lässt keine Wünsche offen. Des weiteren möchte ich mich bei den Helfern vom Nagios-portal.de bedanken, insbesondere bei Pitchfork (PnP), und Mess (check_multi), welche mir wirklich sehr geholfen haben. Natürlich darf ich nicht Alex Burger von SNMPTT vergessen. Weiteren Dank muss ich auch Bernd vom Nagios Process Business Projekt aussprechen. :-) Sollte ich jemanden vergessen haben, immer her damit ;-)

Nagios Installation auf Linux

Einleitung

Nagios ist (wie ihr sicher schon wisst, sonst würdet ihr nicht danach gesucht haben) eine Software, welche euch dabei helfen kann Probleme im Netzwerk schnell zu orten und zu beseitigen. Nagios selbst besteht nur aus einem Kern, welcher verschiedene Zustände interpretiert und sie z.B. über eine Weboberfläche anzeigt oder dem Administrator auf andere Art und Weise benachrichtigt, dass ein Problem vorliegt.

Über verschiedene Hilfsprogramme - im Nagios Jargon Plugins genannt - sammeln diese Informationen, und geben die an Nagios weiter. Dabei werden im Grunde vier Zustände unterschieden:

• OK - Alles ist in Ordnung
• Warning - Eine Warnschwelle wurde überschritten
• Critical - Die kritische Schwelle wurde erreicht
• Unknown - Der Status ist unbekannt

Auf welche Art und Weise diese Zustände zu einem Nagios Server gelangen, sind vielfältig und zumeist auf den jeweiligen Einsatzort optimiert.

In dieser Anleitung werde ich auf verschiedene Plugins eingehen und versuchen, ihren Einsatzzweck zu erläutern.

Hinweise

Für dieses Setup wurde ein Debian Etch als Untergrund eingesetzt, doch wird diese Anleitung sich zum Großteil auf die Quellpakete beziehen. Auf diese Weise sollte die zugrunde liegende Distribution eine untergeordnete Rolle spielen.

Das Setup

Bevor wir anfangen, sollten wir uns darüber im Klaren werden, was wir überwachen wollen. In der Regel sind es Standardabfragen wie Plattenplatz, Arbeitsspeicher, Auslastung des Systems etc. pp. . Dabei muss hier noch kein Halt sein. Dank der Abstraktion zwischen Rückgabewerten und der Interpretation eben dieser, werden keine Grenzen aufgestellt.

Existiert für eine bestimmte Aufgabe kein Plugin, so kann dies einfach erstellt werden. Es stellt sich nur die Frage, ob sich daraus ein tatsächlicher nutzen ließe, wie dies z.B. beim überwachen des Kaffeestandes der Fall wäre.

In diesem Beispiel erstelle ich mir mit Hilfe von Vmware eine Testumgebung, welches sich in der Regel dann auch auf ein produktives Netzwerk anwenden lässt. Ob nun Vmware, Xen (hier zum Testeinsatz kommt, od. eine andere Virtualisierungssoftware spielt dabei keine Rolle. Ich habe dabei folgendes Setup im Auge:

Auf dieser Grafik sind zwei Nagios Rechner vertreten, damit bei Bedarf ein zweiter Nagios Rechner die Arbeit des ausgefallenen übernehmen kann und die Benachrichtigung sowie Überwachung übernimmt.

Darunter befindet sich ein einzelner SSH Rechner die die Verbindung zwischen dem externen Netzwerk sowie der DMZ herstellt. Um die darunter liegenden Hosts und Services überprüfen zu können, muss Nagios diesen Rechner passieren.

Weitere Komponenten werden im Laufe der Anleitung hinzugefügt und sind in der Grafik noch nicht vertreten.

Zu überwachen

Nachdem der Netzwerkaufbau klar ist, stellt sich die nächste Frage: Was wollen wir überwachen? Auf dem Bild wird bereits angedeutet, welche Aufgabe dem jeweiligen Rechner zugesprochen wurde. Da wären die Klassiker wie Webserver, Mailserver und Datenbanken.

Diese bestehen natürlich aus einem Betriebssystem sowie diversen Diensten die zusammen eine Einheit bilden.

In der Nagiossprache sprechen wir von Hosts (Rechner) und Services (der Rest) welche zu überwachen wären. Wenn wir uns zunächst einmal die Hosts vornehmen hätten wir im groben folgende Komponente:

• Verfügbarkeit - Ist der Rechner an sich also ansprechbar
• Abhängigkeit - Um diesen Rechner zu erreichen, welche Wege müssen beschritten werden (Switches, Router ...).

Als nächstes folgt der Service, welcher in der Regel aufwendiger zu prüfen ist. Dabei lassen sich die Prüfungen in folgende Kategorien einordnen:

• Läuft der Dienst
• Sind die Ressourcen ausreichend
• Verhält sich das Programm gemäß dem Protokoll
• Ist er von einem anderen Service abhängig

Ist der Administrator sich dessen im Klaren geworden, kann er bereits beginnen ein paar Strukturen auf ein (vorzugsweise) Blatt Papier zu notieren, um einen Überblick zu erhalten. Eine Möglichkeit wäre diese:

Generische Tests

Typ	Zu überwachen
Festplattenspeicher	/var	/tmp	/home	/srv
Arbeitsspeicher	Ram	Swap
Netzwerk	eth0	eth1
CPU	Load
Prozesse	cron	xinetd	syslog

Für Server die eine bestimmte Aufgabe erfüllen, kommen entsprechend angepasste Prüfungen zum zuge. Es würde keinen Sinn ergeben, einen Dienst zu überprüfen, welcher nicht installiert wurde.

Da wären z.B.:

Spezifsche Tests

Typ	Zu überwachen
Apache	Reaktionszeit	SSL Zertifikat gültig
MYSQL	Auslastung	Funktionsfähig	Speicherverbrauch
SSH	Dienst läuft	Schlüssel sind gültig
Etc.	...	...

Die Möglichkeiten zur Überprüfung können also je nach Wunsch sehr filigran ausfallen. Dabei tritt jedoch bei einer zu feinen Überprüfung unter Umständen das Problem auf, das der Administrator mit einer Flut von Benachrichtigungen zu kämpfen hat. Daher sollte mit Bedacht nur überwacht werden, was tatsächlich nötig ist, und nicht der Prämisse folgen alles zu Überwachen, weil sich die Möglichkeit bietet.

Jeder Host und Service Prüfcheck erzeugt sowohl auf der zu überprüfenden Komponente eine Last, sondern auch auf dem Nagios Rechner. In der Summe können dies Belastungen für beide Seiten darstellen, die einen Einfluss auf die Produktivität haben können.

Benachrichtigungen

Ein sehr viel schwieriger Teil bei dem Aufbau einer Überwachung mittels Nagios betrifft mit hoher Wahrscheinlichkeit die Benachrichtigung. Mit ihm steht und fällt, ob die Benachrichtigungen ihre gewünschte Wirkung erzielen und den Administrator oder weiteren Kontakt über ein akutes Problem informieren, oder ob wirklich wichtige Nachrichten in der Flut untergehen.

Das Nagios Benachrichtigungssystem ist ein sehr ausgefeiltes und beherrscht seit der Version 3 neue Möglichkeiten wie Eskalationen, Ausnahmen oder unterstützt auch Schichten.

Von diesen Möglichkeiten gebrauch zu machen lohnt sich aus der Sicht des Autors aber erst bei einer ausgewachsenen IT Abteilung, in welcher auch z.B Schichtarbeiten anfallen. Ist dies nicht der Fall, sollte das Konzept nach dem K.I.S (Keep it simple) Prinzip einfach gehalten werden, da bei einem Fehler unter Umständen Nachrichten verloren gehen können.

Dem Prinzip folgend, bietet sich eine Prioritäten Struktur an. Dabei wird unterschieden zwischen sehr wichtigen und weniger wichtigen Benachrichtigungen. Dieses Konzept bietet den Vorteil sich flexibel zu verhalten, den Überblick zu waren und vor allem die optimale Unterstützung eines Ticketsystem zu. Doch dazu gleich mehr. Eine einfache Grafik soll dieses Konzept aufzeigen:

Erläuterung:

• • Priorität 1:

In der Priorität 1 werden keine einzelnen Komponenten aufgenommen sondern nur der Status eines Gesamtbildes. Darunter zu verstehen ist die Tatsache, das eine Dienstleistung nicht nur aus einer Komponente besteht, sondern sich aus mehreren zusammensetzt.

Ein Beispiel: Damit ein Kunde seine E-Mail versenden und empfangen kann, muss zunächst einmal eine Verbindung mit dem SMTP Dienst hergestellt werden können. Dazu muss der Server erreichbar sein; der Dienst laufen und auch korrekt konfiguriert worden sein. Für den Empfang gilt selbiges mit dem Unterschied, das ein POP3/IMAP Dienst ansprechbar sein muss. Des weiteren ist auch ein SPAM- und Virusscanner mit von der Partie. Erst diese zusammen ergeben ein vollständig nutzbares E-Mail System.

Würde nun also z.B der Virenscanner hängen, könnte dies unter Umständen erst auffallen, wenn der Kunde beklagt, er würde keine E-Mails mehr empfangen oder seine Kunden keine von ihm empfangen. Verknüpft man nun alle Dienste und sieht sie als Eins, würde der Status entsprechend von OK auf Kritisch wechseln, statt dass nur ein einzelner Dienst auf Kritisch steht.

Auf diese Weise wird sehr viel schneller ersichtlich, wenn ein Problem vorliegt.

Die entsprechende Benachrichtigung solle dann nicht allzulang auf sich warten lassen. Wie in der Grafik bereits angedeutet, wird in dieser Anleitung noch zusätzlich ein Ticketsystem zum Einsatz kommen. Es soll die anfallenden Probleme in eine entsprechende Queue einsortieren. Auch soll von dort die Benachrichtigung des Administrators erfolgen.

Um jedoch bei kritischen Problemen den Admin zu erreichen, werden mehrere Wege eingeschlagen. Zum einen wird eine Kurznachricht per SMS versendet. Dann erfolgt eine persönliche Nachricht per E-Mail, um bei einem Ausfall des Ticketsystems dennoch sein Ziel zu erreichen. Im Ticketsystem wird dann ebenfalls noch eine Nachricht generiert und dem Kontakt zugestellt.

• • Priorität 2:

Hier gibt es noch keinen Unterschied zur Priorität 1, doch kann diese genutzt werden, um z.B. Backend Software ebenfalls abfangen zu können. soll heißen, Software mit der ein Kunde keinen direkten Kontakt hat, aber welche die internen Abläufe betreffen, wie z.B Bestellsysteme od. Support.

• • Priorität 3:

In diese Priorität laufen z.B. Probleme hinein, um die sich ein Admin möglichst zeitnah kümmern sollte. Dies kann derAausfall einer Node darstellen, innerhalb eines geclusterten Dienstes. Das Gesamtsystem wird von dem Ausfall nocht nicht direkt beeinflußt, dank der Redundanz. Die Benachrichtigung erfolgt nur über das Ticketsystem. Wird das Problem nicht innerhalb einer gesetzten Frist behoben, so wird das Problem in die Priorität 2 verschoben. Damit lässt sich das Eskalationmanagment vom Nagios ins Ticketsystem verlagern.

• • Priorität 4:

In der letzten Prioritätsstufe sind nur kleinere Probleme zu lösen, wie sich füllende od. ausgefallen Raid Festplatten; Warnungen in Logdateien etc. pp.

Auch hier erfolgt die Benachrichtigung nur über das Ticketsystems.

En Detail

Welche Programme und Plugins zum Einsatz kommen

Abgesehen von den Standardplugins für die Überwachung der normalen Ressourcen wie Plattenspeicher, Arbeitsspeicher etc. kommen noch einige besondere Plugins hinzu, welche hier kurz erläutert werden. Ihre Installation und Anwendung findet in den Folgeseiten statt.

check_multi

check_multi ist kein Nagiosplugin im eigentlichen Sinne. Es ist ein Plugin welches aufgerufen und seinerseits die eigentlichen Plugins zur Statusabfrage aufruft. Die Grafik (in Anlehnung an der Grafik von der check_multi Seite) soll dieses verdeutlichen:

Damit ergibt sich unter anderem die Möglichkeit viele Checks zu vereinfachen und zusammen zufassen. Das dies möglich ist, verdanken wir Nagios 3 und der Option, mehrzeilige Ausgaben zu verarbeiten. Bisher konnte nur eine begrenzte Menge an Informationen, die ein Plugin zurückgab, ausgewertet werden. Es erfolgte dann schlicht eine gekürzte Ausgabe. Mit Nagios 3 wurde dieses Limit weit hinauf gesetzt. Genau dies macht sich check_multi zu nutze.

Es ruft die vorher konfigurierten Plugins auf, welche ihren Status auf der Standardausgaben ausgeben, incl (sofern vorhanden) den Performancewerten und reicht sie an Nagios wie ein normales Plugin weiter. Nagios kann danach jede Zeile einzeln auswerten.

Damit lassen sich insb. generische Tests zusammenfassen und verhelfen uns so zu einem besseren Überblick. Statt also pro Host n Standardtests einzutragen, reicht nun ein einzelner.

Eine weitere Möglichkeit, die check_multi bietet, liegt darin Cluster Setups zu berücksichtigen. Ein Status ist auch dann noch O.K, wenn von 5 Webserver nur noch 2 in Betrieb sind. Auch lässt sich wieder Status umkehren: wenn nur ein NFS Spiegel Server laufen darf, ist der Status kritisch, wenn mehr als einer läuft (split brain).

check_by_ssh

check_by_ssh ist ebenfalls kein herkömmliches Plugin. Anders als check_ssh überprüft er nicht den Status eines SSH Servers, sondern dient dazu ein Plugin über einen SSH Tunnel aufzurufen. Auf diese Weise kann auch der Status eines Host abgefragt werden, wenn er nur per SSH erreichbar ist, oder sicher über öffentliche Netze.

In der Regel wird auf dem Zielhost ein Benutzer erstellt, in dessen Heimatverzeichnis der öffentliche SSH Schlüssel (publickey authentification) liegt. Nagios loggt sich dann mit diesem Benutzer ein und führt den Check aus. Diese Art der Remote Überprüfung stellt einerseits nur sehr geringe Anforderungen an die Firewall und die zu laufenden Dienste, auf der anderen Seite ist der Konfigurationsaufwand nicht zu verachten.

check_nrpe

check_nrpe dient ebenfalls dazu, auf einem Remote Host Plugins aufzurufen. Das Gegenstück zum check_nrpe ist der NRPE Daemon, welcher auf dem zu prüfenden Host laufen muss. Er bietet den Vorteil, das kein eigener (Shell)Benutzer erforderlich ist, und seine Daten ebenfalls verschlüsselt über das Netz übertragen kann. Er ist leicht in der Konfiguration, erfordert jedoch einen offenen Port in der Firewall. Bei mehreren Checks ist der NRPE dem check_by_ssh vorzuziehen, da er eine geringe Last verursacht. Da er über einen TCP Wrapper (xinetd/inetd) aufgerufen werden kann, lässt er sich auch nur gezielt von vorher konfigurierten Hosts aufrufen.

NSCA

NSCA nimmt eine Sondestellung ein. Während Nagios mit check_nrpe und check_by_ssh selbst den Check auslöst, also aktiv vorgeht, ist es beim NSCA umgekehrt. Der Remote Host ruft seine Checks selbst auf (z.B. via Cron) und sendet die Ergebnisse per send_nsca an den Daemon nsca, welcher auf dem Monitoring (Nagios) Server läuft. Dies wird als passive check bezeichnet. Nagios wartet also auf die Ergebnisse vom Remote Host. Wenn diese nach einem konfigurierten Wert nicht eintreffen, deklariert Nagios den Status als unbekannt.

Diese Art von Prüfungen kommen immer dann zum Einsatz, wenn die vorhandene Infrastruktur od. Policy Regeln keinen Zugang zum Remote Host zulassen. In unserem Fall werden wir NSCA verwenden, um die Statusinformationen zu einem zweiten Nagiosserver zu übertragen.

OTRS

OTRS gehört nicht zu den Nagios Plugins. Es ist ein webbasiertes Ticketsystem, welches in den Häusern von der damaligen Firma SuSE GmbH entstanden ist. Sie benötigten ein flexibles System, um eingehende Probleme koordiniert zu verarbeiten. Dieses aus der Notwendigkeit entstandene Perl- Programm, wurde es dann unter der GPL veröffentlicht.

Nach kurzer Zeit setzten es sehr viele Firmen ein, wodurch der Support und die Nachfrage am OTRS so stark wuchs, das daraus dann eine eigene Firma entstand.

OTRS lässt sich durch Module erweitern und eines von ihnen ist das Monitoring Modul. Seine Aufgabe ist es, Mails die ein Mail Modul abruft zu durchsuchen und entsprechend zu bearbeiten. Dabei wird der Betreff als auch der Body durchsucht. Findet das Modul eine Mail von Nagios, wird festgestellt, ob bereits ein Ticket zu dieser Mail besteht. Ist noch keines vorhanden, wird ein solches erstellt. Sendet Nagios eine weitere Benachrichtigung, z.B. mit einem Status Recover so wird das Ticket automatisch geschlossen. Bleibt das Problem bestehen, wird die Mail verworfen.

Auf diese Weise können wir dem Nagios- Benachrichtigungssystem ein wenig die Komplexität nehmen und OTRS einspannen.

NDOUtils

Nagios besaß einst einen eingebauten Datenbank- Support für MySQL. Aber der Version 2.x ist diese Unterstützung entfernt worden, um den Nagioskern möglichst schlank zu halten. Die Unterstützung für die Datenbank wurde nun über die NDOUtils wieder für Nagios3 verfügbar. Über eine spezielle Schnittstelle - dem event_broker - teilt Nagios dem NDO Daemon eine Statusveränderung mit. Die aktuelle Konfiguration von jedem Host, jedem Service, sowie deren Status, ist somit in der Datenbank vertreten und kann von jeder Anwendung ausgelesen und interpretiert werden.

Von dieser Möglichkeit machen diverse Programme Gebrauch wie z.B. NagVis und auch der Process Business Viewer. Auch wird davon ausgegangen, das zukünftige Nagios Versionen (Vermutlich ab 4.x) die NDOUtils fester Bestandteil einer Nagios Installation werden.

Leider befinden sich die NDOUtils derzeit noch in starker Entwicklung, sodass nur mit Bedacht auf eine andere Version (zumeist neuerer) aktualisiert werden sollte. Wer mehr über die Funktionsweise der Utils erfahren möchte, dem sei diese PDF ans Herz gelegt, welche die Arbeitsweise genau erläutert.

PnP

PnP ist ein akronym und steht für PnP is not Perfparse und dient zur Verarbeitung der Performancedaten. Damit wird auf die Teils aufwendige Konfiguration von Perfparser hingewiesen. PnP schickt sich an, sehr einfach zu installieren zu lassen, und diesem Anspruch wird es gerecht. PnP ist eine PHP Anwendung und generiert aus den Performancewerten der Plugins anschauliche Grafiken mittels RRD.

NagVis

NagVis ist eine PHP Anwendung die eine Karte nutzt, um den Status von Hosts, Diensten od. Gruppen darzustellen (Screenshots). Die Karte kann z.B. mittels eines Grafikprogramms, Dia/Visio oder einer herkömmlichen Kamera erstellt werden. Dieses Bild wird dann mit aktiven Symbolen im NagVis ausgestattet, welche den aktuellen Zustand der Komponente wiederspiegeln. Dieser Status wird aus einer Datenbank ausgelesen, die von den NDOUtils und Nagios gefüllt werden. Auf diese Weise können ganze Rechenzentren, Unternehmensstandorte etc. auf eine Weise abgebildet werden, die schnell erkennen lassen, wo ein Problem aufgetreten ist.

Nagios Process Business View

Dieses Nagios Addon entstand aus der Notwendigkeit heraus, Geschäftsprozesse im Nagios abbilden zu wollen. Bisher haben wir jeden einzelnen Dienst od. Host für sich allein betrachtet, doch nutzt ein Webserver nichts, wenn die dazu gehörige Datenbank für den Onlineshop streikt. Zwar wird Nagios den Status der Datenbank entsprechend ausweisen, doch der Kunde kann den Shop nicht nutzen, auch wenn der Webserver den Status O.K besitzt. Das Selbe gilt auch für die weiteren nötigen Komponenten wie Netzwerk, Mail und andere involvierte Server und Dienste.

Ein funktionierender Online-Shop ist also die Summe seiner einzelnen Bestandteile. Und hier kommt das Plugin zum Einsatz. Mittels einer Konfigurationsdatei lassen sich Hosts und Services mit einander Verknüpfen und auf der Nagioswebseite als ein Host und Service abbilden. Mittels der logischen Operatoren UND/ODER können auch Cluster Setups berücksichtigt werden. Der große Vorteil dieser Fake Hosts/Services besteht darin, das auch sämtliche Nagios Mechanismen wie die Benachrichtigung und Historie etc. greifen.

SNMPTT

Eine weitere Möglichkeit an einen Status zu kommen, besteht in der Nutzung von SNMP. Dies kann über zwei Wege erfolgen. Variante 1 besteht darin, das diverse SNMP Plugins einen SNMP Daemon über z.B. den Plattenplatz, Traffic oder Ram befragen. Dabei wird auch Nagios hier wieder selbst aktiv. Variante 2 besteht darin, das ein Gerät nicht befragt wird, sondern von sich aus Aktiv eine Nachricht - ein sogenannter Trap -(zumeist in zwei UDP Pakete) an einen Empfänger - Trapeceiver - sendet. Der Empfänger muss diese Nachricht dann entsprechend auswerten oder an ein Programm weiterreichen.

Unter den Unix System kommt zum einen ein Daemon aus z.B. den net-snmp Tools zum Einsatz, der als Empfänger fungiert. Hat der Daemon einen Trap entgegen genommen, ruft er das Perl Programm snmptt auf, wertet die darin enthaltenen Informationen aus und ordnet ihm einen Status zu. Dieser Trap landet nach einer erfolgreichen Identifizierung in einer Datenbank, worauf wiederum ein Nagios Plugin zugreift und einen Status im Nagios generiert.

Terminologie Hinweise

Auf den nachfolgenden Unterseiten werden folgende Terminologie Hinweise zu finden sein:

host:# Komando

Hier werden Kommandos aufgeführt, die auf dem jeweiligen Rechner auszuführen sind

foo bla Wert x

Wenn dieses Symbol auftaucht, handelt es sich um den Inhalt einer Konfigurations- Datei

Hinweis

Generelle Information: blub fasel

Hier sind Hinweise und Tipps zu lesen

Hier gilt es aufzupassen

Installation

Hier geht es nun zur Installation der einzelnen Komponenten.

---