Observability и trace sampling

1) Warum Observability

• Metriken (Aggregate, reagieren schnell);
• Logs (Details und Forensics);
• Traces (durchgehende Ursache-Wirkungs-Beziehungen);
• Profile (CPU/heap/lock Inhalt im Modus prod).

Schlüssel: Korrelation zwischen Signalen + Wirtschaftlichkeit der Telemetrie (Sampling, Retentionen, Kompression).

2) Signalkarte und Prinzipien

2. 1 RED/USE

ROT (für API): Rate (RPS), Fehler (% 5xx/4xx wichtig), Dauer (p50/p95/p99).
USE (für Ressourcen): Dienstprogramm, Sättigung, Fehler (NIC, CPU, Laufwerk, Warteschlangen).

2. 2 Produktinvarianten

Definieren Sie ein SLO (z. B. "p95 Latenz "/v1/Zahlungen" ≤ 300 ms, fehlerhaftes Budget 0. 5% in 30 Tagen"). Alerts sollten nur „schreien“, wenn SLO verletzt oder verbrannt wird.

2. 3 Kontext

Implementieren Sie W3C Trace Context ('traceparent', 'tracestate') und baggage, um jene/Geschäftsattribute (z.B. 'tenant', 'region', ohne PII) sicher zu übertragen.

3) Architektur der Beobachtbarkeit

SDK/Auto-Tool: OpenTelemetry (OTel) in Diensten (HTTP/gRPC/DB/Clients).
OTel Collector als Bus: Empfang → Anreicherung → Sampling → Export (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• Metriken: Prometheus/Mimir/VictoriaMetrics;
• Treyses: Tempo/Jaeger/Zipkin;
• Protokolle: Loki/ELK/Vector→S3+deshevoye Speicher;
• Profile: Pyroscope/Parca.
• Korrelation: Graphen von Diensten, Beispiele, Übergang von einem p99-Diagramm zu einem bestimmten Trace.

4) Sampling-Tracing: Strategien

4. 1 Kopfbasiertes Sampling (am Eingang, vor Kenntnis des Ergebnisses)

Einfache und kostengünstige Implementierung (im SDK/ingress).
Nachteile: kann seltene Fehler/langsame Abfragen überspringen.

Wann: hohe RPS, strenge Budgets, vorhersehbarer Anteil erforderlich (z.B. 1-5%).

4. 2 Tail-basiertes Sampling (am Ausgang, das Ergebnis wissend)

Die Entscheidung fällt im Collector nach Abschluss des Spans.
Sie können garantiert Anomalien auswählen: Fehler, p99, spezifische Routes/Tenants.
Nachteile: Pufferung, schwieriger und teurer.

Wann: Sie benötigen „sinnvolle“ Traces zu moderaten Kosten.

4. 3 Kombinationsmodell

Globaler Kopf 1-5%, plus Tail-Regeln: „immer Fehler/Slow-Spans speichern“, „50% des Canary-Traffics sampeln“, „alle Trails der Zahlungswege im Falle eines Vorfalls speichern“.

5) Dynamische Abtastung und Telemetrie-Budget

Budget-aware: Halten Sie das Volumen ≤ N traces/min; bei Überschreitung die Schwellenwerte anheben (z. B. nur p99 auswählen. 5+, error-only).
Regeln nach Route/Tenant: wichtige Endpunkte/Tenanten - mit größerem Anteil.
Adaptive Fenster: Überspannungen → den Anteil der Fehler/langsamen vorübergehend erhöhen.
Reduktion der Kardinalität: User-Agent, IP/ASN, Squash-Stack-Spuren normalisieren, Geheimnisse maskieren.

6) Confighi (Referenzen)

6. 1 OpenTelemetry Collector - tail-sampling (yaml-fragment)

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

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6. 2 Prometheus - Beispiele (Fragment)

