Distributed Tracing

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Verteilte Traces geben die Antwort auf die Frage wo und warum Zeit auf dem Anfragepfad über Gateway, API, Warteschlangen, DB, externe Anbieter (PSPs/Spielestudios) verloren geht. OpenTelemetry (OTel) ist ein offener SDK/Agenten-/Protokoll-Standard, der Traces, Metriken und Protokolle kombiniert. In iGaming ist es ein grundlegendes Werkzeug, um p95/p99 zu halten, Zahlungsprobleme schnell zu lokalisieren und Engpässe vor Spitzenturnieren zu identifizieren.

1) OTel-Konzepte

Trace ist der vollständige Transaktionsweg (Einzahlung, Wette, Auszahlung).
Span - Arbeitsbereich (HTTP-Handler, SQL-Abfrage, Warteschlangen-/Provider-Aufruf).
Attribute - Schlüsselwert mit Details ('net. peer. name`, `db. system`, `psp. route`).
Events - Sofortereignisse (Retray, Timeout, Cache-Fehler).
Links - Kommunikation mit anderen Spuren (wichtig für async/queue).
Ressource - Prozess-Metadaten: 'service. name`, `service. version`, `deployment. environment`, `cloud. region`.

2) Verbreitung des Kontextes

traceparent: 00-<trace_id>-<span_id>-01 tracestate:...

Optional - Baggage für sichere Schlüssel (z.B. 'tenant', 'route'), keine PII dort ablegen.

Wo man den Kontext durchbohrt: API-Gateway → interne RPCs → Produzent in der Warteschlange → Consumer → externe HTTPs (PSPs/Provider).

3) Semantische Konventionen (obligatorisches Minimum)

HTTP/RPC: `http. method`, `http. route`, `http. status_code`.
DB/Cache: 'db. system` (`mysql`/`postgresql`/`redis`), `db. statement'(maskiert), 'db. operation`.
Warteschlangen: 'messaging. system` (`kafka`/`rabbitmq`), `messaging. destination`, `messaging. operation` (`send`/`process`).
Zahlungen: 'psp. route`, `psp. provider`, `payment. id'(pseudonymisiert), 'amount', 'currency'.
iGaming Domain: 'Spiel. provider`, `game. session_id` (hash), `player. id_hash`.

Eine einheitliche Taxonomie → die Vergleichbarkeit von Dashboards und die schnelle Ursachensuche.

4) Sampling: Wie man nicht in Daten ertrinkt

Kopfbasiert (am Abfrageeingang)

Einfach, billig; geeignet für den allgemeinen Fluss.
Minus - Sie können „interessante“ langsame/fehlerhafte Spuren verlieren.

Tail-based (в Collector)

Die Entscheidung fällt nach Abschluss der Spans: Wir speichern nur Fehler/langsame/wichtige Segmente (VIP/Zahlungen).
Ideal für Prod-Belastung: stark reduziert die Kosten bei hohem Informationsgehalt.

• Kopf: 5-10% für „Hintergrund“ Abdeckung.
• Tail: 100% Fehler + p95 + langsam + Zahlungswege/kanarische Releases.

5) Topologien von OpenTelemetry Collector

Agent-Side-Car (auf jedem Knoten/Pod): lokale Akzeptanz, minimaler Puffer, Export in den Aggregator.
Gateway (Cluster): Tail-Sampling, Routing, Anreicherung, Export nach Tempo/Jaeger/Zipkin/OTLP.

Beispiel: tail-sampling (YAML-Fragment)

yaml processors:
tailsampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code:
status_codes: [ ERROR ]
- name: slow_p95 type: latency latency:
threshold_ms: 250
- name: payments type: string_attribute string_attribute:
key: service. name values: [ "payments-api", "payments-worker" ]

6) Korrelation mit Metriken und Protokollen

