Verteilte Verfolgungen

Verteilte Verfolgungen

1) Warum und was es ist

Distributed Tracing ist eine Möglichkeit, Transaktionen über den gesamten Anfragepfad hinweg zu verknüpfen: Front → API-Gateway → Microservices → DB/Caches → Broker → Jobs/Piplines.
Das Ergebnis ist ein Treis (trace) aus Spans (span), wobei jeder Span die Arbeit der Komponente mit Attributen, Ereignissen und Status erfasst. Es beschleunigt RCA, hilft, SLO zu halten und reduziert MTTR.

• Sichtbarkeit des kritischen Weges und „Engpässe“.
• Korrelation von Symptomen (Metriken) mit Ursachen (Spans) und Details (Logs).
• Analyse von Retrays, Warteschlangen, DLQ, Fan-Outs, Latenzsägen.

2) Trace-Datenmodell

Trace ist ein Aufrufgraph mit 'trace _ id'.
Span — операция: `name`, `kind` (SERVER/CLIENT/PRODUCER/CONSUMER/INTERNAL), `start/end`, `status`, `attributes`, `events`, `links[]`.
Attribute - Schlüsselwert (route, db. system, messaging. system, cloud. Region usw.).
Events - Instant Labels innerhalb des Spans (z.B. 'retry', 'cache _ miss').
Span Links - Verbindungen außerhalb der Eltern-Kind-Beziehung (Batchi, Retrai, Fan-In/Out).
Ressource - Prozess/Service Metadaten ('service. name', Version, Umgebung).

3) Kontext und Übertragbarkeit

3. 1 W3C Trace Context

• 'traceparent': 'version-traceid-spanid-flags' (Flags enthalten Sampling).
• 'tracestate': herstellerspezifischer Zustand (auf Minimum).
• Baggage - Schlüssel für den Geschäftskontext (eingeschränkt, keine PII/Geheimnisse).

3. 2 Den Kontext durchschauen

HTTP: `traceparent`/`tracestate`; gRPC: Metadaten; WebSocket: beim Upgrade und in Nachrichten;

Botschaften: in den Köpfen (Kafka/NATS/RabbitMQ) - wir behalten den ursprünglichen Kontext bei PRODUCER und übertragen ihn auf CONSUMER.
Basen: „tragen“ keinen Kontext - wir loggen Attribute in span (query, rows, db. system), aber keine Bedeutung.

4) Sampling: Wie man nicht pleite geht

Kopfprobe (am Eingang): probabilistisch/nach Regeln (Route, Tenant, Endpunkt).
Tail Sampling (auf dem Kollektor): Speichern Sie „interessante“ Trails - Fehler, lange p95/p99, seltene Pfade.
Beispiele: Histogramm-Metriken speichern Links zu bestimmten 'trace _ id'.
Empfehlung: kombinieren - Kopf 5-20% + Tail-Regeln 100% für 5xx/timeout/p99.

5) Attribute und Taxonomie (Minimum erforderlich)

• `service. name`, `service. version`, `deployment. environment`, `cloud. region`, `http. route`, `http. method`, `http. status_code`, `db. system`, `db. statement'(verkürzt/keine Daten), 'messaging. system`, `messaging. operation`, `peer. service`, `net. peer. name`, `tenant. id`, `request. id`.

Business Labels: ordentlich, ohne PII. Beispiel: 'bestellen. segment`, `plan. tier`.

6) Asynchrone Skripte, Warteschlangen und Batches

PRODUCER → CONSUMER: Erstellen Sie einen Span PRODUCER mit Kontext; in der Nachricht - headers (traceparent, baggage). CONSUMER startet SERVER/CONSUMER-span mit Link zum PRODUCER (wenn keine strenge Hierarchie vorhanden ist).
Fan-Out: Ein Eintrag - viele Outputs → Child-Spans oder Links.
Batch: CONSUMER liest ein Bündel von N Nachrichten → einen Span mit 'events' für jede messageId oder 'links' für N separate Kontexte.
DLQ: separate span 'messaging. dlq. publish` с reason и count.
Retrays: 'event: retry' + 'retry. count '-Attribut; am besten ein neuer CHILD-Span pro Versuch.