Fügen Sie in der Anwendung beim Schreiben von Histogrammen die Beispiele mit 'trace _ id' hinzu. In Grafana führen Klicks auf „Nadeln“ in die Trais.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6. 3 Loki - Reduzierung der Logkosten

Labels sind nur stabil ('service', 'env', 'region', 'route _ class').
Hohe Kardinalität (request_id, user_id) - in payload, aber mit Reduktion.
Sample „erfolgreiche“ Info-Logs, speichere alle Fehler/Warnungen.

6. 4 Jaeger/Tempo - Retention und Index

Lagern Sie rohe Trails 3-7 Tage, Aggregate/Symmetrien länger.
Aktivieren Sie Parkett/Blöcke im billigen Speicher (S3-kompatibel), Indizes sind kompakt.

7) Fahrsimulation

7. 1 Benennung und Attribute

`service. name`, `service. version`, `deployment. environment`.
`http. method`, `http. route`, `http. target`, `http. status_code`, `net. peer. name`.
Geschäftsattribute ohne PII: 'tenant', 'region', 'payment _ provider', 'game _ id'.

7. 2 Veranstaltungen und Verbindungen

Span-Ereignisse: wichtige Punkte (Beginn der DB-Transaktion, Retray, Circuit Open, Cache Miss).
Links: zapros→vebkhuk/sobytiye Kommunikation; nützlich für EDA und outbox/inbox.

7. 3 Instanzen (Beispiele)

Fügen Sie den Latenz-/Größenhistogrammen Beispiele mit 'trace _ id' hinzu: Navigation 'von Metrik → zu Trace' mit einem Klick.

8) Metriken: welche und wie

8. 1 Technische

ROT nach Routen/Tenanten/Anbietern (PSP, KYC).
Пулы: `db_connections_in_use`, `http_client_in_flight`, `queue_depth`.
Stabilisierung: Retries, Timeouts, Circuit Open/Half-Open, Rate-Limit-Hits.
Go/Java/Python-Laufzeit: GC-Pausen, Heap, Safepoints, GIL-Latenzen.

8. 2 Geschäftsmetriken

Registrazii/loginy/deposity/wywody, die Konversion, die Misserfolge 3DS/KYC, chargeback-ratio.
Wichtige Fiches: Time-to-Wallet, Erfolgsrate Auszahlung.

8. 3 Kardinalität und Lagerung

Histogramme mit expliziten Buckets (z.B.'[50,100,200,300,500,1000,2000] ms').
Vermeiden Sie Markierungen mit hoher Kardinalität (raw user_id, request_id) - nehmen Sie sie in Protokolle/Traces.

9) Protokolle: Standards und Korrelation

Format: JSON + erforderliche Schlüssel ('timestamp', 'level', 'message', 'trace _ id', 'span _ id', 'service', 'env').
Bearbeiten: PAN, Token, PII maskieren.
Sampling: 100% für 'error/warn', 5-20% für' info 'auf' lauten 'Wegen.
Die Bindung an Traces erfolgt über 'trace _ id'. Logzeilen → „Pivot“ in Trace und umgekehrt.

10) Profiling in der Produktion

Aktivieren Sie continuous profiling (Pyroscope/Parca) für CPU/heap/alloc/locks.
Korrelieren Sie p99 Spitzen mit heißen Stapeln; 7-14 Tage aufbewahren.

11) Alerting durch SLO/fehlerhaftes Budget

SLO-Alerts: „Ein fehlerhaftes Budget wird schneller ausgegeben als X %/Stunde“ (Predictive Alerts).
Symptome, nicht Ursachen: Alertitis pro Client-Ebene (RUM/Edge oder Per-Rout), nicht auf der CPU.
Multi-Fenster, Multi-Burn-Rate: 2% für 1 h und 5% für 6 h - zwei Bedingungen.
Stille bei geplanten Degradationen: Verschiebung der Schwellen bei Fichflaggen/Kanarienvogel.

12) Kosten und Retention

