SLOs entwerfen

Diese Seite enthält Informationen, die Sie möglicherweise benötigen, bevor Sie ein Service Level Objective (SLO) erstellen.

Eine Einführung zu SLOs finden Sie unter Service Level Objectives –Übersicht.

SLI-Typ und Complianceziele

Cloud Service Mesh unterstützt die folgenden Arten von Service Level Indicators:

  • Latenz: Die Zeit in Millisekunden, die ein Dienst benötigt, um eine Antwort auf eine Anfrage zurückzugeben.
  • Verfügbarkeit: Die Zeit, in der ein Dienst antwortet. erfolgreich war.
  • Sonstiges: Benutzerdefinierter SLO-Typ, der auf Ihren konfigurierbaren Messwerten basiert.

Sie definieren auch das Complianceziel, das Sie von Ihrem Dienst erwarten. Im Allgemeinen sollten SLOs nicht höher als notwendig oder sinnvoll für Ihre Nutzer sein. Überlegen Sie, an welchem Punkt die Nutzer einen Dienstausfall eventuell bemerken. Wenn die Nutzer beispielsweise bei Ihrem Dienst den Unterschied zwischen einer Latenzzeit von 300 ms und 500 ms nicht erkennen können, verwenden Sie im SLO den höheren Wert als Latenzschwellenwert. Die Kosten sind niedriger und die Nutzer werden den Unterschied nicht bemerken.

Berücksichtigen Sie beim Festlegen eines Complianceziels die Endnutzeranforderungen für den Dienst. Beispielsweise kann für ein internes Tool, das von Mitarbeitern verwendet wird, um die Urlaubszeit zu reservieren, ein Verfügbarkeitsziel von 99 % (eine ungefähre Ausfallzeit von 3 Tagen pro Jahr) ausreichen. Ein kritischer Dienst für einen Onlineshop kann jedoch eine Verfügbarkeit von 99,999 % (etwa 5 Minuten Ausfallzeit pro Jahr) erfordern.

Compliancezeiträume

Ein SLO definiert nicht nur ein Ziel für einen SLI, sondern gibt auch einen Zeitraum an, in dem der SLI gemessen wird. Beispielsweise unterscheidet sich die Verfügbarkeit von 99 % im Laufe eines Tages von der Verfügbarkeit von 99 % im Laufe eines Monats. Das erste SLO würde nicht mehr als 14 Minuten durchgehende Ausfallzeit (24 Stunden * 1 %) zulassen, während das zweite SLO eine durchgehende Ausfallzeit von bis zu circa 7 Stunden (30 Tage * 1 %) zulassen würde.

Der Compliancezeitraum ist besonders wichtig, wenn ein SLO in einem Service Level Agreement (SLA) mit Ihren Nutzern enthalten ist. Ein SLA ist ein Vertrag mit den Nutzern Ihres Dienstes, der in der Regel die Konsequenzen angibt, wenn die SLOs nicht erfüllt werden. Die Entscheidung, ob Sie mit Ihren Nutzern ein SLA abgeschlossen haben oder nicht, ist eine produktbezogene Entscheidung bzw. Geschäftsentscheidung. Sie müssen jedoch zu Monitoringzwecken einen Compliancezeitraum für die SLOs angeben, wenn Sie diese erstellen.

Wenn Sie SLOs konfigurieren, wählen Sie die Art des Compliancezeitraums aus:

  • Kalender: Wenn Sie Kalender als Zeitraumtyp auswählen, geben Sie auch die Länge des Zeitraums an. Diese kann einen Tag, eine Woche oder einen Monat betragen. Die Zeiträume überschneiden sich nicht und werden an das Start- und Enddatum des Kalenders angepasst. Die Compliance kann nur am Ende des Zeitraums ausgewertet werden.

  • Fortlaufend: Wenn Sie Fortlaufend als Zeitraumtyp auswählen, geben Sie auch die Anzahl der Tage für die Länge des Zeitraums an, beispielsweise 30 Tage. Im Gegensatz zu Kalenderzeiträumen haben fortlaufende Zeiträume keine festen Start- und Enddaten. Cloud Service Mesh wertet SLOs kontinuierlich mit einer rollierenden Compliancezeitraum. Die ältesten Daten aus der vorherigen Berechnung werden in der aktuellen Berechnung nicht mehr berücksichtigt, da sie durch neue Daten ersetzt werden. Durch einen fortlaufenden Zeitraum erhalten Sie mehr Compliancemessungen, da die Compliance einmal pro Tag für die letzten 30 Tage gemessen wird, nicht nur einmal im Monat. Dienste können jedoch zwischen Compliance und Nichtcompliance hin- und herwechseln, da sich der SLO-Status täglich ändert.

Fehlerbudgets

Ein weiteres wichtiges Monitoringkonzept ist das Fehlerbudget. Ein SLO gibt einen SLI und einen Zielwert an, der den Erfolg des Dienstes im Compliancezeitraum misst. Das Fehlerbudget für ein SLO gibt die Gesamtzeit an, in der ein Dienst nicht konform sein darf, bevor er gegen das SLO verstößt. Somit liegt das Fehlerbudget bei 100% - SLO%. Wenn Sie beispielsweise ein Verfügbarkeits-SLO für einen fortlaufenden Zeitraum von 30 Tagen mit einem Complianceziel von 99,99 % haben, beträgt das Fehlerbudget 0,01 % von 30 Tagen. Das sind etwas mehr als vier Minuten zulässige Ausfallzeit alle 30 Tage. Ein Dienst mit einem SLO von 100 % hat kein Fehlerbudget.

Mithilfe von Fehlerbudgets können Sie nachvollziehen, wie viele schlechte SLI-Messungen im verbleibenden Compliancezeitraum stattfinden dürfen, bevor ein Verstoß gegen das SLO vorliegt. Sie können das Fehlerbudget verwenden, um Wartungsaufgaben wie die Bereitstellung neuer Versionen zu verwalten. Wenn das Fehlerbudget nahezu aufgebraucht ist, empfiehlt es sich nicht, riskante Aktionen wie die Bereitstellung neuer Updates auszuführen. Wenn das Fehlerbudget jedoch gegen Ende eines Compliancezeitraums noch kaum aufgebraucht ist, bietet es sich an, neue Features einzuführen, da dann das Risiko geringer ist, dass gegen das SLO verstoßen wird.

Wenn Sie ein SLO mit einem Compliancezeitraum wie einem Kalendermonat messen, nimmt Service Mesh anfangs für das Fehlerbudget den Höchstwert an und senkt diesen im Laufe der Zeit. Wenn der Wert für das Fehlerbudget unter 0 fällt, wird ein SLO-Verstoß ausgelöst. Cloud Service Mesh setzt das Fehlerbudget des SLO am Ende der Compliance zurück Punkt.

Wenn Sie ein SLO über einen rollierenden Compliancezeitraum messen, befinden Sie sich tatsächlich immer am Ende eines Compliancezeitraums. Statt bei null anzufangen werden alte Datenpunkte kontinuierlich entfernt und neue Datenpunkte kontinuierlich hinzugefügt. Wenn ein Zeitraum mit schlechter Compliance aus dem Compliancezeitfenster fällt und das SLO den Vorgaben entspricht, steigt das Fehlerbudget. Ein error budget ≥ 0 weist zu einer beliebigen Zeit auf ein konformes rollierendes SLO-Zeitfenster hin und ein error budget < 0 weist auf ein nicht konformes rollierendes SLO-Fenster hin.

Weitere Informationen