OpenTelemetry für AI-Agents: vendor-neutrale Observability

Pexon Consulting | 12 Min. Lesezeit | 11.06.2026

TL;DR

OpenTelemetry AI Agent Observability ist 2026 die Architektur-Antwort, wenn ein AI-Stack über mehrere Layer skaliert und kein Vendor-Lock-in in Beobachtbarkeit entstehen soll: Agents, LangChain, Service Mesh, Infrastruktur und Kubernetes emittieren Traces, Metrics und Logs in einem einheitlichen Format über OTLP. Pexon Consulting baut Self-Hosted-Setups mit OTel Collector als Pipeline plus dem Grafana-Stack (Tempo, Loki, Prometheus) als DSGVO-konforme Antwort auf LangSmith, Helicone und andere SaaS-Tools.

Warum vendor-neutrale Observability bei AI-Stacks zwingend wird

Wir hören das aktuell wöchentlich: Ein Engineering-Team hat seinen ersten produktiven AI-Stack mit LangSmith als Tracing-Lösung gestartet. Funktioniert gut für drei Monate. Dann passieren drei Dinge gleichzeitig. Erstens: Die LangSmith-Rechnung wird teurer als gedacht (39 USD pro Seat plus Trace-Cost). Zweitens: Die Compliance-Abteilung fragt, ob Traces mit Kundenkontext wirklich in eine US-SaaS gehen sollen. Drittens: Das Team hat zusätzlich Helicone für Cost-Tracking, Datadog für Infra-Monitoring und ein eigenes Postgres-Logging — drei verschiedene Stacks, die nichts voneinander wissen.

Das Problem ist nicht LangSmith — das Problem ist die fehlende Standardisierung. Ohne einheitliches Telemetrie-Protokoll baust du für jede Vendor-Wahl einen eigenen SDK-Integration-Pfad, exportierst in unterschiedliche Formate, korrelierst über Trace-IDs, die nicht kompatibel sind. Skaliert nicht.

OpenTelemetry ist seit 2023 der etablierte Cloud-Native-Standard für genau dieses Problem. Ursprünglich für Microservices gedacht, seit Mitte 2025 mit den GenAI Semantic Conventions auch für AI-Workloads spezifiziert. Damit haben Agents, LangChain, Service Mesh und Kubernetes denselben Telemetrie-Standard — und du kannst self-hosted DSGVO-konform sammeln, statt SaaS-Lock-in zu akzeptieren.

Die drei Säulen: Traces, Metrics, Logs

OTel definiert drei Telemetrie-Signale, die zusammen die volle Beobachtbarkeit liefern.

Traces. Verteilte Aufrufe als Span-Hierarchie. Bei AI-Agents heißt das: Ein User-Request löst einen Root-Span aus, jeder Agent-Hop ist ein Sub-Span, jeder LLM-Call ein weiterer Sub-Span, jeder Tool-Call ein weiterer. Die Hierarchie zeigt, wie sich der Request durch das System bewegt hat, mit Latenzen pro Schritt.

Bei einem typischen Customer-Support-Agent mit Multi-Tool-Loop bekommst du Spans wie folgt:

Metrics. Numerische Zeitreihen. Bei AI-Workloads die relevanten Metrics: Token-Verbrauch pro Modell pro Stunde, Latenz-Verteilungen p50/p95/p99 pro Tool, Cost pro User pro Tag, Auslastung der vLLM-Cluster, Cache-Hit-Rate bei Prompt-Caching. Metrics sind aggregierbar — du kannst über Millionen Requests die Trends sehen.

Logs. Strukturierte Log-Einträge. Bei AI-Workloads sind Logs primär für Audit-Trail relevant — wer hat wann welchen Tool-Call mit welchen Parametern aufgerufen, welcher User-Identity-Claim war im Token, welche Permissions wurden geprüft. Wichtig: Logs werden über Trace-IDs mit Traces korreliert, sodass du aus einem Trace direkt zu den zugehörigen Logs springen kannst.

Die drei Säulen ergeben gemeinsam ein vollständiges Bild. Trace zeigt den Aufruf-Fluss, Metrics zeigen Trends, Logs zeigen Detail-Kontext. Einer allein reicht nicht.

OTel Auto-Instrumentation für LangChain und LangGraph

OpenTelemetry hat eine wachsende Auto-Instrumentation-Bibliothek, die ohne Code-Änderungen Telemetrie aus etablierten Frameworks zieht.

from opentelemetry.instrumentation.langchain import LangchainInstrumentor
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

tracer_provider = TracerProvider()
tracer_provider.add_span_processor(
    BatchSpanProcessor(
        OTLPSpanExporter(endpoint="http://otel-collector.intern:4317")
    )
)
trace.set_tracer_provider(tracer_provider)