Mengenquoten: Traces ≤ N TB/Monat, Protokolle - heißer 3-7 Tage, kalt S3 30-90 Tage, Metriken - Downsampling (1 min → 5 min → 1 h).
Tail-Rules reduzieren das Volumen × 10- × 100, während sie fehlerhaft/langsam bleiben.
Signale mit den niedrigsten Kosten - Metriken; mit dem größten Wert - die „richtigen“ Traces und Profile.

13) Antipatterns

„100% Trails Always“ → Kostenexplosion, Lärm und Bremsen.
Protokolle im freien Format ohne Schlüssel/Maskierung.
Metriken mit unendlichen Etiketten (user_id/ip/full UA).
Kein 'traceparent '/' baggage' - eine Korrelation ist nicht möglich.
Alerts auf CPU/Heap statt SLO - Chat „brennt“ ohne Nutzen.
Sampling „rand 1%“ ohne Fehlerpriorität/slow - Sie verlieren wertvolle Fälle.

14) Beispiele für Dashboards (Skelette)

API-Übersicht: RPS, Error-Rate nach Klassen, Latenz p95/p99 (Beispiele sind anklickbar), Top-Routes.
Release/Canary: Vergleich der Metriken der alten/neuen Version, Outlier-Rate, Open-Circuits, Retries.
PSP/KYC: Erfolgsrate nach Anbieter, Latenz und Fehler, Korrelation mit Auszahlungsfehlern.
Infra: USE auf Ressourcen, Warteschlangen Sättigung, Netzwerk drops.

15) Spezifität von iGaming/Finanzen

Kritische Pfade (Ein-/Auszahlungen): 100% Tracing nur bei Zwischenfällen oder eingeschränkten Fenstern; im Normalmodus - tail „alles mit Fehler/langer Latenz“.
Region/Tenant: 'tenant', 'jurisdiction', 'brand' zum Baggage hinzufügen; Bauen Sie SLOs nach Gerichtsbarkeit auf.
Anti-Fraud/Bot-Filter: Metriken und Traces von Risk API-Lösungen (allow/deny/challenge), Challenge-Pass-Rate, Velocity-Hits.
Audit/Compliance: Halten Sie das erforderliche Minimum, ohne PII; unveränderliche Protokolle - in einer separaten Schleife.

16) Checkliste Prod-Ready

• Ende-zu-Ende-Propagierung ('traceparent', 'baggage'), Korrelation von Protokollen/Metriken/Traces.
• OTel Collector with tail-sampling (errors/slow/important routes) + probabilistic default.
• RED/USE-Metriken, explizite Buckets, Beispiele → Übergang zum Trace.
• SLO und Alerting nach fehlerhaftem Budget (zwei Zeitskalen).
• Retentionsregelungen und Telemetrie-Budget; Downsampling-Metriken; cold storage für Logs.
• Standardisiertes JSON-Log, Redaction PII/Secrets.
• Profiling in der Produktion enthalten; Dashboards von „heißen“ Stacks für den Vorfall.
• Kanarische Dashboards und Versionsvergleich; Keine „blinden Flecken“.
• Runbook: Wie man den Sampling-Anteil bei einem Vorfall vorübergehend erhöht.
• Attribut-/Label-Namensdokumentation und High-Cardinality-Verbot.

17) TL; DR

Bauen Sie die Beobachtbarkeit um die Korrelation auf: RED/USE-Metriken → Beispiele → Traces → Protokolle/Profile. Verwalten Sie die Kosten durch kombinierte Sampling: kleine Kopf% + Tail-Regeln (Fehler, langsam, wichtige Routen/Tenants). Alerts - auf SLO und Fehlerbudget. Retentionen und Kardinalität unter Kontrolle halten, OTel Collector als „zentrales Nervensystem“ nutzen. Für Zahlungs-/Gerichtswege - vorrangige Telemetrie und strenge Datenhygiene.