Intervallbezogenes Reporting mit Nagios, Livestatus und JasperReportServer

5. April 2013 | Von | Kategorie: Monitoring | Availability

Nach dem ich im letzten Artikel so generell über die Möglichkeiten des Reporting gesprochen habe, soll es in diesem Post mehr um die Möglichkeiten intervallbezogener Berichte gehen. Letztlich haben Berichte immer Bezug auf ein spezielles Intervall. Zum Beispiel ein Bericht über die Top-10-Services, die in der vergangenen Woche die  geringste Verfügbarkeit und damit im Umkehrschluss die meisten Probleme verursacht haben. Diese Intervalle gibt es immer – jedoch meine ich diese nicht, wenn ich von intervallbasiertem Reporting spreche.

Verdeutlichen will ich den erweiterten Intervallbezug an einem einfachen Szenario erläutern. Ein IT-Dienstleister hat eine vertragliche Zusicherung übernommen, dass dieser seinen Kunden Berichte über die Verfügbarkeiten der Dienste erstellt. Hierbei sollen die Verfügbarkeiten für jede Stunde separat ausgewiesen werden. Kein Dienstleister würde nun auf die Idee kommen, Berichte tatsächlich für jede Stunde separat zu erzeugen. Stattdessen wird die Anforderung zusammengefasst und ein Bericht über einen spezifizierten Zeitraum – im folgenden Beispiel ein Monat – erstellt.

intervalbased report

intervalbased report

intervallbased report

intervallbased report

Durch diesem Report ist einem Kunden recht schnell ersichtlich, zu welchen Zeiten ein Dienst auf das jeweilige Stundenintervall zu mehr als 90 % verfügbar war. Zusätzlich enthält der Bericht auch noch, die Information, wie der Tagesdurchschnitt aussah und die allgemeine Verfügbarkeit des Hosts. Gerade durch diese flexible Kombination verschiedenster Verfügbarkeitsdaten lassen sich schnell und einfach Zusammenhänge erkennen und erläutern.

Ab dem 29. März war nicht der HTTP-Service das Problem, sondern ganz offensichtlich gab es ab diesem Zeitpunkt ein Problem mit dem Host als solchen. Dieser war durch den Ausfall eines Routers für die Nagios-Maschine nicht erreichbar und somit aus Sicht von Nagios „unreachable“.

Durch die flexible Anpassung der Berichte, die mittels iReportDesigner erstellt und durch den JasperReportServer automatisch erzeugt und verschickt werden, ist eine schnelle Erfassung wesentlicher Informationen möglich. Darüber hinaus ist mein Vorgehen für das Reporting, dass ich die Verfügbarkeitsdaten (und auch die Definition von Service- und Hostgruppen, Kontakte und deren Zuständigkeiten …) regelmässig mittels Skript von unseren Monitor-Systemen abhole und in einer DB speichere. Hierdurch sind die Daten für die Berichterstattung verfügbar und können während der Berichterstellung einfach in Relation zueinander gesetzt werden.

Da der aufgezeigte Bericht auf einem festen Stundenintervall basiert, stellt sich natürlich die berechtigte Frage, wie diese Intervalle eigentlich konfigruiert werden. Ich habe mir hier zwei Dinge zu Nutze gemacht. Als Grundannahme habe ich festgelegt, dass ein Intervall generell für einen Host und die zugeordneten Dienste gilt. Daraus folgt dann auch, dass ein Intervall lediglich für einen Host definiert werden muss. Hierzu nutze ich Custom-Macros, die Nagios ermöglicht. Hierbei können beliebige Informationen  zum Beispiel für ein Hostobjekt hinterlegt werden.

Da wir bei uns auch WATO zur Konfiguration der Überwachung einsetzen habe ich die Multisite an diesem Punkt  entsprechend erweitert. So dass bei uns nun für Hostobjekte ein Reporting-Intervall hinterlegt werden kann. Der folgende Screenshot zeigt die Einstellungsmöglichkeit, die idealer Weise an einer einzigen Stelle definiert für alle Systeme greift. Aber auch für speziellere Berichte spezifisch für jeden Host angepasst werden kann.

Intervall per Multisite setzen und anpassen

Intervall per Multisite setzen und anpassen

Durch diesen Ansatz können recht schnell und effizient Verfügbarkeitsdaten mittels Livestatus-Socket intervallbasiert aus dem Nagios-Core (selbstverständlich geht dies auch mit einen Icinga-Core) abgefragt und gespeichert werden.

Die gewünschten Relationen und die Berichterstattung erfolgt dann in den weiteren Schritten unabhängig vom Monitoring. Was hier als expliziter Vorteil anzusehen ist, da der Nagios-Core nicht bei der Erstelllung komplexer Berichte in Mitleidenschaft gezogen werden kann.

Eine Anmerkung am Rande: Um auch stundenbasierte Verfügbarkeitsdaten abfragen zu können, empfiehlt es sich in der Nagios-Konfiguration die Log-Rotation auf „hourly“ und wie gehabt  „log_initial_states“ auf den Wert 1 zu setzen. Andernfalls ist es dem Autor bereits schon passiert, das für einzelne Stundenintervalle keine Verfügbarkeitsdaten geliefert wurden.

[UPDATE]

Beim ersten Post hatte ich ganz vergessen zu erläutern, wie ich denn die Konfiguration mittels WATO implementiert habe. Hierzu habe ich ein kleines Plugin für die WATO-Schnittstelle verfasst.


declare_host_attribute(
 NagiosTextAttribute(
 ("report_intervall"),
 ("_INTERVALL"),
 ("Intervall fuer Reports in Minuten"),
 ("Dieses Intervall definiert die minimale Zeitdauer, die im Rahmen technischer Berichterstattung beruecksichtigt werden soll. Die Angabe erfolgt in Minuten. Es ist darauf zu achten, dass die Angabe durch Multiplikation/ Division immer auf ein Stundenintervall zu berechnen ist. Beispiel: 6 Minuten funktioniert, weil auf volle Stunde hochzurechnen. Ebenso funktioniert auch 120 Minuten, weil dies auch auf volle Stunden zu berechnen ist. Im Gegensatz dazu geht 7 Minuten nicht!")),
 show_in_table = True,
 show_in_folder = True,
 show_in_form = True)

 

Dieses Pythoncode-Schnipselchen, habe ich dann unter /omd/sites/<sitename>/share/check_mk/web/plugins/wato/intervall.py angespeichert. WATO bindet es dann automatisch bei der Definition eines Host ein.

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Ping.fm Post to Reddit

Tags: | | | | | | |

Schreibe einen Kommentar

Fühle dich ermuntert einen Kommentar, Anmerkungen, Hinweise oder deine Ideen zum Thema zu hinterlassen. Wir freuen uns über deine Rückmeldung.