AI Observability Implementierungs-Checkliste: 20 Produktionsschritte
Eine AI Observability Implementierungs-Checkliste sollte eine schwierigere Frage beantworten als „ist die API verfügbar?“ Eine produktive AI-Funktion kann HTTP 200 zurückgeben und trotzdem die falsche Antwort liefern, veralteten Retrieval-Kontext verwenden, das falsche Tool aufrufen, über einen teuren Fallback erneut versuchen, sensible Prompt-Daten in Logs preisgeben oder zu lange brauchen, um nützlich zu sein.
Das praktische Ziel besteht darin, jedes für den Nutzer sichtbare Ergebnis mit den Modellversuchen, Retrieval-Schritten, Tool-Aufrufen, Richtlinienentscheidungen, der Latenz, der Token-Nutzung und den Kosten zu verknüpfen, die es erzeugt haben. Dafür braucht es konventionelle Anwendungs-Telemetrie plus AI-spezifischen Kontext und Evaluierungssignale.
Dieser Leitfaden bietet einen phasenweisen Implementierungsplan für LLM-Anwendungen, Agenten, Retrieval-Augmented-Generation-Systeme und Multi-Model-Gateways. Er ist anbieterneutral und verwendet, wo möglich, OpenTelemetry-Konzepte. Außerdem enthält er eine Signal-zu-Entscheidung-Matrix, eine Akzeptanztest-Matrix, einen Sieben-Tage-Rollout-Plan, einen Telemetrievertrag, ein Instrumentierungsmuster, ein Alarm-Runbook und eine Vendor-Scorecard, damit ein Team von den Anforderungen zu einem operativen Launch gelangen kann.
AI Observability in einem Satz
AI Observability ist die Fähigkeit, das Verhalten, die Qualität, die Zuverlässigkeit, die Sicherheit und die Kosten eines AI-Workflows aus einer korrelierten Menge von Traces, Metriken, Logs, Evaluierungen und Nutzerergebnissen zu erklären.
Monitoring sagt Ihnen, dass sich ein Schwellenwert verändert hat. Observability hilft Ihnen zu bestimmen, warum er sich verändert hat und welche Requests, Modelle, Prompts, Retrieval-Ergebnisse, Tools, Tenants oder Releases beteiligt waren.
Verwenden Sie die AI Observability Implementierungs-Checkliste in diesem Leitfaden als Release-Gate und nicht als einmalige Dokumentationsübung. Führen Sie sie immer dann erneut aus, wenn Sie ein Modell, einen Prompt, einen Retrieval-Index, ein Tool-Schema, eine Routing-Richtlinie oder einen Evaluator ändern.
Für eine AI-Anwendung kann ein einzelner Request mehrere unterschiedliche Versuche enthalten:
user action
└─ application workflow
├─ retrieval query
├─ model attempt 1
├─ tool call
├─ model attempt 2
└─ validation and user-visible result
Wenn diese Schritte nicht unter einer einzigen Trace- oder Request-Identität zusammengeführt werden können, wird Debugging zum Rätselraten.
Das minimale AI-Observability-Datenmodell
Das Datenmodell ist die Grundlage der AI Observability Implementierungs-Checkliste, weil jedes Dashboard, jeder Alarm, jede Evaluierung und jede Incident-Abfrage von konsistenten Korrelationsfeldern abhängt.
Beginnen Sie mit einem Trace auf Workflow-Ebene und Child-Spans für jede wesentliche Operation. OpenTelemetry definiert Traces, Metriken, Logs und Baggage als Kernsignale. Die generativen AI Semantic Conventions bieten einen sich entwickelnden Wortschatz für Modell- und Agentenoperationen und werden, Stand 4. August 2026, im dedizierten OpenTelemetry-Semantic-Conventions-Repository gepflegt. Da sich diese Konventionen weiterentwickeln können, pinnen Sie die Version, die Sie implementieren, und behalten Sie eine kleine interne Kompatibilitätsschicht bei, statt herstellerspezifische Feldnamen in Ihrem gesamten Code zu verstreuen.
Erfassen Sie mindestens diese Feldgruppen.
| Feldgruppe | Zu erfassen | Warum es wichtig ist |
|---|---|---|
| Korrelation | trace_id, request_id, Sitzungs-ID, Workflow, Umgebung, Release |
Verknüpft den gesamten Anfragepfad |
| Route | Provider, angefordertes Modell, aufgelöstes Modell, Region, Endpunkt oder Routen-Alias | Erklärt, wo die Anfrage tatsächlich ausgeführt wurde |
| Versuch | Versuchsnummer, Wiederholungsgrund, Fallback-Quelle und -Ziel | Trennt eine Benutzeranfrage von mehreren abrechenbaren Aufrufen |
| Leistung | Wartezeit in der Queue, Zeit bis zum ersten Token, Gesamtlatenz, Tool- und Retrieval-Latenz | Lokalisert die langsame Phase |
| Nutzung | Eingabe, zwischengespeicherte Eingabe, Ausgabe, Reasoning oder anbieterspezifische Nutzungsfelder | Erklärt Kapazität und Kosten |
| Ergebnis | Status, normalisierte Fehlerklasse, Abschlussgrund, Validierungsergebnis | Unterscheidet Transporterfolg von Aufgabenerfolg |
| Qualität | Version des Evaluators, Score, bestanden/nicht bestanden, Benutzerfeedback, akzeptiertes Ergebnis | Verfolgt, ob die Antwort nützlich war |
| Governance | Mandant, Richtlinienentscheidung, Redaktionsstatus, Aufbewahrungsklasse | Unterstützt Datenschutz- und Auditkontrollen |
Vermeiden Sie es, den Roh-Prompt und die Roh-Antwort als verpflichtende Felder zu behandeln. In vielen Systemen sollten sie standardmäßig deaktiviert sein oder nur in einem separat kontrollierten Evaluierungsdatensatz gespeichert werden.
Jedes Signal einer betrieblichen Entscheidung zuordnen
Mehr Telemetrie ist nicht automatisch besser. Bevor Sie ein Attribut, eine Metrik oder ein Dashboard hinzufügen, benennen Sie die Entscheidung, die es unterstützt, und die Person, die für diese Entscheidung verantwortlich ist.
| Signal | Welche Frage beantwortet es? | Typische Entscheidung | Primärer Verantwortlicher |
|---|---|---|---|
| Annahme-Rate abgeschlossener Vorgänge | Hat der Workflow die Kundenaufgabe gelöst? | Rollback, Prompt/Modell ändern oder nachgelagerte Fehler untersuchen | Produkt- und AI-Engineering |
| p95 End-to-End-Latenz | Ist das gesamte Erlebnis schnell genug? | Route ändern, Retrieval-/Tool-Latenz reduzieren oder Streaming anpassen | Plattform-Engineering |
| Zeit bis zum ersten Token | Wirkt Streaming reaktionsschnell? | Queueing, Provider-Route oder Prompt-Größe optimieren | Plattform-Engineering |
| Fallback-Rate | Ist die primäre Route gesund und wirtschaftlich? | Provider-Gesundheit, Kapazität oder Routenrichtlinie untersuchen | Zuverlässigkeits-Engineering |
| Kosten pro akzeptiertem Ergebnis | Verbrauchen Wiederholungen und schlechte Ergebnisse die Einsparungen? | Modellmix, Caching, Prompt-Größe oder Validierung ändern | Engineering und FinOps |
| Erfolgsrate der Retrieval-Absicherung | Verwendete die Antwort autorisierten, relevanten Kontext? | Index, Filter, Reranker oder Zitationsvalidierung neu aufbauen | Search/RAG-Verantwortlicher |
| Fehler bei der Tool-Abstimmung | Wurde ein externer Seiteneffekt sicher abgeschlossen? | Das Tool pausieren, Zustand abgleichen oder Idempotenz reparieren | Anwendungsverantwortlicher |
| Anzahl der Redaktionsfehler | Gelangen sensible Daten zum Exporter? | Export stoppen, Telemetrie quarantänisieren oder Richtlinie aktualisieren | Sicherheit/Datenschutz |
Diese Tabelle verhindert den häufigen Fehler, dass ein Dashboard Dutzende von Diagrammen enthält, aber niemand weiß, welche Aktion eine Änderung auslösen sollte.
Eine praxisnahe Trace-Struktur
Verwenden Sie einen Trace für den für den Nutzer sichtbaren Workflow, nicht einen unabhängigen Trace pro Provider-Aufruf. Die Wurzel sollte die Kundenaufgabe beschreiben, während Child-Spans die Operationen beschreiben, die zum Ergebnis beigetragen haben.
workflow: answer_support_question
attributes: tenant_class, release, accepted_outcome, final_status
├─ retrieval.search
│ attributes: index_version, top_k, authorization_result
├─ gen_ai.attempt
│ attributes: provider, requested_model, resolved_model, attempt=1
├─ tool.lookup_order
│ attributes: tool_schema_version, idempotency_key, result
├─ gen_ai.attempt
│ attributes: provider, resolved_model, attempt=2, fallback_reason
└─ evaluation.validate_answer
attributes: evaluator_version, pass, score_band
Die semantischen Konventionen für generative KI von OpenTelemetry entwickeln sich noch weiter. Behandeln Sie sie als gemeinsame Fachsprache, aber fixieren Sie die Version der Konvention, dokumentieren Sie alle lokalen Erweiterungen und testen Sie Upgrades in Staging. Halten Sie Geschäftsergebnisse wie accepted_outcome in Ihrem eigenen stabilen Anwendungs-Namespace, damit eine Änderung der semantischen Konvention das Produkt-Reporting nicht unterbricht.
Stufe 1: Definieren Sie Ergebnisse, bevor Sie Dashboards hinzufügen
1. Benennen Sie den Workflow und das akzeptierte Ergebnis
Beginnen Sie nicht mit providerweiten Token-Diagrammen. Beginnen Sie mit einer Kundenaufgabe wie:
- Support-Antwort ohne Eskalation akzeptiert;
- Code-Patch besteht Tests;
- Extraktion entspricht dem erforderlichen Schema;
- Agent schließt die angeforderte Aktion ohne manuelle Wiederherstellung ab;
- generierte Medien passieren das Product-Review-Gate.
Erstellen Sie einen maschinenlesbaren workflow-Namen und ein accepted_outcome oder ein entsprechendes Ergebnis. Dies wird zum Nenner für Qualitäts-, Kosten- und Zuverlässigkeitsmetriken.
2. Definieren Sie die Fehler-Taxonomie
Trennen Sie mindestens diese Klassen:
- Transportfehler: Timeout, Verbindungsfehler oder Upstream-5xx;
- Kapazitätsfehler: Rate Limit, Kontingent, Warteschlangensättigung oder Kontextlimit;
- Vertragsfehler: ungültiges JSON, fehlendes Feld, nicht unterstütztes Tool-Schema oder beschädigter Stream;
- Qualitätsfehler: Antwort ist irrelevant, falsch, unvollständig oder nicht fundiert;
- Sicherheitsfehler: Richtlinienverstoß, erfolgreicher Prompt-Injection-Angriff oder unsichere Tool-Ausführung;
- Geschäftsfehler: technisch gültige Ausgabe, die der Nutzer ablehnt oder abbricht.
Eine einzelne error=true-Dimension reicht nicht aus. Sie verschleiert, ob Sie Infrastrukturarbeit, eine Prompt-Änderung, eine Modelländerung oder eine Produktänderung benötigen.
3. Wählen Sie erste Service-Level-Indikatoren aus
Beginnen Sie mit einem kleinen Satz, der die Nutzererfahrung widerspiegelt:
workflow availability = accepted workflow completions / eligible workflow starts
quality pass rate = evaluator-passing completions / evaluated completions
p95 end-to-end latency = p95(workflow completed - workflow started)
cost per accepted outcome = total workflow cost / accepted outcomes
Behalten Sie die Verfügbarkeit des Providers als Diagnosemetrik bei, nicht als Produkt-SLI. Ein Provider kann gesund sein, während Ihr Workflow fehlschlägt, weil Retrieval, Tools, Validierung oder Routing defekt sind.
Stufe 2: Den vollständigen Request-Pfad instrumentieren
4. Erstellen Sie einen Root-Span pro für den Benutzer sichtbaren Workflow
Generieren Sie den Root-Trace an der Anwendungsgrenze, bevor Retrieval oder Model-Routing beginnt. Propagieren Sie diesen Kontext durch Queues, Worker, Gateways, Tool-Services und Callbacks.
Verwenden Sie Child-Spans für:
- Retrieval und Reranking;
- jeden Modellversuch;
- jeden Tool-Aufruf;
- Guardrail- oder Policy-Prüfungen;
- Output-Parsing und Validierung;
- Fallback-Auswahl;
- Persistenz und nachgelagerte Zustellung.
5. Zeichnen Sie die angeforderte und die aufgelöste Route auf
Das vom Client benannte Modell ist nicht immer das Modell, das die Anfrage bedient hat. Zeichnen Sie beides auf:
{
"ai.requested_model": "support-balanced",
"ai.resolved_provider": "provider-b",
"ai.resolved_model": "model-version-2026-07",
"ai.route_reason": "primary_rate_limited",
"ai.attempt": 2
}
Das ist für Multi-Provider-Systeme essenziell. Außerdem macht es eine Model-Fallback-Strategie überprüfbar statt unsichtbar.
6. Messen Sie Streaming separat
Die Gesamtlatenz allein beschreibt kein Streaming-Erlebnis. Erfassen Sie:
- Warteschlangendauer;
- Verbindungs- und Provider-Latenz;
- Zeit bis zum ersten Token oder ersten nützlichen Ereignis;
- Generierungsdauer;
- End-to-End-Abschlusszeit;
- Zeitpunkt der Client-Abmeldung.
Eine Anfrage kann eine akzeptable Gesamtlatenz haben, aber eine schlechte Zeit bis zum ersten Token. Sie kann auch das erste Token schnell erzeugen und dann hängen bleiben.
7. Machen Sie Retries und Fallbacks zu erstklassigen Versuchen
Überschreiben Sie niemals den ersten fehlgeschlagenen Versuch mit dem finalen Erfolg. Ein Workflow-Span sollte jeden abrechenbaren Versuch enthalten oder mit ihm verknüpft sein, einschließlich:
- Retry-Nummer;
- Auslöser;
- Backoff-Dauer;
- Provider und Modell;
- Tokens und Kosten;
- Status der Teilausgabe;
- endgültige Behandlung.
Dadurch wird verhindert, dass eine Retry-Sturmwelle als „100% Erfolg“ erscheint.
Stufe 3: AI-spezifischen Qualitätskontext hinzufügen
8. Versionieren Sie Prompts, Tools, Richtlinien und Evaluatoren
Speichern Sie stabile Kennungen statt nur des Rohinhalts:
prompt_version
tool_schema_version
retrieval_index_version
policy_version
evaluator_version
route_policy_version
Diese Dimensionen ermöglichen es Ihnen, eine Version vor und nach einer Änderung zu vergleichen. Ohne Versionierung wird es schwierig, einen Qualitätsabfall zuzuordnen.
9. Verfolgen Sie die Retrieval-Qualität
Für Retrieval-Augmented Generation erfassen Sie:
- Query-Version und Filter;
- Retrieval-Latenz;
- Dokument- oder Chunk-IDs;
- Aktualität der Quelle;
- Top-k und Reranker-Version;
- Rate leerer Ergebnisse;
- Access-Control-Entscheidung;
- Ergebnis der Zitations- oder Grounding-Validierung.
Speichern Sie keine vollständigen privaten Dokumente in einem allgemeinen Trace-Speicher. Speichern Sie kontrollierte Verweise oder Hashes, sofern die Debugging-Richtlinie nicht ausdrücklich das Erfassen von Inhalten erlaubt.
10. Verfolgen Sie Tool-Aufrufe und Seiteneffekte
Jede Tool-Spanne sollte den Tool-Namen, die Schema-Version, die Autorisierungsentscheidung, die Latenz, das normalisierte Ergebnis und die Information enthalten, ob sie eine externe Nebenwirkung erzeugt hat.
Bei Tools mit Nebenwirkungen sollten außerdem ein Idempotenzschlüssel und der Abstimmungsstatus erfasst werden. Das ist wichtig, wenn ein Modellaufruf nach Abschluss des Tools ein Timeout hat.
11. Online- und Offline-Bewertungen zusammenführen
Online-Signale sind schnell, aber verrauscht: Daumen hoch, Abbruch, erneute Generierung, Korrektur, Eskalation oder Aufgabenerledigung. Offline-Bewertungen sind langsamer, aber kontrolliert: kuratierte Testmengen, Rubrik-Bewertungen, ausführbare Tests und menschliche Prüfung.
Verknüpfen Sie beide mit denselben Workflow- und Versionskennungen. Mischen Sie keine Werte aus unterschiedlichen Versionen von Bewertungsmodellen in einer Trendlinie, ohne die Änderung zu kennzeichnen.
Stufe 4: Datenschutz, Sicherheit und Aufbewahrung steuern
12. Telemetrie vor der Erfassung klassifizieren
Definieren Sie drei Stufen:
- Metadaten: Route, Zeit, Token, Status, Versionen und IDs.
- Abgeleitete Inhaltssignale: Länge, Sprache, Sicherheitskategorie, Bewertungs-Score oder Hash.
- Rohinhalt: Prompts, Antworten, abgerufener Text, Tool-Argumente und Tool-Ergebnisse.
Erfassen Sie Metadaten breit. Erfassen Sie Rohinhalt nur dann, wenn der Anwendungsfall, der Nutzerhinweis, die Zugriffskontrolle und die Aufbewahrungsrichtlinie dies unterstützen.
13. An der Erfassungsgrenze redigieren
Redaktion sollte nach Möglichkeit vor dem Export erfolgen. Decken Sie ab:
- API-Schlüssel, Bearer-Token, Cookies und Autorisierungs-Header;
- E-Mail-Adressen, Telefonnummern, Kontonummern und staatliche Identifikatoren;
- Geheimnisse in Tool-Argumenten oder abgerufenen Dokumenten;
- signierte URLs und Datenbank-Verbindungszeichenfolgen;
- tenant-spezifische Inhalte, die in gemeinsamen Observability-Speichern verboten sind.
Verwenden Sie Allowlists für exportierte Attribute. Eine Denylist wird irgendwann ein neues Feld mit geheimen Werten übersehen. Wenden Sie dieselbe Disziplin an, die in diesem Leitfaden zur Verwaltung von AI-API-Schlüsseln beschrieben wird.
14. Aufbewahrung und Zugriff nach Datenklasse festlegen
Rohinhalt sollte nicht dieselbe Aufbewahrungsfrist wie risikoarme Metriken erben. Definieren Sie getrennte Speicherung, Verschlüsselung, Zugriffsrollen, Audit-Logs und Löschprozesse. Testen Sie die Löschung, statt anzunehmen, dass ein Richtliniendokument ausreicht.
Das NIST AI Risk Management Framework und sein Generative-AI-Profil betonen fortlaufende Messung, Dokumentation und Risikomanagement über den gesamten Systemlebenszyklus hinweg. Observability hilft dabei, Nachweise zu liefern, aber wahlloses Logging kann ein neues Datenschutz- und Sicherheitsrisiko schaffen.
15. Hochkardinalitäts-Dimensionen kontrollieren
Verwandeln Sie Benutzer-IDs, Trace-IDs, Prompt-Text, Dokument-IDs oder rohe Fehlermeldungen nicht in Metrik-Labels. Bewahren Sie Daten mit hoher Kardinalität in Traces oder Logs auf und leiten Sie dann begrenzte Metriken wie Workflow, Modellfamilie, Fehlerklasse, Umgebung und Region ab.
Stufe 5: Alarme erstellen, die auf Maßnahmen hinweisen
16. Auf nutzerwirksame Symptome alarmieren
Alarmieren Sie bei Symptomen wie:
- freigegebene Abschlussrate unter dem Ziel;
- Qualitäts-Erfolgsrate, die unter die Release-Schranke fällt;
- p95-Latenz oder Zeit bis zum ersten Token, die das Fehlerbudget aufbraucht;
- Kosten pro akzeptiertem Ergebnis, die das Limit überschreiten;
- unsichere Nebenwirkung oder Richtlinienverstoß;
- Fallback-Rate, die über ihr normales Band steigt.
Verwenden Sie Provider-Fehler, Token-Spitzen und Retrieval-Misses als Diagnosealarme oder Dashboard-Signale, sofern sie das benutzerseitige Ziel nicht direkt gefährden.
17. Verwenden Sie Burn-Rate-Fenster für SLO-Alarme
Ein statischer Schwellenwert kann viel Rauschen erzeugen. Beim Error-Budget-Burn-Rate-Alerting wird gefragt, wie schnell der Dienst das zulässige Ausfallbudget verbraucht. Die SRE-Leitlinien von Google empfehlen, ein schnelleres Fenster mit einem langsameren Bestätigungsfenster zu kombinieren, damit schwere Vorfälle schnell paged werden, ohne dass jeder kurze Spike alarmierend ist.
18. Fügen Sie Release- und Routen-Anmerkungen hinzu
Jedes Dashboard sollte Prompt-, Anwendungs-, Routing-, Modell- und Evaluator-Releases anzeigen. Fügen Sie Deployment-Anmerkungen hinzu und vergleichen Sie Canary- mit Kontrollkohorten. Andernfalls sieht das Team eine Linie sich bewegen, ohne zu sehen, was sich geändert hat.
Stufe 6: Vor dem vollständigen Rollout validieren
19. Führen Sie Ausfalltests durch
Testen Sie mindestens:
- Upstream-Timeout;
- Rate-Limit- und Kontingenterschöpfung;
- fehlerhafte strukturierte Ausgabe;
- teilweise Unterbrechung des Streamings;
- Retrieval liefert keinen autorisierten Kontext zurück;
- Tool ist erfolgreich, aber die Antwort geht verloren;
- Fallback verändert das Modellverhalten;
- der Telemetrie-Exporter ist nicht verfügbar;
- eine Redaktionsregel erhält ein unbekanntes Feld.
Bestätigen Sie, dass der Workflow sicher fehlschlägt, der Trace kohärent bleibt und der Alarm den richtigen Owner identifiziert.
20. Rollen Sie in vier Stufen aus
- Shadow: Telemetrie ausgeben, ohne Routing oder Nutzerverhalten zu ändern.
- Canary: für einen kleinen Traffic-Anteil aktivieren und Overhead, Kardinalität und Datenqualität vergleichen.
- Geschützte Produktion: Release-Schwellenwerte und Rollback-Regeln anhängen.
- Vollproduktion: nach bestandenen Prüfungen zu Datenschutz, Zuverlässigkeit und Kosten ausweiten.
OpenTelemetry unterstützt Head- und Tail-Sampling-Muster. Bewahren Sie nach Möglichkeit alle Fehler und seltenen Fehlerklassen auf und sampeln Sie dann Routine-Erfolgstraffic, um die Kosten zu kontrollieren. Sampling-Regeln dürfen nicht genau die Traces entfernen, die benötigt werden, um einen Vorfall zu erklären.
Produktions-Abnahmetest-Matrix
Abnahmetests beweisen, dass die AI Observability Implementierungs-Checkliste unter Fehler-, Datenschutz- und Telemetrieverlust-Szenarien funktioniert und nicht nur bei erfolgreichen Anfragen.
Erklären Sie Observability nicht für abgeschlossen, nur weil Spans in einem Trace-Viewer erscheinen. Führen Sie kontrollierte Tests durch und speichern Sie Belege für jede Release-Gate.
| Test | Injected condition | Required telemetry evidence | Pass condition |
|---|---|---|---|
| Upstream-Timeout | Erzwingen, dass der primäre Modellpfad seine Deadline überschreitet | Span des ersten Versuchs, Timeout-Klasse, Retry- oder Fallback-Entscheidung, finales Ergebnis | Keine verwaisten Spans; finale Zuordnung und Gesamtkosten sind sichtbar |
| Rate-Limit | Einen Provider-429 zurückgeben oder ein Testkontingent ausschöpfen | Roh-Provider-Code, normalisierte Kapazitätsklasse, Backoff-Dauer, Routenwechsel | Das Retry-Budget ist begrenzt und der Alarm verweist auf den Routenverantwortlichen |
| Invalid Structured Output | Ungültiges JSON oder ein fehlendes Pflichtfeld zurückgeben | Contract-Validierungs-Span, Version des Validators, Reparaturversuch, finales Pass/Fail | HTTP-Erfolg wird nicht als akzeptierter Erfolg gezählt |
| Broken Stream | Die Ausgabe nach dem ersten Token unterbrechen | Zeit bis zum ersten Token, Flag für partielle Ausgabe, abrechenbare Nutzung, Retry-Entscheidung | Doppelte Inhalte und doppelte Tool-Ausführung werden verhindert |
| Empty Retrieval | Keine autorisierten Dokumente zurückgeben | Retrieval-Filter, Autorisierungsergebnis, Grund für leeres Ergebnis, Antwort-Policy | Das System folgt dem freigegebenen Verhalten ohne Kontext |
| Tool Ambiguity | Ein Tool fertig werden lassen, während die Modellanfrage abläuft | Idempotency-Key, Zustand der Side Effects, Abgleichsergebnis | Das Tool wird nicht zweimal ausgeführt und der Zustand ist wiederherstellbar |
| Redaction Canary | Einen synthetischen Secret-Wert in ein Testfeld einfügen | Lokales Erkennungsereignis ohne exportierten Secret-Wert | Der Export wird blockiert oder vor dem Verlassen der Grenze redigiert |
| Exporter Outage | Das Telemetrie-Ziel stoppen | Exporter-Queue/Drop-Metriken und Anwendungszustand | Der User-Traffic bleibt innerhalb seines Zuverlässigkeitsbudgets |
| Sampling Check | Seltener auftretende Fehler bei hohem Anteil erfolgreichem Traffic erzeugen | Fehler-Traces aufbewahrt; Routine-Erfolge wie konfiguriert gesampelt | Beispiele von Vorfällen bleiben nach dem Sampling durchsuchbar |
| Release Regression | Ein Canary-Deployment mit bekannter Latenz- oder Qualitätsverschlechterung ausrollen | Release-Annotation, Canary-Kohorte, Kontroll-Kohorte, SLI-Vergleich | Der Rollback-Schwellenwert greift mit einem identifizierbaren Change Owner |
Für jeden Test erfassen Sie den Owner, das Testdatum, die Trace-ID, den erwarteten Alarm, den beobachteten Alarm und das Remediation-Ticket. So wird Observability zu einer wiederholbaren Release-Kontrolle statt zu einem einmaligen Instrumentierungsprojekt.
Seven-Day Implementation Plan
Für ein fokussiertes Team kann die AI observability implementation checklist als siebentägige Abfolge umgesetzt werden, bei der jeder Tag mit prüfbaren Nachweisen endet.
Diese Abfolge ist bewusst eng gefasst. Sie liefert einen vertrauenswürdigen vertikalen Ausschnitt, bevor das Team den Umfang erweitert.
- Tag 1 — Ergebnisvertrag: Wählen Sie einen Workflow mit hohem Wert, definieren Sie zulässige Starts, akzeptierte Ergebnisse, Fehlerklassen und SLI-Formeln.
- Tag 2 — Trace-Skelett: Erstellen Sie den Root-Workflow-Span und propagieren Sie den Kontext durch die Anwendung, die Warteschlange, das Gateway, die Retrieval-Schicht und die Tools.
- Tag 3 — Modellversuche: Erfassen Sie angeforderte und aufgelöste Routen, Versuche, Latenz, Abschlussgrund, Provider-Nutzung, Wiederholungen und Fallbacks.
- Tag 4 — Qualität und Kosten: Verknüpfen Sie Validierungsergebnisse, Evaluator-Versionen, Benutzerergebnisse und normalisierte Workflow-Kosten.
- Tag 5 — Datenschutzkontrollen: Klassifizieren Sie Felder, implementieren Sie einen Allowlist-Export, testen Sie die Schwärzung, legen Sie die Aufbewahrung fest und überprüfen Sie die Zugriffsgrenzen.
- Tag 6 — SLOs und Dashboards: Erstellen Sie das Minimum-Dashboard, fügen Sie Release-Anmerkungen hinzu, definieren Sie Burn-Rate-Alarme und weisen Sie Verantwortliche zu.
- Tag 7 — Fehlerübungen: Führen Sie die Abnahmematrix aus, beheben Sie Lücken, starten Sie ein Canary und dokumentieren Sie Rollback-Bedingungen.
Am Ende von Tag sieben ist das Ziel keine universelle Instrumentierung. Das Ziel ist ein Produktions-Workflow, dessen Verhalten, Qualität, Zuverlässigkeit, Sicherheit und Kosten von Anfang bis Ende erklärt werden können.
Minimum-Dashboard für den Start
Das Dashboard ist die operative Ansicht der AI Observability Implementation Checklist. Es sollte zuerst Kundenergebnisse und erst danach Infrastrukturdetails anzeigen.
Halten Sie die erste operative Ansicht klein genug, um sie während eines Vorfalls zu verwenden:
- Ergebniszeile: zulässige Starts, akzeptierte Abschlüsse, Qualitäts-Through-Rate und Abbruch oder Eskalation.
- Zuverlässigkeitszeile: normalisierte Fehler, Fallback-Rate, Retry-Verstärkung und Verbrauch des Fehlerbudgets.
- Latenzzeile: End-to-End p50/p95/p99, Warteschlangenzeit, Zeit bis zum ersten Token, Retrieval-Latenz und Tool-Latenz.
- Wirtschaftszeile: Input-/Output-/Cache-Token, gesamte Workflow-Kosten und Kosten pro akzeptiertem Ergebnis.
- Änderungszeile: Anwendung, Prompt, Routenrichtlinie, Modell, Retrieval-Index, Tool-Schema und Evaluator-Releases.
- Untersuchungslinks: repräsentative Traces für jede Fehlerklasse, jeden Release, jede Route und jeden betroffenen Workflow.
Das Dashboard sollte einen Pfad vom Symptom zum Trace unterstützen. Wenn ein Alarm einen Qualitätsabfall anzeigt, das Team aber in wenigen Klicks keine Traces betroffener Workflows erreichen kann, ist der Untersuchungszyklus unvollständig.
Bewertungskarte für die Evaluation der AI Observability Platform
Die kommerzielle Bewertung sollte prüfen, ob eine Plattform Ihr Betriebsmodell unterstützt, und nicht, ob sie die längste Funktionsliste hat. Bewerten Sie Kandidaten anhand derselben instrumentierten Pilot-Workload.
| Kriterium | Gewichtung | Was in einem Pilotprojekt zu verifizieren ist |
|---|---|---|
| Workflow-Korrelation | 20% | Ein Trace verbindet Modellversuche, Retrieval, Tools, Validierung und das Nutzerergebnis |
| OpenTelemetry-Interoperabilität | 15% | Standard-Export/-Import funktioniert; lokale Erweiterungen bleiben abfragbar; Daten sind portierbar |
| Quality- und Evaluation-Joins | 15% | Online-Feedback und versionierte Offline-Evaluierungen sind mit Produktions-Traces verbunden |
| Datenschutz und Governance | 15% | Feld-Allowlists, Redaction, regionale Kontrollen, Zugriffsrollen, Audit-Logs und Löschtests |
| Zuverlässigkeitsbetrieb | 15% | SLOs, Burn-Rate-Alarme, Sampling-Kontrollen, Release-Anmerkungen und Unterstützung für Incident-Drills |
| Kostenzuordnung | 10% | Provider-Nutzung, Retries, Fallbacks, gecachte Tokens und Kosten pro akzeptiertem Ergebnis sind abgestimmt |
| Abdeckung für Agent/RAG/Tools | 5% | Retrieval- und Side-Effect-Tool-Operationen haben erstklassige Spans und Filter |
| Betriebskosten | 5% | Ingestion, Storage, Query, Retention und Engineering-Overhead passen zum erwarteten Volumen |
Verwenden Sie für jedes Kriterium eine Bewertung von 1–5, multiplizieren Sie sie mit der Gewichtung und verlangen Sie schriftliche Nachweise aus dem Pilotprojekt. Eine Plattform, die Ihren Telemetrievertrag nicht beibehalten oder Ihre Daten nicht exportieren kann, erzeugt operativen Lock-in, auch wenn ihre Dashboards ausgefeilt aussehen.
Copyable Telemetry Contract
Der schnellste Weg, eine AI observability implementation checklist operativ nutzbar zu machen, besteht darin, sie in einen versionierten Telemetrievertrag zu überführen. Der Vertrag definiert, was jeder Workflow und jeder Modellversuch ausgeben muss, welche Felder optional sind, welche Werte zulässig sind und welche Felder in hochvolumigen Indizes verboten sind.
Das folgende Beispiel verwendet einen internen Namespace. Ordnen Sie ihn den fest verankerten OpenTelemetry-GenAI-Konventionen innerhalb eines Adapters zu, anstatt Anwendungscode Konventionsänderungen auszusetzen.
telemetry_contract:
version: "2026-08-04"
workflow_span:
required:
- ai.workflow.name
- ai.workflow.version
- ai.request.id
- deployment.environment
- service.version
- ai.outcome.status
- ai.outcome.accepted
- ai.latency.total_ms
optional:
- ai.tenant.tier
- ai.experiment.id
- ai.user.feedback
prohibited:
- end_user.email
- end_user.name
- raw.authorization_header
model_attempt_span:
required:
- ai.attempt.number
- ai.route.requested_model
- ai.route.resolved_provider
- ai.route.resolved_model
- ai.result.status
- ai.usage.input_tokens
- ai.usage.output_tokens
- ai.latency.first_token_ms
- ai.latency.total_ms
conditional:
- ai.fallback.reason
- ai.error.class
- ai.error.provider_code
- ai.usage.cached_input_tokens
content_capture:
default: "off"
allowed_when:
- approved_evaluation_dataset
- explicit_debug_session
controls:
- redact_before_export
- access_logged
- retention_approved
Überprüfen Sie diesen Vertrag im Code Review genauso wie ein API-Schema. Ein neuer Modellanbieter, ein Agent-Tool, eine Fallback-Richtlinie oder ein Evaluator darf nicht ausgeliefert werden, bis seine Telemetrie-Felder dem Vertrag zugeordnet sind und die gleichen Akzeptanztests bestehen.
Instrumentierungsmuster für einen KI-Workflow
Lassen Sie nicht jedes Team Span-Namen und Attribute unabhängig voneinander erfinden. Stellen Sie einen kleinen Wrapper bereit, der den root-Workflow-Span erstellt, untergeordnete Versuche aufzeichnet, normalisierte Ergebnisse erfasst und vor dem Export Redaction anwendet.
Dieses Python-Beispiel ist absichtlich provider-neutral. Die internen Attributnamen sollten in der Wrapper- oder Collector-Schicht auf Ihre festgelegte OpenTelemetry-Semantikversion übersetzt werden.
from opentelemetry import trace
tracer = trace.get_tracer("checkout-assistant")
def run_ai_workflow(request, router, evaluator):
with tracer.start_as_current_span("ai.workflow.checkout_help") as workflow_span:
workflow_span.set_attribute("ai.workflow.name", "checkout_help")
workflow_span.set_attribute("ai.workflow.version", "2026-08-04")
workflow_span.set_attribute("ai.request.id", request.request_id)
result = None
for attempt_number in range(1, 3):
with tracer.start_as_current_span("ai.model.attempt") as attempt_span:
route = router.resolve(request, attempt_number)
attempt_span.set_attribute("ai.attempt.number", attempt_number)
attempt_span.set_attribute("ai.route.requested_model", request.model)
attempt_span.set_attribute("ai.route.resolved_provider", route.provider)
attempt_span.set_attribute("ai.route.resolved_model", route.model)
result = route.generate(request)
attempt_span.set_attribute("ai.result.status", result.status)
attempt_span.set_attribute("ai.usage.input_tokens", result.input_tokens)
attempt_span.set_attribute("ai.usage.output_tokens", result.output_tokens)
if result.status == "ok":
break
attempt_span.set_attribute("ai.error.class", result.error_class)
evaluation = evaluator.score(request, result)
workflow_span.set_attribute("ai.outcome.status", result.status)
workflow_span.set_attribute("ai.outcome.accepted", evaluation.accepted)
workflow_span.set_attribute("ai.evaluator.version", evaluation.version)
workflow_span.set_attribute("ai.quality.score", evaluation.score)
return result
Produktionscode sollte außerdem Dauer, Zeit bis zum ersten Token, Fallback-Gründe, Abbrüche, Streaming-Fehler und Ausnahmen erfassen. Die wichtige Designentscheidung ist die Hierarchie: Ein Kunden-Workflow enthält einen oder mehrere abrechenbare Versuche, und der Workflow erfasst das endgültig akzeptierte Ergebnis.
Alarmrichtlinie und Runbook für die erste Reaktion
Eine Implementierungs-Checkliste für AI Observability ist unvollständig, wenn Dashboards keine Reaktionsregeln haben. Jede Startmetrik benötigt einen Auslöser, einen Verantwortlichen und eine erste Diagnoseabfrage.
| Alarm | Beispielauslöser | Erste Frage | Unmittelbare Maßnahme |
|---|---|---|---|
| Accepted-outcome burn | Schneller und langsamer Erschöpfungsverbrauch des Fehlerbudgets | Welcher Workflow, welches Release, welche Route oder welcher Tenant hat sich geändert? | Rollout pausieren oder das betreffende Release zurücksetzen |
| Latenz-Regression | Die p95-Workflow-Latenz überschreitet den SLO | Hat sich die Latenz von Queue, Retrieval, Modell oder Tool verschoben? | Den langsamen Schritt umgehen oder die Last reduzieren |
| Fallback-Spitze | Die Fallback-Rate überschreitet ihr normales Band | Fällt der primäre Provider aus, drosselt er oder treten Timeouts auf? | Normalisierte und rohe Provider-Fehler prüfen |
| Kosten-pro-Ergebnis-Spitze | Die Kosten steigen, während die Akzeptanz gleich bleibt oder sinkt | Nehmen Retries, Ausgabelänge oder teure Routen zu? | Retries begrenzen und die vorherige Routenrichtlinie wiederherstellen |
| Qualitäts-Score-Abfall | Die Pass-Rate des Online- oder Stichproben-Evaluators sinkt | Hat sich die Version von Prompt, Retrieval, Modell oder Evaluator geändert? | Den Release-Kohort mit dem zuletzt gesunden Kohort vergleichen |
| Tool-Unsicherheit | Das Ergebnis eines Seiteneffekts lässt sich nicht abgleichen | Wurde das Tool vor Timeout oder Abbruch beendet? | Automatische Wiederholung stoppen und in die Abgleichung übergehen |
| Telemetrieverlust | Die erwartete Vollständigkeit von Spans oder Nutzungsdaten sinkt | Ist die Instrumentierung defekt oder steigt der Export-Backpressure? | Fehlende Telemetrie als Betriebsvorfall behandeln |
Die On-Call-Ansicht sollte direkt von einem Alarm zu Traces verlinken, gefiltert nach Workflow, Release, angefordertes Modell, aufgelöste Route und Fehlerklasse. Wenn Einsatzkräfte diese Filter während eines Vorfalls manuell rekonstruieren müssen, ist das System nicht startbereit.
Verantwortlichkeiten und Produktionsübergabe
Weisen Sie die Checkliste vor dem Rollout benannten Rollen zu. Geteilte Verantwortung ohne explizite Entscheidungsinstanz führt in der Regel zu Dashboards, die zwar alle sehen können, die aber niemand pflegt.
| Verantwortung | Verantwortliche Rolle | Erforderlicher Übergabenachweis |
|---|---|---|
| Definition des Workflow-Ergebnisses | Produkt- oder AI-Feature-Owner | Regel für akzeptierte Ergebnisse und Beispiele für Ablehnungen |
| Span- und Metrik-Schema | Plattform- oder Observability-Owner | Versionierter Telemetrievertrag und Schema-Tests |
| Route- und Fallback-Felder | Gateway- oder Reliability-Owner | Validierung von angeforderter/aufgelöster Route und Versuch |
| Qualitäts-Evaluator | AI-Engineering-Owner | Evaluator-Version, Datensatz, Schwellwerte, bekannte Grenzen |
| Datenschutz und Aufbewahrung | Sicherheits- oder Datenschutz-Owner | Datenklassifizierung, Redaktions-Test, Freigabe der Aufbewahrung |
| SLOs und Alarme | Service-Owner | SLO-Dokument, Paging-Regeln, Dashboard, Runbook |
| Kostenzuordnung | Owner für Engineering-Finanzen | Vollständigkeit der Nutzung und Abgleich von Kosten pro Ergebnis |
| Release-Bereitschaft | Engineering-Leitung | Abgeschlossene Akzeptanzmatrix und Rollback-Auslöser |
Planen Sie 30 Tage nach dem Launch eine Überprüfung ein. Entfernen Sie nicht verwendete Felder, fördern Sie wiederholt nützliche Debug-Abfragen in Dashboard-Ansichten, überprüfen Sie Kardinalität und Speicherkosten und aktualisieren Sie den Vertrag, wenn sich das Workflow-Verhalten ändert.
Copyable AI Observability Implementation Checklist
Verwenden Sie diese Liste als Startfreigabe:
- [ ] Definieren Sie jeden Workflow und das akzeptierte Kundenergebnis.
- [ ] Definieren Sie Transport-, Kapazitäts-, Vertrags-, Qualitäts-, Sicherheits- und Geschäftsfehler.
- [ ] Wählen Sie SLIs für Verfügbarkeit, Qualität, Latenz und Kosten pro Ergebnis aus.
- [ ] Genehmigen Sie einen versionierten Telemetrievertrag mit erforderlichen, optionalen und verbotenen Feldern.
- [ ] Erstellen Sie einen Root-Trace pro für den Benutzer sichtbaren Workflow.
- [ ] Leiten Sie Kontext durch Queues, Tools, Retrieval und Gateways weiter.
- [ ] Zeichnen Sie angeforderte und aufgelöste Provider-/Modellrouten auf.
- [ ] Erstellen Sie einen separaten Span für jeden Retry- und Fallback-Versuch.
- [ ] Erfassen Sie Queue-Zeit, Zeit bis zum ersten Token und die gesamte Latenz.
- [ ] Erfassen Sie den vom Provider gemeldeten Tokenverbrauch und die normalisierten Kosten.
- [ ] Versionieren Sie Prompts, Tools, Retrieval-Indizes, Richtlinien, Routen und Evaluatoren.
- [ ] Zeichnen Sie Retrieval-Referenzen, Aktualität, Autorisierung und Grounding-Ergebnisse auf.
- [ ] Zeichnen Sie Tool-Autorisierung, Idempotenz, Ergebnis und Side-Effect-Status auf.
- [ ] Verknüpfen Sie Nutzerfeedback und Offline-Evaluationsergebnisse mit Traces.
- [ ] Klassifizieren Sie Telemetrie als Metadaten, abgeleitete Signale oder Rohinhalt.
- [ ] Schwärzen Sie Geheimnisse und sensible Felder vor dem Export.
- [ ] Wenden Sie separate Aufbewahrungs- und Zugriffsrichtlinien nach Datenklasse an.
- [ ] Halten Sie hochkardinale Werte aus Metrik-Labels heraus.
- [ ] Lösen Sie Alarme für SLOs mit Nutzerwirkung und Error-Budget-Verbrauch aus.
- [ ] Annotieren Sie Releases und vergleichen Sie Canary gegen Control.
- [ ] Führen Sie Drills für Ausfälle, Datenschutz, Sampling und Exporter-Ausfälle durch.
- [ ] Speichern Sie Nachweise aus Akzeptanztests und Trace-IDs für die Release-Freigabe.
- [ ] Vergleichen Sie Observability-Plattformen mit einer gewichteten Pilot-Scorecard.
- [ ] Benennen Sie verantwortliche Owner für Ergebnisse, Schema, Datenschutz, SLOs, Qualität und Kosten.
- [ ] Verknüpfen Sie jeden alarmwürdigen Alarm mit einem First-Response-Runbook und einer Trace-Abfrage.
Common AI Observability Mistakes
Prompts ohne Datenrichtlinie protokollieren
Roh-Prompts wirken beim Debugging nützlich, können aber Kundendaten, Geheimnisse, urheberrechtlich geschütztes Material oder regulierte Informationen enthalten. Beginnen Sie mit Metadaten und aktivieren Sie die kontrollierte Erfassung von Inhalten nur dort, wo sie gerechtfertigt ist.
Kosten pro Anfrage statt Kosten pro Ergebnis messen
Eine billige Anfrage, die die Validierung nicht besteht, ist nicht billig. Retries, Fallbacks und menschliche Korrektur gehören zu den Workflow-Kosten. Dasselbe Prinzip gilt für Prompt-Caching-ROI: Optimieren Sie die akzeptierte Aufgabe, nicht eine isolierte Token-Rate.
Jeden Modellaufruf als unabhängig behandeln
Agenten und RAG-Systeme sind Workflows. Wenn Modell-, Retrieval- und Tool-Spans nicht korreliert sind, kann das Team die Kausalität nicht rekonstruieren.
Sich auf ein einziges Provider-Dashboard verlassen
Provider-Dashboards sind nützlich für Upstream-Nutzung und Fehler, aber sie sehen nicht Ihr vollständiges Anwendungsergebnis, das Retrieval-System, die Tool-Ausführung, das Nutzerfeedback oder den Fallback-Pfad über mehrere Provider hinweg.
Alles instrumentieren, bevor Entscheidungen definiert sind
Telemetrie verursacht Betriebskosten. Jedes Feld sollte eine Entscheidung für Debugging, Alerting, Evaluierung, Governance oder Optimierung unterstützen. Entfernen Sie Felder, die niemand verwendet.
Where an AI Gateway Fits
Ein LLM-Gateway kann eine nützliche Korrelations- und Richtliniengrenze sein, da mehrere Anwendungen und Anbieter einen einzigen Kontrollpunkt durchlaufen. Es kann Metadaten zu Route, Versuch, Nutzung, Latenz und Fehlern normalisieren, bevor es Telemetrie an Ihren Observability-Stack exportiert.
Das Gateway ist nicht die Gesamtlösung. Der Anwendungscode bleibt weiterhin für Workflow-Ergebnisse, Retrieval-Kontext, Tool-Semantik, Nutzerfeedback und geschäftliche Konversion verantwortlich. Das stärkste Design verknüpft Gateway-Telemetrie mit diesen Signalen auf Anwendungsebene.
Flatkey bietet eine OpenAI-kompatible Zugriffsschicht für mehrere KI-Modelle. Wenn Ihr Team Anbieter-Integrationen konsolidiert, entdecken Sie Flatkey und verwenden Sie diese Checkliste, um den Telemetrievertrag rund um Ihre Anwendung und Routing-Schicht zu definieren.
Häufig gestellte Fragen
Was sollte ich zuerst für AI Observability implementieren?
Beginnen Sie die AI-Observability-Implementierungs-Checkliste mit einem Root-Trace pro Kunden-Workflow, Child-Spans für Modellversuche, angeforderten und aufgelösten Modellfeldern, Latenz, Nutzung, normalisierten Fehlern und einem Signal für ein akzeptiertes Ergebnis. Fügen Sie die Erfassung roher Prompts später hinzu, wenn Ihre Datenschutzrichtlinie dies erlaubt.
Reicht OpenTelemetry für LLM-Observability aus?
OpenTelemetry bietet die transportneutrale Grundlage für Traces, Metriken und Logs sowie sich weiterentwickelnde semantische Konventionen für generative KI. Sie benötigen dennoch Workflow-Definitionen, Evaluierungen, Datenschutzkontrollen, SLOs, Dashboards und Incident-Prozesse.
Sollten Prompts und Antworten in Traces gespeichert werden?
Nicht standardmäßig. Verwenden Sie zunächst Metadaten, Versionen, Hashes und abgeleitete Qualitätssignale. Speichern Sie Rohinhalte nur in kontrollierten Systemen mit einem expliziten Zweck, einer Zugriffsrichtlinie, einer Aufbewahrungsfrist und einem Löschprozess.
Welche AI-Observability-Metriken sind am wichtigsten?
Beginnen Sie mit der akzeptierten Abschlussrate, der Erfolgsrate der Qualitätsprüfung, der End-to-End-Latenz p95, der Zeit bis zum ersten Token beim Streaming, der Fallback-Rate und den Kosten pro akzeptiertem Ergebnis. Fügen Sie anschließend workflowspezifische Metriken hinzu, sobald diese vertrauenswürdig sind.
Wie überwache ich mehrere AI-Anbieter?
Verwenden Sie über alle Anbieter hinweg ein stabiles Telemetrie-Schema. Zeichnen Sie bei jedem Versuch sowohl die angeforderte Route als auch den aufgelösten Anbieter/das Modell auf, normalisieren Sie Fehler, ohne den rohen Anbieter-Code zu verwerfen, und verknüpfen Sie alle Versuche unter demselben Workflow-Trace.
