Das SLO (Service Level Object) ist der Hauptbaustein eines Servicemodells. Es ermöglicht die Abbildung eines Geschäfts- oder IT-Service mit all seinen redundanten Elementen und ist die Voraussetzung für die Implementierung von Service-Alarmen. Ein SLO kann den Status von Geräten oder Diensten zusammenfassen (z. B. die Gesamtverfügbarkeit redundanter Dienste/Verbindungen/etc.). Einfache Beispiele für solche Dienste wären eine DNS-Funktion mit ihrem primären und sekundären Nameserver oder eine Gruppe von Tomcat-Servern, bei denen nur 3 von 4 Servern laufen müssen, damit der Dienst verfügbar ist und eine ausreichende Leistung bietet.

So fügen Sie ein SLO hinzu: Wählen Sie z. B. unter /root /Customer /Services im Dropdown-Menü die Option „Add SLO“ (SLO hinzufügen) aus:

Nachdem Sie einen Namen für das neue SLO eingegeben haben, geben Sie dessen Typ an (optional) und klicken Sie dann auf „OK“ oder „OK, Weiter hinzufügen“, wenn ein weiteres SLO hinzugefügt werden soll:

Die folgenden SLO-Typen können ausgewählt werden:

• Allgemein
  
  • Anwendung
  • Anwendungsschritt
  • Geschäft
  • Kunde
  • Gerät
  • Funktion
  • Infrastruktur
  • IT
  • Standard (Standard)
  • Oben
• Prozess
  • Prozess
  • Prozessschritt
  • Prozessaufgabe

Der Standard-SLO-Typ ist „Standard“. Wenn „Top“ ausgewählt wird, wird der SLO in einer Service-Bestandsansicht angezeigt. Weitere Informationen finden Sie im Abschnitt „Service-Bestand anzeigen“.

Objekte mit einem SLO verknüpfen

Es gibt zwei Methoden, um Objekte mit einem SLO zu verknüpfen: Abhängigkeiten (statisch) und Filter (dynamisch).

Abhängigkeiten

Untergeordnete SLOs oder andere vorhandene Elemente aus einem anderen Bereich der Objektstruktur können über das Element „Abhängigkeit bearbeiten“ im Dropdown-Menü des SLO als Abhängigkeit verknüpft werden:

Auf der rechten Seite erscheint ein neues Fenster, in dem Sie nach Objekten suchen können, die Sie mit dem SLO verknüpfen möchten. Durchsuchen Sie die Objektstruktur und wählen Sie die Objekte aus, indem Sie entweder auf den Pfeil jedes Objekts klicken (nur verknüpfbare Objekte haben einen aktiven Pfeil) oder indem Sie zuerst die Kontrollkästchen der gewünschten Objekte aktivieren und dann auf einen der Pfeile im rechten Fenster klicken. Das Kontrollkästchen des Objekts, auf dessen Pfeil Sie geklickt haben, kann deaktiviert bleiben, es wird trotzdem ausgewählt.

Nach dem Hinzufügen der Objekte sollten diese links unterhalb des SLO angezeigt werden. Klicken Sie auf „OK“:

Objekte mit EQL mit einem SLO verknüpfen

Eine weitere Möglichkeit, bestimmte Objekte schnell mit einem SLO zu verknüpfen, ist die Verwendung der EQL-Befehlszeile für die rekursive Filterung. Im obigen Beispiel wurden zwei Geräte mit dem SLO verknüpft. Dienstmodelle verknüpfen jedoch meist einzelne Aufträge und nicht ganze Geräte. Mit EQL können mehrere Jobs einfach verknüpft werden. Wählen Sie wie oben beschrieben im Dropdown-Menü „SLOs“ die Option „Abhängigkeit bearbeiten“ und navigieren Sie zur übergeordneten Gruppe der Geräte, die die Jobs enthalten. Klicken Sie dann auf die Schaltfläche „EQL“ in der unteren rechten Ecke des rechten Fensters. Geben Sie die EQL-Abfrage „get job“ in das EQL-Abfragefeld ein:

Alle Jobs unterhalb der Gruppe „/root /Customer /Devices“ werden im rechten Fensterbereich aufgelistet. Wählen Sie diejenigen aus, die mit dem SLO verknüpft werden sollen, und klicken Sie auf einen der Pfeile. Bestätigen Sie mit „OK“. Das Ergebnis:

Anstatt alle Jobs mit „get job“ aufzulisten, ermöglicht EQL eine zusätzliche Filterung nach Name, Status usw. Weitere Informationen finden Sie im Kapitel „EQL: SKOOR Engine-Abfragesprache“.

Filter

Anstatt statische Abhängigkeiten zu Objekten aufzubauen, können SLOs Objekte, die bestimmten Kriterien entsprechen, dynamisch verknüpfen. Nach dem Hinzufügen eines SLO muss die Methode im Abschnitt „Child objects“ (Untergeordnete Objekte) auf „Define Filter“ (Filter definieren) umgestellt werden.

Die Dropdown-Menüs „Search below“ und „Type“ werden in der SLO-Konfiguration angezeigt, ebenso wie ein Filterbereich zum Hinzufügen von Kriterien. Verwenden Sie die Schaltfläche „Browse“, um eine Gruppe auszuwählen, in der nach Objekten für dieses SLO gesucht wird. Um Filterkriterien hinzuzufügen oder zu entfernen, können Sie auf die Schaltflächen „+“ oder „-“ auf der rechten Seite der Liste klicken. 

Objekte werden entsprechend den definierten Kriterien automatisch zum SLO hinzugefügt oder daraus entfernt. 

SLO-Korrelationsregeln

Jetzt kann man den Einfluss konfigurieren, den die Zustände dieser zugrunde liegenden Objekte auf das SLO haben. Wählen Sie „Parameter bearbeiten“ aus dem Dropdown-Menü „SLOs“ oder klicken Sie auf das Stiftsymbol.

SLOs mit Zustandsgewichtung UND, Beliebiger Zustand

Die Standardgewichtung für SLO-Zustände ist „UND“ und „Berücksichtigte Zustände“ ist auf „Beliebiger Zustand“ gesetzt:

Ergebnis-Zustandstabelle

Das SLO übernimmt den schlechtesten Zustand aller verknüpften Objekte:

SLOs mit Zustandsgewichtung UND, nur Major

In diesem Beispiel lautet die Zustandsgewichtung „UND“ und „Berücksichtigte Zustände“ ist auf „Nur Major“ gesetzt. Das bedeutet, dass alle zugrunde liegenden Objekte den Zustand „OK“ haben müssen oder zumindest nicht den Zustand „Major“, damit das SLO weiterhin den Zustand „OK“ hat.

Ergebnis-Zustandstabelle

Nur ein schwerwiegender Status der verknüpften Objekte „Icmp auf Server1” und „Icmp auf Server2” wird vom SLO übernommen. Der Status des SLO ist „Major”, wenn der Status eines zugrunde liegenden Objekts „Major” ist.

Bei SLOs, die mit der „AND“-Regel konfiguriert sind, muss Folgendes beachtet werden

• UND mit Major bedeutet lediglich, dass das SLO den Status Major annimmt, wenn sich ein oder mehrere abhängige Objekte im Status Major befinden.
• UND mit Beliebiger Status ist das Verhalten eines Gruppenobjekts. Das SLO übernimmt den schlechtesten Status der verknüpften Objekte (d. h. den schlechtesten Status unterhalb des Status No Data). No Data-Status werden als OK betrachtet.
• Ein SLO ohne ein Objekt, das einen Status (Messung) vorantreibt, nimmt selbst den Status „Undefined“ an.
• Undefinierte Zustände von Objekten unterhalb des SLO halten den Zustand des SLO ebenfalls im Zustand „Undefined“, solange kein anderes Objekt einen anderen Zustand auslöst.
• Da gestoppte oder inaktive Jobs den Zustand „Undefined” annehmen, werden SLOs, die keine aktiven Jobs darunter haben, ebenfalls zu „Undefined”.

