Zero-Code-Instrumentierung ist ein Weg, Telemetrie aus einer Anwendung zu erfassen, ohne ihren Quellcode zu ändern. Ein Agent, ein Runtime-Hook oder ein eBPF-Programm koppelt sich an den Prozess und instrumentiert gängige Bibliotheken wie HTTP-Server, Datenbank-Clients und Messaging-Frameworks automatisch. OpenTelemetry verwendet diesen Begriff für die frühere automatische Instrumentierung.
Was ist Zero-Code-Instrumentierung?
Zero-Code-Instrumentierung liefert Traces, Metriken und oft auch Logs einer Anwendung, ohne dass Sie deren Code bearbeiten. Statt die OpenTelemetry-API in Ihren Handlern aufzurufen, hängen Sie beim Start einen Agent an oder aktivieren einen Runtime-Hook, der die bereits genutzten Bibliotheken instrumentiert. Die OpenTelemetry-Dokumentation hat den Begriff anstelle von „automatischer Instrumentierung“ eingeführt, weil er genauer beschreibt, was Sie tun: im Code nichts.
Sie ergänzt die codebasierte Instrumentierung, statt sie zu ersetzen. Zero-Code bringt vom ersten Tag an breite Abdeckung für Frameworks und Protokolle; manuelle Spans und Attribute liefern den fachlichen Kontext, den nur Ihr Code kennt.
So funktioniert es
Der Mechanismus hängt von der Laufzeitumgebung ab:
- Bytecode-Manipulation (Java): Ein Java Agent schreibt Klassen unterstützter Bibliotheken beim Laden um und fügt Span-Erzeugung und Context Propagation ein.
- Monkey Patching (Python, Node.js, Ruby): Bibliotheksfunktionen werden beim Import gekapselt.
- Profiler-APIs (.NET): Über die Profiling-Schnittstelle der CLR injiziert eine externe Komponente die Instrumentierung.
- eBPF (kompilierte Sprachen wie Go oder beliebige Prozesse): Kernel-Programme beobachten Funktionsaufrufe oder Netzwerkverkehr von außerhalb des Prozesses. OpenTelemetry hat dafür eBPF-basierte Projekte wie die automatische Instrumentierung für Go und OpenTelemetry eBPF Instrumentation (OBI).
Alle Ansätze erzeugen Daten gemäß den Semantic Conventions. Ein Java-Service und ein Python-Service melden HTTP-Spans also mit denselben Attributen.
Beispiele je Sprache
Java
export OTEL_SERVICE_NAME=checkout
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
java -javaagent:./opentelemetry-javaagent.jar -jar checkout.jarPython
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
opentelemetry-instrument --service_name checkout python app.pyNode.js
npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register app.js.NET, PHP und weitere Laufzeitumgebungen
Für .NET liefert das Projekt OpenTelemetry .NET Automatic Instrumentation Installationsskripte und nutzt die Profiler-Schnittstelle der CLR. ASP.NET Core, HttpClient und gängige Datenbank-Clients werden damit ohne Codeänderung getraced. PHP setzt auf eine kompilierte Erweiterung zusammen mit Instrumentierungspaketen, die Sie über Composer installieren. Ruby bietet ein All-in-one-Gem für die Instrumentierung, das nur wenige Zeilen Konfiguration braucht. Die Abdeckung unterscheidet sich zwischen den Sprachen. Prüfen Sie deshalb die Liste der unterstützten Bibliotheken für Ihren Stack, bevor Sie sich in Produktion darauf verlassen.
Konfiguriert wird über standardisierte Umgebungsvariablen wie OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_RESOURCE_ATTRIBUTES und OTEL_TRACES_SAMPLER, die in allen Sprachen gleich funktionieren.
Zero-Code auf Kubernetes mit dem Operator
Der OpenTelemetry Operator macht Zero-Code-Instrumentierung zu einer Plattformfunktion. Sie definieren einmal eine Instrumentation-Ressource mit Exporter-Endpunkt, Propagatoren und Sampler und aktivieren Workloads dann per Annotation am Pod-Template:
metadata:
annotations:
instrumentation.opentelemetry.io/inject-java: "true"Der Operator injiziert den Agent über einen Init-Container und setzt die Umgebungsvariablen. Annotationen gibt es unter anderem für Java, Node.js, Python, .NET und Go. Anwendungsteams erhalten Tracing, ohne ihre Images anzufassen, und das Plattform-Team steuert die Versionen zentral.
Vorteile und Grenzen
| Vorteile | Grenzen |
|---|---|
| Schneller Nutzen, keine Codeänderungen und kein neuer Code im Deployment | Instrumentiert nur unterstützte Bibliotheken und Frameworks |
| Einheitliche Abdeckung über viele Services und Teams | Kein fachlicher Kontext wie Bestellwert oder Mandant ohne manuelle Attribute |
| Funktioniert auch für Fremd- und Legacy-Anwendungen | Mehr Startzeit und Speicherbedarf, abhängig von Runtime und Agent |
| Upgrades zentral steuerbar | Kann laute Spans erzeugen, etwa für Health Checks, die gefiltert werden müssen |
Zero-Code, eBPF oder manuell: die richtige Wahl
Die drei Ansätze bedienen unterschiedliche Bedürfnisse. Sprach-Agents liefern für unterstützte Frameworks die meisten Details, einschließlich Datenbankabfragen und Messaging-Metadaten, und reichen den Trace-Kontext innerhalb des Prozesses weiter. eBPF-basierte Instrumentierung braucht überhaupt keine Unterstützung der Runtime und erfasst auch Services, die Sie nicht mit einem Agent neu starten können. Sie sieht allerdings weniger Anwendungskontext und hängt von Kernel-Funktionen ab. Manuelle Instrumentierung bietet volle Kontrolle und fachliche Attribute, kostet aber Entwicklungszeit. In der Praxis kombinieren die meisten Teams alle drei: Agents für die verbreiteten Sprachen im Haus, eBPF für Lücken wie kompilierte Programme oder Fremdsoftware und manuelle Spans für die wenigen Codepfade, in denen fachlicher Kontext wirklich zählt.
Best Practices
- Mit Zero-Code starten, dann manuelle Spans ergänzen, wo Geschäftslogik zählt. Agents stellen in der Regel die OpenTelemetry-API bereit, sodass manuelle Spans im selben Trace landen.
service.nameund Umgebung explizit setzen; Standardwerte wieunknown_servicemachen Daten schwer auffindbar.- Nicht benötigte Instrumentierungen deaktivieren, um Overhead und Rauschen zu senken; die meisten Agents bieten Schalter pro Bibliothek.
- Agent-Versionen pinnen und Upgrades in Staging testen, denn Änderungen an der Instrumentierung können Span-Namen und Attribute verändern.
- Overhead messen, und zwar unter realistischer Last, bevor Sie breit ausrollen.
- Rauschen im Collector filtern, etwa Spans von Health Checks und Readiness Probes.
Wie Obseria hilft
Obseria arbeitet mit den standardisierten Zero-Code-Agents von OpenTelemetry und dem Operator. Richten Sie OTEL_EXPORTER_OTLP_ENDPOINT auf Obseria, und Teams mit bestehendem OpenTelemetry-Setup sehen typischerweise innerhalb von 15 Minuten den ersten Trace. Alternativ wird der Obseria Agent einmal pro Host installiert und erfasst Metriken, Logs, Traces und Profile ohne Codeänderungen pro Service. Sprach-Guides: Java, Python und Node.js.
