In diesem Abschnitt wird das Konzept der SLIs (Service Level Indicators) beschrieben. Es wird dargelegt, welche SLIs sinnvoll oder nützlich sind, und es werden Beispiele für SLI-Implementierungen ausgewählter Dienste präsentiert. Diese Seite richtet sich an Personen, die Beispiele zur Implementierung dienstspezifischer SLIs benötigen.
Einführung in SLIs
Die Zuverlässigkeit eines Dienstes ist eine abstrakte Idee. Was Zuverlässigkeit bedeutet, ist vom Dienst und den Anforderungen seiner Nutzer abhängig. Ein Service Level Indicator (SLI) ist ein Maß für diese Zuverlässigkeit und wird verwendet, um eine Beschreibung der Zuverlässigkeit des Dienstes zu ermöglichen und den Dienst zu verwalten.
SLIs werden für ein Zeitfenster gemessen. Die Größe des Fensters hängt normalerweise davon ab, für welche Entscheidung die Informationen verwendet werden. So können Sie beispielsweise einen einzelnen SLI messen:
- Über die letzte Stunde (zum Erstellen von Benachrichtigungsrichtlinien).
- Über Wochen (für taktische Entscheidungen).
- Über Monate (für strategische Entscheidungen).
Wir empfehlen 28 Tage als Ausgangspunkt für die Messung Ihres SLI. Dieser Wert bietet ein gutes Gleichgewicht zwischen strategischen und taktischen Anwendungsfällen.
Weitere Informationen finden Sie in den folgenden Abschnitten des Site Reliability Engineering Workbook:
Eigenschaften guter SLIs
Als "gute" SLIs gelten solche Maßnahmen, die folgende Kriterien erfüllen:
SLIs eignen sich gut zum Messen der Nutzerzufriedenheit.
Gute SLIs stehen in engem Zusammenhang mit der Nutzerzufriedenheit. SLIs dienen als Grundlage für Service Level Objectives (SLO), für SLIs festgelegte Schwellenwerte. Sie legen SLOs so fest, dass die meisten Nutzer zufrieden sind, wenn der entsprechende SLI innerhalb eines definierten Bereichs liegt. Damit diese Beziehung belastbar ist, muss der SLI ein gutes Maß für die Nutzerzufriedenheit sein.
Ist der SLI ein gutes Maß für die Nutzerzufriedenheit, so ändert sich der SLI im Falle eines Ereignisses, das sich auf die Zufriedenheit der Nutzer auswirkt. Gleichermaßen ändert sich der SLI nicht, wenn keine sich auf die Zufriedenheit der Nutzer auswirkenden Ereignisse vorliegen.
SLIs skalieren monoton und linear mit der Nutzerzufriedenheit.
Gute SLIs skalieren monoton und linear mit der Nutzerzufriedenheit. Wenn sich der SLI verbessert, steigt die Nutzerzufriedenheit. Wenn der SLI abnimmt, nimmt auch die Nutzerzufriedenheit ab. Der Umfang der Verbesserung eines guten SLI-Werts entspricht dem Umfang der Verbesserung der Nutzerzufriedenheit.
SLIs ergeben Werte zwischen 0 % und 100 %.
Ein guter SLI liefert einen Leistungsmesswert zwischen 0 % und 100 %: Dieser Bereich ist intuitiv und leicht zu verwenden. Beispiel: Eine SLI-Leistung von 100 % bedeutet, dass alles gut läuft. Eine SLI-Leistung von 0 % bedeutet, dass nichts gut läuft.
Mit einem SLI zwischen 0 % und 100 % wird zum Festlegen eines SLO für den SLI einfach ein Prozentsatzziel von beispielsweise 99,9 % bestimmt. Die SLI-Leistung des Dienstes muss diesem Wert entsprechen oder ihn übertreffen, um das SLO zu erfüllen.
Versprechen
Wenn Sie einen SLI mit diesen Attributen implementieren möchten, können Sie sich den SLI als eine Art Nutzerversprechen vorstellen. Wenn Sie eingehaltene und gebrochene Versprechen über die Zeit erfassen, können Sie daraus einen Wert von 0 % bis 100 % ableiten. Solche SLIs lassen sich auch gut in Fehlerbudgets umwandeln: Für ein bestimmtes SLO ist Ihr Fehlerbudget die Anzahl der Versprechen, die Sie über ein Zeitfenster hinaus brechen können, ohne dass das SLO verletzt wird.
Beispiele für Versprechen:
- Einer Kundenanfrage eine Antwort mit dem HTTP-Statuscode
200zurückgeben. - In weniger als 100 ms auf eine gRPC-Anfrage reagieren.
- Den Workflow "Virtuelle Maschine erstellen" erfolgreich beenden.
- Daten bereitstellen, die in den letzten zehn Minuten aktualisiert wurden.
- Innerhalb einer Minute ab der Startzeit mit der Ausführung eines geplanten Batchjobs beginnen.
SLI-Spezifikationen und -Implementierungen
Eine SLI-Spezifikation ist das, was Sie messen möchten. Die Spezifikation enthält nicht die genauen technischen Details dazu, wie Sie messen werden. Im Folgenden finden Sie beispielsweise eine Spezifikation eines SLI für die Seitenladezeit:
- Der Prozentsatz der Startseitenanfragen, die in weniger als 100 ms geladen werden.
Es gibt viele Möglichkeiten, einen SLI zu messen. Alle haben ihre Vor- und Nachteile. Die Methoden zur Messung des SLI sind die SLI-Implementierungen. Sie können beispielsweise die Seitenladespezifikation so implementieren:
- Über das Latenzfeld des Anfragelogs des Anwendungsservers.
- Über vom Anwendungsserver exportierte Messwerte.
- Über von einem Load-Balancer vor den Anwendungsservern exportierte Messwerte.
- Über einen Blackbox-Monitoring-Dienst, der künstliche Anfragen an das System sendet und misst, wie lange es dauert, bis gültige Antworten empfangen werden.
- Über einen anwendungsspezifischen Code, der im Browser des Kunden ausgeführt wird, Timinginformationen erfasst und diese an einen Sammlungsdienst sendet.
Bei jeder dieser Optionen müssen Kompromisse zwischen folgenden Eigenschaften eingegangen werden:
- Treue: Gibt an, wie genau das Nutzererlebnis erfasst wird.
- Abdeckung: Gibt den Anteil der gemessenen Nutzerinteraktionen an.
- Kosten: Die Kosten (Zeit und Geld) für die Entwicklung und Wartung der Lösung.
Die Genauigkeit der Nutzerfreundlichkeit verbessert sich, wenn SLIs näher am Nutzer gemessen werden. Beispiel: Eine Implementierung, die Code im Browser des Nutzers verwendet, misst die Latenz genauer als sie vom Nutzer wahrgenommen oder mit anderen Messmethoden ermittelt wird.
Der Nachteil besteht darin, dass die browserbasierte Messung auch Latenzen enthält, die durch die Verbindung des Nutzers zu Ihrem Dienst entstehen. Wenn beispielsweise ein Dienst über das öffentliche Internet verwendet wird, kann diese Latenz aufgrund des geografischen Standorts oder aufgrund von Netzwerkbedingungen erheblich variieren.
Dies hat zur Folge, dass das browserbasierte Signal ein gutes Maß für die Nutzerzufriedenheit darstellt. Dieses Signal liefert jedoch möglicherweise keine umsetzbaren Informationen, mit denen Sie die Zuverlässigkeit Ihres Dienstes verbessern können.
Informationen zum Kombinieren mehrerer Messungen zum Ausgleichen dieses Nachteils finden Sie in diesem Beitrag von The Telegraph.
Bucketing
Möglicherweise benötigen Sie mehrere SLIs für einen Dienst, wenn Ihr Dienst verschiedene Aufgaben für unterschiedliche Nutzer ausführt oder eine Aufgabe mit verschiedenen möglichen Ergebnissen erledigt.
Verschiedene Aufgaben
Dienste, die mehrere Arten von Aufgaben für verschiedene Nutzerkategorien ausführen und bei denen jede Art von Aufgabe die Nutzerzufriedenheit beeinflusst, profitieren von mehreren SLIs.
Verarbeitet Ihr Dienst beispielsweise Lese- und Schreibanfragen, so können Nutzer, die diese Aufgaben ausführen, unterschiedliche Anforderungen haben:
- Leseanfragen müssen schnell verarbeitet werden.
- Schreibanfragen müssen erfolgreich sein.
Um diese unterschiedlichen Anforderungen zu erfassen, muss Ihr SLI zwischen den beiden Fällen unterscheiden können. Normalerweise hat der SLI-Messwert ein Label, mit dem Sie Werte zur Klassifizierung in einen von mehreren Buckets einordnen können.
Eine Aufgabe mit unterschiedlichen Ergebnissen
Dienste, die nur eine Art von Aufgabe ausführen, bei denen aber die Nutzererwartungen von der Antwort abhängig sind, profitieren von mehreren SLIs.
Bietet Ihr Dienst beispielsweise nur Lesezugriff auf Daten, so können Nutzer unterschiedliche Toleranzwerte akzeptieren, je nach dem Ergebnis der Anfrage:
- Nutzer sind möglicherweise tolerant für Fehler, die schnell zurückgegeben werden, da sie dann die Anfrage sofort wiederholen können.
- Nutzer sind möglicherweise weniger tolerant gegenüber Anfragen, die sehr lange dauern.
- Die Nutzer tolerieren den schlimmsten Fall am wenigsten: Anfragen, bei denen das Zurückgeben eines Fehlers lange dauert.
In diesem Fall muss der Latenz-SLI zwischen erfolgreichen und fehlgeschlagenen Anfragen unterscheiden können.
Nächste Schritte
Informationen zum Implementieren von SLIs für Google Cloud-Dienste mithilfe von Google Cloud-Messwerten finden Sie hier:
Informationen zur Implementierung von anwendungsspezifischen SLIs finden Sie hier:
Ein Beispiel für die Erstellung eines SLI für Dienste, die benutzerdefinierte Messwerte melden, finden Sie unter SLOs festlegen: Beobachtbarkeit mit benutzerdefinierten Messwerten.