SLOs mit Zustandsgewichtung ODER

Im folgenden Beispiel wurde ein dritter Job mit dem SLO verknüpft. Die Zustandsgewichtung ist OR und „Berücksichtigte Zustände“ wird automatisch auf „Beliebiger Zustand“ (für „muss“) gesetzt. Die einfache OR-Konfiguration berücksichtigt nur den Major-Zustand der zugrunde liegenden Objekte. Nur Objekte, die als „Muss“ markiert sind, können dazu führen, dass das SLO andere Zustände annimmt.

Mit der Auswirkungsgewichtung wird die Anzahl oder der Prozentsatz der untergeordneten Objekte im Major-Zustand definiert. Sobald dieser Wert erreicht ist, nimmt das SLO den Major-Zustand an. Es gibt zwei Möglichkeiten, die Zustandsgewichtung zu konfigurieren: 

• Die Anzahl der Objekte im Zustand „Major“ (mindestens)
• Die Anzahl der Objekte, die sich in einem besseren Zustand als „Major“ befinden müssen (Weniger)

Mit dem Schieberegler unterhalb der Definition der Auswirkungsgewichtung kann die Anzahl der Objekte definiert werden, ebenso wie durch direkte Eingabe der Anzahl in das entsprechende Feld.

Der Prozentsatz der Objekte ist eine gute Wahl, insbesondere wenn das SLO seine untergeordneten Objekte dynamisch filtert.

SLOs mit Zustandsgewichtung OR (erweitert)

Für Konfigurationen, bei denen auch andere Zustände als „Major“ berücksichtigt werden müssen, muss die Zustandsgewichtung „ODER (erweitert)“ konfiguriert werden. 

Die Zahlen in der Korrelationsmatrix definieren den Zustand des SLO in Abhängigkeit vom Zustand der zugrunde liegenden Objekte. Wenn 1 fehlgeschlagener (wobei „fehlgeschlagen” „Major” bedeutet) untergeordneter Job zu einem Warning-Zustand des SLO führen soll, 2 fehlgeschlagene Jobs zu einem „Minor”-Zustand und 3 fehlgeschlagene Jobs dazu, dass das SLO den Zustand „Major” annimmt, würde die Konfiguration wie folgt aussehen:

Dieses Beispiel zeigt einen fehlgeschlagenen Job, der dazu führt, dass das SLO in den Warning-Zustand (gelb) wechselt.

Die Matrix wird wie folgt gelesen:

• Die Spalten stellen den Status der zugrunde liegenden Objekte dieses SLO dar. Die erste Spalte enthält die Objekte im Status „Warning“, die zweite Spalte die Objekte im Status „Minor“ und die dritte Spalte die Objekte im Status „Major“.
• Die Zeilen stellen den resultierenden Status des SLO dar.

Ergebnis-Zustandstabelle

Der Status des SLO hängt von der Auswirkungsgewichtung der verknüpften Objekte ab:

Im folgenden Beispiel werden auch Minor-Zustände für den Gesamtzustand des Top-SLO berücksichtigt:

3 Jobs haben den Status „Minor“ oder schlechter (2 „Minor“, 1 „Major“), sodass die Gewichtsregel „Minor“, wenn mindestens 3 von 3 den Status „Minor“ oder schlechter haben, gilt und das SLO im Status „Minor“ verbleibt. 

Ergebende Zustandstabelle

SLOs mit Zustandsgewichtung OR und Must-Parameter

Der Status wichtiger untergeordneter Objekte kann direkt an das SLO weitergegeben werden, ohne dass Regeln zur Gewichtung berücksichtigt werden müssen, während gleichzeitig die Gewichtung der Status anderer untergeordneter Objekte kontrolliert werden kann. Durch Aktivieren des Kontrollkästchens „Must“ neben einem untergeordneten Objekt wird der Status des Objekts wie folgt nach oben weitergegeben:

• Wenn „Berücksichtigte Zustände“ auf „Beliebiger Zustand“ (für „Must“) gesetzt ist, wird jeder Zustand des Must-Objekts an das SLO weitergegeben, es sei denn, der Zustand des SLO ist aufgrund der Gewichtungseinwirkung der anderen Objekte, die nicht als „Must“ markiert sind, bereits schlechter.
• Wenn „Berücksichtigte Zustände“ auf „Nur Major“ (für „Muss“) gesetzt ist, wird nur ein Major-Zustand des „Muss“-Objekts an das SLO weitergegeben.
• Wenn mehr als ein Objekt als „Must“ markiert ist, gilt das AND-Korrelationsverhalten für alle „Must“-Objekte, d. h. der schlechteste Zustand aller dieser Objekte wird nach oben übertragen.

Die folgende Abbildung veranschaulicht eine solche Konfiguration:

Beachten Sie, dass die Zahlen neben den Matrixfeldern (... von 2 sind ...) automatisch um 1 verringert werden, wenn 1 Objekt als „Must“ festgelegt wird. Die Werte innerhalb der Matrixfelder werden jedoch nicht automatisch aktualisiert und müssen nach dem Markieren von Objekten als „Must“ überprüft werden. Die Auswirkungsgewichtung berücksichtigt nur Objekte im Zustand „Major“. Aufgrund des „Must“-Objekts nimmt das SLO einen „Minor“-Zustand an, da „States considered“ auf „Any state“ (für „Must“) gesetzt ist.

Ergebnis-Zustandstabelle

Zustandssimulation

Bei der Konfiguration eines SLO, insbesondere mit Auswirkungsgewichtung, ist es hilfreich, die Auswirkungen von Objektzuständen auf das SLO zu testen. Mit der Registerkarte „Simulieren“ kann die aktive Konfiguration getestet werden. Die Anzahl der Objekte und Must-Objekte kann überschrieben werden, um dieselbe SLO-Konfiguration mit einer anderen Anzahl von untergeordneten Objekten zu simulieren. Dies ist besonders nützlich, wenn das SLO einen Filter verwendet, um untergeordnete Objekte zu verknüpfen, und daher während seiner Lebensdauer eine unterschiedliche Anzahl von Objekten haben kann.

Zunächst zeigt das Simulationsfenster eine kurze Meldung mit der konfigurierten Zustandsgewichtung und den berücksichtigten Zuständen für Must-Objekte an. Unterhalb dieser Meldung ist der Bildschirm in zwei Bereiche unterteilt. Der Bereich „Inputs“ enthält einen Fader pro Zustand für Must-Objekte (Anzahl der „muss aktiv sein“-SLO-Unterobjekte) und normale Objekte (Anzahl der SLO-Unterobjekte (ohne „muss“)). Der Bereich „SLO-Zustand“ zeigt den resultierenden Zustand in Abhängigkeit von den Fader-Positionen im Bereich „Inputs“.

Die Fader für den Undefined- und den OK-Zustand reagieren automatisch auf Bewegungen anderer Fader. Alle anderen Fader müssen manuell eingestellt und zurückgesetzt werden. Beachten Sie, dass der Zustand „No Data” bei SLOs als OK betrachtet wird.

Wartungsflag ignorieren

Das Wartungsflag ignorieren bewirkt, dass der Wartungsstatus der zugrunde liegenden Objekte (Maintenance Major, Maintenance Minor oder Maintenance Warning) nicht an das SLO weitergegeben wird (sie werden als OK betrachtet). Wenn jedoch die Wartung für das SLO selbst festgelegt ist, hat dieses Flag keine Wirkung und die Wartung wird für das SLO festgelegt (siehe Abschnitt „Neubewertung bearbeiten”).

Dies wird meist für Top-SLOs eines Business-Service festgelegt, bei denen der Business-Prozess-Eigentümer und/oder Service-Manager möglicherweise kein Interesse an Objekten unterhalb des Top-SLO hat, die sich derzeit in Wartung befinden, solange ihr Service davon nicht betroffen ist.

