Service Level Agreements gehören zum lästigen Teil der Admin-Arbeit – wer ihre Einhaltung überprüfen will, muss die Ausfallzeiten von Diensten addieren und je nach Tageszeit bewerten. Eine Nagios-Erweiterung kann das besser und warnt von sich aus, wenn ein Verstoß droht.

Wer jederzeit wissen will, welche seiner Server, Router und Dienste gerade ausgefallen sind, fährt mit Nagios bestens. Das Monitoring-Multitalent überwacht beliebige Komponenten und reagiert auf Unregelmäßigkeiten. Doch um Service Level Agreements haben sich die Entwickler noch nicht gekümmert, Nagios liefert nur die nackten Zahlen, wenn etwas hakt. Selbst die im Business-Reporting-Artikel in diesem Heft vorgestellte Technik stellt nur fest, wann welcher Businessprozess versagt hat. Ob die entdeckten Ausfälle im Rahmen des Erträglichen bleiben, muss der Admin dann selbst herausfinden.

Dieser Rahmen des Erträglichen ist üblicherweise in SLAs spezifiziert. Service Level Agreements sind Vereinbarungen zwischen einem Service Provider und seinen Kunden. Oft ist der Service Provider einfach die firmeneigene IT-Abteilung, besonders interessant sind SLAs aber bei externen Dienstleistern. Die IT Infrastructure Library (ITIL, siehe [1]) kennt diese Form der SLAs unter dem Namen Contracts.

Ausfallzeiten

Ein SLA spezifiziert unter anderem die Soll-Verfügbarkeit eines Dienstes über einen gewissen Zeitraum hinweg. Als Service-Zeiträume sind üblicherweise die Büroarbeitszeiten definiert, etwa Montag bis Freitag von 07:00 bis 17:00 Uhr. Innerhalb dieser Zeiträume darf der Dienst maximal eine vereinbarte Zeitdauer ausfallen.

Meist sind die Ausfallzeiten nicht direkt, sondern indirekt als Verfügbarkeit angegeben, beispielsweise 99,9 Prozent im Monat. Der SLA-Vertrag legt auch fest, unter welchen Bedingungen ein Dienst als nicht mehr erreichbar gilt.

Störungsmelder

Nagios kennt die SLA-Regeln nicht, aber alle Techniken, um Ausfälle zu erkennen. Eine vom Autor dieses Artikels stammende neue Erweiterung [2] nutzt einen Eventhandler, der bei relevanten Diensten jeden Ausfall in einer eigenen Datenbank protokolliert (Abbildung 1). Ein Reporting-Skript verarbeitet und korreliert diese Einträge.

Abbildung 1: Nagios überwacht das Firmennetz und meldet relevante Ausfälle per SLA-Eventhandler. Der protokolliert alles in einer Log-Tabelle. Aus diesen Daten ermittelt das Reporting-Skript den Stand der SLA-Einhaltung. Ein SLA-Check-Plugin übergibt den Status aus der Report-Tabelle an Nagios.

Den aktuellen Stand der SLA-Zeiten ermittelt periodisch ein Nagios-Plugin, sodass die komplette Nagios-Maschinerie darauf reagieren kann. Droht eine SLA-Verletzung, feuert ein eigener Event, der beliebige Alerting-Mechanismen in Gang setzt. So erfährt etwa der IT-Leiter per SMS, dass seine Dienste das SLA des wichtigsten Kunden demnächst überschreiten. Von einzelnen Ausfallmeldungen bleibt er aber verschont.

Nagios-Erweiterung

Der Quellcode der NagioSLA-Erweiterung steht auf Sourceforge [2] zum Download bereit. Programmiert ist NagioSLA in Perl. Der Code greift mit dem Perl-Modul DBI::MySQL auf die MySQL-Datenbank zu. Für den Betrieb setzt die Erweiterung Nagios mit NDO-Utils voraus (Nagios Data Out). Die gelten zwar noch als experimentelles Addon, haben sich in der Praxis aber schon bestens bewährt. Eine Portierung von NagioSLA auf andere Datenbanken als MySQL ist geplant, jedoch funktionieren die NDO-Utils derzeit auch nur mit MySQL.

Nagios ruft einen Eventhandler auf, wenn eine überwachte Komponente ihren Status ändert, zum Beispiel ein Ping auf Server 1 statt »OK« plötzlich »Critical« liefert, weil der Server nicht mehr erreichbar ist. Die NagioSLA-Erweiterung nutzt diesen Mechanismus. Der neue Eventhandler speichert den Namen der Dienste, die in den »Critical«-Status eintreten, gemeinsam mit deren Hostnamen und einem Zeitstempel in der SLA-Log-Tabelle der Datenbank (Tabelle 2). Ist Server 1 wieder per Ping erreichbar, ruft Nagios den Handler erneut auf und dieser speichert den »OK«-Event.

