Begriff

OpenTelemetry (OTel)

Observability Standards S2

2 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Früher war Monitoring ein Chaos. Für Logs nahmst du "Log4j". Für Metriken "Prometheus Client". Für Tracing "Jaeger Agent". Jede Library sprach eine andere Sprache. Wenn du das Tool wechseln wolltest, musstest du deinen Code umschreiben. OpenTelemetry beendet das Chaos. Es ist ein Standard (wie USB). Du baust OTel in deine App ein ("Sende Daten"). OTel kümmert sich darum, wohin die Daten gehen (zu Prometheus, zu Datadog, zu NewRelic). Es vereint Logs, Metrics und Traces in einem einzigen SDK.

Merksatz: Ein CNCF-Framework, das Standards, Bibliotheken und Agenten bereitstellt, um Telemetriedaten (Logs, Metriken, Traces) herstellerunabhängig zu sammeln und zu exportieren.

Auto-Instrumentation: In Java oder Node.js startest du deine App mit einem Agenten: java -javaagent:opentelemetry-javaagent.jar -jar myapp.jar Du musst keine einzige Zeile Code ändern! Der Agent sieht automatisch HTTP Requests und DB Queries und sendet sie.
Collector: Die Daten gehen meist an einen OTel Collector (ein kleiner Server). Der Collector verteilt sie: "Metriken an Prometheus, Traces an Jaeger".

Praxisroutine

In der Praxis lernst du OpenTelemetry (OTel), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Context Propagation (Baggage)

Wie weiß Service B, dass der Request von Service A (User X) kommt? OTel injiziert HTTP Header (traceparent). Service B liest diese Header und führt den Trace fort. Zusätzlich gibt es Baggage: Key-Value Paare, die mitreisen. baggage: premium-user=true. Service C (ganz hinten) kann das lesen und den DB-Query priorisieren, ohne dass Service A und B den Code ändern mussten. Die Metadaten "fliegen einfach mit".

2. Sampling Strategien

Du kannst nicht 100% aller Traces speichern (zu teuer bei 10k Requests/s).

Head-Sampling: Entscheidung am Anfang (Service A). "Trace 1 ja, Trace 2 nein". Schnell, aber man verpasst Fehler in Service C.
Tail-Sampling: Entscheidung am Ende (im Collector). "Sammle alle Teile. War ein Fehler dabei? Ja -> Speichern. Nein -> Verwerfen." Teurer (RAM Buffer), aber man erwischt jeden Fehler.

3. Vendor Lock-in Exit

OTel ist der Albtraum für kommerzielle Anbieter (Datadog/NewRelic). Früher warst du an deren Agenten gebunden. Heute nutzt du OTel. Wenn Datadog zu teuer wird, änderst du eine Zeile im OTel Collector Config (exporters: [prometheus]) und bist weg. Deine App muss nicht neu deployt werden.

Trace Context (W3C vs B3)

Damit ein Trace ("#4F3A") über Netzwerk-Grenzen hinweg am Leben bleibt, injiziert und extrahiert OTel definierte HTTP-Header. Früher kochte hier jeder sein eigenes Süppchen (Zipkin nutzte B3-Header X-B3-TraceId, Jaeger nutzte uber-trace-id). OTel pusht radikal den standardisierten W3C Trace Context. Ein Header sieht so aus: traceparent: 00-4bf92f...-00f067...-01. Er enthält die Version, die extrem wichtige Trace-ID (für den gesamten Pfad), die Parent-Span-ID (für den konkreten Aufrufer) und Flags (z.B. ob dieser Trace gesampelt, also gespeichert werden soll). Wenn dein Backend diesen Header per Middleware nicht aktiv weiterreicht, "bricht" der Trace in zwei isolierte Hälften.

Der OTel Collector Pipeline-Mechanismus

Der OTel Collector ist kein stumpfer Router, er ist eine komplexe Data-Pipeline (Receiver -> Processor -> Exporter). Gerade der Processor ist in Production elementar. Er betreibt Batching (Sammelt 10k Spans und sendet sie gebündelt alle 5 Sekunden), Memory-Limiting (Wirft Spans weg, bevor der OTel Collector an OOM stirbt) und "PII Redaction". Wenn ein Entwickler versehentlich Kreditkarten in Logs pumpt, fängt eine Regex-Regel im Processor das ab und maskiert es (XXXX-XXXX), bevor es Datadog oder Jaeger berührt.

Probabilistic vs. Tail-Based Sampling

OTel generiert bei High-Traffic rasend schnell Terabytes an Logs. Beim Head-Based / Probabilistic Sampling wirft der Agent direkt an der Quelle (z.B. im Load Balancer) per Zufallswert 95% der Requests unwiderruflich weg (Drop). Das ist billig, aber du verlierst genau die 1% Error-Requests, die nachts gekracht sind! Enterprise-Lösungen nutzen Tail-Based Sampling. Jeder Span fließt zum OTel Collector. Der Collector ist ein gigantischer Ring-Buffer im RAM. Er wartet das Ende der Transaktion ab. Ist der HTTP-Status 200, wirft er den Trace in den Müll. Ist der Status 500 (Error) oder sehr langsam (>2s), pickt er alle Fragmente aus dem RAM zusammen und exportiert sie. Man sammelt also selektiv "Nadeln", ohne den Heuhaufen zu bezahlen.

Quick-Check

Ersetzt OTel Prometheus?
Nein. OTel erzeugt und sammelt die Daten. Prometheus speichert sie. OTel ist der Lieferant, Prometheus das Lager. OTel hat kein eigenes Backend/UI.
Was ist W3C Trace Context?
Der Standard Header (traceparent), den OTel nutzt. Früher hatte Zipkin X-B3-TraceId, Google hatte andere. Jetzt verstehen sich alle Tools dank W3C Standard.
Logs in OTel?
Noch in "Beta/Stable". OTel versucht, Logs zu strukturieren und mit Traces zu verknüpfen ("Zeige mir die Logs genau für diesen Request"). Das ist mächtiger als reine Textsuche.