OpenTelemetry OTel Tracing Observability
OpenTelemetry vereint traces, metrics und logs unter einem einzigen offenen Standard und beseitigt den proprietären Agenten-Lock-in, der bei jedem Backend-Wechsel die Kosten in die Höhe treibt. Wir instrumentieren Dienste in Go, Java, Python, Node.js und .NET mit OTel SDKs, konfigurieren die Collector-Pipeline für PII-Schwärzung und tail-based sampling und exportieren Signale an beliebige Backends — Prometheus, Tempo, Jaeger oder Datadog — für US- und EU-Kunden in regulierten Branchen.
OpenTelemetry vereint traces, metrics und logs unter einem einzigen offenen Standard und beseitigt den proprietären Agenten-Lock-in, der bei jedem Backend-Wechsel die Kosten in die Höhe treibt. Wir instrumentieren Dienste in Go, Java, Python, Node.js und .NET mit OTel SDKs, konfigurieren die Collector-Pipeline für PII-Schwärzung und tail-based sampling und exportieren Signale an beliebige Backends — Prometheus, Tempo, Jaeger oder Datadog — für US- und EU-Kunden in regulierten Branchen.
Herausforderungen
Entwickler instrumentieren spans mit Anfrageparametern, Benutzer-IDs oder Payload-Feldern, ohne zu bemerken, dass diese Werte regulierte personenbezogene Daten enthalten. Sind sie erst im Backend, lässt sich PII kaum entfernen und kann gegen DSGVO- oder HIPAA-Anforderungen verstoßen.
Unkritisches Instrumentieren jedes Funktionsaufrufs oder das Erstellen hochkardinaler spans (Labels pro Nutzer, pro Request-ID) erhöht Speicher-, CPU- und Netzwerklast. Schlecht abgestimmtes sampling lässt 100 % der traces durch und sättigt Collector und Backend-Speicher.
Head-based sampling entscheidet zu Beginn eines trace über die Aufzeichnung und übersieht daher seltene, aber wichtige Fehlerpfade. Tail-based sampling puffert den vollständigen trace vor der Entscheidung und erhöht Latenz und Speicherlast im Collector. Die falsche Strategie führt zu fehlenden kritischen traces oder überhöhten Speicherkosten.
Ein fehlender oder fehlerhafter W3C-TraceContext-Header unterbricht den trace an der ersten Dienstgrenze und erzeugt getrennte spans, die nicht korreliert werden können. Polyglotte Stacks — Go-Gateway, Java-Dienst, Python-ML-Worker — erfordern jeweils sprachspezifische Propagationskonfiguration.
Proprietäre Agenten (Datadog-Agent, New Relic APM) betten herstellerspezifische APIs in den Anwendungscode ein. Ein Backend-Wechsel erfordert Änderungen auf Code-Ebene, und das Agenten-Binary selbst kann Lizenzierungs-, Sicherheits- und Abhängigkeitskomplexität einführen.
Der Collector unterstützt Receiver, Processors und Exporters in kombinierbaren Pipelines, jedoch verursacht eine falsch konfigurierte Processor-Reihenfolge (z. B. Batching vor Filterung) Datenverluste oder übermäßigen Speicherverbrauch. Multi-Backend-Fan-out und umgebungsbasiertes Routing vergrößern die Konfigurationsfläche zusätzlich.
Lösungen
Wir instrumentieren Dienste mit offiziellen OTel SDKs und Auto-Instrumentierungsagenten und erzeugen OTLP-formatierte traces, metrics und logs ohne proprietäre API im Anwendungscode — Backends sind ohne Code-Änderungen austauschbar.
Wir entwerfen OTel-Collector-Pipelines mit Attribute-Processor-Regeln, die regulierte Felder vor dem Export schwärzen, hashen oder löschen und so sicherstellen, dass die Telemetrie für alle nachgelagerten Backends DSGVO-konform und regulierungsgerecht ist.
Wir konfigurieren tail-based-Sampling-Richtlinien im Collector, die 100 % der Fehler- und langsamen traces aufzeichnen und gleichzeitig den Routineverkehr reduzieren — jede Anomalie wird erfasst, ohne Speicherbudgets zu sprengen.
Auto-Instrumentierung deckt Frameworks (HTTP, gRPC, Datenbank, Messaging) automatisch ab; wir ergänzen gezielte manuelle spans für geschäftskritische Code-Pfade — Zahlungsflows, ML-Inferenzaufrufe, regulatorische Ereignisse — wo Framework-Tracing nicht ausreicht.
Wir konfigurieren W3C-TraceContext- und Baggage-Propagation in jeder Sprachlaufzeit, testen die Propagation Ende-zu-Ende in der CI-Pipeline und validieren die trace-Kontinuität über Dienstgrenzen hinweg mit synthetischen verteilten Testszenarien.
OTLP-Exporters im Collector verteilen Signale gleichzeitig an ein oder mehrere Backends. Kunden können Jaeger oder Tempo für regulierte Daten On-Premises betreiben und nicht-sensible Metriken parallel nach Datadog spiegeln — ohne Änderungen an der Instrumentierung.
Stack
OpenTelemetry SDKs (Go, Java, Python, Node.js, .NET), OTel Collector, OTLP, Auto-Instrumentierungsagenten, manuelle span-Instrumentierung, Context-Propagation (W3C TraceContext / Baggage), Semantic Conventions, Exporters (Prometheus, Grafana Tempo, Jaeger, Datadog, OTLP/gRPC), tail-based sampling, Collector-Processors (PII-Schwärzung, Attributfilterung, Batch), Sampling-Richtlinien.
Compliance
PII aus der Telemetrie herausgehalten · herstellerneutraler Export · trace-Auditpfad · NIS2-Ende-zu-Ende-Observability
Fallstudien
Android + iOS refactor and rebuild for a German last-mile logistics operator — multi-point route planning, real-time driver tracking and in-app invoicing live in the EU.
Production social platform — App Store + Google Play, live across the US and EU — with geo Radar, encrypted messaging and a virtual economy.
Three-app ride-hailing platform — driver, passenger, dispatcher — with real-time GPS, document verification, dual cash/card payments.
Warum YuSMP
Jeder span und jede Metrik wird über die offene OTel-API emittiert. Ein Wechsel von Datadog zu Grafana Tempo oder das Hinzufügen eines zweiten Backends ist eine Collector-Konfigurationsänderung — kein Refactoring-Sprint über Dutzende von Diensten.
Unser Collector-Pipeline-Design behandelt PII-Schwärzung als erstklassige Anforderung, nicht als nachträglichen Gedanken. Regulierte Felder werden entfernt oder gehasht, bevor ein Signal ein externes Backend erreicht, und halten Ihre Telemetrie DSGVO-konform.
Wir instrumentieren alle drei Signaltypen und konfigurieren exemplars, die Prometheus-Metriken mit den zugrunde liegenden traces verknüpfen, damit Entwickler von einem Latenz-Spike im Dashboard direkt zum betreffenden trace springen — ohne Kontextwechsel.
FAQ
OpenTelemetry ist ein CNCF-Projekt, das eine herstellerneutrale API, ein SDK und ein Übertragungsprotokoll (OTLP) für traces, metrics und logs definiert. Im Gegensatz zu proprietären Agenten — Datadog APM, New Relic, Dynatrace — wird kein herstellerspezifischer Code in Ihrer Anwendung eingebettet. Sie instrumentieren einmalig über die offene OTel-API und leiten Signale über den Collector an ein beliebiges konformes Backend weiter. Ein Backend-Wechsel erfordert lediglich eine Anpassung der Collector-Exporter-Konfiguration, keine Änderungen am Anwendungscode.
Traces zeichnen den vollständigen Weg einer einzelnen Anfrage über alle Dienste auf — jede Operation ist ein span mit Zeitstempel, Attributen und Status. Metrics sind numerische Aggregationen über die Zeit (Anfragerate, Fehlerrate, Latenz-Perzentile), geeignet für Dashboards und Alarme. Logs sind zeitgestempelte Text- oder strukturierte Ereignisse einzelner Komponenten. OTel vereint alle drei unter einem SDK und Übertragungsprotokoll; exemplars verknüpfen Metrikdatenpunkte direkt mit den zugehörigen traces.
OTel selbst schwärzt keine PII — das ist Aufgabe der Pipeline. Wir konfigurieren den Attribute Processor und Transform Processor des OTel Collectors so, dass span-Attribute und Log-Felder, die regulierte Daten enthalten könnten (E-Mail-Adressen, Benutzer-IDs, Kartennummern, Sozialversicherungsnummern), vor Erreichen des Backends gelöscht, gehasht oder maskiert werden. So bleibt die Telemetrie DSGVO-konform und entspricht ähnlichen Rahmenwerken, ohne dass Änderungen an der Instrumentierung auf Anwendungsebene erforderlich sind.
Head-based sampling entscheidet zu Beginn eines trace, ob dieser aufgezeichnet wird — schnell und speichereffizient, verwirft jedoch seltene Fehler-traces mit derselben Wahrscheinlichkeit wie Routine-traces. Tail-based sampling puffert den vollständigen trace im Collector, bevor eine Entscheidung getroffen wird, und ermöglicht Richtlinien wie „alle traces mit Fehlern oder Latenz über 1 s immer aufbewahren". Wir konfigurieren tail-based sampling für Produktionssysteme, bei denen fehlende Fehler-traces kostspieliger sind als der zusätzliche Speicher- und CPU-Bedarf des Collectors.
Der OTel Collector ist ein herstellerunabhängiger Agent, der OTLP (oder andere Formate) empfängt, Signale verarbeitet — Batching, Filterung, Attribut-Transformation, PII-Schwärzung, tail-based sampling — und an ein oder mehrere Backends gleichzeitig exportiert. Sie können Signale direkt aus SDKs an ein Backend exportieren, doch der Collector entkoppelt die Instrumentierung von der Backend-Wahl, zentralisiert die Behandlung sensibler Daten (PII-Schwärzung) und ermöglicht Fan-out an mehrere Backends ohne Anwendungsänderungen. Wir empfehlen ihn für jeden Produktionseinsatz.
Der Overhead hängt von der Sampling-Rate und der Kardinalität ab. Bei head-based sampling mit 10 % und sorgfältig abgestimmten span-Attributen (keine hochkardinalen Labels wie Benutzer-ID pro span) liegt der CPU-Overhead typischerweise unter 2 %, der Speicherbedarf ist minimal. Auto-Instrumentierungsagenten verursachen beim Start zusätzliche Ladezeiten für Bibliotheken. Tail-based sampling im Collector erhöht den Speicherbedarf proportional zum Pufferfenster. Wir erstellen Performance-Profile der instrumentierten Dienste vor und nach dem Deployment und passen die Sampling-Richtlinien an, um den Overhead innerhalb vereinbarter SLOs zu halten.
Die Migration erfolgt schrittweise. Wir starten den OTel Collector parallel zum bestehenden Agenten, leiten einen duplizierten OTLP-Stream an ein Test-OTel-kompatibles Backend weiter, während der proprietäre Agent im Produktionsbetrieb bleibt. Sobald Signal-Parität bestätigt ist — trace-Abdeckung, Metrik-Kardinalität, Alarm-Treue — entfernen wir die Auto-Instrumentierung des proprietären Agenten und belassen nur die OTel SDKs in der Anwendung. Der Collector kann weiterhin über seinen OTLP-Exporter nach Datadog exportieren, falls Datadog als Backend beibehalten wird — ein harter Cutover ist nicht erforderlich.
Antwort innerhalb eines Werktages. NDA auf Anfrage.
