SLOs messen

Dieses Dokument im Google Cloud Architecture Framework baut auf den vorangegangenen Diskussionen über Service Level Objectives (SLOs) auf, indem es das „Was“ und „Wie“ der Messung in Bezug auf gängige Dienstarbeitslasten untersucht. Dieses Dokument basiert auf den Konzepten, die unter Komponenten von Service Level Objectives definiert sind.

Festlegen, was erfasst werden soll

Unabhängig von Ihrer Domain haben viele Dienste die gleichen gängigen Features und können generische SLOs verwenden. In diesem Abschnitt werden allgemeine SLOs für verschiedene Arten von Diensten erörtert und die SLIs, die für jede SLO gelten, ausführlich erläutert.

In den folgenden Abschnitten wird jeweils ein bestimmter Diensttyp beschrieben und kurz erläutert. Anschließend sind unter jedem Diensttyp mögliche SLIs, eine Definition des Indikators und andere Informationen zum SLI aufgeführt.

Anfragengesteuerte Dienste

Dieser Diensttyp empfängt eine Anfrage von einem Client (einem Nutzer oder einem anderen Dienst), führt eine Berechnung durch, sendet möglicherweise Netzwerkanfragen an ein Back-End und gibt dann eine Antwort an den Client zurück.

Verfügbarkeit als SLI

Die Verfügbarkeit ist der Anteil der gültigen Anfragen, die erfolgreich verarbeitet werden. In der folgenden Liste finden Sie Informationen, die Sie bei der Verwendung der Verfügbarkeit als SLI beachten sollten:

• Als Dienstinhaber entscheiden Sie, was eine gültige Anfrage ist. Gängige Definitionen sind beispielsweise nicht null oder entspricht einem Client-Server-Protokoll. Eine gängige Methode zum Beurteilen der Gültigkeit ist die Überprüfung von HTTP- oder RPC-Antwortcodes. Beispielsweise sind HTTP-5xx-Codes serverbezogene Fehler, die auf ein SLO angerechnet werden, während 4xx-Codes Clientfehler sind, für die dies nicht gilt.
• Jeder vom Dienst zurückgegebene Antwortcode muss geprüft werden, um sicherzustellen, dass die Anwendung diese Codes richtig und konsistent verwendet. Ist der Code ein genauer Indikator für die Erfahrung der Nutzer mit dem Dienst? Wie reagiert beispielsweise eine E-Commerce-Website, wenn ein Nutzer versucht, einen Artikel zu bestellen, der nicht auf Lager ist? Schlagt die Anfrage fehl und wird eine Fehlermeldung zurückgegeben? Werden auf der Website ähnliche Produkte vorgeschlagen? Fehlercodes müssen an die Erwartungen der Nutzer gebunden sein.
• Entwickler können Fehler versehentlich missbrauchen. Anhand des Szenarios nicht auf Lager aus dem vorherigen Punkt könnte ein Entwickler versehentlich einen Fehler zurückgeben. Das System funktioniert jedoch ordnungsgemäß und ist nicht fehlerhaft. Es darf kein Fehlercode zurückgegeben werden, obwohl der Nutzer den Artikel nicht kaufen konnte. Die Dienstinhaber sollten über das geringe Inventar informiert werden, aber die Tatsache, dass kein Kauf möglich war, ist aus Kundensicht kein Fehler und sollte nicht auf ein SLO angerechnet werden.
• Ein Beispiel für einen komplexeren Dienst ist ein Dienst, der asynchrone Anfragen verarbeitet oder Kunden einen langwierigen Prozess bietet. Sie können die Verfügbarkeit auch anders darstellen. Wir empfehlen jedoch, die Verfügbarkeit als Anteil der gültigen Anfragen darzustellen, die erfolgreich sind. Die Verfügbarkeit kann auch als die Anzahl der Minuten definiert werden, für die die Arbeitslast eines Kunden ausgeführt wird (manchmal als gute Minuten bezeichnet).
• Angenommen, Sie bieten einen Dienst mit virtuellen Maschinen (VMs) an. Sie können die Verfügbarkeit als die Anzahl der Minuten nach einer ersten Anfrage messen, in der die VM für den Nutzer verfügbar ist.

