Überwachung und Protokollierung

1) Warum es bei iGaming wichtig ist

Geld in Echtzeit: Annahme von Einzahlungen, sofortige Auszahlungen, Berechnung von Wetten und Gewinnen, Turniere - alles ist empfindlich gegenüber Verzögerungen und Ausfällen.
Regulierung und Audit: Vollständige Rückverfolgbarkeit der Aktivitäten ist erforderlich (KYC/AML, Zahlungen, verantwortungsvolle Spiellimits).
Komplexe verteilte Architektur: API-Gateways, Zahlungsorchestrierung, EDA/Kafka, Anbieterdienste, mobile Clients, Fronten, BI-Bus.
Das Ziel: MTTD/MTTR zu reduzieren, SLO auf Goldsignalen zu halten und die Forensik der Vorfälle zu gewährleisten.

2) Grundbegriffe der Beobachtbarkeit

Protokolle: detaillierte Ereignisse (strukturierte JSONs), die für Untersuchungen und Audits geeignet sind.
Metriken: Aggregate über die Zeit (TSDB), geeignet für SLO/Alert.
Traces: Ursache-Wirkungs-Ketten von Anfragen (trace/span) über Dienste/Broker/DB.
Events: Domain Events (BetPlaced, DepositApproved) sind die Brücke zwischen Geschäftsmetriken und Technik.

3) „Goldene Signale“ und SLI/SLO für iGaming

Latency: P95/P99 für kritische Threads (Autorisierung, Einzahlung, Wette, Sitzungsstart, Spin).
Verkehr: API RPS, Zahlung TPS, Ereignis EPS.
Fehler: Anteil 5xx/4xx, decline-rate, failed-withdrawals, Fehler der Anbieter.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99. 7% erfolgreiche Kartenberechtigungen in 30 Tagen (Fehlerbudget 0. 3%).

4) Sammlungs- und Verarbeitungsarchitektur

1. Injection: Agenten (OTel Collector/Fluent Bit), SDK in der Anwendung, RUM/Synthetik.
2. Routing: Telemetrie-Broker/Bus (OTLP/HTTP/GRPC), Filter und PII-Maskierung.

• Metriken: TSDB (Aggregationen, Downsampling).
• Protokolle: hot (indexierbar )/warm (weniger indexierbar )/cold (Objektspeicher, WORM).
• Traces: zeitindizierte Lagerung mit Retenationen und Tail-Sampling.
• 4. Analytics/Alerts: Regeln (PromQL/LogQL/SQL), Korrelation mit Treisamien und Releases.
• 5. Dashboards: technische + Business-Typen (Zahlungen, RNG/Anbieter, Turnier-Engine).

5) Logstandard (JSON) und Ereignistaxonomie

Strenge JSON-Protokollierung, einzelne Schlüssel und Ebenen werden empfohlen.

Уровни: `DEBUG < INFO < NOTICE < WARN < ERROR < FATAL < AUDIT`

Таксономия: `auth.`, `payment.`, `gameplay.`, `risk.`, `psp.`, `kyc.`, `rg.` (responsible gaming), `ops.`.

json
{
"ts": "2025-11-04T19:45:31. 842Z",
"lvl": "AUDIT",
"event_type": "payment. deposit_approved",
"correlation_id": "c-7d2c1f0b",
"trace_id": "2d6a9c0e4c0b1f72",
"span_id": "9f3a81d2a1c3b764",
"request_id": "r-8f12de9e",
"tenant": "brand_eu",
"psp": "acq_xyz",
"user_id_hash": "u:sha256:1e63…",
"device_id": "d-3c8f…",
"ip_trunc": "203. 0. 113. 0/24",
"amount_minor": 5000,
"currency": "EUR",
"result": "approved",
"latency_ms": 312,
"tags": ["pci_safe", "kyc_passed", "low_risk"],
"extra": {
"bin": "411111",
"method": "card",
"region": "EU",
"ab_test": "checkout_v2"
}
}

• Wir maskieren PAN/BIN (wir speichern nur Felder, die gemäß der Richtlinie zulässig sind), E-Mail/Telefon - Hash/Token.
• IP abgeschnitten bis/24, GeoIP separat aufbewahren.
• Wir verbieten freien Text in 'extra' für Benutzereingaben ohne Sanitaise.

6) Korrelation: trace_id, correlation_id, idempotency_key

