Beobachtbarkeit und Telemetrie

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Beobachtbarkeit ist die Fähigkeit zu antworten: „Warum funktioniert es so?“ ohne Veröffentlichung neuer Bilder. Bei iGaming ist das kritisch: Spitzenturniere, Zahlungsspitzen, Multiregionalität und Anforderungen an verantwortungsvolles Gambling/PII. Die Basis sind Metriken, Protokolle, Traces, kombiniert durch gemeinsame Identifikatoren und Standards (OpenTelemetry), mit SLO-Verträgen, geräuschresistenter Alerting und Kostenkontrolle.

1) Rahmen der Beobachtbarkeit: woraus es besteht

Metriken (Zahlen nach Zeit): RED/USE, Business KPI, SLI. Gespeichert in TSDB.
Protokolle (Ereignisse in Text/JSON): Audit, Fehler, geschäftliche Fakten, Sicherheit.
Traces (Spans): Anforderungspfad durch Dienste, Latenzen, Ursachen von Verzögerungen.
Profiling: CPU/Speicher/eBPF-Streams, Heap/Lock-Inhalte.
RUM und Synthetik: reale Nutzer (Web/App) + Roboter-Checks.
Telemetrie-Katalog: Schemata, PII-Richtlinien, Aufbewahrungsfristen, Kosten-Tags.

2) Taxonomie der Signale und Prinzipien

RED для API: Rate, Errors, Duration.
USE für Infrastruktur: Utilization, Saturation, Errors (CPU, Laufwerke, Netzwerk, Warteschlangen).
SLI/SLO: messbare Indikatoren (z.B. erfolgreiche Abfragen/alles, p95 Latenz), Verfügbarkeitsziele (z.B., "99. 9% in 30 Tagen"), Fehlerbudget → Prozessauslöser.
High-cardinality mit Bedacht: Labels sollen bei Schnitten (Region/Tenant/Anbieter) hilfreich sein, aber nicht TSDB sprengen.

3) Standards und Ende-zu-Ende-Korrelation

OpenTelemetry (OTel): Einheitliches SDK/Protokoll für Metriken, Logs und Traces.
Kennungen: 'trace _ id', 'span _ id', 'correlation _ id', 'player _ id' (pseudonymisiert), 'payment _ route'.
ID-Ablauf: Das Eingangstor → alle Microservices → Zahlungen/PSP → Warteschlangen/Jobs → Logs/Metriken/Spans.

Beispiel: Korrelationsüberschriften

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Metriken: Was und wie wir messen

Namensgebung/Labels

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

Beispiele für Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Histogramme und Beispiele

Speichern Sie die Histogramme der Latenz (native-histograms/ β uckets) und binden Sie exemplar mit 'trace _ id' für den Sprung vom „langsamen Baket“ auf eine bestimmte Spur.

5) Protokolle: strukturiert und sicher

Nur JSON (keine „Freiform“ im Angebot).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
PII Masking/Hash, separate Indizes/Retention für Sensitive.
Protokollpiplines: Parsen → Normalisierung → Anreicherung (Geo/ASN) → PII-Bearbeitung → Indizierung.

Beispiel für ein JSON-Ereignis

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Traces: Wo Zeit verloren geht

Spans: Eingabeaufforderung, Anbieteraufrufe (PSP/Spieleanbieter), DB/Cache, dienstübergreifende RPCs.
Attribute: 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• kopfbasiert (probabilistisch) für das Volumen,
• tail-based (je nach Bedingungen: Fehler, p95 +, VIP-Segment),
• garantiert-keep für zahlungs-/PII-kritische.

7) Beobachtbarkeit von Front und Mobile

RUM: TTFB, FCP/LCP/CLS/INP, JS-Fehler, Netzwerke und SPA-Routing.
Crash-Berichte: Symbolisierung, Deobfuskation, Bildversion, Gerät/OS.
Synthetik: Entry/Deposit/Rate Szenarien; Geo-verteilte Prüfungen.

8) SLO, SLI und Fehlerbudget

Beispiel SLO (Pseudo-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Alerting nach Fehlerbudget, nicht nach „jeder Metrik“.
Freeze-Verfahren bei Budgetverbrennung: Freigaben/Kanaren begrenzen.

9) Alerting ohne Lärm

Multi-Fenster, Multi-Burn-Regeln: kurzes/langes Fenster.
Deduplizierung/Rooting: nach Diensten/Regionen/Kritikalität im On-Call.
Runbook-URL und Kontext-Auto-Selektion (letzte Deploys, Config-Änderungen, Abhängigkeitsgraph).
Ruhige Stunden und Unterdrückung während geplanter Arbeiten.

Beispielregel (PromQL-Idee)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Profiling und eBPF

