Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen.Visit our Privacy Policy to learn more. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Erweiterte Verfügbarkeiten (SLAs)

Checkmk Manual
Letzte Aktualisierung: 4. Februar 2019

Suche im Handbuch

1. Einleitung

1.1. Was leisten 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 im Jahr 87,6 Stunden Downtime zulassen. Verteilen sich diese auf 0,24 Stunden täglich, mag das für viele Systeme in Ordnung sein. Ein ganztägiger Ausfall könnte dagegen enormen Schaden anrichten.

Ab Version 1.5.0 verfügt Checkmk über eine separate Funktion für Service Level Agreements. Das SLA-Feature baut auf den Verfügbarkeitsdaten auf und erlaubt nun eine wesentlich detailliertere Auswertung. Zwei unterschiedliche Anforderungen können umgesetzt werden:

  • Prozentualer Anteil, die ein Servicestatus (OK, WARN, CRIT, UNKNOWN) ober-/unterhalb eines gegebenen Werts liegt.
  • Maximale Anzahl „Ausfälle“, genauer der Status CRIT, WARN, UNKNOWN einer gegebenen Dauer.

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 zwei mal für zwei oder mehr Minuten den Zustand CRIT annehmen darf.

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

  • Service-spezifisch: Zu einem Service wird sein zugeordnetes SLA angezeigt.
  • Spalten-spezifisch: Zu jedem Service wird ein fixes SLA angezeigt.

Hier sehen Sie beispielsweise die Auswertung der letzten 15 Tage für ein Dateisystem in der Übersicht – und auch sofort, dass seit zwei Tagen offensichtlich Probleme bestehen.

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-Status 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 Availability-Daten. 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. Wegen dieser Nähe zu Ansichten ist das SLA-Feature auch in die Ansichten-Konfiguration eingebettet.

1.2. Funktionsweise

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: Service MyService soll innerhalb eines Montats zu mindestens 90 Prozent OK sein. Für diese SLA-Periode werden auch nicht (zwangsläufig) alle Daten des Montats aus einem 24/7-Betrieb genutzt. Die Daten können auf die in WATO definierten Zeitperioden, also etwa Arbeitszeiten, begrenzt werden.

So ergibt sich dann eine Anforderung wie: 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 (SLA-Anforderung) sein. SLA- und Zeitperiode ergänzen sich also, wobei letztere natürlich nicht eingeschränkt werden muss: Selbstverständlich können Sie alle innerhalb einer SLA-Periode angefallenen Monitoringdaten verwenden.

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

  • SLA-Periode: Der Zeitraum (z. B. wöchentlich), welcher in der SLA vereinbart wurde und die Grundlage für den Bericht darstellt.
  • Zeitperiode: Aktive Zeitperioden aus der WATO-Konfiguration; etwa nur Werktage.

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-Definitionen) 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 dreischrittiger Ablauf, sofern sie an bestimmte Services gebunden werden:

  • SLA über Views ➳ Edit ➳ SLAs definieren.
  • SLA per Regel WATO ➳ Host & Service Parameter ➳ Grouping ➳ Assign SLA definition to Service an Hosts/Services binden (optional).
  • Ansichten für SLA erstellen beziehungsweise anpassen.

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ünf mal für zwei oder mehr Minuten den Zustand WARN annehmen.

2. SLAs einrichten

2.1. SLA anlegen

Zunächst legen Sie das eigentliche SLA an. Zur Konfiguration gelangen Sie über Views ➳ Edit ➳ SLAs.

Legen Sie über 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:

Option Erklärung
Scheduled Downtimes Berücksichtigung geplanter Wartungszeiten.
Status Classification Berücksichtigung von Flapping, Downtimes und Zeiten außerhalb der Monitoringzeiten.
Service Status Grouping Umklassifizierung der Status.
Only show objects with outages Nur Objekte mit gegebenen Ausfallraten anzeigen.
Host Status Grouping Berücksichtigung des Host-Status UNREACH als UNREACH, UP, DOWN.
Service Time Berücksichtigung von Servicezeiten.
Notification Period Berücksichtigung von Benachrichtigungszeiten.
Short Time Intervals Ignorieren von Intervallen unterhalb einer gegebenen Dauer, um kurzzeitige Störungen zu ignorieren (ähnlich dem Konzept Soft states).
Phase Merging Aufeinander folgende Berichtszeiträume trotz gleichem Status nicht verschmelzen.
Query Time Limit Begrenzung der Abfragezeit als Maßnahme gegen langsam oder gar nicht antwortende Systeme.
Limit processed data Begrenzung der zu verarbeitenden Datenzeilen; standardmäßig 5.000.