7) Integration mit Protokollen und Metriken

Logs schreiben JSON mit 'trace _ id '/' span _ id' → aus dem Span gehen wir mit einem Klick in Logs.
Die RED/USE-Metriken enthalten Beispielwerte → von p99-Peaks gehen wir zu „schlechten“ Spans.
Die Tracks erzeugen über Ereignisse technische Signale (Abhängigkeitsfehler) und geschäftliche Signale (Conversion).

8) Leistung und Kosten

Sampling und Trottling von Ereignissen.
Reduktion der Kardinalität von Attributen (keine' user _ id '/' session _ id 'als Label!).
Komprimierung/Batching durch Exporteur; Exportzeitlimits.
Lagerung: heiße 1-7 Tage, weiter - Aggregate/nur „problematische“ Trails.
Kategorien von Ausgaben: Sammler, Indizes, Lagerung, egress.

9) Sicherheit und Privatsphäre

In Transit: TLS 1. 3/mTLS kollektor↔agenty; At Rest: Verschlüsselung, eigene Schlüssel (siehe „Verschlüsselung im Transit/At Rest“).
PII und Geheimnisse: Wir schreiben nicht in Attribute/Ereignisse; Tokenisierung/Maskierung auf dem Producer.
Multiarrangement: 'tenant. id 'als Ressourcenlabel und Isolation von Räumen, Leserichtlinien; Auditierung des Trail-Zugriffs (siehe „Auditing und unveränderliche Protokolle“).

10) Umsetzungsprogramme (Referenz)

10. 1 OpenTelemetry SDK (Pseudocode)

python from opentelemetry import trace from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. resources import Resource from opentelemetry. sdk. trace. export import BatchSpanProcessor from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10. 2 OTel Collector - tail sampling (Fragment)

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10. 3 Kafka - Kontexttransfer (Konzept)

PRODUZENT: Wir fügen die Köpfe' traceparent', 'baggage' hinzu.
CONSUMER: wenn die Nachricht einen neuen Thread initiiert - neuer SERVER/CONSUMER-Span c Link zum Kontext aus den Headern.

11) Data/ETL и ML

Für Batch-Pipelines: Span pro Batch/Partition mit 'dataset. urn`, `run. id`, `rows. in/out`, `freshness. lag`.
Für ML: Training/Inference Spans, Modellversion, Latenz, Feature Store.
Verbindung mit Lineage: 'run. id` и `dataset. urn 'ermöglichen den Übergang von der Trace zur Datenursprungsgraphen.

12) SLO der Tracing-Plattform

Verfügbarkeit ingestion: ≥ 99. 9%

Verzögerung bis zur Indexierung: ≤ 60 mit p95

Head-Sample-Abdeckung: ≥ 5-10% der Schlüsselrouten

100% Speichern von Trails mit ERROR-Status und mit Latenz> Schwelle nach Katalog „kritische Pfade“

Plattformen Alertas: Wachstum von Tropfen, Export-Timeouts, Indexer Lag, Überhitzung der Kardinalität.

13) Prüfung und Verifizierung

Trace-Vertrag in CI: das Vorhandensein von Spans auf den wichtigsten Endpoints, obligatorische Attribute, korrekte' traceparent 'fliegt durch das Gateway/Proxy.
Synthetic/Rum-Proben: Sammeln Sie Trails von außen.
Chaos/Incidents: Abhängigkeiten deaktivieren, überprüfen, ob der Tail-Sampler Fehler „aufnimmt“.
Rauch in der Produktion: nach der Veröffentlichung - „gibt es Spans“ und exemplar → trace.

14) Checklisten

