Das SLO (Service Level Object) ist der wichtigste Baustein eines Servicemodells. Es ermöglicht die Abbildung eines Geschäfts- oder IT-Dienstes mit all seinen redundanten Elementen und ist die Voraussetzung für die Implementierung einer Dienstalarmierung. Ein SLO kann den Zustand von Geräten oder Diensten zusammenfassen (z. B. die Gesamtverfügbarkeit von redundanten Diensten/Links/etc.). Grundlegende Beispiele für solche Dienste könnten eine DNS-Funktion mit einem primären und einem sekundären Nameserver sein, oder eine Gruppe von Tomcat-Servern, bei der nur 3 von 4 Servern laufen müssen, damit der Dienst verfügbar ist und eine ausreichende Leistung bietet.

So fügen Sie einen SLO hinzu: Wählen Sie z. B. unter /root /Customer /Services die Option SLO hinzufügen aus dem Dropdown-Menü:

Geben Sie einen Namen für das neue SLO ein, legen Sie den Typ fest (optional) und klicken Sie dann auf OK oder klicken Sie auf OK, Add next, wenn ein weiteres SLO hinzugefügt werden soll:

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

• Allgemein
  
  • Anwendung
  • Anwendungsschritt
  • Geschäftlich
  • Kunde
  • Gerät
  • Funktion
  • Infrastruktur
  • IT
  • Standard (Voreinstellung)
  • Startseite
• Prozess
  • Prozess
  • Prozess-Schritt
  • Prozessaufgabe

Der Standard-SLO-Typ ist Standard. Wenn Top gewählt wird, erscheint der SLO in einer Dienstinventaransicht. Siehe Abschnitt Dienstinventar anzeigen für weitere Details.

Verknüpfung von Objekten mit einem SLO

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

Abhängigkeiten

Unter-SLOs oder andere existierende Objekte von einer anderen Stelle im Objektbaum können als Abhängigkeit verknüpft werden, indem Sie den Punkt Abhängigkeit bearbeiten auf dem SLO aus dem Dropdown-Menü wählen:

Auf der rechten Seite erscheint ein neuer Rahmen, in dem nach Objekten gesucht werden kann, die mit dem SLO verknüpft werden sollen. Durchsuchen Sie den Objektbaum 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 und dann einen der Pfeile im rechten Rahmen auswählen. Das Kontrollkästchen des Objekts, auf das der Pfeil geklickt wird, kann unmarkiert bleiben, es wird trotzdem ausgewählt.

Nachdem Sie die Objekte hinzugefügt haben, sollten sie links unter dem SLO erscheinen. Klicken Sie auf OK:

Verknüpfung von Objekten mit einem SLO mittels EQL

Eine weitere Möglichkeit, bestimmte Objekte schnell mit einem SLO zu verknüpfen, ist die Verwendung der EQL-Befehlszeile für rekursive Filterung. Im obigen Beispiel wurden 2 Geräte mit dem SLO verknüpft. Servicemodelle verknüpfen jedoch meist einzelne Aufträge, nicht ganze Geräte. Mehrere Jobs können mit EQL einfach verknüpft werden. Wählen Sie wie oben im Dropdown-Menü SLOs die Option Abhängigkeit bearbeiten und suchen Sie nach der übergeordneten Gruppe der Geräte, die die Aufträge 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 Feld EQL-Abfrage ein:

Alle Aufträge unterhalb der Gruppe /root /Customer /Devices werden im rechten Fensterbereich aufgelistet. Wählen Sie die Aufträge 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, erlaubt EQL eine zusätzliche Filterung nach Name oder Status usw. Siehe Kapitel EQL: SKOOR Engine Abfragesprache für weitere Details.

Filter

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

In der SLO-Konfiguration erscheinen die Dropdown-Listen Suche unten und Typ sowie ein Filterabschnitt zum Hinzufügen von Kriterien. Verwenden Sie die Schaltfläche Durchsuchen, um eine Gruppe auszuwählen, in der Objekte für diesen SLO gesucht werden. 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 zu der SLO hinzugefügt oder daraus entfernt.

SLO-Korrelationsregeln

Nun kann man konfigurieren, welchen Einfluss die Zustände dieser zugrundeliegenden Objekte auf den SLO haben. Wählen Sie dazu Parameter bearbeiten aus dem Dropdown-Menü SLOs oder klicken Sie auf das Bleistiftsymbol.

SLOs mit Zustandsgewichtung AND, Beliebiger Zustand

Die Standard-SLO-Zustandsgewichtung ist AND und die berücksichtigten Zustände sind auf Any state eingestellt:

Resultierende Zustandstabelle

Das SLO nimmt den schlechtesten Zustand eines der verknüpften Objekte an:

SLOs mit Zustandsgewichtung AND, nur Major

In diesem Beispiel ist die Zustandsgewichtung AND und die berücksichtigten Zustände sind auf Major only gesetzt. Das bedeutet, dass alle zugrundeliegenden Objekte im Zustand OK oder zumindest nicht im Zustand Major sein müssen, damit die SLO noch im Zustand OK ist.

