Einführung in OpenTelemetry

Wenn Logs, Metriken und Traces getrennt entstehen, bleibt der Weg einer Anfrage unsichtbar. An einer vorbereiteten Anwendung ordnen Sie API, SDK, Instrumentierungsbibliotheken, OTLP, Collector und Backends in einen gemeinsamen Datenfluss ein. Eine Architekturkarte zeigt anschließend, wo Telemetrie erzeugt, verarbeitet, gespeichert und in Grafana dargestellt wird und welche Verantwortung bei Entwicklung oder Plattform liegt.

Automatische Instrumentierung liefert schnell technische Spans, doch Umfang und Qualität unterscheiden sich je nach Sprache und Framework. In Ihrem gewählten Track aktivieren Sie den passenden Mechanismus, senden denselben HTTP-Request und prüfen Service-Name, Dauer, Status und Parent-Child-Beziehungen. Der Vergleich mit dem unbeobachteten Ausgangszustand ergibt eine belastbare Basis, auf der gezielte Codeänderungen aufbauen.

Ein automatisch erzeugter HTTP-Span erklärt noch nicht, warum ein Bestellschritt fehlschlägt. Sie ergänzen einen fachlichen Span, ein Event und ausgewählte Attribute im Anwendungscode und prüfen, wie API, SDK und Instrumentation Scope zusammenspielen. Die resultierende Trace-Ansicht beantwortet eine konkrete Diagnosefrage, ohne Kundendaten oder ungebremste Identifikatoren in die Telemetrie aufzunehmen.

Ein Trace zerfällt, sobald ein Service den eingehenden Kontext nicht übernimmt oder beim ausgehenden Aufruf nicht weitergibt. Sie verfolgen einen Request über mehrere Services, prüfen den W3C Trace Context und reparieren eine unterbrochene Parent-Child-Beziehung. Danach grenzen Sie Baggage von Span-Attributen ab. Der vollständige Trace bestätigt, dass Ursache und Dauer über alle Servicegrenzen erhalten bleiben.

Traces erklären einzelne Requests, Metriken zeigen Muster und Logs liefern Ereignisdetails. Für denselben Fehler ergänzen Sie eine Metrik mit kontrollierter Kardinalität und verbinden strukturierte Logs über Trace- und Span-ID mit dem Request. Über einen vorbereiteten Referenzpfad, Exemplars und provisionierte Grafana-Korrelationen grenzen Sie passende Traces und Logs ein. Alle drei Belege müssen auf dieselbe Ursache zeigen.

Uneinheitliche Service-Namen und ungebremste Attribute machen Telemetrie teuer und schwer vergleichbar. Sie setzen Resources, Instrumentation Scope und passende Semantic Conventions ein, ersetzen ein hochkardinales Attribut durch eine Dimension mit begrenztem Wertebereich und vermeiden ein sensibles Feld bereits an der Quelle. Anschließend konfigurieren Sie Head Sampling und dokumentieren dessen blinde Flecken; Tail Sampling bleibt eine spätere Architekturentscheidung.

Kubernetes sammelt Anwendungstelemetrie nicht automatisch. Sie deployen den instrumentierten Service als Deployment, setzen OTLP-Endpoint, Protokoll und Resource-Attribute über die Workload-Konfiguration und senden einen Request durch einen Service an die vorbereitete Referenz-Pipeline. Collector-Ausgabe und Trace bestätigen, dass Anwendung und Netzwerkziel zusammenpassen. So wird sichtbar, was in Kubernetes läuft und was erst im Backend gespeichert wird.

Ein Collector kann als Sidecar, Agent pro Node oder zentraler Gateway-Dienst laufen. Sie vergleichen diese Muster nach Nähe zur Quelle, Netzwerkpfad, Kubernetes-Anreicherung und Betriebsverantwortung und zeichnen den Weg der Beispielanwendung ein. Für das Labor wählen Sie einen versionsgebundenen Gateway-Pfad. Eine Entscheidungsmatrix hält fest, wann Entwicklung selbst konfigurieren kann und wann die Plattform übernehmen muss.

Eine Collector-Konfiguration verarbeitet nur Komponenten, die im Service-Block zu Pipelines verbunden sind. Aus einem Gerüst bauen Sie getrennte Wege für Traces, Metriken und Logs mit OTLP Receiver, ausgewählten Processors und Debug Exporter. otelcol validate, Testdaten und versionsgebundene interne Metriken belegen, dass jede Pipeline startet, Daten annimmt und keine Signalart unbemerkt verwirft.

Ohne Workload-Kontext bleiben identische Service-Namen aus mehreren Namespaces schwer unterscheidbar. Mit vorbereiteten Berechtigungen und einer per Downward API gesetzten Pod-UID reichert der Collector Signale um Namespace, Pod und Deployment an. Danach filtern Sie einen unerwünschten Datensatz, entfernen ein verbliebenes sensibles Attribut und ordnen Memory Limiter sowie Batching sinnvoll ein. Der Vergleich zeigt suchbaren Kontext ohne vertrauliche Werte.

OpenTelemetry speichert Telemetrie nicht dauerhaft. Sie ersetzen den Referenzexport durch Ihre Collector-Pipelines, verbinden diese über versionsgebundene Endpoints mit Tempo, Prometheus und Loki und senden einen Referenz-Request. In Tempo prüfen Sie den Trace, in Prometheus die Metrik und in Loki das Log. Vorbereitete Attributabbildungen halten ausgewählte Service- und Korrelationsmerkmale auffindbar; eine Checkliste bestätigt den vollständigen Export.

Rohdaten beantworten noch nicht, ob ein Service langsamer, fehlerhafter oder stärker ausgelastet wird. Aus versionsgebundenen HTTP-Metriken und vorbereiteten Abfragen bauen Sie in Grafana ein Dashboard für Request-Rate, Fehleranteil und Latenz. Anschließend binden Sie vorbereitete Exemplar- und Datenquellen-Korrelationen ein, um passende Traces und Logs einzugrenzen. Das Ergebnis entsteht ohne PromQL- oder LogQL-Deep-Dive.

Ein Gateway oder Sidecar ersetzt keine saubere Context Propagation in der Anwendung. Über eine vorbereitete, mit Gateway API konfigurierte Istio-Route samt OpenTelemetry-Provider und festgelegtem Sampling vergleichen Sie direkte und vermittelte Requests, prüfen traceparent und reparieren fehlende Weitergabe. Ein Trace über Edge, Proxies und Services belegt die Korrektur. Routing, mTLS und Mesh-Betrieb vertieft der Service Mesh Workshop.

Ein langsames oder nicht erreichbares Backend darf Datenverlust nicht unbemerkt lassen. Während einer vorbereiteten Störung beobachten Sie Queue, Retries, Backpressure und interne Collector-Metriken, unterscheiden temporäre von dauerhaften Fehlern und korrigieren Endpoint oder Pipeline. Debug-Ausgabe und wieder ankommende Signale bestätigen die Erholung. Dabei wird klar, warum auch persistente Queues keine absolute Zustellgarantie bieten.

Das Abschluss-Szenario zeigt erhöhte Latenz und zugleich eine Lücke im Telemetriepfad. Mit Dashboard, Trace, korreliertem Log, Collector-Debug-Ausgabe und internen Metriken trennen Sie Anwendungsfehler von Beobachtungsfehlern, beheben beide Ursachen und wiederholen den Referenz-Request. Normale Servicewerte und drei verbundene Signale belegen den Erfolg; ein Runbook und eine Transfer-Checkliste sichern das Vorgehen für Ihr Team.