Fügen Sie zu jedem Log und jeder Metrik 'trace _ id' (von OTel), 'span _ id', 'correlation _ id' (durchgängig für den Geschäftsprozess), 'idempotency _ key' (für Zahlungsanforderungen) hinzu.
Übergabe der Baggage (tenant/brand, market, A/B-Variante) zum Aufbau der Slices.

7) Metriken: technisch und geschäftlich

Technische: RPS, p95 Latenz, Fehlerrate, Sättigung, GC, Poolnutzung, Kafka Verbraucher lag.
Geschäft: CR- registratsii→depozit, erfolgreiche Autorisierungen, Auszahlungsstornierungen, NGR/GGR, ARPPU, RTP-Anomalien, Drop-off im KYC-Schritt, Anteil der verantwortlichen Grenzen.

promql sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

8) Tracing und OpenTelemetry

Wir instrumentieren Gateway, Payment Orchestrator, Game Core, Benachrichtigungen, KYC/AML, Integration mit Anbietern.
Head-Sampling für Gesamtstrom + Tail-Sampling (erhöht) für Fehler/latente Spans und Zahlungen.
Propagierung des Kontextes: 'traceparent '/' tracestate', Kafka-Köpfe, gRPC-Metadaten.
Wir kommentieren die Spans mit Domain-Events: 'BetPlaced', 'WithdrawalRequested'.

9) Alerting ohne Lärm

Mehrstufige Schwellenwerte (Warnung/kritisch), Flapping-Unterdrückung, Deduplizierung, Zeitfenster.
Korrelation: Wir verbinden „Wachstum 5xx“ + „Kafka lag“ + „p95 latency PSP“ → einem Vorfall.
SLO-basierte Warnungen: Wir geben das Error-Budget aus - wir eskalieren.
Alerts-as-Code (GitOps), Revue und Regeltests.

yaml groups:
- name: payments rules:
- alert: PaymentErrorSpike expr: (sum(rate(payment_errors_total[5m])) / sum(rate(payment_attempts_total[5m]))) > 0. 02 for: 10m labels: { severity: "critical", team: "payments" }
annotations:
summary: "Payment errors> 2% per 10m"
runbook: "runbooks/payments/error-spike. md"

10) Logsuche (Beispiel LogQL)

logql
{app="psp-orchestrator", level=~"ERROR    FATAL"}
= "decline"
json amount_minor > 10000 region="EU"

Ziel ist es, den Lärm schnell herauszufiltern und „teure“ Ausfälle in der Zielregion hervorzuheben.

11) Dashboards: Was ist obligatorisch

Zahlungen Gesundheit: Erfolg/Fehler durch PSP, Latenz durch Methode, Karte der Regionen, SLA-Anbieter.
Game Core: RPS nach Anbieter, p95 Spin, error ratio SDK, RTP Anomalien nach Slot.
Player Journey: registratsiya→KUS→depozit→igra→vyvod (Konversionstrichter, Zeit zwischen den Schritten).
Infra: Kafka lag, DB-Verbindungen, Cache-Trefferverhältnis, Cluster Kubernetes (Gitter von Pods/Knoten).

12) Lagerung, Rückstände und Kosten (FinOps)

Kardinalität unter Kontrolle: Vermeiden Sie Metriken mit hoch modifizierbaren Labels (user_id).
Retentionen: Metriken hot 30-90 Tage, Downsampling bis 13 Monate; logs hot 7-14 Tage, warm 30-90 Tage, kalt 1-3 Jahre (unter Berücksichtigung der Regulatorik).
WORM/immutability für Audit-Logs, Objektsperre.
Komprimierung/Partitionierung und ILM-Richtlinien; separate Indizes für audit/PII-safe.
Log-Sampling auf INFO/DEBUG; ERROR/AUDIT - vollständig.

13) Sicherheit und Compliance

PII/PCI: Tokenisierung, Hashing, Maskierung; Minimierung von Daten.
RBAC/ABAC: Zugriff auf Protokolle/Traces - nach Rollen, Aufteilung der Markisen.
Geheimnisse und Schlüssel: keine Credentials/Token protokollieren; Geheimdetektoren auf CI.
Audit-Trail: Admin-Eingänge, Limit-/Auszahlungsänderungen, manuelle Bilanzanpassungen - nur im AUDIT-Index, ausnahmslos.
Legal-Hold: Mechanismus zum Einfrieren von Retentionen bei Untersuchungen.

14) Qualität der Telemetriedaten