Resultierende Zustandstabelle

Nur ein Major-Zustand der verknüpften Objekte Icmp auf Server1 und Icmp auf Server2 wird an das SLO vererbt. Der Zustand des SLO ist Major, wenn der Zustand eines zugrunde liegenden Objekts Major ist.

Bei SLOs, die mit der "AND"-Regel konfiguriert sind, ist Folgendes zu beachten

• AND mit Major bedeutet nur, dass das SLO den Zustand Major annimmt, wenn sich 1 oder mehrere abhängige Objekte im Zustand Major befinden.
• AND with Any state ist das Verhalten eines Gruppenobjekts. Das SLO nimmt den schlechtesten Zustand der verbundenen Objekte an (d.h. den schlechtesten Zustand unterhalb des Zustands No Data). No Data-Zustände werden als OK betrachtet.
• Ein SLO ohne ein Objekt, das einen Zustand schiebt (Messung), nimmt selbst den Zustand Undefined an.
• Undefined-Zustände von Objekten unterhalb des SLO halten den Zustand des SLO ebenfalls im Zustand Undefined, solange kein anderes Objekt einen anderen Zustand schiebt.
• Da gestoppte oder inaktive Jobs den Zustand Undefined einnehmen, werden auch SLOs, die keine aktiven Jobs darunter haben, Undefined.

SLOs mit Zustandsgewichtung OR

Im folgenden Beispiel wurde ein dritter Job mit dem SLO verknüpft. Die Zustandsgewichtung ist OR und die berücksichtigten Zustände sind automatisch auf Any state (für 'must') gesetzt . Bei der einfachen ODER-Konfiguration wird nur der Major-Status der zugrunde liegenden Objekte berücksichtigt. Nur Objekte, die als ' Must' gekennzeichnet 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 Zustand Major festgelegt. Sobald dieser Wert erreicht ist, nimmt das SLO den Zustand Major an. Es gibt zwei Möglichkeiten, die Zustandsgewichtung zu konfigurieren:

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

Mit dem Schieberegler unter der Definition der Auswirkungsgewichtung kann die Anzahl der Objekte definiert werden, aber auch durch direkte Eingabe der Anzahl in das entsprechende Feld.

Die prozentuale Anzahl der Objekte ist vor allem dann eine gute Wahl, wenn die SLO ihre Unterobjekte dynamisch filtert.

SLOs mit Zustandsgewichtung OR (fortgeschritten)

Für Konfigurationen, die auch andere Zustände als Major berücksichtigen sollen, muss die Zustandsgewichtung OR (advanced) konfiguriert werden.

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

In diesem Beispiel führt 1 fehlgeschlagener Auftrag dazu, dass das SLO in den Zustand Warning (gelb) übergeht.

Die Matrix wird wie folgt gelesen:

• Die Spalten stellen den Zustand der zugrunde liegenden Objekte dieses SLO dar. In der ersten Spalte befinden sich die Objekte im Zustand Warning, in der zweiten Spalte die Objekte im Zustand Minor und in der dritten Spalte im Zustand Major
• Die Zeilen stellen den resultierenden Zustand des SLO dar

Resultierende Status-Tabelle

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

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

3 Stellen haben den Zustand Minor oder schlechter (2 Minor, 1 Major), so dass die Gewichtungsregel Minor gilt , wenn mindestens 3 von 3 im Zustand Minor oder schlechter sind, so dass die SLO im Zustand Minor bleibt.

Resultierende State-Tabelle

SLOs mit Zustandsgewichtung OR und Must-Parameter

Der Zustand wichtiger untergeordneter Objekte kann direkt an die SLO weitergegeben werden, ohne dass irgendwelche Gewichtungsregeln berücksichtigt werden. Wenn Sie das Kontrollkästchen Muss neben einem untergeordneten Objekt aktivieren, wird der Zustand des Objekts auf folgende Weise nach oben weitergegeben:

• Wenn "States considered" auf " Any state" (für "must") gesetzt ist, wird jeder Zustand des Must-Objekts an das SLO weitergegeben, es sei denn, der Zustand des SLO nimmt aufgrund der Gewichtungsauswirkungen der anderen nicht als Must markierten Objekte bereits einen schlechteren Zustand an
• Wenn States considered auf Major only (für 'must') gesetzt ist, wird nur ein Major-Zustand des Must-Objekts an den SLO weitergegeben.
• Wenn mehr als ein Objekt als "Must" gekennzeichnet ist, gilt das UND-Korrelationsverhalten für alle "Must" -Objekte, d. h. der schlechteste Zustand all dieser Objekte wird nach oben verschoben.

In der folgenden Abbildung ist eine solche Konfiguration dargestellt:

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

Resultierende Zustandstabelle

Simulation von Zuständen

