# Jäger: Distributed Tracing für Microservices & Cloud-Stacks

TL;DR / Management Summary In einer Microservice-Umgebung (Docker/Kubernetes) ist ein einzelner HTTP-Request oft an 10 verschiedenen Containern beteiligt. Wenn die Antwort langsam ist, sagen Logs (ELK) und Metriken (Prometheus) oft nicht aus, welcher dieser 10 Container schuld ist. Jäger implementiert Distributed Tracing: Jede Anfrage bekommt eine eindeutige ID (Trace ID) und wird durch den gesamten Stack verfolgt. Ein Senior Admin nutzt Jäger, um Latenzen auf Millisekunden-Ebene zu visualisieren und “Bottleneck-Services” sofort zu identifizieren.

# 1. Was ist Distributed Tracing?

Die Reise eines Pakets.

Ein Trace besteht aus mehreren Spans (Zeitspannen):

• Trace: Die gesamte Transaktion (z.B. “Benutzer bestellt Produkt”).
• Span: Ein einzelner Arbeitsschritt (z.B. “Suche in Datenbank”, “Prüfe Kreditkarte”).
• Context Propagation: Die Trace-ID wird in den HTTP-Headern von einem Service zum nächsten gereicht.

# 2. Die Komponenten von Jäger

Vom Agent zum Collector.

1. Jäger Agent: Ein kleiner Sidecar-Prozess (Artikel 812), der die Spans von der Applikation via UDP entgegennimmt.
2. Collector: Empfängt die Traces von den Agenten und schreibt sie in eine Datenbank (Elasticsearch oder Cassandra).
3. Query & UI: Die Web-Oberfläche zur Visualisierung der Traces als Gantt-Chart.

# 3. Deep Dive: OpenTelemetry (OTel)

Der moderne Standard.

Jäger ist heute Teil der OpenTelemetry Initiative.

• Konzept: Sie instrumentieren Ihre Applikation mit dem OTel-SDK.
• Vorteil: Sie können den Tracing-Provider (Jäger, Honeycomb, Datadog) jederzeit wechseln, ohne den Code der Applikation ändern zu müssen.

# 4. Day-2 Operations: Sampling-Strategien

Datenflut vermeiden.

Tracing erzeugt enorme Datenmengen.

• Probabilistic Sampling: Sichert nur z.B. 1% aller Anfragen. (Standard für Produktion).
• Adaptive Sampling: Jäger erkennt automatisch Lastspitzen und passt die Rate an.
• Tail-based Sampling: Nur “interessante” Traces (z.B. Fehler oder langsame Anfragen > 2s) werden dauerhaft gespeichert.

# 5. Troubleshooting & “War Stories”

Wenn der Pfad im Dunkeln liegt.

# Top 3 Fehlerbilder

1. Symptom: “Broken Trace”. Die Kette bricht nach dem ersten Service ab.

   • Ursache: Die Applikation reicht die trace-id Header nicht an den nächsten Service weiter.
   • Lösung: OTel-Middleware in der Applikation prüfen.

2. Symptom: Jäger Collector überlastet.

   • Ursache: Zu hohe Sampling-Rate in einem High-Traffic Cluster.
   • Fix: UDP-Buffer am Host erhöhen oder Sampling auf 0.1% senken.

3. Symptom: Keine Daten in der UI.

   • Lösung: Prüfen, ob die Firewall Port 14268 (HTTP) oder 6831 (UDP) blockiert.

# “War Story”: Der “Geister-Wait” in der Cloud

Ein Admin untersuchte eine Latenz von 500ms in einem K8s-Cluster. Prometheus zeigte normale CPU-Werte. ELK zeigte keine Fehler. Die Entdeckung via Jäger: Im Gantt-Chart sah der Admin eine Lücke von 450ms zwischen dem Frontend und dem Auth-Service. In dieser Zeit passierte scheinbar gar nichts. Die Ursache: Ein fehlerhafter DNS-Resolver im Kubernetes-VNet (Artikel 774) versuchte erst IPv6 (Timeout), bevor er auf IPv4 zurückfiel. Lehre: Metriken zeigen, dass es langsam ist. Tracing zeigt, wo genau die Zeit verschwendet wird – auch wenn kein Code ausgeführt wird.

# 6. Monitoring & Reporting

Service-Qualität.

# Service Dependency Graph

Jäger generiert automatisch eine Landkarte Ihrer Applikation:

• Wer spricht mit wem?
• Wie hoch ist die Fehlerrate pro Verbindung?

# 7. Fazit & Empfehlung

Jäger ist das ultimative Werkzeug für die Performance-Analyse in komplexen Systemen.

• Empfehlung: Nutzen Sie Jäger, sobald Ihre Applikation aus mehr als 3 Microservices besteht.
• Wichtig: Verwenden Sie Elasticsearch als Storage-Backend für Jäger (Artikel 819), da Sie so die mächtigen Analyse-Funktionen für beide Welten (Logs und Traces) kombinieren können.

# Anhang: Cheatsheet (Jäger Ports)

# Referenzen

• Jäger Tracing Official Website
• OpenTelemetry Documentation
• Distributed Tracing in a Nutshell (Blog)