議論： Logs, Metriken und Traces: welches Signal welche Frage beantwortet

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

翻訳がないため、原文を表示しています。 原文

Drei Details zur Weitergabe und zur Stichprobe. Das Format der «Header», über die die Trace-Kennung wandert, ist W3C Trace Context: `traceparent: 00-<trace-id, 32 Hexzeichen>-<parent-id, 16 Hexzeichen>-<flags>` plus `tracestate`; die OpenTelemetry-SDKs nutzen standardmässig die Propagatoren `tracecontext` und `baggage`, und ein Proxy oder ein Message-Broker, der diese Header nicht durchreicht, ist die häufigste Stelle, an der «der Trace an der ersten Dienstgrenze endet». Die im Artikel beschriebene Entscheidung «nach Abschluss» heisst im Collector Tail Sampling (`tailsamplingprocessor` aus opentelemetry-collector-contrib); sie setzt voraus, dass alle Spans eines Traces bei derselben Collector-Instanz landen, weshalb vor mehrere Collectors ein nach Trace-ID routender `loadbalancingexporter` gehört, und sie hält Spans für die Dauer von `decision_wait` im Speicher – die Stichprobe ist also nicht gratis, sondern kostet RAM proportional zum Aufkommen. Exemplars schliessen die Lücke zwischen Metrik und Trace: Ein Histogramm-Bucket kann die Trace-ID einer Beispielmessung mitführen, sodass der Sprung vom Alarm zur Beispielanfrage ohne Suche gelingt. OpenTelemetry führt inzwischen ein viertes Signal, Profiles, als experimentelles OTLP-Signal.