Erweiterte Verfügbarkeiten (SLAs)

In Checkmk können Sie Verfügbarkeiten auswerten und für diese auch eine rudimentäre SLA-Auswertung konfigurieren. Nun ist die absolute Verfügbarkeit in einem Zeitraum nicht sonderlich aussagekräftig. Dazu ein extremes Beispiel: Eine Verfügbarkeit von 99,9 Prozent würde weniger als 10 Stunden Downtime pro Jahr zulassen — genau genommen sogar nur 8 Stunden, 45 Minuten und 36 Sekunden. Verteilen sich diese auf etwas mehr als 43 Minuten pro Monat, mag das für viele Systeme in Ordnung sein. Eine ganze Stunde Ausfall am Stück würde dagegen enormen Schaden anrichten. Es ist naheliegend, dass so ein Ausfall in der Beurteilung von Verfügbarkeit abgebildet sein sollte.

Wenn Sie eine der kommerziellen Editionen einsetzen, verfügt Checkmk über eine separate Funktion für Service Level Agreements (SLA). Das SLA-Feature baut auf den Verfügbarkeitsdaten auf und erlaubt nun eine wesentlich detailliertere Auswertung.

Zwei unterschiedliche Anforderungen können umgesetzt werden:

Sie können dabei mehrere Instanzen einer oder beider Anforderungen kombinieren, um beispielsweise sicherzustellen, dass ein bestimmter Service im Berichtszeitraum mindestens zu 90 Prozent OK sein muss und maximal zweimal für zwei oder mehr Minuten den Zustand CRIT annehmen darf.

Die Ergebnisse dieser Berechnungen lassen sich später auf zwei Varianten in Tabellenansichten rendern:

Hier sehen Sie beispielsweise die Auswertung für ein Dateisystem in der Übersicht: von heute (mit 3 Symbolen in der Spalte ganz rechts) und der letzten 15 Tage davor — und auch sofort, dass bis vor 4 Tagen offensichtlich Probleme bestanden:

Aber was bringen Ihnen diese Auswertungen nun? Zum einen können Sie die Erfüllung oder Nichterfüllung abgeschlossener SLAs sehen und beispielsweise gegenüber Kunden offenlegen. Zum anderen können Sie bereits im Voraus eine drohende Nichterfüllung erkennen: Standardmäßig geht die SLA-Anzeige auf CRIT, sobald sie gebrochen wurde. Sie lässt sich aber auch so einstellen, dass sie bereits auf CRIT geht, wenn zum Beispiel die erlaubten CRIT-Zustände des Services zu 80 Prozent aufgebraucht sind. Und noch davor könnte sie auf WARN wechseln.

Letztlich sind SLAs vor allem sehr detaillierte Ansichten, generiert aus verrechneten Verfügbarkeitsdaten. Diese bekommen Sie später an zwei Punkten zu sehen: In Tabellen, wahlweise zu allen dort aufgeführten Hosts und Services, oder nur zu Services, die ganz konkret an einzelne SLAs gebunden sind. Und zweitens gibt es zu jeder Service-SLA-Kombination eine ausführliche Detailseite.

Datengrundlage für die SLA-Funktion sind die Verfügbarkeitsdaten. Die Berechnungen zu den SLA-Vorgaben werden aber natürlich nicht auf den gesamten Rohdatenbestand angewendet, schließlich sollen mit SLAs Aussagen über bestimmte Zeiträume getroffen werden. Also wird zunächst bestimmt, in welchem Zeitraum die SLA-Vorgaben erfüllt werden sollen, die sogenannte „SLA-Periode“. Etwa: „Der Service MyService soll innerhalb eines Monats zu mindestens 90 Prozent OK sein.“ Für diese SLA-Periode werden auch nicht (zwangsläufig) alle Daten des Monats aus einem 24/7-Betrieb genutzt. Die Daten können auf die im Setup definierten Zeitperioden, also etwa Arbeitszeiten, begrenzt werden.

