Observability mit OpenTelemetry: Microservices im Griff

Warum klassisches Monitoring in Microservices-Architekturen versagt

Die Zeiten, in denen ein einzelner Server mit einem Nagios-Check zuverlässig Auskunft über den Systemzustand gab, sind endgültig vorbei. In modernen Microservices-Landschaften mit Dutzenden bis Hunderten unabhängig deployten Services, Event-Streams, Serverless-Funktionen und Edge-Workloads reicht klassisches Monitoring nicht mehr aus. Ein einzelner Nutzer-Request durchläuft häufig zehn oder mehr Services, Message Broker und Datenbanken – und genau an dieser Verkettung scheitern klassische Werkzeuge.

Wir haben in zahlreichen Kundenprojekten erlebt, wie Teams im Produktionsfall mit fragmentierten Log-Dateien, widersprüchlichen Metriken und fehlenden Trace-Informationen arbeiten müssen. Das Ergebnis: Fehlerdiagnosen dauern Stunden, Root-Cause-Analysen werden zur Kaffeesatzleserei und die Mean Time to Recovery (MTTR) steigt dramatisch. Observability ist die Antwort auf diese Komplexität – und OpenTelemetry (OTel) ist der offene Standard, auf den sich die Industrie geeinigt hat.

Die drei Säulen moderner Observability

Observability beschreibt die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Outputs zu verstehen. Anders als Monitoring – das vorab definiert, was gemessen wird – erlaubt Observability explorative Analysen bisher unbekannter Probleme. Die drei Säulen sind:

• Metriken (Metrics): Aggregierte Zahlenwerte über die Zeit – etwa Request-Rate, Fehlerquote oder P95-Latenz. Ideal für Dashboards und Alerting.
• Logs: Strukturierte Ereignisdaten mit Zeitstempel. Unverzichtbar für Detailanalysen einzelner Vorfälle.
• Traces: End-to-End-Verfolgung einzelner Requests durch die gesamte verteilte Architektur. Der Schlüssel, um Bottlenecks und kaskadierende Fehler zu verstehen.

Zunehmend werden diese drei Säulen durch Profiling und Real User Monitoring (RUM) ergänzt. Doch erst die korrelierte Auswertung aller Signale erlaubt echte Observability – und genau hier setzt OpenTelemetry an.

Was OpenTelemetry einzigartig macht

OpenTelemetry entstand 2019 aus der Fusion zweier Projekte: OpenTracing und OpenCensus. Heute ist OTel das zweitgrößte Projekt in der Cloud Native Computing Foundation (CNCF) direkt nach Kubernetes. Die Mission: einheitliche, vendor-neutrale APIs, SDKs und Datenformate für Telemetrie-Daten.

Herstellerunabhängigkeit als Schlüsselvorteil

Vor OpenTelemetry mussten Teams sich festlegen: Datadog, New Relic, Dynatrace, Prometheus, Jaeger – jede Lösung brachte eigene Agenten, eigene SDKs und proprietäre Formate mit. Ein Wechsel bedeutete eine Instrumentierungs-Migration quer durch alle Services. Mit OTel instrumentieren Sie einmal und können den Backend-Anbieter über Konfiguration wechseln. Das spart nicht nur Entwicklungszeit, sondern verhindert Vendor-Lock-in – ein strategisch wichtiger Punkt für CTOs und IT-Leitungen.

Die Kernkomponenten im Überblick

• OTel SDK: Sprachspezifische Bibliotheken (Go, Java, Python, Node.js, .NET, Rust, PHP u.v.m.)
• OTel API: Abstraktion für Instrumentierung – unabhängig vom konkreten SDK
• OTel Collector: Zentraler Gateway für Empfang, Verarbeitung und Export von Telemetrie
• OTLP (OpenTelemetry Protocol): Das standardisierte gRPC/HTTP-Protokoll
• Auto-Instrumentation: Automatisches Tracing ohne Code-Änderungen für gängige Frameworks

Praxis: OpenTelemetry in Node.js und Python integrieren

Die Einstiegshürde für OTel ist überraschend niedrig. Hier ein Beispiel für eine Node.js-Anwendung mit Express und TypeScript:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { Resource } from '@opentelemetry/resources';
import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions';

