Datenbanküberwachung mit Nagios Ein Praxisbeispiel

Transkript

1 Datenbanküberwachung mit Nagios Ein Praxisbeispiel Nicole Schulze Kassenärztliche Vereinigung Niedersachsen Hannover Schlüsselworte: Nagios, Monitoring, Reporting Einleitung Das Open Source Monitoringtool Nagios lässt sich flexibel an die eigenen Wünsche anpassen und integriert sich problemlos in die Systemlandschaft neben Ticket-, Troubleshootingsystem oder anderem. Mithilfe von Nagios überwacht die Kassenärztliche Vereinigung Niedersachsen (KVN) ihre komplette Systemlandschaft. Wir haben ca. 60 Datenbanken auf Unix und Linux von einigen GB bis einigen TB im Einsatz. Der Vortrag beschränkt sich auf die ORACLE-Datenbanküberwachung und wird zeigen wie schon mit einfachen Mitteln gutes Monitoring betrieben werden kann. Dazu kann man viele fertige Plugins oder auch Eigenentwicklungen nutzen, ganz an die persönlichen Bedürfnisse angepasst. Die Einbindung des Reportingtools PNP liefert Trend- und Performancedaten aus der Vergangenheit und unterstützt das Kapazitätsmanagement oder auch die Analyse und Ursachenforschung im Fehlerfalle. Für die Konfiguration des Systems nutzt die KVN Textdateien und Versionierung mit Subversion. Damit, und durch die interne Objektorientierung von Nagios, lassen sich schnell und unkompliziert neue Systeme ins Monitoring aufnehmen. Die Benachrichtigung der zuständigen Personen im Fehlerfalle geschieht aktuell per . Eine telefonische Alarmierung samt Eskalierung bei Nichtannahme ist geplant. Die Alarmierung wird nach Prioritäten, Wochentagen und Uhrzeiten gesteuert. Per Webinterface findet ein personalisierter Zugriff auf das Monitoring statt. Hier ist zu jedem einzelnen Dienst eine URL im Wiki abgelegt, die direkt zur Dokumentation für eine Rufbereitschaft oder auch den normalen Betrieb führt. Während des Vortrags werde ich eine Beispielinstallation mit all den vorab erwähnten Möglichkeiten zeigen und erläutern. Dank der Flexibilität von Nagios wären auch viele andere Varianten möglich. Installation Die Installation von Nagios ist sehr einfach. Die Nagiossourcen und die Dokumentation findet man auf der Nagioshomepage [1]. Laut des Quickstart Installation Guides kann man innerhalb von 20 Minuten ein System aufbauen, dass für die Mehrheit der Anwender zum Start von Nagios ausreicht.

2 Als Systemvoraussetzung benötigt man die Pakete apache2 und C/C++ development libraries. Sowie jeweils den User und die Gruppe nagios. Danach konfiguriert und übersetzt man den Sourcecode und installiert ihn mit make install. Die restlichen Schritte der Anleitung abarbeiten und schon ist es geschafft. Die Startseite von Nagios kann im Browser aufgerufen werden: Abb. 1: Der erste Erfolg - Nagios-Startseite Plugins Nagios ist auf externe Plugins angewiesen. Nur durch das Zusammenspiel von Nagios und den Plugins entsteht das erfolgreiche Überwachungstool. Ursprünglich für Netzwerküberwachung entwickelt, kann Nagios dank der vielfältigen Plugins eigentlich alles monitoren. Die Plugins sind kleine Testprogramme, die eine definierte Rückmeldung haben müssen, damit Nagios diese verarbeiten kann. In der Regel setzt sich die Rückmeldung aus 3 Bestandteilen zusammen. Als erstes kommt der Rückgabewert des Programms: 0 für OK, 1 für WARNING, 2 für CRITICAL und 3 für UNKNOWN. Der zweite Teil ist die lesbare Ausgabe, die im Webinterface angezeigt wird. Und der dritte Teil sind die sogenannten Performancedaten, die von Add-ons wie PNP benötigt werden. Die Performancedaten sind wünschenswert, allerdings keine Pflicht. Plugins laufen sowohl direkt auf dem Nagiosserver, als auch auf den überwachten Maschinen. Fertige Plugins Es gibt offizielle Nagios Plugins [1] und viele Weitere, die die Nagios Community bereitstellt. Dort findet man unter anderem auch einige Plugins für die ORACLE- Überwachung [2]. Die fertigen Plugins liefern vielleicht schon die komplette Überwachung, die man sich wünscht. Wenn nicht, können Sie als Grundlage für die eigene Pluginprogrammierung dienen.