So ergibt sich dann eine konkretisierte Anforderung wie: „Der Service MyService soll innerhalb eines Monats (SLA-Periode) während der Arbeitszeiten (Zeitperiode), Montag bis Freitag von 10.00 bis 20.00 Uhr, zu 90 Prozent OK sein (SLA-Anforderung).“ SLA- und Zeitperiode ergänzen sich also, wobei letztere nicht eingeschränkt werden muss: Selbstverständlich können Sie alle innerhalb einer SLA-Periode angefallenen Monitoring-Daten verwenden.

Zusammengefasst: Sie benötigen zwei Perioden, um die Datenbasis für die Berechnung einer SLA-Anforderung einzuschränken:

Für jede SLA-Periode bekommen Sie ein eigenständiges Resultat. Wie viele dieser Einzelresultate Sie in einer Tabelle sehen, konfigurieren Sie über eine Ansicht. So ließen sich zum Beispiel die letzten fünf Wochen, beschränkt auf Werktage, als fünf einzelne SLA-Perioden direkt an Hosts und Services anzeigen.

Wie üblich bei Checkmk, gibt es zwischen der Datenquelle (SLA-Definition) und der Ausgabe (Ansicht) noch eine Regel, um SLAs bestimmten Services zuordnen zu können — ein Muss ist das aber nicht. Und somit ergibt sich für SLAs in der Regel ein dreistufiger Ablauf, sofern sie an bestimmte Services gebunden werden:

Im Folgenden sehen Sie, wie Sie ein einfaches SLA samt Ansicht einrichten: Die Dateisysteme der Hosts MyHost1 und MyHost2 sollen im Berichtszeitraum von einer Woche zu mindestens 90 Prozent OK sein (heißt hier im Beispiel maximal zu 80 Prozent belegt). Zusätzlich dürfen sie maximal fünfmal für zwei oder mehr Minuten den Zustand WARN annehmen.

Zunächst legen Sie das eigentliche SLA an. Zur Konfiguration gelangen Sie über Customize > Business reporting > Service Level Agreements (diesen Menüeintrag sehen Sie übrigens nur im Show-more-Modus):

Legen Sie mit New SLA ein neues SLA an. Im Bereich General Properties vergeben Sie zunächst eine eindeutige ID, hier MySLA, sowie einen Titel, etwa Filesystems:

Unter SLA settings setzen Sie nun die SLA period auf den gewünschten Zeitraum, wie zum Beispiel Weekly. Die folgend aufgestellten Anforderungen gelten also immer für den Zeitraum einer Woche.

Bevor Sie die eigentlichen Anforderungen aufstellen, können Sie aber noch unter Filtering and computation options weitere Einschränkungen und Optionen setzen, die für unser einfaches Beispiel-SLA jedoch nicht benötigt werden:

Anschließend legen Sie die eigentlichen Anforderungen im Bereich SLA requirements mit Add new timeperiod fest. Sofern Sie Zeitperioden festgelegt haben, können diese auch bei den SLAs eingesetzt werden, wie bereits für die allgemeine Verfügbarkeit erwähnt. Wählen Sie dazu unter Active in timeperiod eine Zeitperiode aus oder hier im Beispiel 24X7 - Always, um die Anforderungen an einen 24/7-Betrieb zu stellen. Vergeben Sie unter Title einen sprechenden Namen, hier etwa 90 percent OK:

Bei Computation Type wählen Sie für die erste Anforderung Service state percentage und fügen über Add state configuration ein neues Kriterium hinzu. Es öffnet sich ein neuer Absatz für das Monitoring state requirement. Um mindestens 90 Prozent Verfügbarkeit zu verlangen, setzen Sie hier den Datensatz auf OK, Minimum, 90. Wird dieser Wert unterschritten, gilt das SLA als broken und nimmt den Zustand CRIT an, wie Sie später auf der Ergebnisseite sehen werden.

Vielleicht soll das SLA aber nicht erst auf CRIT gehen, wenn es gebrochen wurde, sondern bereits auf WARN, sobald 50 Prozent des Puffers verbraucht sind, und auf CRIT, wenn noch 10 Prozent Puffer übrig sind. Das eigentliche Brechen des SLA würde dann zwar den Hinweis broken erzeugen, aber keine weitere Zustandsänderung (mehr dazu unten im Abschnitt SLA-Detailseite). Für eine solche Konfiguration aktivieren Sie das Kästchen bei Levels for SLA monitoring: Hier können Sie Restwerte für den Übergang nach WARN und CRIT eingeben. Damit sind Sie mit der ersten Anforderung fertig.

