Das SLO (Service Level Object) ist der Hauptbaustein eines Servicemodells. Es ermöglicht die Abbildung eines Geschäfts- oder IT-Services mit all seinen redundanten Elementen und ist die Voraussetzung für die Implementierung von Service Alarming. Ein SLO kann den Zustand von Geräten oder Diensten zusammenfassen (z. B. Gesamtverfügbarkeit redundanter Dienste/Verbindungen usw.). Grundlegende Beispiele für solche Dienste könnten eine DNS-Funktion mit ihren primären und sekundären Nameservern oder eine Gruppe von Tomcat-Servern sein, bei denen nur drei von vier Servern ausgeführt werden müssen, damit der Dienst verfügbar ist und ausreichende Leistung bietet.

Um ein SLO hinzuzufügen: Wählen Sie z. B. unter /root /Customer /Services die Option SLO hinzufügen aus dem Dropdown-Menü aus:

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

Folgende SLO-Typen stehen zur Auswahl:

• Gemeinsam
  
  • Anwendung
  • Bewerbungsschritt
  • Geschäft
  • Kunde
  • Gerät
  • Funktion
  • Infrastruktur
  • ES
  • Standard (Standard)
  • Spitze
• Verfahren
  • Verfahren
  • Prozessstufe
  • Prozessaufgabe

Der Standard-SLO-Typ ist Standard . Wenn „Oben“ ausgewählt ist, wird das SLO in einer Service-Inventaransicht angezeigt. Weitere Informationen finden Sie im Abschnitt Serviceinventar anzeigen .

Objekte mit einem SLO verknüpfen

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

Abhängigkeiten

Sub-SLOs oder andere vorhandene Elemente von irgendwo anders im Objektbaum können als Abhängigkeit verknüpft werden, indem Sie im Dropdown-Menü das Element „Abhängigkeit bearbeiten“ für das SLO verwenden:

Auf der rechten Seite erscheint ein neuer Rahmen, in dem Sie nach Objekten suchen können, 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üpfbaren Objekten ist ein aktiver Pfeil zugeordnet) oder indem Sie zuerst die Kontrollkästchen der erforderlichen Objekte und dann einen der Pfeile im rechten Rahmen aktivieren. Das Kontrollkästchen des Objekts, auf das der Pfeil geklickt wird, kann deaktiviert bleiben, es wird trotzdem ausgewählt.

Nach dem Hinzufügen der Objekte sollten diese links unter dem SLO erscheinen. Klicken Sie auf OK :

Verknüpfen von Objekten mit einem SLO mithilfe von 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 verbunden. Allerdings verknüpfen Servicemodelle meist einzelne Jobs, nicht ganze Geräte. Mehrere Jobs können einfach mit EQL verknüpft werden. Wählen Sie wie oben 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 EQL- Schaltfläche in der unteren rechten Ecke des rechten Bereichs. Geben Sie den EQL-Query- Get-Job in das EQL-Query-Feld ein:

Alle Jobs unterhalb der Gruppe /root /Customer /Devices werden im rechten Bereich 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 bestimmte Kriterien erfüllen, dynamisch verknüpfen. Nach dem Hinzufügen eines SLO muss die Methode im Abschnitt „Untergeordnete Objekte“ auf „Filter definieren“ umgestellt werden.

In der SLO-Konfiguration werden die Dropdown-Listen „Suche unten “ und „ Typ“ sowie ein Filterabschnitt zum Hinzufügen von Kriterien angezeigt. Verwenden Sie die Schaltfläche „Durchsuchen“ , 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 gemäß den definierten Kriterien automatisch zum SLO hinzugefügt und 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 im Dropdown-Menü „SLOs“ die Option „Parameter bearbeiten“ oder klicken Sie auf das Stiftsymbol.

SLOs mit Zustandsgewichtung AND, Beliebiger Zustand

Die Standardgewichtung der SLO- Staaten ist AND und die berücksichtigten Staaten sind auf „Beliebiger Zustand“ eingestellt:

Resultierende Zustandstabelle

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

SLOs mit Statusgewichtung AND, nur Major

In diesem Beispiel ist die Gewichtung der Bundesstaaten AND und die berücksichtigten Bundesstaaten sind auf „Nur Major eingestellt. Dies bedeutet, dass alle zugrunde liegenden Objekte den Status „ OK oder zumindest nicht den Status „ Major haben müssen, damit sich das SLO weiterhin im Status „ OK befindet.

Resultierende Zustandstabelle