Vor dem Verkauf

• Der W3C Trace Context wird überall rollen; für Nachrichten - headers.
• Basic Head Sampling enthalten; tail-Regeln für 5xx/p99 sind konfiguriert.
• Erforderliche Attribute: route, method, status, service. version, tenant. id.
• JSON-Logs mit 'trace _ id '/' span _ id', Metriken mit Beispielen.
• PII-Desinfektionsmittel; Verschlüsselung unterwegs/im Ruhezustand; Zugriffsrichtlinien.
• Dashboards: „kritischer Weg“, „Abhängigkeitsfehler“, „Retrays/Timeouts“.

Betrieb

• Monatliche Überprüfung der Kardinalität der Attribute; Quoten.
• SLO-Tail-Sampling-Tuning (weniger Rauschen, alles „heiß“ - in der Stichprobe).
• RCA-Training mit Metrikübergang → Beispiel → Trace → Logs.
• Überprüfung von Abdeckungen für Warteschlangen, DLQ, ETL-Jobs.

15) Runbook’и

RCA: Wachstum von p99 auf/pay

1. RED-Dashboard öffnen; von bin p99 über exemplar nach treis.
2. Suchen Sie den „schmalen“ CLIENT-Span (z.B. 'gateway. call'), check 'retry. count', Timeouts.
3. Dienst-/Abhängigkeitsversionen, Region/Zone vergleichen.
4. Aktivieren Sie die Degradierung (zwischengespeicherte Antwort/RPS-Limit), benachrichtigen Sie die Besitzer der Abhängigkeit.
5. Nach dem Fix - RCA und Tickets zur Optimierung.

DLQ-Anstieg

1. Filter Tracks durch 'messaging. dlq. publish`.
2. Überprüfen Sie die Ursachen (Ereignisse), korrelieren Sie mit der Freigabe.
3. Starten Sie reprocess, erhöhen Sie vorübergehend den Timeout bei CONSUMER, benachrichtigen Sie Downstream-Besitzer.

16) Häufige Fehler

Es gibt keine Kontextualisierung durch Gateways/Broker. Lösung: Middleware/Interseptoren, einheitliche Bibliotheken.
Alle Trails sind 100%. Teuer und sinnlos - verwenden Sie Tail-Sampling.
Logs ohne' trace _ id'. Die Korrelation → MTTR ↑ geht verloren.
PII in Attributen. Maskieren/Tokenisieren; Speichern Sie nur den technischen Kontext.
„Stumme“ Hintergrundjobs. Fügen Sie Spans zu batch/partition und 'run hinzu. id`.
Die Verschiedenheit der Benennung. Geben Sie ein Wörterbuch mit Spannamen und Attributschlüsseln ein.

17) FAQ

F: Ist Head oder Tail Sampling besser?
A: Die Kombination. Der Kopf gibt die Basisschicht, tail garantiert die Erhaltung von Anomalien/Fehlern.

F: Wie verfolge ich Kafka ohne starre Hierarchie?
A: Verwenden Sie Span-Links zwischen PRODUZENT und VERBRAUCHER; Kontext - in den Köpfen.

F: Was tun mit sensiblen SQL?
A: 'db. statement 'verkürzt/normalisiert (keine Werte) oder' db. operation'+ Maße/Zeit.

F: Wie verknüpfe ich mit Geschäftskennzahlen?
A: Fügen Sie Domänenattribute ohne PII (Plan/Segment) hinzu, verwenden Sie „Geschäftsphasen“ -Ereignisse innerhalb des Spans und wechseln Sie von Konversionsmetriken zu exemplar.

• „Beobachtbarkeit: Protokolle, Metriken, Traces“
• „Audit und unveränderliche Protokolle“
• „Verschlüsselung in Transit/At Rest“
• „Herkunft der Daten (Lineage)“
• «Privacy by Design (GDPR)»
• „Management von Geheimnissen“