Latenz, Traffic, Fehler, Sättigung

Vier Zahlen decken den Großteil des Betriebs ab

Aus dem Google SRE Buch. Vier Signale, die du auf jeder Service-Ebene misst. Wenn du diese vier gut instrumentierst, fängst du die meisten Produktionsprobleme, bevor es die Nutzer tun.

Latenz: Wie lange dauert eine Anfrage? Berichte Verteilungen, nicht nur Durchschnittswerte. Die p99 (99. Perzentil-Latenz) ist wichtiger als der Mittelwert, da die Tail-Latenz (Schwanzlatenz) das ist, was Nutzer als „langsam“ wahrnehmen. Ein Dienst mit 50 ms Mittelwert und 5.000 ms p99 hat ein reales Problem, das die meisten Nutzer nie bemerken, aber die am stärksten betroffenen 1 % absolut spüren.

Traffic: Wie viele Anfragen pro Sekunde? Gesamtanfragen, pro Endpunkt, pro Statuscode, pro Region. Baseline bekannt; Alarme bei Anomalien (plötzlicher Abfall = Ingress-Problem; plötzlicher Anstieg = Lastspitze oder Angriff).

Fehler: Rate fehlgeschlagener Anfragen. Unterscheide 4xx (Client-Fehler, nicht deine Schuld) von 5xx (Server-Fehler, deine Schuld). Verfolge die Fehlerrate als Prozentsatz des Traffics, nicht als absolute Zählung, damit Alarme auf allen Lastniveaus funktionieren.

Sättigung: Wie ausgelastet ist das System? CPU-Auslastung, Speicher, Tiefe des Verbindungspools, Warteschlangenlänge. Der führende Indikator. Sättigung steigt, bevor Latenz oder Fehler sich verschlechtern. Eine Ebene bei 90 % Sättigung ist nur eine schlechte Minute vom Zusammenbruch der Warteschlange entfernt.

An einer Proxy-Ebene speziell

Jedes Signal leuchtet an der Edge-Ebene auf:

- Latenz am Proxy: Dauer des TLS-Handshakes, Upstream-Verbindungszeit, Gesamtzeit von Anfrage bis Antwort. Getrennt gemessen, da sie an verschiedenen Teilen des Pfades liegen.

- Traffic am Proxy: Gesamtanfragen/Sekunde, Verteilung pro Backend (ein heißes Backend signalisiert Lastbalancer-Schieflage), Aufschlüsselung nach Statuscode.

- Fehler auf Proxy-Ebene: 4xx von Clients (Ihre Nutzer treffen auf ungültige Endpunkte), 5xx von Backends (Ihre Dienste schlagen fehl), interne Proxy-Fehler (502 = Backend nicht erreichbar, 504 = Backend-Timeout).

- Auslastung auf Proxy-Ebene: Anzahl der TLS-Sitzungen, Tiefe des Upstream-Verbindungspools, CPU-Auslastung des Proxys selbst (TLS-Terminierung ist CPU-lastig).

Profi-Tipp: Ein plötzlicher Anstieg von 502-Fehlern bei niedriger Backend-Latenz bedeutet, dass das Backend die Verbindung vor der Antwort trennt (Connection Reset, Crash, OOM). Ein Anstieg von 504-Fehlern bedeutet, dass das Backend langsam ist, aber noch antwortet. Lesen Sie den Fehlercode; er zeigt Ihnen, wo der Fehler liegt.

Die Signale lesen

Ihr Dashboard zeigt Folgendes für die letzten 10 Minuten:

- Traffic: nahezu konstant bei 800 req/s (kein Anstieg)

- Latenz: p50 stabil bei 40 ms, p99 stieg in 5 Minuten von 200 ms auf 2.500 ms an & steigt weiterhin

- Fehler: 4xx-Quote stabil bei 0,3 % (normales Hintergrundniveau); 5xx-Quote stieg von 0,1 % auf 1,2 % (überwiegend 504 Gateway Timeout)

- Auslastung: Die CPU-Auslastung der Backends stieg im selben Zeitraum von 5 Minuten von 45 % auf 78 %; die CPU-Auslastung des Proxys blieb stabil bei 30 %

Wann skalieren, wann abladen, wann eskalieren

Kapazitätsentscheidungen benötigen Auslöser

Metriken zu beobachten ist einfach. Zu wissen, wann man daraufhin handeln muss, ist die eigentliche Disziplin.

Skalieren Sie hoch, wenn: die Sättigung eine anhaltende Schwelle überschreitet (z. B. Backend-CPU >70 % für 5 Minuten), oder die Warteschlangenlänge ein Zielwert überschreitet, oder die p99-Latenz den SLO überschreitet. Der Auslöser sollte auslösen, bevor etwas bricht, nicht erst im Moment des Bruchs.

Entlasten Sie eine Replik, wenn: sie konsistent langsam ist oder Fehler produziert, während die Peers gesund sind (eine einzelne Replik, die „heiß“ läuft, ist oft ein hostbezogenes Problem und kein Anwendungsproblem), oder wenn eine neue Version ausgerollt wird, oder wenn eine Replik ordnungsgemäß in den Ruhestand versetzt wird.

Eskalieren Sie an einen Menschen, wenn: ein SLO schneller verbrannt wird, als es das Fehlerbudget tragen kann, oder ein Sättigungsauslöser auslöst, ohne dass das Autoscaling ihn auffängt, oder ein Kaskadenn muster auftritt (Fehlerrate und Wiederholungsrate steigen gleichzeitig).

Eskalieren Sie nicht, wenn: eine einzelne schlechte Minute von selbst abklingt, oder Hintergrund-Batch-Jobs erwartete periodische Schwankungen verursachen, oder Rauschen die Schwelle überschreitet (die Schwelle ist falsch, nicht das System).

SLOs & Fehlerbudget-Verbrauch

Ein SLO (Service Level Objective) definiert die akzeptable Leistung: „Erfolgsquote >= 99,9 % über ein 28-Tage-Fenster“. Das Komplement (0,1 %) ist das Fehlerbudget.

Burn-Rate: Wie schnell das Fehlerbudget aufgebraucht wird. Wenn 10 % des Budgets in 1 Stunde aufgebraucht werden, liegt die Rate 240x schneller als das nachhaltige Niveau (1 Stunde ist 1/672 eines 28-Tage-Fensters; 10 % in diesem Fenster aufzubrauchen = 10 % × 672 = 6720 % projiziert für das gesamte Fenster, obwohl nur 100 % erlaubt sind).

Mehrfenster-Burn-Rate-Alerts: Alarmierung, wenn sowohl ein kurzes Fenster (5 Minuten bei 14,4x-Rate) als auch ein langes Fenster (1 Stunde bei 6x-Rate) schneller aufgebraucht werden als das nachhaltige Niveau. Erfasst sowohl schnelle Ausfälle als auch langsame Leistungseinbußen.

Warum dies für die Kapazität wichtig ist: Ein Dienst, der ein SLO von 99,9 % mit 1 % Puffer erreicht, kann kleine Störungen absorbieren. Ein Dienst bei 99,93 % (knapp unter dem SLO) ist nur einen schlechten Tag von einer Verletzung entfernt. Kapazitätsentscheidungen sollten auf einen komfortablen SLO-Puffer abzielen, nicht auf das Minimum, das es erfüllt.

Eine Kapazitätsentscheidung unter Beobachtung

Ihr Dienst hat ein SLO von 99,9 % erfolgreicher Anfragen über 28 Tage. Aktueller Zustand aus der Überwachung der letzten Stunde:

- Erfolgsquote: 99,5 % (seit 30 Minuten anhaltend)

- Backend-CPU: durchschnittlich 82 % im gesamten Cluster (Ziel: 70 %)

- p99-Latenz: 800 ms (SLO-Ziel: <500 ms)

- Traffic: 1.400 req/s, gestiegen von der Baseline von 1.000 req/s (40 % über dem Normalwert; der Trend steigt weiterhin)

- Autoscaling: konfiguriert, Replikate hinzuzufügen, wenn die CPU-Auslastung > 80 % für 5 Minuten anhaltend ist; derzeit läuft ein Scale-up-Prozess, der in ca. 90 Sekunden 3 Replikate hinzufügen wird

Entwirf einen Observability-Plan für den Launch

Synthese

Du kannst nun ein /health entwerfen, das echte Fehler erkennt, ein /version, mit dem du Deploys verifizieren kannst, Dashboards mit den vier Goldenen Signalen auf Proxy-Ebene & Kapazitätstrigger, die an die SLO-Burn-Rate gekoppelt sind.

Wende alle vier an.

Dein Team startet search.example.com (den Suchdienst aus der Lektion zu Fehlermodi). Das Team möchte Observability bereitstellen, die Probleme erkennt, bevor es die Nutzer tun, mit einer klaren Entscheidungs-Matrix für „Eskalation oder nicht“. SLO: 99,9 % erfolgreiche Anfragen, p99-Latenz < 300 ms, über ein 28-Tage-Fenster.

Abschluss des Kurses

Abschluss des Kurses

Du hast alle fünf Lektionen abgeschlossen:

- Proxys & Origins: die Edge-Ebenen-Struktur, die fast jeder öffentliche Webdienst verwendet

- Stateless horizontale Skalierung: warum eine stateless Ebene sich kostengünstig vervielfachen lässt & wie man sie dimensioniert

- Trennung von Ingress & Egress: warum aus einem Rechner zwei werden & der Fehlermodus, der dies erzwingt

- Fehlermodi & Schadensausmaß: SPOFs, Kaskadeneffekte, Postmortems, schuldfreie Maßnahmen

- Beobachtbarkeit & Kapazität (dieses Thema): was zu messen ist, damit Probleme aufkommen, bevor es die Nutzer merken

Der rote Faden: Ein verteiltes System im Web-Maßstab ist keine Magie. Es ist ein kleiner Satz an Mustern (Reverse Proxy, stateless Replikate, Ingress/Egress-Trennung, Bulkheads & Circuit Breaker, die vier Golden Signals), die durchdacht kombiniert werden. Sobald man die Muster erkennt, sieht man sie in jeder Produktionsarchitektur.

Begleitende Lektionen: Fünf Lektionen zur Geometrie von * recast das gleiche Material als Graphentheorie & Geometrie. Sie passen in beiden Reihenfolgen gut.

Gut gemacht.