3 Selbstgeschriebene Plugins Stellt man fest, dass die fertigen Plugins nicht das gewünschte liefern, ist man schnell bei der eigenen Programmierung angelangt. Die KVN hat in der ORACLE-Überwachung einige selbstenwickelte Plugins laufen. Die Gründe sind vielfältig. Zum Beispiel sollten die Connects an die Datenbank minimiert werden, es waren weitere Inhalte bei den Perfomancedaten notwendig oder KVN-spezifische Themen mussten überwacht werden. Nagios-Konfiguration Die Nagioskonfiguration liegt bei der KVN in Textdateien. Die zentrale Datei ist hierbei nagios.cfg. Es wäre möglich alles in dieser Datei abzulegen. Doch sinnvoller ist es, die Konfiguration auf viele einzelne Dateien zu verteilen und mit verschiedenen Unterverzeichnissen zu strukturieren. Wir haben die Strukturierung über unsere Netzwerkstruktur realisiert. Während unserer aktuellen Migration von Nagios haben wir andere Aufteilungen diskutiert und sind doch bei unserer altbewährten Methode geblieben. Viele Überschneidungen hätte z.b. eine Aufteilung nach Verantwortlichkeiten gebracht, was die Übersichtlichkeit der Konfiguration nicht verbessen würde. Nagios unterscheidet zwischen Hosts und Services. Hosts sind standardmässig Rechner oder z.b. Router. Services sind die Dienste, die auf einem Host laufen. Bei der KVN haben wir auch Datenbanken als Hosts definiert und nennen sie logische Hosts. Durch diesen kleinen Trick lösen wir die Datenbanken in der Ansicht und der Konfiguration von dem Host auf dem sie laufen. Damit findet sich folgende Struktur in unserer Konfiguration: /usr/local/nagios/etc/ intern/ extern/ xxx.xxx.0.0/ xxx.xxx.0.0/ subnetxyz/ subnetxyz/ hosts.xxx.xxx.xxx.0 services.<servername> hosts-ora.<servername> services-ora.db_<oracle-sid> hosts.xxx.xxx.xxx.0 services.<servername> hosts-ora.<servername> services-ora.db_<oracle-sid> hosts.xxx.xxx.xxx.0 enthält alle Hostsdefinitionen der Hosts in diesem Netzwerksegment services.<servername>

4 enthält alle Services auf dem Host hosts-ora.<servername> enthält alle logischen ORACLE-Datenbankhosts auf dem Server services-ora.db_<oracle_sid> enthält alle Services zum logischen ORACLE-Datenbankhost Mit den vielen Neuerungen der aktuellen Nagiosversion könnten wir vermutlich diese Aufteilung aufheben. Da wir aber nur gute Erfahrungen mit den logischen Hosts gemacht haben, werden sie auch nach der Migration noch existieren. Webinterface Das Webinterface bietet einen guten Überblick über den aktuellen Status aller überwachten Server. Für die Benutzerverwaltung nutzt man am einfachsten und schnellsten htpasswd. Die Benutzernamen müssen den Nagioskontakten entsprechen. Jeder Nutzer sieht dann nur die Hosts und Services die seinem Kontakt zugeordnet sind. Benachrichtigung Die definierten Kontakte sind für den Zugriff auf das Webinterface wichtig. Noch wichtiger sind sie aber für die Benachrichtigung bei Problemen. Sobald ein Fehler im System erkannt wird, durchläuft Nagios diverse Schritte. Wurde für diesen Dienst eine Downtime hinterlegt? Soll für diesen Dienst zum aktuellen Zeitpunkt benachrichtigt werden? Welche Art der Benachrichtigung will der hinterlegte Kontakt erhalten? Muss nach einer bestehenden Zeitspanne eskaliert werden? Die Benachrichtigung ist, genauso wie die sonstige Überwachung, ein in der Konfiguration definiertes Kommando. Sie kann also problemlos an die eigenen Bedürfnisse angepasst werden. Begonnen haben wir bei der KVN mit SMS-Benachrichtigung. Mit Einführung von Black- Berrys haben wir dann zur -benachrichtigung gewechselt. Toll wäre eine Kombination verschiedenster Benachrichtigungsmethoden. Je nach Uhrzeit, Wichtigkeit des Dienstes oder Kontakt könnte dann z.b. ein Anruf erfolgen oder eine verschickt werden. Hier merken wir immer wieder in Diskussionen, dass ein Mix, die beste Lösung wäre. Bis zur Umsetzung einer telefonischen Benachrichtigung bei uns im Haus, können wir allein über die Betreffs der s und einer Filterfunktion im Mailprogramm die dringenden von den weniger dringenden mails unterscheiden. Im Rahmen der Migration ist das Benachrichtigungskonzept ein großer Bestandteil. Es sollte gut durchdacht sein. Zu viele unnütze Informationen sorgen dafür, dass die notwendigen und wichtigen Infos irgendwann nicht mehr wahrgenommen werden. Neben der Benachrichtigung per SMS, oder Anruf gibt es z.b. auch ein Browserplugin für den Firefox [4], den status monitor nagstamon [5] oder die Möglichkeit den Nagiosstatus per RSS feed zu erhalten. Performancedaten

5 Es gibt verschiedene Tools, die Performancedaten grafisch aufbereiten. Früher haben wir nagiosgrapher genutzt. Doch inzwischen nutzen wir schon seit mehr als 2 Jahren PNP [3]. Die URLs zu den Graphen der Add-Ons wird in der action_url der Hosts- und Servicedefinitionen abgelegt. Danach gelangt man einfach aus der Serviceübersicht zur Graphenansicht. Abb. 2: Serviceansicht mit hinterlegter action_url Abb. 3: PNP-Graphen Wiki Der Verweis zum Wiki wird per notes_url in der Hosts- bzw. Servicedefinition eingebunden. Dank der vorhersehbaren URLs kann man hier mit Variablen arbeiten, wie übrigens auch bei der action_url für PNP. Das macht die Konfiguration sehr simpel. Das Wiki gibt die Möglichkeit wichtige Infos zu den Hosts und Services für die Rufbereitschaften oder auch den Tagesbetrieb abzulegen. Durch die Einbindung im Nagioswebinterface sind sie im Bedarfsfall schnell zur Hand. Infos [1] Nagios-Homepage:

6 [2] Oracle-Plugins: [3] PNP4Nagios: [4] Nagios Checker: [5] nagstamon: Kontaktadresse: Nicole Schulze IT-Service_Zentrum Kassenärztliche Vereinigung Niedersachsen Berliner Allee 22 D Hannover Telefon: +49(0) Fax: +49(0) Internet: