Health-Check-Mechanismen

1) Warum

Health-Checks sind die erste Barriere gegen kaskadierende Ausfälle: Sie nehmen Knoten korrekt aus der Rotation, verhindern Rückfallstürme, vereinfachen den Abbau und beschleunigen die Erholung, indem sie SLO beibehalten und MTTR reduzieren.

2) Grundlegende Arten von Inspektionen

Lebendigkeit - der Prozess ist „lebendig“ (kein Deadlock/Leck/Panik). Fehler → Neustart der Instanz.
Readiness - Der Dienst ist in der Lage, den Datenverkehr mit Ziel-SLOs zu bedienen (Pools werden angehoben, der Cache wird aufgewärmt, abhängige Ressourcen sind normal). Der Fehler → vom Ausgleich ausgeschlossen, aber nicht neu gestartet werden.
Startup - Der Dienst ist bereit, zu liveness/readiness (langer Bootstrap, Migrationen, Warmup) zu wechseln. Schützt vor vorzeitigen Neustarts.
Deep-Health (domänenspezifisch): Geschäftsinvarianten (die Wette läuft Ende-zu-Ende, die Einzahlung ist beim aktiven PSP autorisiert). Verwendet für Degradationssignale, aber nicht für einen sofortigen Neustart.
External/Synthetic: aktive Pings von außen (API-Pfad, Front-Script, PSP/KYC-Endpunkt) - messen die Benutzerverfügbarkeit.

3) Musterdesign: allgemeine Regeln

1. Billige Lebendigkeit: Wir gehen nicht in externe Abhängigkeiten; Überprüfen Sie die Ereignisschleife, Heap/FD, Watchdog.
2. SLO-Readiness: Wir überprüfen die lokalen Ressourcen, die für die Wartung benötigt werden (DB-Pools, Warm-Cache, Limits). Externe Abhängigkeiten - durch nicht-blockierende „can-serve?“ Signale.
3. Latenzbudget: Jede Probe hat einen eigenen SLA (z. B. ≤100 -200 ms); wenn überschritten - „degraded“, aber nicht 5xx auf liveness.
4. Backoff & Jitter: Probenintervalle 5-15 sec, Timeout 1-2 sec, mit exponentieller Verzögerung bei Fehlern, um Synchronstürme zu vermeiden.
5. Hysterese: N erfolgreiche/fehlerhafte Antworten für Statuswechsel (z.B. 'successThreshold = 2', 'failureThreshold = 3').
6. Versionierung: Endpunkte '/healthz', '/readyz', '/startupz' sind stabil; deep-checks unter '/health/... 'mit benannten Checks.
7. Ohne Geheimnis und PII: Antworten - nur Status und Kurzcodes.
8. Erklärbarkeit: JSON mit einer Liste von Unterprüfungen:'{"status ": "degraded "", checks ": [{"name ": "db"", ok": true", latencyMs": 18}, {" name":" psp. eu","ok":false,"reason":"timeout"}]}`.

4) Deep-Checks Beispiele nach Schichten

4. 1 DB/Cache/Speicher

DB: Kurztransaktion 'SELECT 1' pro Read-Replikat und Poolvalidierung; latency/replication-lag Schwellenwerte.
Cache: „GET “/„ SET“ des Testschlüssels + Hit-Ratio Guard (niedriger Hit → Warning).
Object Storage: HEAD eines vorhandenen Objekts (ohne Download).

4. 2 Warteschlangen/Streaming

Makler: ping-topic publish + consume innerhalb der lokalen partition; consumer-lag Schwellenwerte.
DLQ: Kein Anstieg der Nachrichten im toten Brief hinter dem Fenster.

4. 3 Externe Anbieter (PSP/KYC/AML)

PSP: leichte Auth-Probe (nicht monetär), Vertrags-/Zertifikat-/Quotenprüfung; Wenn es keine sicheren Proben gibt, verwenden wir Proxy-Metriken (Erfolg der Autorisierungen in 5-10 Minuten für Banken/GEO).
KYC/AML: Health-API und Warteschlange SLA; bei Degradation - Wechsel zu einem alternativen Stream/Provider.

4. 4 APIs/Front

Synthetik: Transaktionspfad (Login → Einzahlung-Initiierung → Einsatz „in den Sand“) in EU/LATAM/APAC.
RUM-Signal: Anteil der JS/HTTP- und LCP/TTFB-Fehler - Trigger „außerhalb“.

5) Integration mit der Plattform

5. 1 Kubernetes / Cloud

'startupProbe' schützt den Bootstrap (Migrationen/Cache Warmup).
'livenessProbe' ist minimalistisch; 'readinessProbe' berücksichtigt Pools/Cache/lokale Warteschlangen.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisruptionBudget und maxUnavailable unter Berücksichtigung der Verfügbarkeit.
HPA/KEDA: Skalierung nach Warteschlangen/SLI; readiness beeinflusst das Routing.

5. 2 Balancer/Schleusen/Mesh

Gesundheits-Routing auf L7-Ebene (HTTP 200/429/503 semantics).
Outlier detection (envoy/mesh) - Entfernt den Pool durch error-rate/latency Perzentile.
Circuit-Breaker: Grenzen gleichzeitiger Anfragen/Abhängigkeitsverbindungen, Integration mit Gesundheitssignalen.

5. 3 Auto-Scaling und Degradierung

Readiness = FALSE → Der Datenverkehr wird entfernt, aber der Pod lebt (kann sich sonnen).
Deep-degrade (PSP down) → Feature-Flags für den Graceful-Modus (z.B. Zahlungsmethoden vorübergehend ausblenden, Waiting-Room aktivieren).

