Zurück zum Blog

LLM Observability mit OpenTelemetry: KI-Funktionen messbar betreiben

AISoftware ArchitectureBackend DevelopmentSoftware Quality

LLM Observability mit OpenTelemetry wird für Softwareunternehmen relevant, sobald KI-Funktionen nicht mehr als Demo laufen, sondern Teil echter Produktprozesse sind. Dann reichen Logs einzelner Prompts nicht mehr aus: Führung und Technik müssen Kosten, Latenz, Fehler, Modellwechsel und Tool Calls nachvollziehen können.

Was LLM Observability mit OpenTelemetry bedeutet

LLM Observability beschreibt nicht nur, ob ein Modell geantwortet hat. Es geht darum, KI-Verhalten in den normalen Betrieb eines Softwaresystems einzuordnen: Traces, Metriken, Logs, Kosteninformationen und fachliche Qualitätssignale müssen zusammen betrachtet werden.

OpenTelemetry ist dafür interessant, weil es Telemetrie herstellerneutral beschreibt. Statt ein eigenes Monitoring-Schema für jeden LLM-Provider, jedes Framework und jedes Backend zu bauen, können Teams gemeinsame Attribute und Metriken nutzen.

Für produktive KI-Funktionen sind vor allem diese Signale wichtig:

  • Latenz: Wie lange dauern Modellaufruf, Retrieval, Tool Calls und Antwortstreaming wirklich?
  • Kosten: Welche Features, Kunden oder Workflows verursachen hohe Token- und Infrastrukturkosten?
  • Fehlerarten: Sind Probleme Modellfehler, Timeouts, Rate Limits, leere Retrieval-Ergebnisse oder fehlerhafte Tools?
  • Qualität: Wo brechen Antworten fachlich ab, werden nachbearbeitet oder führen zu Supportfällen?
  • Datenzugriff: Welche Systeme und Datenquellen wurden für eine Antwort genutzt?

Die GenAI Semantic Conventions von OpenTelemetry sind noch in Entwicklung. Genau deshalb sollten Teams sie nicht blind als fertigen Standard behandeln, sondern als nützliche Grundlage für ein eigenes, stabiles Betriebsmodell.

Wo Teams mit Instrumentierung starten sollten

Der häufigste Fehler ist, LLM Observability erst nach dem ersten größeren Incident einzubauen. Dann fehlen historische Vergleichswerte, Kosten sind schwer zuzuordnen und niemand weiß, ob ein Modellwechsel wirklich geholfen hat.

Ein pragmatischer Startpunkt ist ein kleines Telemetrie-Schema pro KI-Workflow:

ai_workflow: contract_review
owner: product-platform
signals: ["latency", "token_usage", "tool_calls", "error_type"]
business_metric: "review_completed_without_manual_retry"
privacy_rule: "no_prompt_payloads_in_logs"

Daraus entstehen konkrete Architekturentscheidungen:

  • Keine Prompt-Payloads in Standardlogs: Inhalte können personenbezogene Daten, Geschäftsgeheimnisse oder Kundendokumente enthalten.
  • Korrelation statt Dashboard-Silos: LLM-Spans müssen mit Request-ID, Nutzerrolle, Tenant und Backend-Operationen verbunden sein.
  • Kosten pro Feature messen: Durchschnittskosten pro Anfrage reichen nicht, wenn einzelne Workflows die Marge zerstören.
  • Modellwechsel testbar machen: Teams brauchen Vergleichswerte für Antwortzeit, Fehlerrate, Tokenverbrauch und fachliche Trefferquote.
  • Ownership festlegen: Produkt, Engineering und Support müssen wissen, wer Warnungen bewertet und Prioritäten setzt.

OpenTelemetry löst diese Entscheidungen nicht automatisch. Es verhindert aber, dass KI-Beobachtbarkeit als Sonderlösung neben dem restlichen Betrieb entsteht.

Warum das wichtig ist

KI-Funktionen scheitern selten nur daran, dass ein Modell "schlecht" ist. Häufiger entstehen wirtschaftliche Probleme durch unsichtbare Kosten, schwankende Latenz, unklare Fehlerbilder und fehlende Verantwortung zwischen Produkt, Backend und Betrieb.

LLM Observability mit OpenTelemetry macht diese Probleme früh steuerbar. Teams können sehen, welche Workflows profitabel sind, welche Architekturpfade zu teuer werden und wo Qualität nicht reproduzierbar ist. Für wachsende Unternehmen ist das keine reine Monitoring-Frage, sondern eine Führungsaufgabe: Wer KI produktiv einsetzen will, braucht Messbarkeit, bevor Skalierung die Fehler vergrößert. Eine Architecture & AI Review kann prüfen, ob KI-Funktionen technisch beobachtbar und wirtschaftlich kontrollierbar sind.