LangchainInstrumentor().instrument()

Mit diesen 12 Zeilen Code wird jeder LangChain- und LangGraph-Aufruf automatisch als OTel-Span getrackt. Die Spans folgen den GenAI Semantic Conventions — ein Standard, der seit 2025 die Attribute für AI-Workloads spezifiziert: gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.response.finish_reason und mehr.

Damit sind deine LangChain-Spans automatisch kompatibel mit jedem OTel-konformen Backend — Tempo, Jaeger, Datadog, New Relic, Honeycomb, Grafana Cloud. Kein Vendor-Lock-in mehr auf SDK-Ebene.

OTel Collector: die Pipeline-Komponente

Apps emittieren Telemetrie nicht direkt an die Backends, sondern an einen lokalen OTel Collector. Das ist die zentrale Komponente, die Telemetrie sammelt, transformiert und an die richtigen Backends weiterleitet.

Beispiel-Konfiguration für einen typischen Pexon-Setup:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
  attributes:
    actions:
      - key: gen_ai.request.prompt
        action: hash
      - key: gen_ai.response.text
        action: hash
  filter:
    spans:
      exclude:
        match_type: strict
        attributes:
          - key: gen_ai.request.model
            value: "internal-dev-only"

exporters:
  otlp/tempo:
    endpoint: tempo.intern:4317
    tls:
      insecure: false
  prometheus:
    endpoint: 0.0.0.0:8889
  loki:
    endpoint: http://loki.intern:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, attributes, filter]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch, attributes]
      exporters: [loki]

Was hier passiert: Drei Receiver (OTLP-gRPC und OTLP-HTTP) sammeln Telemetrie von den Apps. Processors machen Transformation — attributes hasht Prompts und Responses zu Privacy-Schutz, filter schließt bestimmte Spans aus (Dev-Traffic). Exporters senden an die Backends.

Vorteil dieser Architektur: Wenn du das Backend wechseln willst, änderst du den Collector. Apps bleiben unberührt. Vendor-neutralität in der Praxis.

Self-Hosted Backend-Stack mit Grafana

Wir bauen typisch den vollständigen Grafana-Stack als DSGVO-konforme Self-Hosted-Antwort.

Tempo für Traces. Grafana Tempo ist Open Source, Postgres- oder S3-basiertes Trace-Storage, optimiert für hochvolumige Spans. Aufbewahrung typisch 7-30 Tage in Hot-Storage, danach Archive in S3 Glacier oder Backup-Tape. Bei einem Pilotkunden mit 12 Millionen Spans pro Tag haben wir Tempo auf 3 Nodes mit 8 vCPU und 32 GB RAM produktiv stabil betrieben.

Loki für Logs. Grafana Loki indexiert nur Metadaten, nicht den Volltext — was bei AI-Workloads gut passt, weil Log-Volumes sehr hoch sein können. Strukturierte JSON-Logs mit Trace-ID-Korrelation sind Standard. Speicher-Effizienz typisch 80-90% besser als ELK-Stack bei vergleichbarer Funktion.

Prometheus für Metrics. Der etablierte Standard für Metrics, mit Pull-Modell für klassische Infra und Push über das Pushgateway für event-basierte Metrics. Wir nutzen Prometheus plus Mimir (Grafanas verteilte Variante) bei hochlast-Setups.

Grafana als UI. Die einheitliche Visualisierungs-Oberfläche über alle drei Datenquellen. Cross-Signal-Navigation: Du kannst aus einem Tempo-Trace direkt zu den Loki-Logs springen, oder aus einer Prometheus-Metrik zu den Traces, die zu der gemessenen Spike geführt haben.

Jaeger als Alternative. Wer schon Jaeger im Einsatz hat, kann es als Tempo-Alternative für Traces nutzen — funktional ähnlich, weniger eng mit Grafana integriert. Wir nehmen Jaeger bei bestehenden Setups, Tempo bei Greenfield.

GenAI Semantic Conventions im Detail

Ein Wort zu den GenAI Semantic Conventions, die seit Mitte 2025 stabil sind. Sie definieren, welche Attribute ein LLM-Call-Span tragen muss, damit die Telemetrie über Frameworks und Provider hinweg vergleichbar ist.

Pflicht-Attribute für jeden LLM-Call-Span:

• gen_ai.system: anthropic, openai, mistral, etc.
• gen_ai.request.model: claude-sonnet-4-6, gpt-4o, etc.
• gen_ai.usage.input_tokens: Token-Verbrauch Input
• gen_ai.usage.output_tokens: Token-Verbrauch Output
• gen_ai.response.finish_reason: stop, length, tool_calls

Optional-Attribute, die aber für produktive Setups wertvoll sind:

