Distributed Tracing ist ein unverzichtbares Werkzeug, um Microservices-Architekturen transparent zu überwachen. Durch das Verfolgen von Anfragen über mehrere Services hinweg lassen sich Latenzen identifizieren, Fehlerquellen analysieren und Performance-Engpässe aufdecken. In diesem Tutorial zeigen wir praxisnah, wie Context Propagation und Sampling in Container-Umgebungen mit Docker Compose implementiert werden können.
1. Grundlagen des Distributed Tracing
Distributed Tracing verfolgt die Ausführung einer Anfrage über mehrere Services hinweg. Jede Anfrage wird durch einen eindeutigen Trace-Identifier markiert, und jeder Schritt innerhalb eines Services wird als Span aufgezeichnet.
Wichtige Begriffe
- Trace: Gesamter Ablauf einer Anfrage über alle beteiligten Services
- Span: Einzelner Arbeitsschritt innerhalb eines Services
- Context Propagation: Weitergabe von Trace-IDs zwischen Services
- Sampling: Auswahl von Traces, die tatsächlich aufgezeichnet werden, um Overhead zu reduzieren
2. OpenTelemetry Collector als zentrale Komponente
Der OpenTelemetry Collector dient als zentraler Aggregator für Traces, Metriken und Logs. Er kann konfiguriert werden, um Daten von mehreren Services zu empfangen und an Backends wie Jaeger oder Grafana Tempo weiterzuleiten.
services:
otel-collector:
image: otel/opentelemetry-collector:latest
container_name: otel-collector
volumes:
- ./otel-config.yaml:/etc/otel/config.yaml:ro
command: ["--config=/etc/otel/config.yaml"]
ports:
- "4317:4317" # OTLP gRPC
- "55681:55681" # OTLP HTTP
networks:
- tracing
Konfigurationshinweise
- OTLP gRPC Port für Microservices
- Readonly-Mounts für Konfiguration
- Netzwerk-Isolation über eigenes Compose-Netzwerk
3. Service Instrumentierung
Jeder Microservice muss Traces erzeugen und die Context Propagation unterstützen. Das bedeutet, dass Trace-IDs bei HTTP/gRPC Aufrufen an nachgelagerte Services übergeben werden.
# Beispiel in Python mit OpenTelemetry SDK
from opentelemetry import trace
from opentelemetry.instrumentation.requests import RequestsInstrumentor
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)
RequestsInstrumentor().instrument()
with tracer.start_as_current_span("process_request"):
response = requests.get("http://service-b:8080/data")
Wichtige Punkte
- Instrumentierung für HTTP/gRPC nötig
- Automatische Context Propagation durch OpenTelemetry
- Manuelle Spans für kritische Operationen möglich
4. Sampling Strategien
Sampling steuert, welche Traces tatsächlich aufgezeichnet werden. Typische Strategien sind:
- Always On – alle Traces werden erfasst
- Probabilistic – eine bestimmte Quote, z.B. 10% aller Traces
- Rate Limiting – maximal N Traces pro Sekunde
- Tail-Based Sampling – Auswahl basierend auf Fehlern oder Latenzen
processors:
batch:
tail_sampling:
decision_wait: 30s
policies:
- name: error_only
type: status_code
status_codes: [500, 503]
Tipps
- Sampling reduzieren Overhead und Speicherbedarf
- Fehlerbehaftete Requests immer erfassen
- Sampling-Policy regelmäßig an Workload anpassen
5. Netzwerk-Setup in Compose
Alle Services werden in ein eigenes Netzwerk tracing gelegt, um interne Kommunikation zu ermöglichen und externe Ports nur gezielt zu öffnen.
networks:
tracing:
- Microservices senden Traces an
otel-collector:4317 - Backends wie Jaeger oder Tempo ebenfalls im gleichen Netzwerk
- Keine unnötigen Portöffnungen auf Host
6. Backend und Visualisierung
Für die Visualisierung kann Grafana mit Tempo oder Jaeger verwendet werden:
jaeger:
image: jaegertracing/all-in-one:1.42
container_name: jaeger
ports:
- "16686:16686"
networks:
- tracing
Best Practices
- RBAC und Authentifizierung für Backend-Dashboards aktivieren
- Dashboards für Latenzen, Fehlerpfade und Durchsatz erstellen
- Alerting auf hohe Latenzen oder Fehlerquoten konfigurieren
7. Troubleshooting
Fehlerquellen und Checks:
- Collector erreichbar:
curl -v otel-collector:4317 - Microservices korrekt instrumentiert
- Trace-IDs in Logs prüfen
- Sampling korrekt angewendet
8. Security und Performance
- Non-Root Container für Collector und Services
- Readonly-Mounts für Konfigurationsdateien
- Sampling reduziert CPU-Last
- Netzwerk-Isolation minimiert Angriffsfläche
Mit dieser Architektur lassen sich Microservices transparent überwachen. Context Propagation stellt sicher, dass Anfragen über Service-Grenzen hinweg nachvollziehbar bleiben. Sampling und Tail-Based Policies erlauben es, Performance-Overhead zu minimieren, während kritische Fehler immer getraced werden. Compose ermöglicht einen einfachen Aufbau der Umgebung, sodass Observability von Anfang an in Ihre Microservices-Pipeline integriert werden kann.
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3
Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.
Meine Leistungen umfassen:
-
Professionelle Konfiguration von Routern und Switches
-
Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen
-
Erstellung von Topologien und Simulationen in Cisco Packet Tracer
-
Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG
-
Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible
-
Erstellung von Skripten für wiederkehrende Netzwerkaufgaben
-
Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege
-
Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting
Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.