Anschließend legen Sie die eigentlichen Anforderungen im Bereich SLA requirements fest. Sofern Sie in WATO Zeitperioden festgelegt haben, können diese, wie oben bereits für die allgemeine Verfügbarkeit erwähnt, auch bei den SLAs eingesetzt werden. Wählen Sie dazu unter Active in timeperiod eine gewünschte Periode aus oder hier im Beispiel Always, um die Anforderungen an einen 24/7-Betrieb zu stellen.

Vergeben Sie unter Title einen sprechenden Namen, hier etwa 90 Prozent OK.

Bei Computation Type belassen Sie für die erste Anforderung die Vorgabe Service state percentage und fügen über 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 „OK, Minimum, 90“. Wird dieser Wert unterschritten, gilt das SLA als broken und nimmt den Status 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 Statusänderung (mehr dazu unten im Abschnitt „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 über hinzu, bestimmen Sie wieder die Zeitperiode, vergeben Sie als Namen bei Title zum Beispiel Maximal 5 x WARN a 2 Minuten 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ünf mal pro SLA-Periode für ein Maximum von zwei Minuten den angegeben Status haben, ohne, dass das SLA gebrochen wird. Statt WARN könnte an dieser Stelle natürlich auch ein anderer Status genommen werden. Und auch hier dürfen Sie wieder über die Levels for SLA monitoring verfeinern und bestimmen, bei wie viel 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.

2.2. SLA an Service binden

Das Anbinden eines SLA an einen Service erledigen Sie über WATO ➳ Host & Service Parameters ➳ Grouping ➳ Assign SLA definition to service. Erstellen Sie eine Regel, aktivieren Sie die einzige regelspezifische Option Assign SLA to Service und wählen Sie dann aus dem Aufklappmenü 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, Hosttags 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.

2.3. SLA in Ansicht einbinden

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.

Erstellen Sie über Views ➳ Edit ➳ New eine neue Ansicht. In der ersten Abfrage geben Sie All services als Datasource an. Die folgende Abfrage, ob Informationen eines einzelnen Hosts oder Services gezeigt werden sollen, bestätigen Sie einfach ohne Auswahl.

Geben Sie unter General Properties eine ID, hier MySLAView_Demo, einen Titel, etwa My SLA Demo View und letztlich noch ein Thema wie MyTopicSLA an, wenn Sie später alle SLA-Ansichten unter einem eigenen Knoten in der Ansichten-Navigation haben wollen. Sämtliche sonstigen Werte können Sie beim Testen so belassen.

Navigieren Sie nun zum Bereich Columns und fügen Sie initial über 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 zeigt eine fixe SLA-Definition zu jedem Service der Ansicht – die oben erwähnte bessere Alternative, um ein SLA für alle Services 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: Darüber 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 periods 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 Loocking 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 anzeigen:

  • Display SLA subresults for each requirement zeigt jedes betroffene SLA mit dessen Namen separat an.
  • Display a summary for each SLA period zeigt eine grafische Zusammenfassung unter dem Label Aggregated result.
  • Display a summary over all SLA periods: Zeigt eine textliche, prozentuale Zusammenfassung über alle SLAs unter dem Label Summary.

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

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

Wenn Sie die Ansicht nach einzelnen Hosts gruppieren wollen, fügen Sie optional unter Grouping die Spalte Host: 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 den Hostname setzen: MyHost1|MyHost2. Für eine etwas übersichtlichere Beispielansicht können Sie noch einen Filter unter Services 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.

Im Ergebnis bekommen Sie dann eine Ansicht mit fünf Status-Icons als Einzelresultate des Percentage-SLA und dazu eine Zusammenfassung in der Form 100 Prozent für das Outage-SLA. Natürlich nur in den Zeilen der Dateisystem-Services, die Checkmk-Zeilen bleiben leer.

3. Weitere Ansichten

3.1. Spalten-spezifische SLA-Anzeige

Die Service-spezifische Ansicht hat einen großen 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 Server/Service 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 Screenshot sehen Sie die obige SLA-Ansicht für MyHost1 mit einer zusätzlichen Spalte, die für jeden Service SLA-Ergebnisse (maximal drei Outages der Checkmk-Services) anzeigt; so ist der Unterschied zwischen Service- und Spalten-spezifischer Anzeiger 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 Outage- und Prozent-SLAs gesehen. Bei den Optionen der Spalten-spezifischen Ansichten sehen Sie diese beiden ebenfalls – aber nur, wenn das SLA auch tatsächlich Outage- 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 Vorabplanung gefragt, was genau Sie über SLAs abbilden möchten.

3.2. SLA-Detailseite

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

Hier finden Sie vier unterschiedliche Informationen:

  • Rohdaten der Verfügbarkeit,
  • Zusammenfassung aller Anforderungen eines SLA,
  • Einzelergebnisse aller Anforderungen eines SLA und
  • SLA-Spezifikationen.

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

Unter Computation plugin information finden Sie Informationen zu jeder einzelnen Anforderung des SLA. Die Zeitleiste zeigt jeden einzelnen Zustand, in der Zeile Result finden sich 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 orange statt der üblichen roten Balken angezeigt. Rot werden die Balken dann beim Brechen des SLA. Sobald Sie den Mauszeiger auf den Ergebnisbalken ziehen, sehen Sie per Hoover-Menü auch gleich die einzelnen Ereignisse, die für den Status verantwortlich sind; im folgenden Bild ist der Status etwa WARN, weil nur noch vier von fünf erlaubten Ausfällen übrig sind, und auch die Meldung SLA broken würde in diesem Menü erscheinen.

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

Ein kleiner Hinweis zur Nutzung der Ansicht: Wenn Sie mit der Maus über den Ergebnisbalken einer Periode fahren, wird die entsprechende Periode hervorgehoben – bei allen einzelnen Anforderungen und auch der Zusammenfassung unter General information. Per Klick können Sie eine oder mehrere Perioden de-/markieren. Das funktioniert in den Zeilen Result und Aggregated results. Im obigen Screenshot ist beispielsweise die aktuelle Periode ganz rechts hervorgehoben.

3.3. SLAs für BI-Aggregate

Oben haben Sie bereits gelesen, 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 Status einer BI-Aggregation kann über das Regelset Check State of BI Aggregation als ganz normaler Service überwacht werden. Dieser erscheint dann beispielsweise als Aggr MySLA in den Host-Ansichten und kann wiederum über die oben genutzte Regel Assign SLA definition to service mit einem SLA verknüpft werden.

Sie finden die Regel unter WATO ➳ Host & Service Parameters ➳ Active Checks ➳ Check State of BI Aggregation. 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: Hier tragen Sie den Titel einer Top-Level-Regel aus Ihrem BI-Pack ein.

Vorsicht, hier besteht Verwechslungsgefahr: In der BI-Konfiguration erstellen Sie die eigentliche Aggregation, also die Logik, über Regeln – und eine der obersten Regeln wird hier eben über ihren Titel als „Aggregation“ angegeben.

4. Fehlerbehebung

Was prüfe ich, wenn mein SLA nicht oder nicht wie erwartet funktioniert?

In der Praxis sind SLAs ein Zusammenspiel aus allerlei unterschiedlichen Konfigurationen: SLA selbst, Ansichts- und Service-Optionen, Zeitperioden, Regeln und natürlich Availability-Daten. 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:

  • Zeitperioden: WATO ➳ Timeperiods
  • Geplante Wartungszeiten: WATO ➳ Monitoring Configuration ➳ Recurring Downtimes for Hosts/Services – nur  Checkmk Enterprise Edition
  • Servicezeiten: WATO ➳ Monitoring Configuration ➳ Service Period for hosts bzw. ... for services
  • SLA-Service-Verknüpfung: WATO ➳ Host & Service Parameters ➳ Assign SLA definition to service
  • Service-Konfiguration: WATO ➳ Host & Service Parameters ➳ MyService
  • BI-Konfiguration: WATO ➳ Business Intelligence ➳ MyBiPack ➳ MyTopLevelRule
  • BI-Überwachung: WATO ➳ Host & Service Parameters ➳ Active Checks ➳ Check State of BI Aggregation
  • SLA-Konfiguration: Views ➳ SLAs ➳ MySLA
  • Optionen der Ansicht: Views ➳ MyView

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

Wie finde ich heraus, warum mein SLA nicht angezeigt wird in einer View?

Öffnen Sie in so einem Fall die Einstellungen der betroffenen Ansicht und checken 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 auf Spalten-spezifische Anzeige wechseln.

Warum werde ich über mein SLA nicht benachrichtigt, wenn es kurz davor steht über-/unterschritten zu werden?

In der einfachsten Form wechselt der SLA-Status erst beim Brechen der Anforderungen. Um im Voraus benachrichtigt zu werden, müssen Sie die SLA-Levels konfigurieren.