Nur ein Hauptstatus der verknüpften Objekte Icmp auf Server1 und Icmp auf Server2 wird vom SLO geerbt. Der Status des SLO ist Major , wenn der Status 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 ein oder mehrere abhängige Objekte im Zustand Major befinden.
• UND mit beliebigem Zustand ist das Verhalten eines Gruppenobjekts. Das SLO übernimmt den schlechtesten Zustand der verknüpften Objekte (d. h. den schlechtesten Zustand unterhalb des Zustands „Keine Daten“ ). Kein Datenstatus wird als OK betrachtet.
• Ein SLO ohne ein Objekt, das einen Zustand (Messung) pusht, nimmt selbst den Zustand Undefined an.
• Undefined Zustände von Objekten unterhalb des SLO behalten den Zustand des SLO auch im Zustand Undefined , solange kein anderes Objekt einen anderen Zustand anstößt.
• Wenn gestoppte oder inaktive Jobs den Status Undefined annehmen, werden SLOs, die unten keine aktiven Jobs haben, ebenfalls zu Undefined .

SLOs mit Zustandsgewichtung OR

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

Mit der Impact-Gewichtung wird die Anzahl bzw. der Prozentsatz der untergeordneten Objekte im Hauptzustand definiert. Sobald dieser Wert erreicht ist, wird das SLO den Staatsmajor übernehmen. Es gibt zwei Möglichkeiten, die Zustandsgewichtung zu konfigurieren:

• Die Anzahl der Objekte im Bundesstaat Major (mindestens)
• Die Anzahl der Objekte, die in einem besseren Zustand als „Hauptzustand“ sein müssen (weniger)

Mit dem Fader unterhalb der Wirkungsgewichtungsdefinition kann die Anzahl der Objekte definiert werden sowie durch direkte Eingabe der Anzahl in das jeweilige 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, die auch andere Zustände als den Hauptstatus berücksichtigen müssen, muss die OR-Zustandsgewichtung (erweitert) konfiguriert werden.

Die Zahlen in der Korrelationsmatrix definieren den Status des SLO in Abhängigkeit vom Status der zugrunde liegenden Objekte. Wenn ein fehlgeschlagener untergeordneter Job (wobei „fehlgeschlagen“ „ Major “ bedeutet) zu einem Warning -Status auf dem SLO führen sollte, zwei fehlgeschlagene Jobs zu einem „ Minor “-Status führen sollten und drei fehlgeschlagene Jobs dazu führen sollten, dass das SLO den Status „ Major annimmt, dann würde die Konfiguration wie folgt aussehen: Folgendes:

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

Die Matrix liest sich wie folgt:

• 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 im Status „ Major .
• Die Zeilen stellen den resultierenden Status des SLO dar

Resultierende Zustandstabelle

Der Zustand 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 “). Daher gilt die Gewichtungsregel „ Minor , wenn sich mindestens drei von drei Jobs im Status „ Minor “ oder schlechter befinden, sodass das SLO im Status „Minor“ verbleibt.

Resultierende Zustandstabelle

SLOs mit Zustandsgewichtung OR und Must -Parameter

Der Zustand wichtiger untergeordneter Objekte kann direkt an das SLO weitergegeben werden, ohne dass Gewichtungsauswirkungsregeln berücksichtigt werden müssen, und ermöglicht gleichzeitig die Gewichtungskontrolle der Zustände, die sich auf die anderen untergeordneten Objekte beziehen. Durch Aktivieren des Kontrollkästchens „Muss“ neben einem untergeordneten Objekt wird der Status des Objekts auf folgende Weise nach oben weitergegeben:

• Wenn „Zu berücksichtigende Zustände“ auf „Beliebiger Zustand (für „Muss“)“ festgelegt ist, wird jeder Zustand des „ Must “-Objekts an das SLO weitergegeben, es sei denn, der Zustand des SLO nimmt aufgrund der Gewichtungswirkung der anderen nicht markierten Objekte bereits einen schlechteren Zustand an als Muss
• Wenn „Zu berücksichtigende Zustände“ auf „Nur Major (für „Must“) festgelegt ist, wird nur ein „ Major “-Status des Must- Objekts an das SLO weitergegeben
• Wenn mehr als ein Objekt mit „Must“ markiert ist, gilt das UND- Korrelationsverhalten für alle „Must“ -Objekte, dh der schlechteste Zustand aller dieser Objekte wird nach oben verschoben

Die folgende Abbildung zeigt eine solche Konfiguration:

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

Resultierende Zustandstabelle

Zustandssimulation