Bei der Konfiguration einer SLO, insbesondere bei der Gewichtung der Auswirkungen, ist es hilfreich, die Auswirkungen der Objektzustände auf die SLO zu testen. Auf der Registerkarte Simulieren kann die aktive Konfiguration getestet werden. Die Anzahl der Objekte und Must-Objekte kann überschrieben werden, um die gleiche SLO-Konfiguration mit einer anderen Anzahl von untergeordneten Objekten zu simulieren. Dies ist insbesondere dann sinnvoll, wenn das SLO einen Filter zur Verknüpfung von Unterobjekten verwendet 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 Abschnitte unterteilt. Der Abschnitt Eingaben enthält einen Schieberegler pro Zustand für Must-Objekte(Anzahl der 'must be up' SLO-Kinder) und normale Objekte (Anzahl der SLO-Kinder(ohne 'must')). Der SLO-Zustandsabschnitt zeigt den resultierenden Zustand in Abhängigkeit von den Schiebereglerpositionen im Inputs-Abschnitt.

Die Fader Undefined und OK wirken automatisch auf andere Faderbewegungen. Alle anderen Fader müssen manuell gesetzt und zurückgesetzt werden. Beachten Sie, dass der Zustand No Data bei SLOs als OK angesehen wird.

Wartungs-Flag ignorieren

Das Flag Wartung ignorieren bewirkt, dass der Wartungszustand von darunter liegenden Objekten (Maintenance Major, Maintenance Minor oder Maintenance Warning) nicht auf den SLO übertragen wird (sie werden als OK betrachtet). Wenn jedoch auf dem SLO selbst eine Wartung gesetzt ist, hat dieses Flag keine Wirkung und der SLO wird eine Wartung gesetzt haben (siehe Abschnitt Neubewertung bearbeiten).

Dies wird meist auf Top-SLOs eines Business Service gesetzt, wo der Geschäftsprozessverantwortliche und/oder der Service Manager möglicherweise nicht an Objekten interessiert ist, die irgendwo unterhalb des Top-SLOs liegen und gerade gewartet werden, solange ihr Service nicht betroffen ist.

Ist Alarmgrund-Flag

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

Ausfälle übergeordnet

Normalerweise definiert eine Organisation Dienst- oder Prozesseigentümer. In vielen Fällen haben diese Eigentümer 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, kann es erforderlich sein, sicherzustellen, dass Ausfälle von gemeinsam genutzten Diensten den Service-Level des darüber liegenden Geschäftsprozesses oder Dienstes nicht beeinträchtigen. Dies kann durch das Festlegen eines Outage Parent erreicht werden. Der Outage Parent kann ein anderer SLO, ein SLC, ein Gerät, ein Job oder ein Gruppenobjekt sein. Der Eigentümer eines Geschäftsdienstes kann zum Beispiel seinen Top-SLO für den Geschäftsdienst mit einem übergeordneten SLO für Ausfälle konfigurieren, der die wichtigsten IT-Infrastrukturdienste in seinem Netzwerk umfasst, z. B. DNS, DHCP, LDAP. Wenn einer dieser Dienste ausfällt, kann der Geschäftsdienst, der sich (implizit) auf diese Dienste stützt, nicht ordnungsgemäß funktionieren und sollte daher nicht für die Verfügbarkeit seines Geschäftsdienstes verantwortlich gemacht werden (SLA).

Es gelten die folgenden Regeln:

• Wenn das übergeordnete Objekt Outage in den Zustand Major übergeht, wird automatisch ein Wartungsfenster von 30 Tagen für alle SLOs erstellt, auf die dieses Outage Parent referenziert wird.
• Wenn das Outage Parent-Objekt in einen anderen Zustand als Major wechselt, wird die Outage Parent-Wartung automatisch für alle SLOs geschlossen, auf die dieses Outage Parent referenziert ist.
• Die Wartungsfensterdes Outage Parent und ihr Verhalten haben keinen Einfluss auf bereits bestehende Wartungsfenster.

Verhalten von Outage parent Wartungen

Wenn der Outage Parent seinen Status auf Major ändert, wird die Wartung sofort auf dem abhängigen SLO erstellt, so dass keine Alarme ausgegeben werden. Die Wartung wird für die nächsten 30 Tage mit dem hartkodierten Namen outage parent maintenance angelegt:

Die Status-Historie des abhängigen SLO zeigt die Wartung ebenfalls an, überlagert mit blauer Farbe und mit der Dauer und dem Namen sichtbar, wenn man mit der Maus über die schwarze Linie unter dem Wartungsfenster fährt:

Anordnung der SLO-Unterobjekte

Die Reihenfolge der SLO-Unterobjekte und damit die Darstellung im Baum Diagramm und im Objektbaum kann durch Auswahl aus der Dropdown-Liste Objekte sortieren unten im Abschnitt SLO-Verhalten angepasst werden:

• Manuell: Durch Anklicken der Auf- und Ab-Schaltflächen neben den verknüpften Objekten werden diese an die angegebene Position verschoben
• Nach Name: Die zugrunde liegenden Objekte werden alphabetisch sortiert (keine Auf-/Ab-Schaltflächen )
• Nach Zustand: Die zugrundeliegenden Objekte werden nach ihrem aktuellen Zustand sortiert (keine Auf-/Ab-Schaltflächen )