Überwachung und Zustandsüberwachung

1) Ziele und Grundsätze

Ziel: Verstehen Sie in Echtzeit das „Was passiert“ und „Warum“, um Vorfälle zu verhindern und sich schnell zu erholen, ohne das SLO zu stören oder das OPEX aufzublähen.
Prinzipien: SLO-first, „goldene Signale“ (Latenz, Verkehr, Fehler, Sättigung), einheitlicher Telemetrie-Standard (OpenTelemetry), minimal ausreichende Details, Erklärbarkeit, Cost-Aware-Beobachtbarkeit.

2) Beobachtbare Schichten

1. Metriken: Aggregate für SLI/SLO, Kapazität und Trends (RED/USE-Modelle).
2. Traces: Ursache-Wirkungs-Ketten von Anfragen, Zahlungs- und Spieltransaktionen.
3. Logs/Events: detaillierter Kontext und Audit der Aktivitäten der Betreiber/Dienste.
4. Synthetik (Black-Box): externe Überprüfungen von APIs/Web-Pfaden, PSP/KYC-Hels-Pings.
5. RUM (realer Benutzer): Front-End-Metriken (TTFB, LCP, JS-Fehler), Geo-/Geräteschnitte.
6. Low-Level-Telemetrie: eBPF/CPU/IO/Alloc-Profiling, Netzwerk-Perzentilverzögerungen.

3) SLI-Set und „goldene Signale“

Latenz: p50/p95/p99 auf kritischen Pfaden (Login, Einzahlung, Wette, Auszahlung).
Errors: Anteil 5xx/timeout/decline (mit Normalisierung nach Anbietern/Banken).
Traffic/Throughput: RPS/TPS, aktive Sitzungen, Ereignisse/Sek.
Sättigung: CPU/RAM/IO-Boot, Warteschlangentiefe, Pool-Nutzung, Replikation lag.
Business SLI: erfolgreiche Einzahlungen/% -Raten pro Fenster, KYC/PSP-Konversionsabweichungen, Chargeback-Anteil.

4) Telemetrie-Architektur

Standardisierte Injektion: OpenTelemetry SDK/Collector → Normalisierung, Sampling, Privacy-Filter → Speicher (TSDB, Traces, Logs).
Korrelation: trace-id/span-id in Protokollen und Metriken (Beispiele); Einheitliche Korrelationskennung für Zahlungen/Spielereignisse.
Topologie: Service-Mapa (Service-Graph), abhängige externe Anbieter mit Live-SLI.
Kostenmanagement: Retentionsstufen, Aggregationen, dynamisches Sampling, „heiße „/“ kalte “Speicherklassen.

5) Metriken: Design und Kardinalität

Regeln: kleine Anzahl von Labels, Verbot von High-cardinality (userId, sessionId) in der Zeitreihe; solche Teile - nur in Tracks/Logs.
RED/USE: Requests-Errors-Duration для API; Utilization-Saturation-Errors für die Infrastruktur.
Beispiele: Bindung hoher Perzentile an spezifische Trace-Beispiele.
Geschäftsmetriken: $/RPS, PSP-Konvertierung nach Banken/GEO, Anbieter-Fehlertoleranz.

6) Tracing: Tiefe und Sampling

Kontext: Wir durchlaufen den Trace-Kontext durch die Front → API → Broker → Worker → DB/PSP.
Sampling: Basis 1-10%, mit Anomalien - dynamischer Anstieg nach den Regeln (tailbased).
Schwerpunkte: Payment Flow (init → auth → capture/settle), Spieltransaktionen (bet → settle), KYC (init → verify).
Anmerkungen: PSP-Antwortcode, Bank-BIN/Issuer-Kategorie, Region, Risikograd.

7) Protokolle und Audit

Strukturierte Protokolle: JSON, Ebene nach Profil (INFO auf dem Produkt, DEBUG im Debugging).
Privatsphärenfilter: PII-Maskierung, Verbot von rohen KYC-Dokumenten in Protokollen.
Audit-Ereignisse: Wer/Was/Wo/Wann/Warum, Ticket-ID, Pre/Post-Werte für risikoreiche Transaktionen (Boni, Limits, PSP-Routing).
Unwiderruflichkeit: WORM/immutable, Unterschrift, Politik retention.

8) Zustandsüberwachung (Gesundheit)

Liveness/Readiness/Startup: die richtigen Tests (keine Überprüfung externer Abhängigkeiten in Liveness).
Degradierter Modus: Explizite Flags der Dienstdegradierung, so dass Alerts und Statusseite konsistent sind.
Budgetgesundheit: Burn-Rate des Fehlerbudgets (schnelles/langsames Fenster), Headroom nach Ressourcen und Warteschlangen.

9) Alerting und Frühwarnung

SLO-Warnungen: nach Fehlerbudget (4-Stunden- und 1-Stunden-Fenster) statt „roh“ p95.
Anomalien: STL/IQR/Online-Detektoren für 5xx-Bursts, PSP-Berechtigungsabfall in einem bestimmten GEO/Bank.
Wurzel-Grund-Hinweise: Verknüpfen Sie Alerts mit den neuesten Releases/Ficheflags/geplanten Arbeiten.
Runbooks: Jede Alert hat Links zum Playbook, Grafiken, "Quick Checks'.

