Das SLO (Service Level Object) ist der Hauptbaustein eines Servicemodells. Es ermöglicht die Abbildung eines Business- oder IT-Service 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 von redundanten Diensten/Links/etc.). 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 3 von 4 Servern laufen müssen, damit der Dienst verfügbar ist und genügend Leistung bietet.

So fügen Sie ein SLO hinzu: 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 , Weiter hinzufügen, wenn ein weiteres SLO hinzugefügt werden muss:

Folgende SLO-Typen können ausgewählt werden:

• Verbreitet
  
  • Anwendung
  • Bewerbungsschritt
  • Geschäft
  • Kunde
  • Gerät
  • Funktion
  • Infrastruktur
  • ES
  • Standard (Standard)
  • oben
• Verfahren
  • Verfahren
  • Prozessstufe
  • Aufgabe bearbeiten

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

Verknüpfen 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

Sub-SLOs oder andere vorhandene Elemente von einer anderen Stelle in der Objektstruktur können als Abhängigkeit verknüpft werden, indem das Element Abhängigkeit bearbeiten für das SLO aus dem Dropdown-Menü verwendet wird:

Auf der rechten Seite wird ein neuer Rahmen angezeigt, 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üpfbare Objekte haben einen aktiven Pfeil) 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 unterhalb des SLO erscheinen. Klicken Sie auf OK :

Verknüpfen von Objekten mit einem SLO mithilfe von EQL

Eine andere 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 2 Geräte mit dem SLO verbunden. Allerdings verknüpfen Servicemodelle meist einzelne Jobs, 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 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-Abfrage- Get-Job in das EQL-Abfragefeld 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, erlaubt EQL eine zusätzliche Filterung nach Name oder Zustand usw. Siehe Kapitel EQL: Abfragesprache der SKOOR Engine für weitere Details.

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 Untergeordnete Objekte auf Filter definieren umgeschaltet werden.

Die Dropdown-Menüs „ Suchen unten “ und „ Typ “ werden in der SLO-Konfiguration 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 Parameter bearbeiten aus dem Dropdown-Menü SLOs oder klicken Sie auf das Stiftsymbol.

SLOs mit Zustandsgewichtung UND, Beliebiger Zustand

Die Standardgewichtung der SLO -Zustände ist UND und die berücksichtigten Zustände sind auf Beliebiger Zustand eingestellt:

Resultierende Zustandstabelle

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

SLOs mit Zustandsgewichtung UND, nur Major

In diesem Beispiel ist die Zustandsgewichtung UND und die betrachteten Zustände sind auf Major wichtig eingestellt. Das bedeutet, dass alle zugrunde liegenden Objekte im Zustand OK oder zumindest nicht im Zustand Major sein müssen, damit das SLO noch im Zustand OK ist.

Resultierende Zustandstabelle

Nur ein Hauptzustand 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 „UND“-Regel konfiguriert sind, muss Folgendes beachtet werden

• UND mit Major bedeutet nur , dass wenn 1 oder mehr abhängige Objekte im Zustand Major sind, das SLO den Zustand Major .
• AND mit Any state ist das Verhalten eines Gruppenobjekts. Das SLO nimmt den schlechtesten Zustand der verknüpften Objekte an (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) drückt, nimmt selbst den Zustand Undefined an.
• Undefined Zustände von Objekten unterhalb des SLO halten den Zustand des SLO auch im Zustand Undefined , solange kein anderes Objekt einen anderen Zustand drückt.
• Da angehaltene oder inaktive Jobs den Status Undefiniert annehmen, werden Undefined , die unten keine aktiven Jobs haben, ebenfalls Undefined .

SLOs mit Zustandsgewichtung ODER

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

Mit der Impact-Gewichtung wird die Anzahl bzw. Prozentzahl von untergeordneten Objekten im Zustand major definiert. Sobald dieser Wert erreicht ist, übernimmt der SLO den Landesmajor. Es gibt zwei Möglichkeiten, die Zustandsgewichtung zu konfigurieren:

• Die Anzahl der Objekte im Hauptstaat (Mindestens)
• Die Anzahl der Objekte, die in einem besseren Zustand als in einem größeren Zustand sein müssen (Weniger)

Mit dem Fader unterhalb der Schlaggewichtungsdefinition kann die Anzahl der Objekte ebenso definiert werden wie 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 ODER (erweitert)