Beide Aktionen laufen unabhängig von der Servicezeit und den SLA-Bedingungen. Fügt der SLA-Verantwortliche im Nachhinein Feiertage oder Wartungsfenster ein, verändern diese Einstellungen die gesammelten Daten nicht, sondern korrigieren nur den Report. Sogar ein Planspielmodus wäre möglich, bei dem das Reporting-Skript mit realen Logdaten und hypothetischen SLA-Bedingungen arbeitet.

Reporting-Skript

Das Report-Skript korreliert die erfassten Daten (Abbildung 2). Dazu sammelt es zunächst »Critical«- und »OK«-Events in einzelne Objekte und gleicht die Servicezeiten ab. Liegt der Zeitpunkt des Statuswechsels von »OK« zu »Critical« innerhalb der Servicezeit, behält das Skript den Unix-Timestamp. Beim Statuswechsel zurück subtrahiert es die Ausfalldauer von den verbleibenden Sekunden bis zur SLA-Verletzung. Die Ausfalldauer ist im einfachsten Fall die Zeitdifferenz zwischen »Critical« und »OK«.

Abbildung 2: Das Reporting-Skript der NagioSLA-Erweiterung korreliert alle »Critical«- und »OK«-Events. Dabei berücksichtigt es Servicezeiten – Ausfälle außerhalb der Servicezeit fallen nicht ins Gewicht. Dieser einfache Algorithmus geht davon aus, dass Ausfall und Recovery am selben Tag stattfinden.

Liegen Anfang oder Ende der Ausfallzeit jenseits der Servicezeiten, dann zieht das Reporting-Skript derzeit einfach die Zeitdifferenz zum jeweils nächsten Anfang oder Ende der Servicezeit ab. Korrekt wäre eine Schleife, die auch Ausfälle berücksichtigt, die sich über mehrere Servicezeit-Perioden erstrecken. Dieser bessere Algorithmus sollte die Ausfallzeiten innerhalb und außerhalb der Serviceperioden getrennt summieren und somit auch die Einhaltung so genannter Non-Servicetime-SLAs überwachen. Das Diagramm in Abbildung 2 beschränkt sich auf den vereinfachten Fall.

Aus dem resultierenden Array korrelierter Events entfernt das Skript anschließend Duplikate und schreibt die korrigierte Fassung in die Report-Tabelle.

Datenbankdesign

Die Datenbank besteht aus diesen vier Tabellen: »sla_config«, »sla_exclusion«, »sla_log« und »sla_report«. Den Inhalt der Datenbanktabellen zeigt Tabelle 1. In »sla_config« konfiguriert jede Zeile die SLA-Parameter eines Dienstes. Die Servicezeiten für jeden Wochentag sind je in einer Spalte im Format hh:mm-hh:mm einzutragen, beispielsweise »07:00-17:00«. Die Spalte »service_seconds« nennt die Anzahl der SLA-Sekunden, also die Zeitdauer, die der Dienst binnen eines Monats innerhalb der Servicezeiten ausfallen darf.

Zeitrechnung

Eine Verfügbarkeit von 99,9 Prozent über ein Jahr bedeutet, dass der Service für 31 536 Sekunden offline sein darf (8 Stunden und 45 Minuten), falls die Servicezeit rund um die Uhr geht. Eine eventuelle Deckelung der Ausfallzeiten außerhalb der Servicezeiten nimmt der Parameter »no_service_seconds« auf. In die Spalte »dependency« kommen alle Hosts mit ihren Services, von denen die SLA-Vereinbarung abhängt, beispielsweise »Server1:Apache, Server2:DNS«. Der Eintrag in »service_name« soll den Kunden und den Service benennen, für den der SLA gilt, etwa »Marketing-Abteilung:Mailing«.

Die Tabelle »sla_exclusion« enthält Zeiträume, an denen kein Service stattfindet, zum Beispiel geplante Wartungsfenster, Feiertage und Betriebsferien. In »date« steht der Tag und in »time« der Zeitraum, im Gegensatz zu den Wochentagen in »sla_config« bezeichnet die »time«-Spalte hier aber No-Service-Zeiten.