Ist Alarmgrund-Flag

Wenn dieses Flag gesetzt ist, wird dieses SLO anstelle von abhängigen Jobs oder SLOs als Grund in Alarmen angezeigt, die von Alarmgeräten gesendet werden.

Übergeordneter Ausfall

In der Regel definiert eine Organisation Dienst- oder Prozessverantwortliche. In vielen Fällen haben diese Verantwortlichen möglicherweise nicht die volle Kontrolle über alle Unterdienste, von denen ihr Dienst abhängt. In einer Situation, in der sie von gemeinsam genutzten Diensten abhängig sind, muss möglicherweise sichergestellt werden, dass Ausfälle gemeinsam genutzter Dienste das Serviceniveau des übergeordneten Geschäftsprozesses oder Dienstes nicht beeinträchtigen. Dies kann durch Festlegen eines Ausfall-Übergeordneten erreicht werden. Der Ausfall-Übergeordnete kann ein anderes SLO- oder SLC-Gerät, ein Job oder ein Gruppenobjekt sein. Beispielsweise kann der Eigentümer eines Geschäftsdienstes sein oberstes SLO für Geschäftsdienste mit einem Ausfall-Übergeordneten-SLO konfigurieren, das die wichtigsten IT-Infrastrukturdienste in seinem Netzwerk umfasst, d. h. DNS, DHCP, LDAP. Wenn einer dieser Dienste ausfällt, kann der Geschäftsdienst, der (implizit) auf sie angewiesen ist, nicht ordnungsgemäß funktionieren und sollte daher nicht für die Verfügbarkeit seines Geschäftsdienstes (SLA) verantwortlich gemacht werden.

Es gelten die folgenden Regeln:

• Wenn das übergeordnete Objekt „Ausfall“ in den Status „Major“ wechselt, wird automatisch ein Wartungsfenster von 30 Tagen für alle SLOs erstellt, in denen auf dieses übergeordnete Objekt „Ausfall“ verwiesen wird.
• Wenn das übergeordnete Objekt „Ausfall” in einen anderen Status als „Major” wechselt, wird die Wartung des übergeordneten Objekts „Ausfall” automatisch für alle SLOs geschlossen, in denen auf dieses übergeordnete Objekt „Ausfall” verwiesen wird.
• Wartungsfenster für übergeordnete Ausfälle und deren Verhalten haben keine Auswirkungen auf bereits bestehende Wartungsfenster.

Verhalten der Wartung des übergeordneten Objekts „Ausfall“

Wenn der übergeordnete Ausfall seinen Status auf „Major“ ändert, wird die Wartung sofort für das abhängige SLO erstellt, sodass keine Alarme ausgegeben werden. Die Wartung wird für die nächsten 30 Tage mit dem fest codierten Namen „Wartung des übergeordneten Ausfalls“ erstellt:

Der Statusverlauf des abhängigen SLO zeigt ebenfalls die Wartung an, überlagert mit blauer Farbe und mit der Dauer und dem Namen, die sichtbar werden, wenn Sie mit der Maus über die schwarze Linie unterhalb des Wartungsfensters fahren:

Reihenfolge der SLO-Unterobjekte

Die Reihenfolge der SLO-Unterobjekte und damit ihre Darstellung im Inventar und im Objektbaum kann über die Dropdown-Liste „Objekte sortieren“ unten im Abschnitt „SLO-Verhalten“ angepasst werden:

• Manuell: Durch Klicken auf die Aufwärts- und Abwärts-Schaltflächen neben den verknüpften Objekten werden diese an die angegebene Position verschoben.
• Nach Name: Die zugrunde liegenden Objekte werden alphabetisch sortiert (keine Aufwärts-/Abwärts-Schaltflächen).
• Nach Status: Die zugrunde liegenden Objekte werden nach ihrem aktuellen Status sortiert (keine Auf-/Ab-Schaltflächen).