• gen_ai.request.temperature
• gen_ai.request.max_tokens
• gen_ai.response.id
• gen_ai.usage.cache_read_input_tokens (bei Anthropic-Prompt-Caching)
• gen_ai.tool.calls (bei Tool-Use)

Damit kannst du beispielsweise eine Dashboard-Frage stellen wie „Welcher Cost-Center hat in den letzten 24h für mehr als 1.000 USD Claude-Sonnet-Tokens verbraucht“ und bekommst die Antwort aus deinem Prometheus-Daten — ohne LangSmith oder Helicone.

Pexon-Sprint-Setup

Wir liefern den vollständigen Observability-Stack als 8-12-Wochen-Sprint mit festem Preis.

Wochen 1-2: Architektur-Workshop mit Engineering und Compliance. Mapping der Workloads, die instrumentiert werden sollen. Definition der Retention-Vorgaben pro Telemetrie-Signal.

Wochen 3-5: Aufbau des Backend-Stacks auf eurem K8s — Tempo, Loki, Prometheus, Grafana. Plus OTel Collector als zentrale Pipeline. Multi-Tenancy für Mandanten-Trennung wenn nötig.

Wochen 6-8: Auto-Instrumentation für LangChain, LangGraph, FastMCP, plus alle bestehenden Microservices über die OTel-SDKs. Standard-Dashboards für die typischen AI-Observability-Fragen.

Wochen 9-12: Schulung der Engineering-Truppe, Übergabe inkl. Runbooks, Custom-Dashboards für eure spezifischen Use-Cases.

Investment 95-160k EUR je nach Workload-Anzahl und bestehender Cloud-Maturity. Bei Mittelständlern mit existierender Grafana-Praxis ist der Sprint deutlich kürzer und günstiger.

Häufig gestellte Fragen

Wie unterscheidet sich OTel von MLflow Tracing oder LangSmith?

MLflow Tracing und LangSmith sind Framework-spezifische Tools mit eigenem Telemetrie-Format. Sie bieten LangChain/LangGraph-Tiefe, aber leiden bei Cross-Cutting-Setups (mehrere Frameworks, Infra-Layer, Kubernetes). OTel ist der vendor-neutrale Standard, der überall funktioniert — du verlierst etwas Framework-Tiefe, gewinnst dafür Cross-Layer-Konsistenz. Wir kombinieren oft: MLflow für LangGraph-spezifisches Eval, OTel für die produktive Telemetrie über den gesamten Stack. Mehr zu MLflow im MLflow-LangGraph-Tracing-Blog.

Wie hoch ist der Overhead von OTel auf den Apps?

Bei richtig konfiguriertem Setup typisch unter 2% Latenz-Overhead. Spans werden in einem Batch-Processor asynchron exportiert, blocken den App-Code nicht. Bei sehr hochfrequenten Workloads (>10.000 Spans pro Sekunde pro App) bauen wir Sampling ein — typisch 10-25% Sampling reicht für Production-Beobachtbarkeit, plus 100% für Error-Cases.

Wie schützen wir PII in den Spans?

Mehrschichtig. Erstens: GenAI Semantic Conventions empfehlen, Prompts und Responses NICHT als Span-Attribute zu speichern — nur Hashes. Zweitens: Im OTel Collector hashen wir explizit alle sensiblen Attribute, bevor sie an Tempo/Loki gehen. Drittens: Bei besonders sensitiven Inhalten (Banking, Healthcare) deployen wir den Collector im gleichen Trust-Boundary wie die Apps, sodass Klartext nie das Trust-Boundary verlässt.

Kann ich OTel auch mit Claude Code oder OpenAI Agents SDK nutzen?

Beide haben native OTel-Integration. Claude Code seit Version 2.x, OpenAI Agents SDK seit März 2026. Setup ist ähnlich der LangChain-Instrumentation — Environment-Variable plus SDK-Konfiguration. Damit hast du einheitliche Telemetrie über alle drei Hauptframeworks.

Was kostet der Grafana-Stack monatlich für 1.000 User?

Bei moderaten Workloads (200-500 Mio Spans pro Monat, 50-150 GB Logs, 10-30 GB Metrics) liegen die Infrastruktur-Kosten typisch bei 600-1.500 EUR pro Monat (K8s-Cluster, Storage, Backup). Grafana Open Source ist gratis, Grafana Enterprise optional ab 24 USD pro Active User pro Monat (für Enterprise-Features wie SSO/SAML, RBAC).

Nächster Schritt

Wenn euer AI-Stack über mehrere Frameworks und Layer skaliert und ihr eine vendor-neutrale Observability-Antwort sucht: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise einem SRE oder Platform-Engineering-Lead. Du beschreibst die Stack-Landschaft, wir skizzieren den OTel-Setup mit Festpreis-Sprint.

Verwandte Themen