Das Protokoll aller Ausfälle landet in »sla_log«. Hier trägt das Eventhandler-Skript alle Ereignisse ein, für die es von Nagios aufgerufen wird. In »timestamp« steht der Zeitpunkt, in »state« der neue Zustand und in »host_service« finden sich der Host und der ausgefallene Dienst. Das Reporting-Skript verzeichnet dann in »sla_report«, für welchen Service noch wie viele Sekunden bleiben, bevor es zu einer SLA-Verletzung kommt.

Integration

Damit Nagios den SLA-Eventhandler kennt und aufruft, ist zunächst ein neues Kommando »sla_event« in der Nagios-Konfigurationsdatei »commands.cfg« anzulegen. Es ruft das Skript »sla_event.pl« auf und übergibt ihm den Nagios-Hostnamen sowie weitere Parameter:

define command {
  command_name  sla_event
  command_line  $USER1$/sla_event.pl $NAGIOS_HOSTNAME$ [...]
}

Diesen Eventhandler fügt der Admin nun zu den betroffenen Diensten hinzu. Dazu trägt er bei den jeweiligen »define service«-Blöcken die Zeile »event_handler sla_event« ein.

Meldet ein Nagios-Check einen Soft-Critical-Status, passiert noch nichts, da das Skript erst beim Hard-Critical-Status in Aktion tritt. Im Falle eines Hard-Status legt der Eventhandler einen Eintrag in der MySQL-Datenbank in der Tabelle »sla_log« an. Die erste Zeile von Tabelle 2 zeigt diesen Eintrag. Wenn der Service wieder läuft, ruft Nagios den Eventhandler erneut auf, der nun einen »OK«-Eintrag protokolliert (zweite Zeile).

Beispiel

Angenommen die Firma New Media hätte bei ihrem IT-Dienstleister einen Service namens »Mail« bestellt und für diesen eine Verfügbarkeit von 99,9 Prozent pro Monat mit Serviceperiode 24/7 bezahlt. Das bedeutet, dass alle dazu nötigen Services 2592 Sekunden (gut 43 Minuten) pro Monat offline sein dürfen. Die dazu passenden Einträge in »sla_config« sind in Tabelle 1 in der Spalte “Beispiel” zu sehen. Der Server »nmdns1« beherbergt dabei den DNS-Dienst, der für den Mail-Service unabdingbar ist, während der SMTP-Dienst und die Mailqueue auf »nmsmtp1« laufen.

Ist der oben skizzierte 90 Sekunden dauernde Ausfall der einzige, setzt das Reporting-Skript in der Datenbanktabelle »sla_report« den passenden Eintrag auf 2502. Diese Daten lassen sich in einen Report gießen, etwa per Open Office und dessen Datenbank-Modul.

Eleganter ist der Ansatz, Nagios auch für die Darstellung und Auswertung des SLA-Reports zu verpflichten. Zu diesem Zweck enthält das NagioSLA-Projekt ein Nagios-Plugin (auch Check genannt), das ab einem konfigurierbaren Prozentsatz von verbrauchter SLA-Zeit Alarm schlägt. Das eignet sich etwa, um den Servicemanager rechtzeitig zu informieren, wenn eine SLA-Verletzung droht. Es stehen alle Alerting-Mechanismen von Nagios zur Verfügung.

Ebenso ist es möglich, die Daten an die diversen Nagios-Grapher-Erweiterungen weiterzureichen und so grafisch aufzubereiten. Abbildung 3 zeigt NagioSLA zusammen mit PNP [4]. Das Plugin gibt die Anzahl der verbleibenden SLA-Sekunden wahlweise als Ganzzahlen oder als Prozentsätze aus. Der Verlauf ist in beiden Fällen zwar identisch, beim Interpretieren der Werte auf der y-Achse helfen Prozentangaben aber meist mehr als hohe Sekundenbeträge.

Abbildung 3: Die Nagios-PNP-Erweiterung stellt hier den Verlauf der verbleibenden SLA-Zeit dar. Ein eigener Check (Nagios-Plugin) ruft dazu periodisch die Ergebnisse des SLA-Reports ab.

Ausbaufähig

Die Grafiken des PNP-Plugins sind ein pragmatischer Ansatz, um die Entwicklung und den aktuellen Stand der SLA-Einhaltung im Blick zu behalten. Durch das Check-Plugin ist es auch möglich, bei drohenden Verstößen automatisiert den Verantwortlichen zu verständigen. Sowohl bei der Modellierung von SLA-Verträgen als auch beim Reporting bleibt aber Raum für Verbesserungen, zum Beispiel in Form einer Vorlage für Management-taugliche Reports in Open Office. Bei Erscheinen dieses Hefts sollte Nagiosexchange [3] das NagioSLA-Plugin listen und zur Projekthomepage auf Sourceforge [2] verlinken. (fjl)