Lebendigkeit/Bereitschaft der Proben

2) Gestaltungsprinzipien

1. Trennen Sie die Semantik.

Readiness: externe Fähigkeit, Anfragen zu bedienen (berücksichtigt kritische Abhängigkeiten).
Lebendigkeit: Determinante eines „unheilbaren“ Prozesszustandes.
2. Fail-fast, aber nicht „false-fast“. Stellen Sie die Timeouts/Schwelle' failureThreshold 'so ein, dass kurze Bursts nicht zu unnötigen Restarts führen.
3. Keine schweren Operationen in den Proben. Die Überprüfung sollte schnell (≤100 -200 ms) und ohne Nebenwirkungen erfolgen.
4. Anmutiger Abbau. Wenn Abhängigkeiten teilweise nicht verfügbar sind - Readiness = OK, wenn es einen sicheren Vollback (Cache/Vergröberung) gibt.
5. Deterministic I/O. Die Status hängen nur vom aktuellen Status ab, nicht von „zufälligen“ externen Tests.

3) Die Semantik der HEALTH-Endpunkte

3. 1 HTTP-Ansatz (empfohlen)

„GET/healthz/liveness“ → 200 wenn der Prozess „live“ ist (Event-Loop dreht sich, GC bleibt nicht hängen, Watchdog „Herz“ schlägt).
„GET/healthz/readiness“ → 200, wenn die Instanz für kritischen Klassenverkehr bereit ist. Prüfungen: Verbindungspool, lokale Caches, Verfügbarkeit des Kernels der Geschäftslogik.
„GET/healthz/startup“ → 200 nach der Initialisierung (Migration/Cache-Aufwärmen/Laden von Modellen).

• Sie können nicht in liveness zu externen DBs/APIs gehen - dies führt zu „Selbstmorden“ während Abhängigkeitsvorfällen.
• In der Bereitschaft können Sie kritische Abhängigkeiten überprüfen, aber mit Zeiträumen und Degradierung: Wenn es einen gültigen Vollback gibt - nicht fallen.

3. 2 gRPC Health Checking

Verwenden Sie den Standard 'grpc. health. v1. Health/Check 'mit service-scoped Zuständen (' SERVING', 'NOT _ SERVING'). Für Kubernetes - grpc-Proben (oder http-Proxy).

3. 3 Interne Auslöser

Watchdog des „weichen“ Stopps: Bei SIGTERM wird Readiness = FAIL gesetzt → auf 'terminationGracePeriodSeconds' gewartet → die Warteschlangen geübt.

4) Timings und Schwellenwerte (Tuning)

• `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `successThreshold`, `failureThreshold`.

• readiness: `period=5s, timeout=0. 2–0. 5s, failure=2`
• liveness: `period=10s, timeout=0. 2–0. 5s, failure=3`

• startup: 'period = 5s, failure = 60' (bis zu ~ 5 min)
• readiness/liveness werden nach Startup-Erfolg aktiviert

• readiness spiegelt die Verarbeitungsbereitschaft wider (Verbindung zum Broker, gibt es eine DLQ-Degradation),
• liveness - innere Herzschlag Loop.

Backof on failures: Verwenden Sie in der Anwendung den exponentiellen Backoff, um die Abhängigkeiten wieder zu verbinden, sonst wird die Bereitschaft „gesägt“.

5) Konfigurationen (Fragmente)

5. 1 Kubernetes, HTTP-Proben

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 Kubernetes, gRPC-Probe

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 Graceful shutdown

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

'/healthz/drain 'im Service übersetzt Readiness = FAIL (Stop-Accepting), gibt Zeit, um aktive Anfragen abzuschließen.

6) Abhängigkeiten und Degradierung

Kritisch (ohne sie kann nicht bedient werden): DB-Autorisierung für '/login', Zahlungsgateway für '/pay'. Kann in readiness mit einem Timeout von ≤80% der 'timeoutSeconds' Probe überprüft werden.
Unkritisch: Analytik, E-Mail, Cache-Schicht, wenn es ein Nachladen gibt. Schließen Sie sie nicht in die Bereitschaft ein; Benutze Vollbeck.
Feature-Flags: Bei teilweiser Degradation deaktivieren Sie die abhängigen Fiches unter Beibehaltung von Readiness = OK.

7) Warteschlangen und Hintergrund-Handler

• Readiness = OK, wenn das Abonnement/die Verbindung zum Broker installiert ist und eine Ressource verarbeitet werden muss.
• Bei einem DLQ/Laga-Überlauf kann → Readiness OK bleiben (wenn wir es akzeptieren und falten), aber der SLI "Fresh/Lag' leuchtet auf - alert entsprechend den Daten.
• Liveness: Steuern Sie den Poll-Zyklus/Herzschlag, Deadlock-Detektor.

Idempotenz: Beschleunigt die Erholung nach Neustart-Liveness.

8) Sidecar/mesh/ingress

• Aktivieren Sie „readinessGate“ (K8s), um den Sidecar-Status zu berücksichtigen
• Stellen Sie sicher, dass die Proben nicht in mTLS-Barrieren fallen (oder fügen Sie Ausnahmen hinzu).
• Ingress/Envoy/Nginx: Proxy '/healthz/' lokal, nicht 'out out' interne Teile.

9) Sicherheit und Privatsphäre

Health-Endpoints dürfen keine Configs, Bibliotheksversionen, Fehlerstrings offenlegen - nur „OK/FAIL“ + minimaler Ursachencode.
Zugriff von außen einschränken (NetworkPolicy/ACL). Für die Öffentlichkeit - lassen Sie uns nur lebendiges Ping ohne Details.
Die Protokolle der Gesundheitschecks sind auf DEBUG-Niveau, mit Trottling.

10) Beobachtbarkeit und SLO

Exportieren Sie die Metriken: 'health _ readiness {status}', 'health _ liveness {status}', die Verarbeitungszeit der Probe.
Verknüpfen Sie Readiness-Flaps mit dem Verfügbarkeits-SLO (Verlust von Endpunkten → 5xx/connection reset).

• „Häufige Restarts durch Liveness> N/Stunde“ ist ein Symptom für Deedlocks/Leaks.
• „Flap Readiness> X/15 min“ ist ein Symptom für Sucht/Netzwerkprobleme.
• Korrelation mit Deploy ('service. version`).