Latenz als SLI

Die Latenz (oder Geschwindigkeit) ist der Anteil der gültigen Anfragen, die schneller verarbeitet werden, als dies ein festgelegter Schwellenwert vorsieht. Die Latenz gibt also Aufschluss über die Schnelligkeit des Dienstes. Sie kann gemessen werden, indem die Differenz zwischen dem Start- und dem Endzeitpunkt für einen bestimmten Anfragetyp berechnet wird. Denken Sie daran, dass dies die Wahrnehmung der Latenz durch den Nutzer ist. Dienstinhaber messen diesen Wert häufig zu genau. Tatsächlich können Nutzer keinen Unterschied feststellen, wenn eine Aktualisierung 100 Millisekunden (ms) oder 300 ms dauert, und akzeptieren möglicherweise sogar Antworten zwischen 300 ms und 1.000 ms als normal. Weitere Informationen finden Sie im Rail-Modell.

Entwickeln Sie aktivitätsbezogene Messwerte, die sich auf die Nutzer konzentrieren. Hier einige Beispiele für solche Messwerte:

• Interaktiv: Ein Nutzer wartet nach dem Klicken auf ein Element 1.000 ms auf ein Ergebnis.
• Schreiben: Eine Änderung an einem zugrunde liegenden verteilten System dauert 1.500 ms. Diese Zeitspanne gilt zwar als langsam, wird aber von Nutzern tendenziell akzeptiert. Wir empfehlen Ihnen, bei den Messwerten explizit zwischen Schreib- und Lesevorgängen zu unterscheiden.
• Hintergrund:Aktionen, die für den Nutzer nicht sichtbar sind, z. B. eine regelmäßige Aktualisierung von Daten oder andere asynchrone Anfragen, dauern maximal 5.000 ms.

Die Latenz wird häufig als Verteilung gemessen, wie unter SLIs auswählen erwähnt. Bei einer Verteilung können Sie verschiedene Perzentile messen. Sie können beispielsweise die Anzahl der Anfragen messen, die langsamer als das frühere 99. Perzentil sind. Ereignisse, die schneller als dieser Schwellenwert sind, werden als gut eingestuft; langsamere Anfragen werden als nicht so gut eingestuft. Sie legen diesen Schwellenwert anhand der Produktanforderungen fest. Sie können sogar SLOs mit mehreren Latenzen festlegen, z. B. die typische Latenz im Vergleich zur Extremwertlatenz.

Verwenden Sie nicht nur die durchschnittliche Latenz oder Medianlatenz als SLI. Wenn die Medianlatenz zu langsam ist, ist bereits die Hälfte Ihrer Nutzer unzufrieden. Außerdem kann es sein, dass Ihr Dienst tagelang eine hohe Latenz aufweist, bevor Sie das Problem bemerken. Definieren Sie daher Ihren SLO für die Extremwertlatenz (95. Perzentil) und für die Medianlatenz (50. Perzentil).

Im ACM-Artikel Metrics That Matter schreibt Benjamin Treynor Sloss Folgendes:

• „Eine gute praktische Faustregel ... ist: Die Latenz des 99. Perzentils sollte nicht mehr als das Drei- bis Fünffache der Medianlatenz betragen.“
• „Wir halten die Latenzmesswerte für das 50., 95. und 99. Perzentil eines Dienstes alle für wertvoll und legen daher idealerweise SLOs für jeden der Werte fest.“

Bestimmen Sie die Latenzschwellenwerte anhand der historischen Perzentile und messen Sie dann, wie viele Anfragen in jeden Bucket fallen. Dieser Ansatz ist ein gutes Vorbild.