Fügen Sie nun eine zweite Anforderung mit Add new timeperiod hinzu. Bestimmen Sie wieder die Zeitperiode, vergeben Sie als Namen bei Title zum Beispiel Max 5 warnings a 2 minutes und setzen Sie den Computation Type dieses Mal auf Maximum number of service outages. Die eigentliche Anforderung lautet dann: Maximum 5 times WARN with duration 0 days 0 hours 2 mins 0 secs:

Der Service darf laut SLA nun also maximal fünfmal pro SLA-Periode für ein Maximum von zwei Minuten den angegeben Zustand haben, ohne dass das SLA gebrochen wird. Statt WARN könnte an dieser Stelle natürlich auch ein anderer Zustand genommen werden. Und auch hier dürfen Sie wieder über die Levels for SLA monitoring verfeinern und bestimmen, bei wie vielen verbleibenden Vorfällen vor dem Brechen des SLA Sie mit einem WARN beziehungsweise CRIT gewarnt werden.

Wie bereits erwähnt, können Sie weitere solcher Anforderungen hinzufügen und somit detaillierte SLAs stricken. Noch gibt es aber keinerlei Services, die auf dieses SLA „reagieren“ — für unser Beispiel muss eine Regel her und diese Verbindung herstellen. Wie Sie die bis hierher erstellte Konfiguration ohne solch eine SLA-Service-Verbindung nutzen, lesen Sie weiter unten unter Spalten-spezifische SLA-Anzeige.

Das Anbinden eines SLA an einen Service erledigen Sie mit dem Regelsatz Setup > Services > Service monitoring rules > Assign SLA definition to service. Erstellen Sie eine Regel, aktivieren Sie die einzige regelspezifische Option Assign SLA to service und wählen Sie dann Ihre SLA-Definition MySLA, die hier über ihren Titel Filesystems aufgeführt wird:

Anschließend setzen Sie unter Conditions im Bereich Services noch Filter für die gewünschten Services. Wie immer können Sie hier mit regulären Ausdrücken arbeiten und die SLA-Definition wie in diesem Beispiel per Filesystem an alle lokalen Dateisysteme knüpfen. Optional dürfen Sie das Ganze noch über die regeltypischen Filter für Ordner, Host-Merkmale und explizite Hosts einschränken; für das Beispiel handelt es sich um die Hosts MyHost1 und MyHost2:

Natürlich könnten Sie an dieser Stelle auch auf jegliche Angabe von Service-Filtern verzichten, um das SLA an alle Services zu binden. Wie und warum Sie das besser über eine Ansicht mit Spalten-spezifischer SLA-Anzeige erledigen, sehen Sie weiter unten.

Sie haben nun also die SLA-Definition MySLA erstellt und an alle Services der beiden Hosts gebunden, die mit Filesystem beginnen. Jetzt erstellen Sie noch eine neue Ansicht für die SLAs. Für das SLA-Beispiel soll eine simple Ansicht für die beiden Hosts mit den Dateisystem-Services und den SLAs genügen. Zur Verdeutlichung kommen noch die Checkmk-Services hinzu, an die eben kein SLA gebunden ist. Das Ergebnis wird dann so aussehen wie das Bild am Ende dieses Kapitels.

Erstellen Sie über Customize > Visualization > Views > Add view eine neue Ansicht. In der ersten Abfrage geben Sie All services als Datasource an. Die folgende Abfrage, ob Informationen eines einzelnen Objekts gezeigt werden sollen, bestätigen Sie mit dem Standardwert No restrictions to specific objects.

Geben Sie unter General Properties eine ID ein (hier MySLAView_Demo), einen Titel (etwa My SLA Demo View), und wählen Sie letztlich noch ein Thema aus wie Workplace, wenn Sie später die SLA-Ansichten unter einem eigenen Eintrag im Monitor-Menü sehen möchten. Sämtliche sonstigen Werte können Sie für den Test unverändert lassen.