Beim Konfigurieren eines SLO, insbesondere bei der 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 untergeordneter Objekte zu simulieren. Dies ist insbesondere dann nützlich, wenn das SLO einen Filter zum Verknüpfen untergeordneter Objekte verwendet und daher während seiner Lebensdauer eine unterschiedliche Anzahl von Objekten haben kann.

Das Simulationsfenster zeigt zunächst 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 Pro-Status-Fader für Must- Objekte ( Anzahl der „muss aktiv sein“-SLO-Kinder ) und normale Objekte (Anzahl der SLO-Kinder ( ohne „muss“ )). Der Abschnitt „SLO-Status“ zeigt den resultierenden Status abhängig von den Fader-Positionen im Abschnitt „Eingänge“ an.

Die Statusfader Undefined und OK reagieren automatisch auf andere Faderbewegungen. Alle anderen Fader müssen manuell eingestellt und zurückgesetzt werden. Beachten Sie, dass der Status No Data bei SLOs als OK betrachtet wird.

Wartungsflag ignorieren

Das Flag „Wartung ignorieren“ bewirkt, dass der Wartungsstatus zugrunde liegender Objekte ( Maintenance Major , Maintenance Minor oder Maintenance Warning ) ihren Status nicht auf das SLO erhöht (sie werden als OK betrachtet). Wenn jedoch die Wartung auf dem SLO selbst gesetzt ist, hat dieses Flag keine Auswirkung und das SLO wird auf die Wartung gesetzt (siehe Abschnitt Neubewertung bearbeiten ).

Dies wird meist auf Top-SLOs eines Geschäftsservices festgelegt, bei denen der Geschäftsprozessbesitzer und/oder Servicemanager möglicherweise nicht an Objekten unterhalb des Top-SLOs interessiert ist, die derzeit 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.

Ausfall übergeordnetes Element

Typischerweise definiert eine Organisation Service- oder Prozessverantwortliche. In vielen Fällen haben diese Eigentümer möglicherweise nicht die vollständige Kontrolle über alle Unterdienste, von denen ihr Dienst abhängt. In einer Situation, in der sie auf gemeinsam genutzte Dienste angewiesen sind, kann es erforderlich sein, sicherzustellen, dass Ausfälle gemeinsam genutzter Dienste nicht zu einer Beeinträchtigung des Serviceniveaus des darüber liegenden Geschäftsprozesses oder Dienstes führen. Dies kann durch Festlegen eines Outage Parent erreicht werden. Das übergeordnete Ausfallobjekt kann ein anderes SLO oder ein SLC-, Geräte-, Job- oder Gruppenobjekt sein. Beispielsweise kann der Eigentümer eines Geschäftsdienstes sein oberstes SLO für den Geschäftsdienst mit einem übergeordneten Outage- 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 folgende Regeln:

• Wenn das übergeordnete Ausfallobjekt in den Status Major wechselt, wird automatisch ein Wartungsfenster von 30 Tagen für alle SLOs erstellt, auf die auf dieses übergeordnete Ausfallobjekt verwiesen wird.
• Wenn sich das übergeordnete Ausfallobjekt in einen anderen Status als Major ändert, wird die Wartung des übergeordneten Ausfallobjekts automatisch für alle SLOs geschlossen, in denen auf dieses übergeordnete Ausfallobjekt verwiesen wird.
• Ausgefallene übergeordnete Wartungsfenster und deren Verhalten haben keine Auswirkungen auf bereits vorhandene Wartungsfenster.

Verhalten der übergeordneten Wartung bei Ausfall

Wenn der übergeordnete Ausfallstatus seinen Status in „ Major ändert, wird die Wartung sofort auf dem abhängigen SLO erstellt, sodass keine Alarme ausgegeben werden. Die Wartung wird für die nächsten 30 Tage mit dem hartcodierten Namen „Outage Parent Maintenance“ erstellt:

Der Statusverlauf des abhängigen SLO zeigt auch die Wartung an, überlagert mit blauer Farbe und mit Dauer und Name, die sichtbar sind, wenn Sie mit der Maus über die schwarze Linie unter dem Wartungsfenster fahren:

Reihenfolge der untergeordneten SLO-Objekte

Die Reihenfolge der untergeordneten SLO-Objekte und damit die Art und Weise, wie sie im Inventar und in der Objektstruktur angezeigt werden, kann durch Auswahl aus der Dropdown-Liste „ Objekte sortieren “ unten im Abschnitt „SLO-Verhalten“ angepasst werden:

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