Qualität als SLI

Qualität ist der Anteil der gültigen Anfragen, die ohne Beeinträchtigung des Dienstes verarbeitet wurden. Die Qualität ist beispielsweise ein hilfreicher SLI für komplexe Dienste, die so konzipiert sind, dass sie auf behutsame Weise fehlschlagen. Angenommen, eine Webseite lädt ihren Hauptinhalt aus einem Datenspeicher und optionale Assets aus 100 anderen Diensten und Datenspeichern. Wenn eines der optionalen Elemente außer Betrieb oder zu langsam ist, wird die Seite trotzdem ohne die optionalen Elemente gerendert. In diesem Szenario können Sie SLIs für Folgendes verwenden:

• Indem Sie die Anzahl der Anfragen messen, die eine eingeschränkte Antwort erhalten (d. h. eine Antwort, bei der die Antwort mindestens eines Back-End-Dienstes fehlt), können Sie sich die relative Anzahl der fehlerhaften Anfragen anzeigen lassen.
• Sie können die Anzahl der Antworten erfassen, bei denen eine Antwort von einem einzelnen Back-End oder von mehreren Back-Ends fehlt.

Datenverarbeitungsdienste

Diese Dienste nehmen Daten aus einer Eingabe auf, verarbeiten diese Daten und generieren eine Ausgabe. Die Leistung der Dienste bei Zwischenschritten ist nicht so wichtig wie das Endergebnis. Die aussagekräftigsten SLIs sind Aktualität, Abdeckung, Richtigkeit und Durchsatz. Latenz und Verfügbarkeit sind weniger nützlich.

Aktualität als SLI

Die Aktualität ist der Anteil der gültigen Daten, die vor der im Schwellenwert festgelegten Zeit aktualisiert wurden. Die folgende Liste enthält einige Beispiele für die Verwendung der Aktualität als SLI:

• In einem Batchsystem wird die Aktualität als die Zeit gemessen, die seit dem erfolgreichen Abschluss eines Verarbeitungslaufs für eine bestimmte Ausgabe verstrichen ist.
• Bei der Echtzeitverarbeitung oder in komplexeren Systemen wird die Aktualität anhand des Alters des zuletzt in einer Pipeline verarbeiteten Datensatzes gemessen.
• In einem Onlinespiel, bei dem Kartenkacheln in Echtzeit generiert werden, bemerken Nutzer möglicherweise nicht, wie schnell Kartenkacheln erstellt werden, aber sie bemerken vielleicht, wenn Kartendaten fehlen oder nicht aktuell sind. In diesem Fall wird mit der Aktualität der Daten nach fehlenden oder veralteten Daten gesucht.
• Bei einem Dienst, der Datensätze aus einem Tracking-System ausliest, um die Meldung „X Artikel auf Lager“ für eine E-Commerce-Website zu generieren, könnte ein Aktualitäts-SLI als der Prozentsatz der Anfragen definiert werden, die kürzlich (innerhalb der letzten Minute) aktualisierte Bestandsinformationen verwenden.
• Sie können auch einen Messwert für die Bereitstellung nicht aktueller Daten verwenden, um den SLI für Qualität zu informieren.

Abdeckung als SLI

Die Abdeckung ist der Anteil der gültigen Daten, die erfolgreich verarbeitet wurden.

So legen Sie die Abdeckung fest:

1. Legen Sie fest, ob eine Eingabe als gültig akzeptiert oder übersprungen werden soll. Wenn ein Eingabedatensatz beispielsweise beschädigt ist oder die Länge null hat und nicht verarbeitet werden kann, können Sie diesen Datensatz als ungültig einstufen.
2. Zählen Sie die Anzahl der gültigen Datensätze. Diese Anzahl lässt sich mit einer einfachen *count()*-Methode ermitteln und entspricht der Gesamtzahl der Datensätze.
3. Zählen Sie abschließend die Anzahl der Datensätze, die erfolgreich verarbeitet wurden, und vergleichen Sie diese Anzahl mit der Gesamtzahl der gültigen Datensätze. Dieser Wert ist Ihr SLI für die Abdeckung.