6) Zeitüberschreitungs- und Rückzugsrichtlinien

Timeout <Budget SLO: 'timeout = min (⅓ p99, 1-2s)' für synchrone Abhängigkeiten.
Idempotenz: obligatorisch für Retrays; Wir verwenden idempotency-keys.
Exponentieller Backoff + Jitter: verhindert synchrone Welleneffekte.
Retraybudgets: caps per-request/tenant, Schutz vor „retry-storms“.

7) Statussignale und Alerting

Grün/Gelb/Rot: Zusammenfassende Status auf der Service-Dashboards.
Burn-Rate-Alerts nach SLO: schnell (1 h) und langsam (6-24 h).
Correlation-hints: Hinweise zu Releases/Fich-Flags/geplanten Arbeiten.
Auto-Aktionen: Bei „rot“ Deep-Check - Fallback des Anbieters einschalten, Sampling der Tracks erhöhen.

8) Intelligente Strategien für iGaming

Payment-aware readiness: Die Einsatzbereitschaft des Wettdienstes berücksichtigt den Status des PSP-Routers und die Limits nach Bank/GEO.
Odds/Lines publishing: readiness im Pablysher ist abhängig von den zusammengefassten Lag nach Linienquellen und der Laufzeit im Cache/Edge.
Tournament spikes: temporäre Politik der aggressiveren outlier-detection und waiting-room.

9) Antipatterns

Liveness, die in der DB/PSP geht → massive Neustarts bei einem externen Problem.
Ein „vielseitiger“ Gesundheits-Endpunkt ohne Trennung von Startup/Readiness/Liveness.
Harte Auszeiten ohne Backoff/Jitter → Sturm-Retrays.
Keine Hysterese → Routing-Flapping.
Deep-Check, der Restarts auslöst (sein Zweck ist Diagnose und Routing, kein Neustart).
Versteckte 5xx in Health-Endpoints (Real Status Masking).

10) Schnittstellenvorlagen

/startupz → `200 OK {"uptimeSec": ..., "version":"..."}`

Prüfungen: Init-Skripte, Migrationen abgeschlossen, Schlüssel und Configs geladen.

/healthz (liveness) → `200 OK {"heapOk": true,"fdOk":true,"eventLoop":"ok"}`

Checks: Ereignisschleife, Prozessressourcen, keine Panik-/Oom-Flags.

/readyz (readiness) →

`200 OK/503 {"canServe": true,"db":{"ok":true,"latencyMs":12},"cache":{"ok":true},"queue":{"ok":true,"lag":0},"localQuota":{"ok":true}}`

/health/payments (deep) →

`200/206/503 {"psp. eu": {"ok":false,"reason":"timeout"}, "psp. alt":{"ok":true}, "routerMode":"failover"}`

11) Qualitätsmetriken des Gesundheitskreislaufs (KPI/KRI)

Die Zeit, in der der Pod von 'NotReady' zu 'Ready' (warmup-SLO) kommt.
Frequenz „flapping“ readiness per service.
% fälschlicherweise neu gestarteter Pod (root-cause - externe Abhängigkeit).
MTTR-Vorfälle, bei denen Gesundheitsmechanismen eine Rolle spielten (vorher/nachher).
Anteil automatischer Failover/Feature-Degrade ohne On-Call-Teilnahme.
Präzision Synthetik vs RUM (False Positives/Auslassungen).

12) Roadmap für die Umsetzung (4-8 Wochen)

Ned. 1-2: Inventarisierung kritischer Pfade; startup/liveness/readiness; JSON-Antworten mit Sub-Checks und Hysterese eingeben.
Ned. 3-4: Deep-Checks hinzufügen: DB/Cache/Broker; Synthetik für Login/Einzahlung/Wette in 2-3 GEO; Aktivieren Sie outlier-detection in gateway/mesh.
Ned. 5–6: payment-aware readiness и PSP-fallback; Wartezimmer für die Front; Autoscale nach Lag/Warteschlangen; Alerts auf Burn-Rate.
Ned. 7-8: Chaos-Tage (PSP/DB-Replikat deaktivieren), Backoff/Jitter-Prüfung; Fintuning Timeouts, PDB; KPI-Bericht und Anpassung.

13) Artefakte

Health Spec (per service): Checkliste, Zeitbudgets, Hysterese, Aktionen bei Rotstatus.
Runbooks: "Readiness = FALSE: Was tun wir? ", "PSP-Fallback: Schritte und Rückgabekriterien".
Routing Policy: Outlier-Detection-Regeln, Circuit-Breakers, Perzentilschwellen.
Synthetic Playbook: Szenarien und Geografien, SLO Synthetics, Zeitplan.
Release Gate: Release-Blöcke mit rotem Deep-Check der wichtigsten Abhängigkeiten.

Ergebnis

Ein kompetent gestalteter Health-Checks-Kreislauf ist ein schichtweises Signalsystem: leichte Lebendigkeit für die Lebensfähigkeit des Prozesses, Readiness für die Fähigkeit, den Verkehr zu bedienen, Startup für einen sicheren Start und domänenspezifische Deep-Checks für eine kontrollierte Degradation und Routing. In Verbindung mit Autoscaling, Outlier-Routing, Synthetik und SLO-Alerting reduziert es das Risiko von kaskadierenden Ausfällen, reduziert die MTTR und stabilisiert die geschäftskritischen Pfade der iGaming-Plattform.