Fügen Sie zu jedem Logeintrag 'trace _ id '/' span _ id' hinzu.
Speichern Sie die Latenzmetriken als Histogramme und schließen Sie Beispieldaten ein - ein Link zu einem repräsentativen 'trace _ id' für den „Sprung“ von einem p95-boquet zu einer bestimmten Spur.
Release Annotationen (Git SHA, Chartversion) sind wie Events/Labels.

7) Instrumentalisierung (Sprachen und Auto-Agenten)

Go (manuell + Auto)

go tp:= sdktrace. NewTracerProvider(
sdktrace. WithBatcher(exporter),
sdktrace. WithResource(resource. NewWithAttributes(
semconv. SchemaURL,
semconv. ServiceName("payments-api"),
)),
)
otel. SetTracerProvider(tp)

ctx, span:= tracer. Start(ctx, "Deposit")
defer span. End()
span. SetAttributes(
attribute. String("psp. route","pspX"),
attribute. String("currency","EUR"),
)

Java

Auto-Agent '-javaagent: opentelemetry-javaagent. jar', config via env („OTEL _ SERVICE _ NAME“, „OTEL _ EXPORTER _ OTLP _ ENDPOINT“).
Manuell - Anmerkungen/Werkzeug für Zwiebelplätze (JDBC-Pools, Cache).

Node. js / Python

Auto-Tool mit SDK + Plugins (Express/FastAPI/Sellerie).
Für Warteschlangen - Producer/Consumer Wrapper, um 'messaging.' und Links zu platzieren.

8) Warteschlangen und async: die richtigen Spans

Producer ('send'): Span zum Senden an die Spitze/Warteschlange.
Consumer ('process'): Neuer Span der Nachrichtenverarbeitung von Link zu Span des Produzenten (Ursache-Wirkungs-Beziehung ohne generisches' trace _ id 'beibehalten).
Attribute: 'messaging. kafka. partition`, `messaging. rabbitmq. routing_key`, `messaging. message_id`.
Bei Retrays - Event 'retry', der Zähler der Versuche.

9) DB/Cache und N + 1

Aktivieren Sie das Tracing von DB-Treibern, gruppieren Sie Abfragen desselben Typs in Batchi.
Für Redis/Cache die Attribute' cache. hit`/`cache. miss`.
Nehmen Sie „schwere“ Anfragen in die einzelnen Spans - Sie können sehen, wo p99 ist.

10) Externe Anbieter: PSP/Spielestudios

Verpacken Sie HTTP-Clients: 'psp. provider`, `psp. route`, `timeout_ms`, `attempt`.
Protokollieren Sie die Fehlercodes/-typen, aber nicht die PII (Kartennummer, Token).
Vergleichen Sie die Studios/Routen nach 'Dauer', 'Fehlerrate'.

11) Frontend und RUM

OTel Web SDK: `page_view`, `resource_load`, `xhr`.
Durchbohren Sie' traceparent 'in das Backend, um den Benutzerpfad der UI → API → DB zu stopfen.
Segmentierung nach Geo/Netzwerkanbieter - optionale Labels.

12) Sicherheit und PII

Maskieren Sie die Felder ('db. statement 'mit Bearbeitung), hash' player _ id'.
Datenbereiche: „pii = true“, „region = EU/TR/LATAM“.
Kontrolle des Zugangs zu Payment Traces (rollenbasiert).
WORM/Retention: Aufbewahrungsfristen für sensible Spuren, Löschung per Richtlinie.

13) Leistung und Kosten

Tail-Sampling zur Politik: „Fehler + langsame + Zahlungen + kanarische Veröffentlichungen“.
Downsampling Histogramme von Metriken, aggressive Deduplizierung von Protokollen.
Einschränkung der Kardinalität: 'user _ id' nicht als Metrik-Label einzutragen.
Puffer/Batches im Collector, OTLP-Kompression.

14) Dashboards und Analyse