11) Testen

Einheit/Vertrag: Endpunkte '/healthz/' geben korrekte Status zurück, wenn jede Abhängigkeit ausgeschaltet wird.
Chaos: DB/Cache/Broker deaktivieren: Readiness muss fallen oder Follback streng nach Modell einschalten. Lebendigkeit - wird nicht ausgelöst, wenn der Prozess „lebendig“ ist.
Load/Soak: Unter Last müssen die Health-Endpoints schnell bleiben (keine Durchschlagskraft).
Canary: Überprüfen Sie die Stabilität von Readiness, bevor Sie den Traffic erhöhen.

12) Häufige Fehler und wie man sie vermeidet

Liveness validiert OBD/externe APIs. Die Folge sind endlose Restarts bei Zwischenfällen. Die Lösung: Die Lebendigkeit auf „Prozessleben“ beschränken.
Schwere Kontrollen in den Proben. Führt zu falschen Ablehnungen. Die Lösung: einfache Checks + separate Background-Health-Monitore.
Keine Startup-Probe. Langsame Starts „töten“ die Lebendigkeit. Lösung: Startup mit breitem Fenster hinzufügen.
Kein graceful shutdown. Selten 5xx mit deploy. Lösung: preStop + Ausgleichen.
Flippenstürme. Zu aggressive Schwellen. Lösung: 'failureThreshold' anheben, 'timeoutSeconds' erhöhen, Backoff hinzufügen.
Die gleichen Endpunkte für alles. Eine Mischung aus Semantik. Lösung: separate' liveness/readiness/startup'.

13) Mini-Implementierungsmuster

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) Checklisten

Vor dem Verkauf

• Die Endpunkte liveness/readiness/startup werden getrennt, ihre Semantik beschrieben.
• Liveness berührt keine externen Abhängigkeiten; Readiness checkt nur kritisch mit Timeouts und Vollbeck.
• 'initialDelay/period/timeout/failureThreshold' ist für das Serviceprofil konfiguriert.
• Graceful shutdown aktiviert: 'preStop' + Rückzug aus dem Ausgleich.
• Gesundheitsmetriken/Protokolle sind verbunden; Alerts für Restarts/Flap.
• Tests für Abhängigkeitsfehler und langsame Starts bestanden.

Betrieb

• Wöchentlicher Bericht über Restarts und Readiness Flaps.
• Tuning von Schwellenwerten nach Vorfällen; Verknüpfung mit Releases.
• Regelmäßige Chaos-Tests zum Ausschalten von Abhängigkeiten.
• Relevanz der Semantik bei Änderung der Kritikalität von Abhängigkeiten.

15) FAQ

F: Ist es möglich, alles mit einem einzigen Versuch zu schließen?
A: Unerwünscht. Trennen Sie' startup', 'readiness', 'liveness' - dies reduziert Fehlalarme und beschleunigt die RCA.

F: Soll der Cache in readiness überprüft werden?
A: Wenn es einen korrekten (wenn auch langsamsten) Modus ohne Cache gibt - machen Sie die Bereitschaft nicht zunichte, schalten Sie einfach die Degradierung ein.

F: Was tun bei häufigen Restarts durch Liveness?
A: Beseitigen Sie zuerst die Schwänze/das Leck; Lösen Sie dann die Schwellenwerte und fügen Sie einen Watchdog in der App hinzu.

F: Wie kann ich Multi-Leasing berücksichtigen?
A: Readiness sollte die Fähigkeit widerspiegeln, jeglichen Mietverkehr zu bedienen. Für private Probleme eines bestimmten Mieters - ändern Sie nicht die Bereitschaft, sondern signalisieren Sie separate SLI/Alert.

• „Beobachtbarkeit: Protokolle, Metriken, Traces“
• „Verteilte Traces“
• „SLO/SLA und Metriken“
• „Garantien für die Lieferung von Webhooks“
• „Verschlüsselung im Transit“
• „Management von Geheimnissen“