Navigieren Sie nun zum Kasten Columns und fügen Sie initial über Add column die drei allgemeinen Spalten Services: Service state, Hosts: Hostname und Services: Service description hinzu, um eine Basis für die Ansicht zu haben.

In der Spaltenauswahl finden Sie auch zwei SLA-spezifische Spalten: Hosts/Services: SLA - Service specific und Hosts/Services: SLA - Column specific. Letztere ist die oben erwähnte bessere Alternative, um eine fixe SLA-Definition zu jedem Service der Ansicht anzeigen zu lassen. Dazu später mehr.

Fügen Sie an dieser Stelle die Spalte Hosts/Services: SLA - Service specific hinzu. Hier bekommen Sie nun allerhand Optionen für die Darstellung der SLA-Ergebnisse:

SLA timerange: Damit bestimmen Sie den Zeitraum, für den Sie SLA-Ergebnisse sehen wollen. Wenn Sie beispielsweise den Berichtszeitraum Monthly in Ihrer SLA-Definition gewählt haben und hier Last Year festlegen, bekommen Sie zwölf einzelne Resultate. Hier im Beispiel kommt die Option SLA period range zum Einsatz, über die die Anzahl der angezeigten Berichtszeiträume direkt gesetzt werden kann: Für fünf Zeiträume/Ergebnisse setzen Sie Starting from period number auf 0 und Looking back auf 4.

Layout options: Standardmäßig steht diese Option auf Only display SLA Name. Um tatsächlich die Ergebnisse der SLAs zu sehen, wählen Sie hier Display SLA statistics. Damit können Sie bis zu drei unterschiedliche Elemente auswählen:

Für das laufende Beispiel aktivieren Sie alle drei Optionen.

Generic plugin display options: An dieser Stelle legen Sie für die Anzeige von Ausfall-/Prozentsatz-SLAs jeweils fest, ob Zusammenfassungen (Texte) oder Einzelergebnisse (Symbole) der Berichtszeiträume erscheinen. Um beides in Aktion zu sehen, belassen Sie die Option für die prozentualen SLAs auf Show separate result for each SLA period und wählen Sie unter Service outage count display options den Eintrag Show aggregated info over all SLA periods.

Wenn Sie die Ansicht nach einzelnen Hosts gruppieren wollen, fügen Sie unter Grouping die Spalte Hosts: Hostname hinzu — das sorgt für eine optische Trennung der Hosts.

Da die Ansicht nur die Hosts MyHost1 und MyHost2 zeigen soll, müssen Sie im letzten Schritt noch unter Context / Search Filters einen Filter unter Host für Hostname setzen: MyHost1|MyHost2. Für eine etwas übersichtlichere Beispielansicht können Sie noch einen Filter unter Service setzen, beispielsweise filesystem.*|Check_MK.*. So bekommen Sie dann die per SLA überwachten Dateisystem-Services und als nicht überwachtes Gegenstück die Checkmk-Services — so wird der Effekt der Service-spezifischen SLA-Anzeige einfach deutlicher.

Damit ist die Einrichtung der Ansicht abgeschlossen. Nach Auswahl im Monitor-Menü bekommen Sie als Ergebnis eine Ansicht mit fünf Statussymbolen als Einzelresultate des Prozentsatz-SLAs und dazu eine Zusammenfassung als Prozentsatz für das Ausfall-SLA — natürlich nur in den Zeilen der Dateisystem-Services, die Checkmk-Zeilen bleiben leer.

Die Service-spezifische Ansicht hat einen Nachteil: Sie können zwar mehrere Regeln erstellen, die ein und demselben Service unterschiedliche SLAs zuordnen, anzeigen können Sie aber nur das SLA, das mit der ersten dieser Regeln zugeordnet wird. Es gibt keine Möglichkeit, das SLA einer zweiten greifenden Regel in einer zweiten Spalte darzustellen.