Service map: Abhängigkeiten der Dienste, Färbung durch Fehler/Latenz.
Release compare: stabile vs Kanarienrevision (p95, error-rate, payments conv).
Top Slow Traces: entlang der Route '/deposit', Abschnitt nach PSP/Region.
Queue lag: Spuren mit tiefer Verbrauchsverzögerung.

15) Beispiele für Collector-Konfigurationen

Pipelines (Metriken/Traces/Logs, Snippet)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch:
memory_limiter:
limit_mib: 1024 spike_limit_mib: 256 attributes/payments:
actions:
- key: "psp. provider"
action: insert value: "pspX"

exporters:
otlp/traces: { endpoint: tempo:4317, tls: { insecure: true } }
otlp/metrics:{ endpoint: prometheus-otlp:4317, tls: { insecure: true } }
otlp/logs:  { endpoint: loki-otlp:4317, tls: { insecure: true } }

service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ memory_limiter, batch, tailsampling ]
exporters: [ otlp/traces ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/metrics ]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/logs ]

16) Runbooks (typische Szenarien)

A) Wachstum von p99 in 'payments-api'

1. Öffnen Sie „Top Slow Traces“ → fallen Sie in DB/PSP-Spans.
2. Wenn das PSP-Problem darin besteht, die Route zu übersetzen, aktivieren Sie Retrays/Timeouts.
3. Überprüfen Sie die Warteschlange' withdrawals'(lag), erhöhen Sie die Verbraucher.

B) Fehler 5xx nach Veröffentlichung

1. Filtern nach 'service. version`.
2. Stabile/Kanarienrinde vergleichen; Finde Adhäsionen in 'psp. route`.
3. Promotion einfrieren, zurückrollen (siehe „Releasestrategien „/“ Rolbacks “).

C) Verdacht auf N + 1

1. Traces mit einer großen Anzahl von kurzen DB-Spans.
2. Aggregation/Joins aktivieren, Cache-Ebene hinzufügen.

17) Checkliste Umsetzung

1. OTel SDK und einheitliche Resource-Attribute ('service. name`, `env`, `region`).
2. Propagierung des W3C Trace Context durch alle Schichten und Warteschlangen.
3. Minimaler Satz semantischer Attribute (HTTP/DB/queue/PSP).
4. Tail-Sampling: Fehler, p95 +, Zahlungen, Kanar.
5. Logs mit 'trace _ id '/' span _ id', Metriken mit Beispielen.
6. Dashboards: Servicekarte, Releasevergleich, Zahlungsfluss.
7. PII-Richtlinien: Maskierung, Zonen, Rollen, Retention.
8. Tests/Load: Überprüfung der Korrelation und Completeness Tracing vor Peaks.
9. Autogenerierung von Runbook-Links in Alerts.
10. Bericht über Telemetriekosten und Kardinalität.

18) Antipatterns

Traces „nur am Eingang“ ohne DB/Warteschlangen → kein Nutzen.
Das Fehlen von Propaganda in async → „zerrissen“ Ketten von Ursache-Wirkungs-Beziehungen.
Sampling zufällige 1% ohne tail-Logik → nicht fangen langsam/fehlerhaft.
Logs ohne' trace _ id '→ keine Ende-zu-Ende-Korrelation.
Rohe PIIs in Attributen/Protokollen → Compliance-Risiken.
Die Kardinalität „an die Decke“ (user/session as metric labels) → eine Kostenexplosion.

Ergebnisse

OpenTelemetry verwandelt die Beobachtbarkeit von einer Reihe unterschiedlicher Tools in eine End-to-End-Performance-Sprache. Mit der richtigen Propagierung des Kontextes, einer ordentlichen Semantik, einem Tail-Sampling und einer Kombination aus „Metriken ↔ Tracks ↔ Protokollen“ hält das iGaming-Team p95/p99 unter Kontrolle, isoliert schnell Engpässe (DB, Warteschlangen, PSP) und veröffentlicht selbstbewusst Freigaben auch bei Verkehrsspitzen.