Schema Registry für Logs/Events (Versionierung, Kompatibilität).
Einheitliche Nomenklatur der Felder (snake_case, Maßeinheiten).
Validierung auf Injection (Dirty Event Drop, Heiratsmetriken).
Backpressure und Schutz vor „Logstürmen“.

15) SRE-Prozesse, Oncoll und Runbooks

Oncoll-Matrix und Eskalation; Quiet Stunden und Rotation.
Runbooks sind an Alerts gebunden (Diagnoseschritte, SQL/LogQL-Rezepte, Ficheflags für den Abbau).
Postmortem ohne Strafen, Aktionsgegenstände mit Eigentümern und Terminen.
Teamindikatoren: MTTD/MTTR, Prozentsatz der lauten Alert, Runbuke-Abdeckung.

16) RUM und Synthetik

RUM: WebVitals (LCP, CLS, INP), Frontfehler, Gerätedrucke, Regionen/Anbieter.
Synthetik: Szenarien „registratsiya→depozit→spin→vyvod“ aus verschiedenen Regionen; private Standorte für interne Wege (Adminka/Backoffice).

17) Praktiken von Releases, Experimenten und Ficheflags

Wir verlinken Traces mit Releases-Versionen (commit/artefact).
A/B-Tags in baggage → dashboard „Auswirkungen des Experiments auf SLI“.
Canary/Blue-Green: separate Panels für Kanarienvögel, error-budget burn rate.

18) Anomalieerkennung und Anti-Fraud-Signale

Statistische Auslöser (seasonality-aware) bei decline-rate/chargeback-risk/burst neuer Karten.
Korrelationen: „Anstieg der erfolglosen Einlagen + Neuveröffentlichung des PSP-Adapters“.
Streaming-Regeln (Kafka → Flink) für Near-Real-Time-Reaktionen.

19) Umsetzungsfahrplan (nach Phasen)

Stufe 0 - Basis: JSON-Logs, einheitliche Korrelationsfelder, Basis-Service-Metriken, gemeinsame Dashboards, erste Alerts.
Phase 1 - Tracing: OTel-Instrumentierung, Head + Tail Sampling, Verknüpfung mit Protokollen.
Phase 2 - Business-SLI/SLO: Payments/Leads/Spielmetriken, SLO-Alerts, Error-Budget-Prozesse.
Stufe 3 - Reife: Alerts-as-Code, ILM, getrennte Retenzen, Anomalie-Detect, Per-Service-Runbooks, SRE-Praktiken in CI/CD.

20) Checkliste für die Revue

• Logs nur JSON, einzelne Schlüssel, PII-Maskierung.
• In jedem Ereignis: 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• Metriken decken Goldsignale und Geschäftsflüsse ab.
• SLOs werden beschrieben, es gibt ein Error-Budget und Alerts auf Burn Rate.
• Tail-Sampling ist für Zahlungsfehler und hohe Latenzen aktiviert.
• ILM/Retentions und WORM sind für Audit-Logs konfiguriert.
• RBAC für Telemetrie, Zugriffsprüfung.
• Dashboards von Payments/Game Core/Player Journey/Infra.
• Runbooks sind an jeden kritischen Alert gebunden.
• Post-Mortems und Action-Elemente - im Backlog mit den Eigentümern.

Anhang A: OpenTelemetry-Attribute (Empfehlung)

`service. name`, `service. version`, `deployment. environment`

`cloud. region`, `k8s. pod. name`, `k8s. container. name`

`tenant`, `brand`, `market`, `ab_test`, `user_segment`

`payment. method`, `psp`, `game. provider`, `game. id`

Anhang B: Beispiele für Metriken für SLO

`payment_success_ratio`, `withdrawal_ttw_p95` (time-to-wallet), `psp_latency_p99`

`game_spin_latency_p95`, `provider_error_rate`, `kafka_consumer_lag`

`auth_success_ratio`, `kyc_step_dropout`, `cache_hit_ratio`

Anhang C: Schnelle Rezepte für Untersuchungen

„payment _ error _ rate' wächst“ → PSP/Region/Methode vergleichen, Tail-Traces überprüfen, Adapter-Release ansehen.
„p99 spins ↑“ → tracing front→geytvey→provayder, überprüfen Sie die Anbieter/Kanäle, thread-pool-limits, Netzwerk-retrays.
„Kafka lag ↑“ → Gesundheit consumers, Produzenten retrays, backpressure, slow sinks/DB.