Sie können aber sehr wohl mehrere Spalten mit unterschiedlichen fix angegebenen SLAs einblenden. Nützlich sind solche Spalten-spezifischen Ansichten zum Beispiel, wenn Sie mehrere SLAs benötigen, die für alle Services einiger oder aller Hosts gelten sollen. So ließen sich etwa Gold-, Silber- und Bronze-SLAs definieren, die jeweils in einer eigenen Spalte neben den Services eines Hosts angezeigt werden. Somit wäre auf einen Blick klar, welchen SLA-Definitionen ein Service/Host genügt. Kurz gesagt: Über die Spalten-spezifische Ansicht können Sie zu Services mehr als nur ein SLA anzeigen lassen.

In dem oben fertiggestellten Beispiel wurden die eingangs erwähnten drei Schritte abgearbeitet — SLA erstellen, an Service binden, in Ansicht einbauen. Für Spalten-spezifische Ansichten können Sie den zweiten Schritt einfach auslassen. Erstellen Sie nur das SLA und ordnen Sie einer Ansicht die Spalte Hosts/Services: SLA - Column specific zu. Die SLA-Ergebnisse werden dann eben unabhängig vom jeweiligen Service in jeder Zeile angezeigt.

Im folgenden Bild sehen Sie die obige SLA-Ansicht für MyHost1 mit einer zusätzlichen Spalte, die für jeden Service SLA-Ergebnisse (maximal drei Ausfälle der Checkmk-Services) anzeigt:

So ist der Unterschied zwischen Service- und Spalten-spezifischer Anzeige klar zu erkennen. Was ebenfalls klar werden sollte: Das speziell auf die Checkmk-Services ausgelegte SLA ergibt in den Dateisystem-Spalten natürlich nur mäßig Sinn. Es lohnt sich also gründlich zu planen, bevor es an die Umsetzung geht!

Noch ein kleiner Hinweis: Bei den Optionen der Service-spezifischen Ansicht haben Sie oben unter Generic plugin display options die Einstellungen für Ausfall- und Prozentsatz-SLAs gesehen. Bei den Optionen der Spalten-spezifischen Ansichten sehen Sie diese beiden ebenfalls — aber nur, wenn das SLA auch tatsächlich Ausfall- und prozentuale Kriterien beinhaltet. Hier wird eben nicht generisch die passende, sondern statisch eine fixe SLA-Definition aufgerufen. Also sehen Sie auch nur die Optionen, die zu diesem einen SLA gehören.

Es gibt viele Möglichkeiten, SLAs, Services und Ansichten zusammenzubringen — hier ist gute Planung gefragt, was genau Sie über SLAs abbilden möchten.

Das Einbinden der SLA-Informationen in Tabellen bietet eine schnelle Übersicht, aber natürlich können Sie die Ergebnisse auch im Einzelnen betrachten. In einer Ansicht bringt Sie ein Klick auf die Zelle mit den SLA-Daten direkt zur Detailseite der SLA-Ergebnisse des betroffenen Services:

Hier finden Sie vier unterschiedliche Informationen:

General information: Hier sehen Sie die Rohdaten der Verfügbarkeit, und somit der SLA-Berechnungen, als Übersicht mit Zustand der einzelnen Perioden und darunter die aggregierten Resultate der SLA-Anforderungen.

Anschließend folgen Tabellen für jede einzelne SLA-Anforderung. Die Zeitleiste (Timeline) zeigt jeden einzelnen Zustand und die Zeile Result die Ergebnisse für jeden einzelnen Berichtszeitraum. Eine Besonderheit hier: Wenn Sie, wie im Beispiel beschrieben, die SLA-Levels gesetzt haben und das SLA noch vor dem Brechen auf CRIT geht, wird das hier über einen orangen und nicht über den sonst üblichen roten Balken angezeigt. Rot werden die Balken dann beim Brechen des SLA. Sobald Sie den Mauszeiger auf den Ergebnisbalken ziehen, sehen Sie per Tooltipp auch gleich die einzelnen Ereignisse, die für den Zustand verantwortlich sind. Im folgenden Bild ist der Zustand WARN, weil nur noch zwei von drei erlaubten Ausfällen übrig sind:

Auch die Meldung SLA broken würde in diesem Tooltipp erscheinen.