const sdk = new NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'checkout-service',
    [SemanticResourceAttributes.SERVICE_VERSION]: '2.4.1',
    [SemanticResourceAttributes.DEPLOYMENT_ENVIRONMENT]: 'production',
  }),
  traceExporter: new OTLPTraceExporter({
    url: 'http://otel-collector:4318/v1/traces',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Das war es im Wesentlichen. Ab diesem Moment werden HTTP-Requests, Datenbank-Queries, Redis-Calls, gRPC-Aufrufe und viele weitere Operationen automatisch instrumentiert. Für Python sieht es ähnlich aus – mit dem Befehl opentelemetry-instrument python app.py lassen sich viele Frameworks sogar ohne Code-Änderung tracen.

Custom Spans für fachliche Logik

Die Auto-Instrumentation deckt das technische Rückgrat ab. Für fachliche Einsichten lohnen sich manuelle Spans:

const tracer = trace.getTracer('checkout-business-logic');

export async function processOrder(orderId: string) {
  return tracer.startActiveSpan('order.process', async (span) => {
    span.setAttribute('order.id', orderId);
    span.setAttribute('order.priority', 'high');
    try {
      const result = await executeOrderLogic(orderId);
      span.setStatus({ code: SpanStatusCode.OK });
      return result;
    } catch (err) {
      span.recordException(err);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw err;
    } finally {
      span.end();
    }
  });
}

Der OpenTelemetry Collector als Herzstück Ihrer Pipeline

Der Collector ist die zentrale Komponente, die Telemetriedaten empfängt, transformiert und an ein oder mehrere Backends weiterleitet. Wir empfehlen einen zweistufigen Aufbau: einen Agent-Collector als DaemonSet pro Kubernetes-Node und einen Gateway-Collector als zentraler Hub.

Warum diese Architektur?

• Entlastung der Services: Applikationen schicken Telemetrie per UDP/OTLP an den lokalen Agent und sind sofort entkoppelt.
• Zentrale Policies: Sampling, Redaktion (PII-Entfernung), Enrichment und Routing geschehen im Gateway.
• Kosten-Kontrolle: Mit Tail-Based Sampling behalten Sie nur interessante Traces (Fehler, Slow Requests) – und reduzieren Backend-Kosten um 80–90%.

Eine typische Collector-Konfiguration enthält Receivers (OTLP, Prometheus, Jaeger), Processors (Batch, Filter, Attributes) und Exporter (zu Backends wie Grafana Tempo, Loki, Jaeger, Elastic, Datadog oder einem eigenen ClickHouse-Cluster).

DSGVO-Konformität bei Telemetrie-Daten

Gerade in Deutschland ist die Frage der Datenverarbeitung zentral. Telemetrie-Daten enthalten häufig Informationen, die unter die DSGVO fallen: IP-Adressen in Logs, User-IDs in Traces, personenbezogene Header-Werte. Als deutscher Softwareentwicklungs-Partner setzen wir konsequent auf folgende Prinzipien:

• Datensparsamkeit: Filtern Sie sensible Attribute bereits im Collector vor der Weiterleitung. OTel bietet dafür den attributes-Processor mit Regex-Redaktion.
• Data Residency: Hosten Sie Ihr Observability-Backend in der EU – etwa auf Hetzner, IONOS oder AWS Frankfurt.
• Retention-Policies: Definieren Sie klare Aufbewahrungsfristen. Traces 7 Tage, Logs 30 Tage, aggregierte Metriken 13 Monate – so verlangt es oft der DSGVO-konforme Rahmen.
• Pseudonymisierung: Ersetzen Sie User-IDs durch Hashes mit einem rotierenden Salt.

Kosten-Optimierung: Sampling und Aggregation richtig einsetzen

Observability ohne Strategie wird teuer. Ein unsampelter Produktions-Trace-Stream kann bei einem mittleren SaaS-Unternehmen schnell 50.000 € bis 200.000 € pro Monat kosten. Drei wirksame Hebel:

1. Head-Based Sampling

Schon beim ersten Service im Trace wird entschieden, ob der Request aufgezeichnet wird. Einfach zu implementieren, aber Sie verlieren möglicherweise interessante Traces.

2. Tail-Based Sampling

Der Collector puffert alle Spans eines Traces und entscheidet erst nach Abschluss, ob er gespeichert wird – etwa bei Fehler, hoher Latenz oder bestimmten Attributen. Deutlich intelligenter, aber speicherintensiver.

3. Span-Metriken

Aggregieren Sie Spans on-the-fly zu Metriken (Request-Rate, Fehler-Rate, Latenz-Quantile) im Collector. So erhalten Sie die vollständige Sicht – auch bei 1% Trace-Sampling.

Integration in die CI/CD-Pipeline

Observability endet nicht beim Deployment. Moderne DevOps-Teams integrieren Telemetrie in jeden Schritt der CI/CD-Pipeline:

• Deployment-Marker: Jeder Release schickt einen OTel-Event an das Backend – Korrelation zwischen Deployment und Incident wird trivial.
• Synthetic Monitoring: Nach jedem Deployment laufen synthetische User-Journeys, die selbst OTel-instrumentiert sind.
• SLO-basierte Rollbacks: Argo Rollouts und Flagger prüfen Service Level Objectives gegen Observability-Daten und rollen automatisch zurück.
• Error Budget Tracking: Metriken aus OTel fließen in SRE-Dashboards, die Release-Geschwindigkeit an Verlässlichkeit koppeln.

Häufige Fallstricke und wie Sie sie vermeiden

Fallstrick 1: Zu viele Attribute

Jeder Span kann beliebig viele Attribute haben. Teams neigen dazu, alles mitzuschreiben – und erzeugen Cardinality-Explosionen, die Backends in die Knie zwingen. Unsere Empfehlung: ein definiertes Attribut-Budget pro Service.

Fallstrick 2: Fehlende Propagation

Traces werden unterbrochen, wenn Services Headers (traceparent, tracestate) nicht weiterreichen. Besonders häufig in Message Queues, Background-Workern und Legacy-Adaptern. Lösung: W3C Trace Context konsequent durchsetzen und in Code-Reviews prüfen.

Fallstrick 3: Keine semantischen Konventionen

OTel definiert Semantic Conventions für HTTP, Datenbanken, Messaging, Cloud-Provider etc. Ignorieren Sie diese, verlieren Sie die Fähigkeit, Queries service-übergreifend zu stellen. Halten Sie sich konsequent an die Standards.

Backend-Wahl: Build oder Buy?

Mit OTel haben Sie freie Wahl. Im Enterprise-Umfeld sehen wir drei Strategien:

• Managed SaaS: Grafana Cloud, Datadog, New Relic, Honeycomb – schneller Start, planbare Kosten, kein Ops-Aufwand.
• Self-Hosted Open Source: Grafana LGTM-Stack (Loki, Grafana, Tempo, Mimir) oder SigNoz – volle Datenhoheit, höhere Betriebskomplexität.
• Hybrid: OTel als Abstraktion, kritische Daten im eigenen EU-Rechenzentrum, aggregierte Metriken im SaaS.

Fazit: OpenTelemetry als strategische Investition

OpenTelemetry ist weit mehr als eine weitere Monitoring-Bibliothek. Es ist ein strategisches Fundament für jede moderne Microservices-Architektur. Die Herstellerunabhängigkeit allein rechtfertigt die Einführung in den meisten Kundenprojekten, die wir betreuen. Hinzu kommen technische Vorteile wie einheitliche Instrumentierung, reife SDKs in allen relevanten Sprachen und ein vibrierendes Ökosystem.

Für CTOs und IT-Leiter ist die Botschaft klar: Wer heute eine neue Architektur plant oder eine bestehende modernisiert, sollte OpenTelemetry nicht als Option, sondern als Default betrachten. Die Investition in saubere Observability zahlt sich in niedrigeren MTTR-Werten, besseren SLOs und letztlich zufriedeneren Kunden aus.

Sie planen die Einführung von OpenTelemetry oder möchten Ihre bestehende Observability-Strategie auf ein neues Level heben? Als spezialisierter Softwareentwicklungs-Partner aus Deutschland begleiten wir Sie von der Architektur-Entscheidung über die Instrumentierung bis zum produktiven Betrieb – DSGVO-konform, hosted in der EU und mit tiefer Expertise in Cloud-Native-Technologien. Sprechen Sie uns an.