Beobachtbarkeit: Protokolle, Metriken, Traces

Beobachtbarkeit: Protokolle, Metriken, Traces

1) Warum es notwendig ist

• Metriken sind kompakte Aggregate für SLI/SLO und Symptom-Alerting.
• Traces - Ursache-Wirkungs-Ketten von Anfragen (End-to-End).
• Protokolle - detaillierte Ereignisse für Untersuchungen und Audits.

Das Ziel: schnelle RCA, präventive Alerts und überschaubare Zuverlässigkeit im Rahmen des Error Budgets.

2) Prinzipien der Architektur

Einheitlicher Kontext: Wir blättern überall durch 'trace _ id', 'span _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash'.
Standards: OpenTelemetry (OTel) für SDK/Agenten, JSON-Logformat (kanonisch, mit Schema).
Symptome> Ursachen: Alertim nach Benutzersymptomen (Latenz/Fehler), nicht nach CPU.
Signalkommunikation: Von der Metrik → in Spans (Beispiele) → in spezifische Protokolle durch „trace _ id“.
Sicherheit und Privatsphäre: PII-Maskierung in Protokollen, Verschlüsselung in Transit/at Rest, unveränderliche Protokolle für Audits.
Multiarrangement: Trennung von Namespaces/Schlüsseln/Richtlinien.

3) Taxonomie von Signalen und Schaltungen

3. 1 Metriken

RED (Rate, Errors, Duration) für Dienste und USE (Utilization, Saturation, Errors) für Infrastruktur.
Типы: counter, gauge, histogram/summary. Für Latenz - Histogramm mit festen bucket 'ami.
Beispiele: Verweis auf 'trace _ id' in den 'hot' -Bins des Histogramms.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 Traces

Spahn = Operation mit 'name', 'start/end', 'attributes', 'events', 'status'.
W3C Trace Context für Portabilität.
Sampling: basic (head) + dynamic (tail) + Regeln der „Wichtigkeit“ (Fehler, hohe p95).

3. 3 Protokolle

Nur strukturiertes JSON; Ebenen: DEBUG/INFO/WARN/ERROR.
Erforderliche Felder: 'ts _ utc', 'level', 'message', 'trace _ id', 'span _ id', 'tenant _ id', 'env', 'service', 'region', 'host', 'labels {}'.
Verboten: Geheimnisse, Token, PAN, Passwörter. PII - nur tokenisiert/maskiert.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) Sammlung und Transport

Agenten/Exporteure (Daemonset/Sidecar) → einen Puffer auf dem Knoten → Bus/Ingest (TLS/mTLS) → Signalspeicher.
Anforderungen: Backpressure, Retrays, Deduplizierung, Kardinalitätsbegrenzung (Labels!), Schutz vor „Log-Stürmen“.

Metriken: Pull (Prometheus-kompatibel) oder Push über OTLP.
Traces: OTLP/HTTP (gRPC), Tail-Sampler auf dem Kollektor.
Logs: lokale Sammlung (journald/docker/stdout) → Parser → Normalisator.

5) Lagerung und Retention (tiered)

Metriken: heiße TSDB 7-30 Tage (mit Downsample), Aggregate für einen längeren Zeitraum (90-365 Tage).
Traces: 1-7 Tage voll, dann Aggregats/Spans von „wichtigen“ Dienstleistungen; Indizes durch 'service', 'status', 'error' speichern.
Protokolle: heißer Index 7-14 Tage, warm 3-6 Monate, Archiv bis 1-7 Jahre (Einhaltung). Das Audit ist WORM.

Kostenoptimierung: Downsampling, DEBUG-Filterung in der Produktion, Label-Quoten, Sampling für Tracks.

6) SLI/SLO, Alarmierung und Bereitschaftsdienst

SLI: Verfügbarkeit (% der erfolgreichen Abfragen), Latenz (p95/p99), 5xx-Anteil, Frische der Daten, Anteil der erfolgreichen Jobs.
SLO: Ziel auf SLI (z.B. 99. 9% erfolgreich ≤ 400 ms).
Error budget: 0. 1% „Recht auf Fehler“ → Regeln fichfriz/Experimente.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Siloalerts (CPU/Disk) - nur als Hilfsmittel, ohne Paging.

7) Korrelation der Signale

Die Metrik „rot“ → klicken Sie auf das Beispiel → das spezifische „trace _ id“ → schauen Sie sich den „langsamen“ Span an → öffnen Sie die Protokolle für das gleiche „trace _ id“.
Korrelation mit Releases: Attribute' version', 'image _ sha', 'feature _ flag'.
Für Daten/ETL: 'dataset _ urn',' run _ id', Kommunikation mit Lineage (siehe entsprechenden Artikel).

8) Sampling und Kardinalität

Metriken: limitieren Labels (ohne' user _ id', 'session _ id'); Quoten/Validierung bei der Registrierung.
Traces: Wir kombinieren Head-Sample (am Eingang) und Tail-Sample (am Kollektor) mit den Regeln: „alles was 5xx, p99, Fehler - 100%“.
Protokolle: Pegel und Drosselung; für häufige wiederkehrende Fehler - Aggregationsereignisse (dedupe-Schlüssel).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) Sicherheit und Privatsphäre

In Transit/At Rest: Verschlüsselung (TLS 1. 3, AEAD, KMS/HSM).
PII/Secrets: Desinfektionsmittel vor dem Versand, Tokenisierung, Maskierung.
Zugang: ABAC/RBAC zu lesen; Rollenaufteilung Producer/Reader/Admins.
Audit: unveränderliches Log des Zugriffs auf Protokolle/Tracks; Export - in verschlüsselter Form.
Multiarrangement: namespaces/tenant-labels mit Policies; Verschlüsselungsschlüsselisolierung.

10) Konfigurationsprofile (Fragmente)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) Daten/ETL und Streaming

SLI für Daten: Frische (max lag), Vollständigkeit (rows vs expectation), „Qualität“ (Validatoren/Duplikate).
Alertas: Fenster überspringen, Konsument lag, DLQ Wachstum.
Korrelation: 'run _ id', 'dataset _ urn', lineare Ereignisse; Traces für Piplines (span pro batch/partition).
Kafka/NATS: Metriken Produzent/Consumer, Lag/Opt-out; Verfolgungen durch Header (einschließlich 'traceparent').

12) Profilierung und eBPF (Zusatzsignal)

CPU/alloc/IO Low-Level-Hot-Pfade; Profile pro Vorfall.
eBPF-Telemetrie (Netzwerklatenz, DNS, Systemaufrufe) mit Bezug auf 'trace _ id '/PID.

13) Prüfung der Beobachtbarkeit

Signal Contract: Überprüfung des Exports von Metriken/Labels/Histogrammen nach CI.
Synthetische Proben: RUM-Skripte/simulierte Clients für externe SLIs.
Chaos/Feuerbohrer: Abschaltungen von Abhängigkeiten, Degradierung - wir sehen, wie Alerts und Diensthabende reagieren.
Rauch in der Produktion: Post-Deploy-Check, dass neue Endpunkte Metriken und Traces haben.

14) Kosten- und Mengensteuerung

Budgets nach Signal/Befehl; Dashboard „Kosten pro Signal“.
Kardinalität unter dem Budget (SLO nach cardinality), Grenzen für neue Labels.
Downsampling, Retreats nach Datenklasse, Cold Archive und WORM für das Audit.

15) Betrieb und SLO der Beobachtungsplattform

Plattform SLO: 99. 9% erfolgreiche Ingests; Verzögerung bis zum Index der Metriken ≤ 30 s, Protokolle ≤ 2 min, Spuren ≤ 1 min.
Plattform-Alerts: Injection-Lag, Drops-Wachstum, Signatur-/Verschlüsselungsfehler, Pufferüberlauf.
DR/HA: Multiple Zone, Replikation, Config/Rule Backups.

16) Checklisten

• Überall wird 'trace _ id '/' span _ id' gerollt; JSON-Logs mit Schaltung.
• RED/USE-Metrik mit Histogrammen; exemplar → der Strecke.
• Tail-Sampling enthalten; Regeln 5xx/p99 = 100%.
• Alerts durch Symptome + Runibuki; stille Uhr/Anti-Flap.
• PII-Desinfektionsmittel; Verschlüsselung bei Rest/in Transit; WORM für Audit.
• Rückstellungen und Budgets für Volumen/Kardinalität.

• Monatliche Überprüfung der Warnhinweise (Rauschen/Genauigkeit), Tuning der Schwellen.
• Error budget report und ergriffene Maßnahmen (fichfriz, hardening).
• Überprüfung der Dashboard-/Log-/Track-Abdeckungen für kritische Pfade.
• Trainingsvorfälle und Runbook-Updates.

17) Runbook’и

RCA: Wachstum von p99/pay

1. Öffnen Sie das Dashboard RED für 'checkout'.
2. Gehen Sie auf exemplar → eine langsame Spur → offenbaren eine „schmale span“ (z.B., 'gateway. call`).
3. Öffnen Sie die Protokolle durch 'trace _ id' → sehen Sie die Timeouts/Retrays.
4. Aktivieren Sie das Rollback-Flag/RPS-Limit, benachrichtigen Sie die Besitzer der Abhängigkeit.
5. Nach Stabilisierung - RCA, Optimierungstickets, Playback-Test.

1. SLI „Frische“ Rot → der Bahn → Joba Failing Schritt.

2. Überprüfen Sie Broker Lag/DLQ, Konnektorfehler.

3. Reprocess starten, Verbraucher (BI/Produkt) über den Status Channel benachrichtigen.

18) Häufige Fehler

Logs ohne Schema und ohne' trace _ id'. Die Ermittlungen ziehen sich zeitweise hin.
Alerts auf Infrastruktur statt Symptome. Paging geht „in die Milch“.
Die grenzenlose Kardinalität der Metriken. Kostenexplosion und Instabilität.
Alle Strecken sind 100%. Teuer und unnötig; Aktivieren Sie Smart Sampling.
PII/Geheimnisse in den Protokollen. Schließen Sie Desinfektionsmittel und „rote Listen“ ein.
„Stumme“ Fichi. Neuer Code ohne Metriken/Tracks/Logs.

19) FAQ

F: Muss ich den Rohtext der Protokolle speichern?
A: Ja, aber mit Retention und Archiven; für Alert und SLO gibt es genügend Aggregate. Die Prüfung erfolgt in WORM.

F: Was soll ich für die Trails wählen - Head oder Tail Sampling?
A: Kombinieren Sie: Kopf-probabilistisch für Basisabdeckung + Rückzugsregeln für Fehler und Anomalien.

F: Wie kann ich benutzerdefinierte Metriken und technische Metriken verknüpfen?
A: Durch generische' trace _ id 'und Business Labels (' route', 'tenant', 'plan') sowie durch Produktereignisse (Conversions) mit Korrelation zu den Tracks.

F: Wie kann man nicht in Alert ertrinken?
A: Schlagen Sie nach Symptomen, geben Sie stille Stunden, Deduplizierung, Gruppierung, SLO-Priorisierung und Besitzer-Standard für jede Alert ein.

• „Audit und unveränderliche Protokolle“
• „Verschlüsselung in Transit/At Rest“
• „Management von Geheimnissen“
• „Herkunft der Daten (Lineage)“
• «Privacy by Design (GDPR)»
• „Garantien für die Lieferung von Webhooks“