Ein kleiner Hinweis zur Nutzung der Ansicht: Wenn Sie mit der Maus über den Ergebnisbalken Aggregated results oder Result einer Periode fahren, wird diese Periode hervorgehoben — bei allen einzelnen Anforderungen und auch der Zusammenfassung unter General information. Per Klick können Sie eine oder mehrere Perioden markieren oder eine Markierung auch wieder aufheben.

Zum Schluss folgen unter SLA specification noch die Konfigurationsdaten Ihres SLA, mithilfe derer Sie die präsentierten Ergebnisse besser auswerten und nachvollziehen können:

Im Artikel zur Verfügbarkeit haben Sie erfahren, wie die Verfügbarkeit für BI-Aggregate genutzt wird. Und auch die SLAs stehen den Aggregaten (der obersten Ebene) zur Verfügung — über einen kleinen Umweg: Der Zustand eines BI-Aggregats kann über den Regelsatz Check State of BI Aggregation als ganz normaler Service überwacht werden. Dieser erscheint dann beispielsweise als Aggr My Bi Rule Top Level in den Ansichten und kann wiederum über die bereits oben genutzte Regel Assign SLA definition to service mit einem SLA verknüpft werden. Im Ergebnis sieht das dann etwa so aus:

Sie finden die Regel unter Setup > Services > Other services > Check State of BI Aggregation und eine Beschreibung des Regelsatzes im BI-Artikel. Die Regel ist darauf ausgelegt, BI-Aggregate auch auf entfernten Checkmk-Servern abzufragen. Daher müssen Sie hier für die Verbindung die URL zum Server und einen Automationsbenutzer angeben — und natürlich das gewünschte BI-Aggregat: Im Feld Aggregation Name tragen Sie den Titel einer Top-Level-Regel aus Ihrem BI-Paket ein, im folgenden Beispiel die Regel mit dem Titel My BI Rule Top Level:

Hinweis: Hier besteht Verwechslungsgefahr: In der BI-Konfiguration erstellen Sie die eigentliche Aggregation, also die Logik, über Regeln — und eine der obersten Regeln wird hier über ihren Titel als Aggregation Name eingetragen.

In der Praxis sind SLAs ein Zusammenspiel aus allerlei unterschiedlichen Konfigurationen: Das SLA selbst, Ansichts- und Service-Optionen, Zeitperioden, Regeln und natürlich Verfügbarkeitsdaten. Zeigt das SLA andere Ergebnisse als erwartet, gehen Sie einfach die komplette Kette durch. Im Zweifelsfall hilft es auch, den gesamten Prozess einmal mit Stift und Papier zu visualisieren, um alle beteiligten Informationen auf einen Blick zu sehen. Folgende Punkte können Sie dabei als kleine Checkliste verwenden:

Nachdem Sie die Konfigurationen geprüft haben, können Sie die Funktion des SLA über manuelle (gefälschte) Zustandsänderungen und Wartungszeiten prüfen, indem Sie Kommandos auf die Objekte einer Ansicht anwenden.

Öffnen Sie in so einem Fall die Einstellungen der betroffenen Ansicht und überprüfen Sie zunächst das Offensichtliche: Gibt es überhaupt eine Spalte mit einem SLA? Wahrscheinlicher sind aber widersprüchliche Filter: Wenn Sie das SLA mit einer Regel an einen Service gebunden haben, darf dieser Service in den Ansichtsoptionen unter Context / Search Filters natürlich nicht ausgeschlossen werden.

An Services gebundene SLAs bieten noch eine Fehlerquelle: Wie oben beschrieben, können Sie in einer Ansicht zu jedem Service nur ein per Regel verknüpftes SLA anzeigen lassen — und zwar das der ersten passenden Regel. Die Ansicht bekommt schließlich nur die Anweisung, in jeder Zeile das mit dem Service verbundene SLA anzuzeigen, und nicht das zweite oder fünfte verbundene SLA. Sofern Sie entsprechende Regeln angelegt haben, werden sie schlicht ignoriert. In solchen Fällen können Sie zur Spalten-spezifische Anzeige wechseln.

In der einfachsten Form wechselt der SLA-Zustand in den Ansichten der GUI erst beim Brechen der Anforderungen. Um über eine Zustandsänderung bereits vorher informiert zu werden, müssen Sie die SLA-Levels konfigurieren.