Observability & Telemetrie: das laufende LLM-System sichtbar machen
Einführung · 8 Abschnitte · ~9 Min Lesezeit · Stand
Warum ein LLM-System ohne Telemetrie blind läuft
Ein LLM-Dienst in Produktion ist eine Blackbox mit probabilistischem Kern: keine Exceptions, keine Stacktraces, kein „geht/geht nicht“. Eine Antwort kann formal ein 200 OK sein und trotzdem inhaltlich falsch. Wenn du nicht pro Request festhältst, was hineinging, was herauskam und womit es bedient wurde, kannst du einen Incident weder erkennen noch reproduzieren.
Observability ist die Grundlage der ganzen Betriebsschleife: beobachten → erkennen → ändern → betreiben. Dieses Modul baut den ersten Schritt — die anderen drei bauen darauf auf. Alles Weitere im Track (Drift erkennen, sicher ausrollen, SLOs halten) setzt voraus, dass das System sichtbar ist.
Was pro Request erfassen — Umfang gegen Volumen
Der brauchbare Minimalumfang je Request ist mehr als nur die Antwort. Ohne Input, Versionen und Retrieval-Kontext ist ein Fall nicht reproduzierbar; mit rohem Volltext von allem sprengst du bei hohem Traffic Speicher und Kosten.
| Input & Output | Wortlaut oder gekürzt/referenziert — nötig, um den Fall nachzuspielen |
|---|---|
| Token-Zahlen | Prompt- und Completion-Tokens — Basis für Kosten und Latenz-Diagnose |
| Latenz | gesamt UND pro Pipeline-Stufe (siehe Tracing) |
| Kosten | pro Request abgeleitet, für Anomalie-Erkennung |
| Modell- & Prompt-Version | welcher Snapshot/welche Vorlage bediente den Request (siehe Provenienz) |
| Retrieval-Kontext | Referenzen (Doc-IDs, Scores) statt Volltext — spart Volumen, bleibt nachvollziehbar |
Verteiltes Tracing: eine Latenzzahl reicht nicht
Eine LLM-Antwort durchläuft meist mehrere Stufen. Eine einzige aggregierte Latenzzahl sagt dir, dass es langsam ist — aber nicht wo.
- Retrieval
- Rerank
- LLM
- Postprocess
Mit verteiltem Tracing wird jede Stufe zu einem Span unter einer gemeinsamen Trace-/Korrelations-ID. Der Trace zeigt die Zeit pro Stufe und ihre Verschachtelung (parent/child). So sieht man, dass die p95-Regression aus dem Retrieval kommt — und kann einen einzelnen langsamen Request durch alle Stufen verfolgen.
Sampling: welche Traces vollständig behalten
100 % aller Traces mit vollem Payload zu speichern ist bei hohem Traffic zu teuer und PII-lastig. Sampling entscheidet, welche Traces bleiben — und wann die Entscheidung fällt:
| Head-based | Entscheidung am Trace-Start, meist zufällig (z. B. 5 %). Billig, aber outcome-blind — der Ausgang ist noch unbekannt, also fallen die meisten Fehler weg. |
|---|---|
| Tail-based | Entscheidung nachdem alle Spans da sind. Erlaubt outcome-basierte Regeln, braucht aber einen Puffer für alle laufenden Traces. |
| Error-/latency-biased | eine Tail-Regel: behalte alle Fehler und langsamen Traces, plus eine kleine Zufallsbasis normaler Traces. |
Laufzeit-Provenienz: womit wurde dieser Request bedient?
Ein Nutzer meldet eine schlechte Antwort von vor drei Tagen. Seitdem wurde ein neuer Prompt deployt und der Provider hat sein Modell still aktualisiert. Ohne festgehaltene Provenienz ist der Fall nicht reproduzierbar.
Stemple jeden Request mit der exakten Prompt-Version (Hash/Tag), der Modell-Identität inkl. Snapshot/Version und der aufgelösten Config (Temperatur, Retrieval-Parameter, aktive Feature-Flags/Experiment-Zuweisung). Diese Provenienz reist mit dem Trace.
Feedback-Signale als Telemetrie
Ohne Labels ist Nutzer-Feedback ein wertvolles Qualitätssignal. Explizit ist 👍/👎 — aber freiwilliges Feedback ist spärlich und verzerrt (meist nur sehr verärgerte oder begeisterte Nutzer, oft unter wenigen Prozent Klickrate).
Implizite Signale aus dem Nutzerverhalten ergänzen das Bild und decken die Mehrheit ab:
- Regenerate / „nochmal“ — die Antwort taugte nicht
- Copy-to-Clipboard — die Antwort war brauchbar (mit Vorsicht: kann auch Eskalation sein)
- Folgefrage als Umformulierung — das Ziel wurde verfehlt
- schneller Abbruch der Sitzung — kein Erfolg
Metrik vs. Trace vs. Log — und die Kardinalitäts-Falle
Nicht jedes Signal gehört in denselben Store. Die richtige Wahl hängt an der Kardinalität — der Anzahl unterschiedlicher Werte:
| Metrik | aggregierbar, günstig, niedrige Kardinalität (Labels wie Modell, Endpoint, Status). Für Dashboards & Alerts. |
|---|---|
| Trace | ein Request über alle Stufen, mit hoher Detailtiefe. Für Ursachensuche eines konkreten Requests. |
| Log | diskrete Ereignisse mit Kontext. Für nachträgliche Detail-Recherche. |
In Zeitreihen-Backends erzeugt jede eindeutige Kombination aus Metrik-Name und Label-Werten eine eigene Zeitreihe. Hochkardinale Labels wie user_id oder prompt_id (tausende Werte) multiplizieren sich mit den übrigen Labels und sprengen Speicher und Ingestion — die „Cardinality Bomb“. Solche per-Request-Details gehören in Traces/Logs, nicht in Metrik-Labels.
Zusammenfassung — gleich entscheidest du
Du kennst jetzt die Achsen, ein LLM-System sichtbar zu machen: Telemetrie-Umfang, Tracing & Spans, Trace-Sampling, Laufzeit-Provenienz, Feedback-Signale und die Metrik-vs-Trace-vs-Log-Entscheidung mit ihrer Kardinalitäts-Falle.