10) Dashboards (wer und was sieht)

Exec: Aptime/SLO, Burn-Rate, erfolgreiche Einzahlungen/Wetten, Status der Anbieter, Kapazitätsprognose und $/RPS.
SRE/Plattform: RED/USE nach Diensten, Warteschlangen/Lag, Pool-Nutzung, Replikation Lag, CDN/WAF, eBPF-Profile.
Zahlungen/Risiko: PSP/Banken/GEO Autorisierungserfolge, Soft/Hard Declines, KYC Zeit, Chargeback Frühsignale.
Support/CS: Status-Panel von Vorfällen, SLA-Antworten, FAQ-Makros.

11) Kostenmanagement der Beobachtbarkeit (FinOps-Observability)

Retention: 7-14 Tage für „rohe“ Strecken, Einheiten länger; selektiv - heiße Dienste.
Sampling/Aggregation: Dynamisches Sampling von Anomalien, Downsampling von alten Reihen.
Ingest-Richtlinien: Schneiden Sie das Rauschen (Gesundheit Pings, redundante Protokolle), Quoten für High-cardinality Metriken.
Kosten-KPI: $/GB ingest, $/trace, $/SLI dashboard; regelmäßige Revue Top-Esser.

12) Datenschutz und Compliance

PII/Finanzen: Maskierung, Tokenisierung, Datenminimierung in der Telemetrie.
Geo-Lokalisierung: Speicherung und Verarbeitung nach Gerichtsbarkeit; Log-Export - nur über genehmigte Workflows mit Verschlüsselung und TTL.
Telemetrie Access Audit: RBAC/ABAC, SoD für Uploads, Anforderungsprotokoll.

13) Integration mit Incident Management und Releases

Status-Seite: Automatisches Update-Feed aus der Incident-Card.
Release-Gate: Kanarienanalyse nach SLI, Auto-Stop-Release bei Burn-Rate> Schwelle.
Post-mortem: Zeitleiste von Tracks/Logs, tatsächliche SLIs und Verletzungsfenster.

14) Praktische Implementierungstechnik (8-12 Wochen)

Ned. 1-2: Inventarisierung kritischer Pfade und SLI; Auswahl des Stacks (OTel, TSDB, Logs, Traces); Abhängigkeitszuordnung.
Ned. 3-4: Implementierung von OTel in 3-5 Schlüsseldienste (Login/Einzahlung/Wette), grundlegende RED/USE, Trace-Kontext in den Protokollen.
Ned. 5-6: SLO und Burn-Rate-Alerts; Synthetik nach PSP/KYC; die ersten Runbooks; RUM auf Web/Mobile.
Ned. 7-8: dynamisches Sampling, Beispiele, Service-Mapa; Dashboards Exec/SRE/Zahlungen.
Ned. 9-10: eBPF/Profiling von heißen Engpässen; Privacy-Filter; Quoten/Rückstellungen.
Ned. 11-12: Release-Gates und Auto-Rollback über SLI; Integration mit der Status-Seite; Tabletop-Übungen.

15) Artefaktmuster

SLO-Karte des Dienstes: SLI, Ziele, Fenster, Fehlerbudget, Warnungen, Besitzer.
Alert Spec: Metrik/Bedingung, Schwellenwerte, Dedup/Silence, Empfänger, Runbook.
Dashboard Spec: Publikum, Fragen, 6-8 Widgets, Datenquelle, Aktualisierungsrate.
Telemetriepolitik: welche Felder zulässig/verboten sind, Retention, Maskierung, Export.
Cost Review Pack: Top-Serien/Log-Streams, Sampling/TTL-Angebot, erwartete Einsparungen.

16) KPI der Beobachtungsfunktion

MTTA/MTTR (Verbesserung nach Einführung von SLO-Alerting).
% der Vorfälle, die von Synthetics/SLI vor Nutzerbeschwerden entdeckt wurden.
Anteil der Releases, die ohne manuellen Eingriff das Gate per SLI passiert haben.
Reduzierung von $/RPS auf Telemetrie unter Beibehaltung der Diagnosefähigkeit.
Tracing-Abdeckung kritischer Pfade (> 90%).
Die Genauigkeit der Korrelation „Status-Update ↔ tatsächliche SLI“.

17) Antipatterns

„Wir protokollieren alles“ → Kostenexplosion und Lärm.
Alerts für „rohe“ Metriken anstelle von SLO/burn-rate → pager-fatigue.
Hohe Kardinalität der Metriken (userId) → TSDB-Stürme.
Traces ohne Geschäftskontext (PSP/Bank/GEO) → keine Einsicht.
Es gibt keinen Zusammenhang der Beobachtbarkeit mit Releases/Incidents → die Telemetrie lebt getrennt.

Summe

Die Überwachung und Zustandssteuerung ist keine Toolbox, sondern ein verwaltetes System: korrekte SLI/SLO → standardisierte Telemetrie und Korrelation → SLO-Alerting und Runbooks → Integration mit Releases und Status-Kommunikation → Cost-Aware-Betrieb und Privatsphäre. Eine solche Schaltung liefert frühe Signale, schnelle RCAs und Geschäftsresilienz auch bei extremen Verkehrsspitzen.