Richtigkeit als SLI

Die Richtigkeit ist der Anteil der gültigen Daten, die eine korrekte Ausgabe erzeugt haben. Beachten Sie die folgenden Punkte, wenn Sie „Richtigkeit“ als SLI verwenden:

• In manchen Fällen werden die Methoden zum Bestimmen der Richtigkeit einer Ausgabe verwendet, um die Verarbeitung der Ausgabe zu validieren. Beispielsweise sollte ein System, das ein Bild rotiert oder einfärbt, niemals ein Null-Byte-Bild oder ein Bild mit einer Länge oder Breite von null erzeugen. Es ist wichtig, diese Validierungslogik von der Verarbeitungslogik selbst zu trennen.
• Eine Methode zum Messen eines Richtigkeits-SLI ist die Verwendung als funktionierend bekannte Testeingabedaten. Diese Art von Daten sind Daten, die eine bekannte korrekte Ausgabe erzeugen. Denken Sie daran, dass die Eingabedaten für Nutzerdaten repräsentativ sein müssen.
• In anderen Fällen kann es sein, dass eine mathematische oder logische Prüfung der Ausgabe durchgeführt wird, wie im vorherigen Beispiel, bei dem ein Bild gedreht wurde.
• Ein weiteres Beispiel wäre ein Abrechnungssystem, das die Gültigkeit einer Transaktion anhand der Differenz zwischen dem Kontostand vor und nach der Transaktion feststellt. Wenn dieser Wert mit dem Wert der Transaktion selbst übereinstimmt, ist es eine gültige Transaktion.

Durchsatz als SLI

Der Durchsatz ist der Anteil der Zeit, in der die Datenverarbeitungsrate über dem Schwellenwert lag. Beachten Sie bei der Verwendung des Durchsatzes als SLI Folgendes:

• In einem Datenverarbeitungssystem ist häufig der Durchsatz repräsentativer für die Zufriedenheit der Nutzer als eine einzelne Latenzmessung für einen bestimmten Vorgang. Wenn die Größe jeder Eingabe stark variiert, ist es möglicherweise nicht sinnvoll, zu vergleichen, wie lange jedes einzelne Element bearbeitet wird, wenn alle Jobs mit einer akzeptablen Geschwindigkeit ausgeführt werden.
• Byte pro Sekunde ist eine gängige Methode, um den Arbeitsaufwand für das Verarbeiten von Daten unabhängig von der Größe des Datasets zu messen. Aber jeder Messwert, der in Bezug auf die Verarbeitungskosten ungefähr linear skaliert wird, ist geeignet.
• Es kann sich lohnen, Datenverarbeitungssysteme anhand der erwarteten Durchsatzraten zu partitionieren. Sie können auch ein Dienstqualitätssystem implementieren, das dafür sorgt, dass Eingaben mit hoher Priorität verarbeitet und Eingaben mit niedriger Priorität in die Warteschlange gestellt werden. In jedem Fall können Sie durch das Messen des Durchsatzes auf die in diesem Abschnitt beschriebene Weise feststellen, ob Ihr System wie erwartet funktioniert.

Dienste mit geplanter Ausführung

Für Dienste, die in regelmäßigen Abständen eine Aktion ausführen müssen, z. B. Kubernetes-Cronjobs, können Sie die Verzerrung und die Ausführungsdauer messen. Im Folgenden finden Sie ein Beispiel für einen geplanten Kubernetes-Cronjob:

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"
  

Verzerrung als SLI

Abweichung: Der Anteil der Ausführungen, die innerhalb eines akzeptablen Zeitfensters vor oder nach der erwarteten Startzeit beginnen Beachten Sie bei der Verwendung von Verzerrung Folgendes:

• Die Verzerrung misst die Zeitdifferenz zwischen dem planmäßigen Start eines Jobs und dem tatsächlichen Start. Denken Sie an das vorherige Beispiel für einen Kubernetes-Cronjob. Wenn er so eingestellt ist, dass er bei Minute Null jeder Stunde beginnt, aber um drei Minuten nach der vollen Stunde startet, beträgt die Abweichung drei Minuten. Wenn ein Job zu früh ausgeführt wird, kommt es zu einer negativen Verzerrung.
• Sie können messen, wie sich die Verzerrung im Laufe der Zeit entwickelt, indem sie entsprechende akzeptable Bereiche festlegen, die eine gute Verzerrung definieren. Zum Ermitteln des SLI vergleichen Sie die Anzahl der Ausführungen, die innerhalb eines guten Bereichs lagen.

Ausführungsdauer als SLI

Ausführungsdauer: Der Anteil der Ausführungen, die innerhalb des zulässigen Dauerfensters abgeschlossen werden. Im Folgenden werden wichtige Konzepte im Zusammenhang mit der Verwendung der Ausführungsdauer beschrieben:

• Ausführungsdauer ist die Zeit, die zum Fertigstellen eines Jobs benötigt wird. Bei einer Ausführung kommt es häufig zu dem Fehler, dass die tatsächliche Dauer die geplante Dauer überschreitet.
• Ein interessanter Fall ist die Anwendung dieses SLI auf eine nie endende Aufgabe. Da diese Jobs nicht abgeschlossen werden, müssen Sie die für einen bestimmten Job aufgewendete Zeit erfassen, anstatt auf den Abschluss eines Jobs zu warten. Dieser Ansatz bietet eine genaue Verteilung dafür, wie lange es dauert, bis die Arbeit fertiggestellt wurde, selbst in Worst-Case-Szenarien.
• Wie bei der Verzerrung können Sie die Verteilung der Ausführungsdauer verfolgen und akzeptable Ober- und Untergrenzen für gute Ereignisse definieren.

Messwerte für andere Systemtypen

Viele andere Arbeitslasten haben eigene Messwerte, mit denen Sie SLIs und SLOs generieren können. Betrachten Sie hierzu folgende Beispiele:

• Speichersysteme: Langlebigkeit, Durchsatz, Zeit bis zum ersten Byte, Blob-Verfügbarkeit.
• Medien/Video: Client-Wiedergabekontinuität, Startzeit für die Wiedergabe, Vollständigkeit von Transcode-Diagrammausführungen.
• Gaming: Zeit zum Zuordnen aktiver Spieler und Zeit für die Erstellung einer Karte.

Messmethode festlegen

Im vorherigen Abschnitt ging es darum, was Sie messen. Nachdem Sie entschieden haben, was gemessen werden soll, können Sie entscheiden, wie gemessen werden soll. Es gibt mehrere Möglichkeiten, SLI-Messwerte zu erfassen. In den folgenden Abschnitten werden verschiedene Analysemethoden beschrieben. Außerdem werden die Vor- und Nachteile der jeweiligen Methode aufgeführt und geeignete Implementierungstools für die Methode genannt.

Serverseitiges Logging

Bei der serverseitigen Protokollierung werden serverseitige Protokolle von Anfragen oder verarbeiteten Daten verarbeitet.

Anwendungsserver-Messwerte

Die Methode Anwendungsserver-Messwerte umfasst das Exportieren von SLI-Messwerten aus dem Code, der Nutzeranfragen oder deren Daten verarbeitet.

Frontend-Infrastrukturmesswerte

Bei der Methode Messwerte zur Frontend-Infrastruktur werden Messwerte aus der Load Balancing-Infrastruktur verwendet, z. B. ein globaler Layer 7-Load Balancer in Google Cloud.

Synthetische Clients oder Daten

Bei der Methode mit synthetischen Clients oder Daten werden Clients verwendet, die in regelmäßigen Abständen vorgefertigte Anfragen senden und die Antworten validieren.