eBPF/Profiler: Flame-Graphen CPU/alloc, I/O-Latenz, Netzwerk-Drop, Syscall-Anomalien.
Nützlich bei p99-Engpässen, „Jitter“ und seltenen Hängen.

11) Geschäftsbeobachtbarkeit (Produkt & Risiko)

Finanzen/Monetarisierung: Umwandlung von Einlagen, TTW (Time-to-Wallet), Autor von ./settle, Stornierungen/Charjbacks.
Spielaktivität: Retention/Streak, Anteil an Live-Wetten, „Klebrigkeit“ der Anbieter.
Betrugsbekämpfung/Missbrauch: Aktionsgeschwindigkeit, Geräte-/IP-Übereinstimmungen, Korrelationen.
RG-Indikatoren: lange Sitzungen, „Dogon“, Steak-Wachstum.
Geschäftsmetriken korrelieren mit Techmetriken und Releases (Annotationsereignissen).

12) Sicherheit, PII und Compliance

Datenzonen: Dataset/Log-Tags ('pii = true', 'region = EU').
Maskierung vor Indizierung, Pseudonymisierung von Identitäten.
WORM-Speicher für Audits; Rollenzugriff auf das Protokoll.
Aufbewahrungsfristen: unterschiedlich für Techlogs/Audit/Business.
Verbot von rohen Geheimnissen in Protokollen; Scan-Checks im CI.

13) Wertmanagement (FinOps)

Kardinalitätsgrenze: Vorsicht mit 'user _ id', 'session _ id'.
Partitionierung/Retention: heiß (7-14 Tage), warm (30-90), kalt (Archiv).
Sampling-Tracks (tail-based) und Downsampling-Metriken.
Abrechnung mit den Tags' team', 'service', 'tenant': Berichte „wer verbrennt die Beobachtbarkeit“.

14) Toolkit (Referenzstapel)

Metriken: Prometheus/Lake für Metriken, Grafana Dashboards.
Protokolle: Loki/ELK; ingestion Regeln, Reduktion/Parsing.
Treyes: Tempo/Jaeger/OTel-Kollektoren; Beispiellinks aus Metriken.
Synthetik: Blackbox-Exporteur, Browser-Roboter.
Alerting: Alertmanager/Chat-Integration, On-Call-Rotation.
Profiling: eBPF/kontinuierliches Profiling.

15) Beispiele: Basis schnell umsetzen

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Prozesse und Betrieb

Einheitliches Metrik-/Label-Wörterbuch (Namensführer) und Dashboards-Vorlage.
Release-Annotationen durch Automaten in Graphen.
Vorfälle: Karte, Zeitlinie, RCA ohne Anklage, Aktionsgegenstände.
Lernalarme („Game-Day“): simulierte Stürze, PSP-Verzögerungen, Cache-Überhitzung.
Runbooks: Schritt-für-Schritt-Anleitungen und Auto-Links von Alerts.

17) Reifeprüfliste

1. OTel SDK/Collector → einen einzigen Export von Metriken/Logs/Traces.
2. RED/USE deckt alle + SLI/SLO-Dienste über wichtige APIs ab.
3. Die Korrelation „trace _ id“ ⇄ Protokolle ⇄ Metriken (exemplars, jump-links).
4. Fehlerbudget-Alerts mit Multi-Burn und Runabook-Links.
5. RUM + Synthetik auf „Einzahlung/Wette/Auszahlung“.
6. Profiling (eBPF) bei einem White-List-Verkauf.
7. PII-Richtlinien: Maskierung, Zonen, Zugang, Aufbewahrungsfristen.
8. Finanzbericht über die Kosten der Telemetrie („team/service“ -Tags).
9. „Bereit für Spitzenlast“: Testplan, Aufwärmen von Caches, Warnschablonen.
10. Regelmäßige RCAs und Überprüfung von SLOs/Schwellenwerten.

18) Antipatterns

Logs mit „Laken“ ohne Struktur und 'trace _ id'.
Alerts für jede Metrik → alert-fetIg.
Histogramme ohne korrekte Bakette → „flach“ p95.
Die unbegrenzte Kardinalität der Etiketten → eine Explosion der Kosten.
Das Fehlen von RUM/Synthetik ist „alles in Ordnung“, aber der Benutzer nicht.
Mischen von PII mit Techlogs, unbefristete Retention.
Isolation der Telemetrie von Business-KPIs - „Latenz sinkt, Umsatz auch“.

Ergebnisse

Starke Beobachtbarkeit ist die gemeinsame Sprache zwischen Produkt, SRE, Sicherheit und Zahlungen. Durch die Verbindung von Metriken, Protokollen, Tracks unter OTel, die Einführung von SLO mit einem Fehlerbudget, die intelligente Alerting und die Kosten überschaubar machen, erhalten Sie ein System, das Probleme früher bemerkt, sich schneller erholt und Verkehrsspitzen und Turnierlasten vorhersehbar durchläuft.