Für Konfigurationen, die auch andere Zustände als den Hauptzustand berücksichtigen müssen, muss die ODER-Zustandsgewichtung (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 untergeordneter Job (wobei fehlgeschlagen bedeutet Major ) zu einem Warning auf dem SLO führen sollte, 2 fehlgeschlagene Jobs zu einem Minor -Status führen sollten und 3 fehlgeschlagene Jobs das SLO den Status Major annehmen sollten, würde die Konfiguration wie folgt aussehen Folgendes:

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

Die Matrix wird wie folgt gelesen:

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

Resultierende Zustandstabelle

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

Im folgenden Beispiel werden auch Minor 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 mindestens 3 von 3 den Status Minor oder schlechter haben, wodurch 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 Gewichtungsauswirkungsregeln zu berücksichtigen, während gleichzeitig eine Gewichtungskontrolle von Zuständen ermöglicht wird, die sich auf die anderen untergeordneten Objekte beziehen. Durch Aktivieren des Kontrollkästchens Muss neben einem untergeordneten Objekt wird der Zustand des Objekts auf folgende Weise nach oben weitergegeben:

• Wenn States Considered auf Any state (for 'must') gesetzt ist, wird jeder Zustand des Must -Objekts an das SLO weitergegeben, es sei denn, der Zustand des SLO nimmt bereits aufgrund der Gewichtungswirkung der anderen nicht markierten Objekte einen schlechteren Zustand an als Muss
• Wenn States Considered auf Major only (for 'must') gesetzt ist, wird nur ein Major -Zustand des Must -Objekts an das SLO weitergegeben
• Wenn mehr als ein Objekt als Muss markiert ist, gilt das UND- Korrelationsverhalten für alle Muss -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. Die Werte in den Matrixfeldern werden jedoch nicht automatisch aktualisiert und müssen nach dem Markieren von Objekten erneut überprüft werden Muss . Die Impact-Gewichtung berücksichtigt nur Objekte im Zustand Major . Aufgrund des Must -Objekts nimmt das SLO den Status Minor an, da States Considered auf Any state (für 'must') gesetzt ist.

Resultierende Zustandstabelle

Zustandssimulation

Beim Konfigurieren eines SLO, insbesondere mit Auswirkungsgewichtung, ist es hilfreich, die Auswirkung 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 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.

Das Simulationsfenster zeigt zunächst eine Kurzmeldung mit der konfigurierten Zustandsgewichtung und den berücksichtigten Zuständen für Muss -Objekte. Unterhalb dieser Meldung ist der Bildschirm in zwei Bereiche unterteilt. Der Inputs -Bereich enthält einen Per-State-Fader für Must -Objekte ( Count of 'must be up' SLO-Children ) und normale Objekte (Count of SLO-Children ( ohne 'must' )). Der SLO-Zustandsbereich zeigt den resultierenden Zustand in Abhängigkeit von den Faderpositionen im Eingangsbereich.

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

Wartungsflag ignorieren

Das Ignore-Wartungs -Flag bewirkt, dass jeder Wartungsstatus von zugrunde liegenden Objekten ( Maintenance Major , Maintenance Minor oder Maintenance Warning ) ihren Status nicht auf das SLO hochschiebt (sie werden als OK betrachtet). Wenn jedoch die Wartung auf dem SLO selbst gesetzt ist, dann hat dieses Kennzeichen keine Auswirkung und das SLO wird auf Wartung gesetzt (siehe Abschnitt Neubewertung bearbeiten ).

Dies wird meistens auf Top-SLOs eines Business-Services 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 ein Alarmgrund- Flag

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

Ausfall übergeordnetes Element

Typischerweise definiert eine Organisation Dienst- oder Prozessverantwortliche. In vielen Fällen haben diese Eigentümer 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ängen, muss möglicherweise sichergestellt werden, dass Ausfälle von gemeinsam genutzten Diensten das Serviceniveau des darüber liegenden Geschäftsprozesses oder Dienstes nicht diskreditieren. Dies kann erreicht werden, indem ein übergeordnetes Outage festgelegt wird . Das übergeordnete Objekt „Ausfall“ kann ein anderes SLO oder ein SLC- , Geräte-, Job- oder Gruppenobjekt sein. Beispielsweise kann der Eigentümer eines Business Service sein Top-SLO für Business Service mit einem übergeordneten Outage -SLO konfigurieren, das die wichtigsten IT-Infrastrukturdienste in seinem Netzwerk umfasst, dh DNS, DHCP, LDAP. Wenn einer dieser Dienste ausfällt, kann der Unternehmensdienst, der sich (implizit) darauf verlässt, nicht richtig funktionieren und sollte daher nicht für die Verfügbarkeit seines Unternehmensdienstes (SLA) verantwortlich gemacht werden.

Es gelten folgende 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 auf allen SLOs geschlossen, auf die auf dieses übergeordnete Objekt „Ausfall“ verwiesen wird.
• Ausgefallene übergeordnete Wartungsfenster und deren Verhalten haben keine Auswirkung auf bereits bestehende Wartungsfenster.

Verhalten der übergeordneten Wartung bei Ausfall

Wenn das übergeordnete Element „Ausfall“ 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 fest codierten Namen outage parent maintenance erstellt:

Der Zustandsverlauf des abhängigen SLO zeigt ebenfalls die Wartung, ü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:

Sortieren von untergeordneten SLO-Objekten

Die Reihenfolge der untergeordneten SLO-Objekte und somit deren Anzeige im Inventar und im Objektbaum 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 sind alphabetisch sortiert (keine Auf- / Ab -Schaltflächen)
• Nach Status : Die zugrunde liegenden Objekte werden nach ihrem aktuellen Status sortiert (keine Auf- / Ab -Schaltflächen