Willkommen
Willkommen
Eine web-skalierte Flotte enthält viele Maschinen. In jedem Moment sind einige gesund, einige starten gerade, einige werden geleert, einige funktionieren still und leise kaputt. Die Flotte überlebt das, weil jede Maschine auf Nachfrage zwei einfache Fragen beantwortet:
- /health — bin ich momentan in der Lage, echte Anfragen zu bearbeiten?
- /version — was für Code laufe ich?
Zusätzlich gibt es einen Metrik-Endpunkt (üblicherweise /metrics), der Zähler und Schieber für Überwachungstools freizuschrauben ist.
Diese Lektion lehrt, wie diese Endpunkte so entworfen werden sollen, dass sie die Realität wirklich widerspiegeln, was die vier goldenen Signale auf Proxy-Ebene bedeuten und wie beobachtete Daten Kapazitätsentscheidungen treiben.
Am Ende werden Sie:
- einen /health-Endpunkt entwerfen, der echte Wegfehler erkennt, nicht nur Prozess-Lebendigkeit
- einen /version-Endpunkt entwerfen, der Ihnen ermöglicht, eine Bereitstellung zu verifizieren
- die vier goldenen Signale (Latenz, Traffic, Fehler, Überlastung) auf Proxy-Ebene anwenden
- beobachtete Überlastungsdaten auf Kapazitätsentscheidungen zurückverweisen: wann skalieren, wann leeren, wann alarmieren
- über SLAs und die Abnutzung des Fehlerbudgets als den operativen Diskiplin hinter 'wie wichtig nehmen wir das?' nachdenken
Die zwei Arten von Health-Check
Lebendigkeit vs. Bereitstellungsbereitschaft
Lebendigkeit: Ist der Prozess überhaupt am Leben? Wird von Orchestratoren (Kubernetes, systemd) verwendet, um zu entscheiden, ob der Prozess neu gestartet wird.
Bereitstellungsbereitschaft: Ist der Prozess in der Lage, im Moment echte Anfragen zu bearbeiten? Wird von Loadbalancern verwendet, um zu entscheiden, ob Anfragen gesendet werden.
Das sind verschiedene Fragen. Ein Prozess, der am Leben ist, aber seine Datenbank nicht erreichen kann, ist am Leben, aber nicht bereit. Ein Prozess, der gerade startet, ist am Leben, aber noch nicht bereit.
Oberflächliche vs. Tiefen-Health-Checks
Oberflächlich: gibt {"status": "ok"} zurück, wenn der HTTP-Handler ausgeführt wird. Einfach. Erkennen von Prozess-Down nur.
Tief: tatsächlich übt die echte Anfrageverbindung aus. Prüft, ob die Datenbankverbindungs pool eine Verbindung zurückgeben kann, ob der Cache erreichbar ist und ob die downstream-Abhängigkeiten antworten. Erkennen von funktionalen Ausfällen, die flache Überprüfungen verpassen.
Der Kompromiss: Tiefere Überprüfungen kosten mehr (jede ist im Grunde eine synthetische Anfrage) & können kaskadierende Fehler verursachen (wenn jeder Replikas Gesundheitsüberprüfung den Datenbank hammer, ein langsamer Datenbank macht alle Replikas ungesund, was sie aus der Rotation entfernt, was alle Kapazitäten entfernt).
Best Practice: Eine flache Überprüfung für Lebendigkeit (schnell, günstig, ohne externe Abhängigkeiten) & eine tiefergehende Überprüfung für Bereitstellungsfähigkeit (gekachelte Ergebnisse, gedrosselt, um Downstream-Systeme nicht zu überlasten).
Version Endpunkte
/version gibt den Git-Commit, die Aufbaudauer und den Dienstnamen aus. Nach einer Bereitstellung geben Sie curl https://service.example.com/version ein und bestätigen, dass der zurückgegebene Commit mit dem entspricht, den Sie gepusht haben. Wenn es nicht stimmt, hat die Bereitstellung stillschweigend fehlgeschlagen.
Ohne /version kann ein veraltetes Deploy erfolgreich aussehen und für Stunden versteckt bleiben.
Minimaler Antwortformat: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latenz, Verkehr, Fehler, Überlastung
Vier Zahlen decken die meisten Betriebsprobleme ab
Von der Google SRE-Buch. Vier Signale, die Sie auf jeder Dienstebene messen. Wenn Sie diese vier gut instrumentieren, stellen Sie die meisten Produktionsprobleme vor den Benutzern fest.
Latenz: wie lange dauert eine Anfrage? Verwalten von Verteilungen, nicht nur durchschnittliche Werte. Die p99 (99. Perzentil-Latenz) ist wichtiger als der Durchschnitt, weil Schwanzlatenz die Benutzer als 'langsam' empfinden. Ein Service mit 50 ms Durchschnitt und 5000 ms p99 hat ein echtes Problem, das die meisten Benutzer nie bemerken, aber die schlimm betroffenen 1% absolut tun.
Verkehr: wie viele Anfragen pro Sekunde? Gesamtanfragen, pro-Endpunkt, pro-Status-Code, pro-Region. Basiswerte kennen; auf Anomalien hinweisen (plotzlicher Rückgang = Eingangssproblem; plotzlicher Anstieg = Stoß oder Angriff).
Fehler: Haufigkeit fehlgeschlagener Anfragen. Unterscheide 4xx (Klientenfehler, nicht deine Schuld) von 5xx (Serverfehler, deine Schuld). Verfolge die Fehlerhaufigkeit als Prozentsatz des Verkehrs, nicht als absolute Anzahl, damit die Warnungen auf verschiedenen Lastebenen funktionieren.
Nutzungssaturation: Wie voll ist das System? CPU-Auslastung, Speicher, Anzahl der Verbindungen in der Pooltiefe, Warteschlangenlänge. Der vorherrschende Indikator. Die Nutzungsrate steigt vor der Latenz- oder Fehlerdegradation. Ein Ebenen bei 90% Nutzungsrate ist nur eine Minute von der Kollaps der Warteschlange entfernt.
Speziell für eine Proxy-Ebene
Jedes Signal leuchtet in der Kantenlage auf:
- Latenz am Proxy: Dauer des TLS-Handshakes, Zeit für die Verbindung zum upstream, Gesamtzeit für Anforderung-Antwort-Zyklus. Getrennt gemessen, weil sie sich in verschiedenen Teilen des Pfades befinden.
- Datenverkehr am Proxy: Gesamtanforderungen pro Sekunde, Verteilung pro Backend (ein heißes Backend signalisiert eine Verzerrung der Lastverteilung), pro-Status-Code-Zusammenfassung.
- Fehler am Proxy: 4xx von den Clients (Ihre Benutzer klicken auf falsche Endpunkte), 5xx von den Backends (Ihre Dienste schlagen fehl), Proxy-intern Fehler (502 = Backend nicht erreichbar, 504 = Backend Timeout).
- Saturation am Proxy: Anzahl der TLS-Sessions, Pooltiefe für upstream-Verbindungen, CPU am Proxy selbst (TLS-Terminierung ist CPU-intensiv).
Pro-Tipp: Ein plötzlicher Anstieg von 502 mit niedriger Backend-Latenz bedeutet, dass das Backend vor der Antwort abbricht (Verbindung beendet, Crash, OOM). Ein Anstieg von 504 bedeutet, dass das Backend langsam, aber immer noch antwortet. Lesen Sie die Fehlercode; er sagt Ihnen, wo das Scheitern stattfindet.
Die Signale lesen
Ihr Dashboard zeigt folgendes über die letzten 10 Minuten an:
- Datenverkehr: ungefähr flach bei 800 Anforderungen pro Sekunde (keine Welle)
- Latenz: p50 ist stabil bei 40 ms, p99 stieg von 200 ms auf 2.500 ms über 5 Minuten und steigt immer noch an
- Fehler: 4xx-Rate ist stabil bei 0,3% (normale Hintergrundaktivität); 5xx-Rate stieg von 0,1% auf 1,2% (hauptsächlich 504 Gateway Timeout) an
- Saturation: CPU des Backends stieg von 45% auf 78% über die gleichen 5 Minuten; Proxy-CPU ist stabil bei 30%
Wann skalieren, wann leeren und wann benachrichtigen
Kapazitätsentscheidungen brauchen Auslöser
Das Beobachten von Metriken ist einfach. Wissen zu wissen, wann man darauf handeln sollte, ist die Disziplin.
Skalieren Sie, wenn: die Saturation einen nachhaltigen Schwellenwert überschreitet (z. B. Backend-CPU >70% für 5 Minuten), oder die Warteschlangentiefe über einen Zielwert hinauswächst, oder die Latenz p99 den SLO-Wert überschreitet. Die Ausschüttung sollte auslösen, bevor die Dinge kaputtgehen, nicht beim Kaputtmachen.
Entleeren Sie eine Kopie, wenn: sie dauerhaft langsam / fehleranfällig ist, während die Mitspieler gesund sind (eine laufende Kopie ist oft ein Host-Problem und nicht ein Anwendungsproblem), oder wenn ein neues Version ausgerollt wird, oder wenn eine Kopie sanft aus dem Dienst genommen wird.
Benachrichtigen Sie einen Menschen, wenn: der SLO schneller verbraucht wird als der Fehlerbudget dies aufrechterhalten kann, oder ein Saturationstauschöler ohne Auto-Scaling abgebaut wird, oder ein Sturzflutmuster auftritt (Fehlerrate + Wiederholungsrate steigen beide).
Benachrichtigen Sie keinen Menschen, wenn: eine Minute allein schlecht, aber sich danach bessert, oder Hintergrund-Batch-Jobs erwartungsgemäß periodische Sprünge verursachen, oder Rauschen den Schwellenwert überschreitet (der Schwellenwert ist falsch, nicht das System).
SLOs & Fehlerbudget Verbrauch
Ein SLO (Dienst-Niveau-Ziel) definiert akzeptable Leistung: 'Erfolgsrate >= 99,9% über einen 28-tägigen Zeitraum'. Das Komplement (0,1%) ist das Fehlerbudget.
Verbrennungsrate: wie schnell Sie das Fehlerbudget verbrauchen. Wenn Sie in einer Stunde 10% des Budgets verbrauchen, beträgt die Rate 240-fach schneller als nachhaltig (1 Stunde ist 1/672 einer 28-tägigen Zeitraum; Verbrennen von 10% in diesem Zeitraum = 10% × 672 = 6720% für den gesamten Zeitraum projiziert, wenn nur 100% erlaubt ist).
Mehrfach-Fenster-Verbrennungsrate-Anzeigen: benachrichtigen Sie, wenn sowohl ein kurzes Fenster (5 Minuten bei 14,4-facher Rate) als auch ein langes Fenster (1 Stunde bei 6-facher Rate) schneller verbraucht werden als nachhaltig. Fängt sowohl schnelle Ausfälle als auch langsame Abbauprozesse.
Warum ist dies für Kapazitäten wichtig: Ein Dienst, der bei 99,9% SLO läuft, mit 1% Puffer kann kleinere Störungen absorbieren. Ein Dienst bei 99,93% (gerade so, dass der SLO eingehalten wird) ist ein schlechtes Tag vom Verstoß entfernt. Kapazitätsentscheidungen sollten ein komfortables SLO-Marge anstreben, nicht den Mindestwert, der es erfüllt.
Eine Kapazitätsentscheidung unter Beobachtung
Ihr Dienst hat ein SLO von 99,9% erfolgreichen Anfragen über 28 Tage. Aktueller Zustand aus der Überwachung der letzten Stunde:
- Erfolgsrate: 99,5% (nachhaltig für 30 Minuten)
- Backend-CPU: durchschnittlich 82% über das gesamte Fleet (Ziel 70%)
- p99 Latenz: 800 ms (SLO-Ziel: <500 ms)
- Traffic: 1.400 Anfragen/s, von der Basislage 1.000 Anfragen/s (40% über Normal; Trend steigt weiter an)
- Autoscaling: konfiguriert, um Replicas hinzuzufügen, wenn die CPU mehr als 80% für 5 Minuten andauert; derzeit im Mittelpunkt einer Skalierung, die in ~90 Sekunden 3 Replicas hinzufügen wird
Entwerfen eines Launch Observability Plans
Synthesis
Sie können jetzt einen /health entwerfen, der echte Fehler einfängt, einen /version, der Ihnen die Verifizierung von Bereitstellungen ermöglicht, vier-goldene-Signal-Dashboards auf einer Proxy-Ebene und Kapazitätsauslöser, die an der SLO-Verbrennungsrate gekoppelt sind.
Wenden Sie alle vier Anforderungen an.
Ihr Team startet search.example.com (das Suchdienst von dem Unterricht über Fehlermodi). Das Team möchte Observability-Features bereitstellen, die Probleme erfassen, bevor die Benutzer davon erfahren, mit einem klaren Entscheidungs-Matrix für Paging oder Nicht-Paging. SLO: 99,9% erfolgreiche Anfragen, p99-Latenz < 300 ms, über einen Zeitraum von 28 Tagen.
Schließen Sie den Kurs
Schließen Sie den Kurs
Sie haben alle fünf Lektionen abgeschlossen:
- Proxies & Origins: die Kantenform, die fast jedes öffentliche Webdienst verwendet
- Stateless Horizontal Scaling: Warum ein stateles Tier sich leicht vervielfältigt und wie man es dimensioniert
- Ingress & Egress Separation: Warum eine Box sich in zwei aufspaltet und das Fehlermod, das dies erzwingt
- Failure Modes & Blast Radius: SPOFs, Kettenreaktionen, Post-Mortems, schuldloses Handeln
- Observability & Capacity (dieser): Was gemessen werden muss, damit Probleme sich vor Benutzern zeigen
Die Hauptlinie: Ein web-skaliertes verteiltes System ist keine Magie. Es handelt sich um eine kleine Menge an Mustern (Umgehung-Proxy, stateless Kopien, Trennung von Eingang und Ausgang, Bulkheads & Schaltkreise, vier goldene Signale), die sorgfältig zusammengestellt werden. Sobald Sie die Muster erkennen, sehen Sie sie in jeder Produktionsarchitektur.
Kommilitonen-Unterrichtungen: fünf geometry-of-*-Unterrichtungen setzen denselben Stoff als Graphentheorie und Geometrie um. Sie passen gut in jede Reihenfolge.
Gut gemacht.