Client-Instrumentierung

Bei der Clientinstrumentierung werden dem Client, mit dem der Nutzer interagiert, Sichtbarkeits-Features hinzugefügt und Ereignisse in der Bereitstellungsinfrastruktur protokolliert, die SLIs erfasst.

Messmethode auswählen

Nachdem Sie entschieden haben, was und wie Ihr SLO gemessen werden soll, besteht der nächste Schritt darin, eine Messmethode zu wählen, die der Erfahrung Ihrer Kunden mit Ihrem Dienst am ehesten entspricht und Ihnen den geringsten Aufwand abverlangt. Um dieses Ideal zu erreichen, müssen Sie möglicherweise die Methoden in den vorherigen Tabellen kombinieren. Im Folgenden finden Sie Vorschläge, deren einzelne Schritte Sie im Laufe der Zeit implementieren können. Die Schritte sind in der Reihenfolge des zunehmenden Aufwands aufgeführt:

• Exporte von Anwendungsservern und Infrastrukturmesswerte verwenden. In der Regel können Sie sofort auf diese Messwerte zugreifen und sie bieten schnell einen Mehrwert. Einige APM-Tools enthalten eingebundene SLO-Tools.
• Clientinstrumentierung verwenden. Da in Legacy-Systeme normalerweise keine Clientinstrumentierung für Endnutzer eingebunden ist, kann das Einrichten der Instrumentierung eine erhebliche Investition erfordern. Wenn Sie jedoch eine APM-Suite oder ein Frontend-Framework verwenden, das eine Clientinstrumentierung bietet, können Sie schnell einen Einblick in die Zufriedenheit Ihrer Kunden gewinnen.
• Logverarbeitung verwenden. Wenn Sie keine Serverexporte oder Clientinstrumentierung implementieren können (siehe vorherige Aufzählung), aber Logs vorhanden sind, kann die Logverarbeitung der beste Ansatz sein. Eine weitere Methode besteht darin, Exporte und die Logverarbeitung zu kombinieren. Verwenden Sie Exporte als sofortige Quelle für einige SLIs (z. B. sofortige Verfügbarkeit) und die Logverarbeitung für langfristige Signale (z. B. Slow-Burn-Benachrichtigungen, die unter SLOs und Benachrichtigung erläutert werden).
• Synthetische Tests implementieren. Nachdem Sie sich ein grundlegendes Verständnis davon verschafft haben, wie die Kunden Ihren Dienst nutzen, testen Sie ihn. Sie können beispielsweise fehlerfreie Daten in Testkonten übertragen und sie abfragen. Dieser Ansatz kann helfen, Fehlermodi herauszustellen, die nicht leicht zu beobachten sind, z. B. bei Diensten mit geringem Traffic.

Nächste Schritte

• SLOs und Benachrichtigungen lesen.
• The Art of SLOs des Google-Teams für Customer Reliability Engineering lesen.
• Onlinekurs Site Reliability Engineering: Measuring and Managing Reliability zum Erstellen von SLOs absolvieren.
• Site Reliability Engineering: Implementing SLOs lesen.
• Konzepte beim Dienstmonitoring lesen.
• Implementing Service Level Objectives von Alex Hidalgo lesen.
• Developing SLOs with Cloud Monitoring lesen.
• Flexiblen SLO Generator der Professional Services Organization (PSO) von Google testen
• Ressourcen zu DevOps.

• Mehr über die DevOps-Funktionen aus dieser Reihe erfahren:

  • Monitoring und Beobachtbarkeit
  • Monitoringsysteme für fundierte Geschäftsentscheidungen
  • Proaktive Fehlerbenachrichtigung

• Über den DevOps Quick Check erfahren, wo Sie im Vergleich zum Rest der Branche stehen.

• Empfehlungen in anderen Säulen des Architektur-Frameworks entdecken

• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.