ClawHosters
von Daniel Samer
7 Min. Lesezeit
Ein Team hat einen System Prompt angepasst. Im Testing sah alles gut aus. In Produktion sprangen die Reasoning Chains von durchschnittlich 4 Schritten auf 11. Token-Kosten verdoppelt. Keine Fehler-Logs, keine Alerts, kein HTTP 500. Aufgefallen ist es erst bei der Monatsrechnung. Diesen Fall hat Agentix Labs dokumentiert, und er ist vermutlich das beste Argument für ai agent observability, das du je hören wirst.
Wenn du einen AI Agent in Produktion betreibst, reicht normales Uptime Monitoring nicht aus. Dein Agent kann "online" sein und trotzdem dein Budget verbrennen, 40 Mal denselben Tool Call wiederholen oder still und leise Instruktionen verlieren, weil das Context Window voll ist.
Hier ist, worauf du stattdessen achten solltest.
Warum klassisches Monitoring bei AI Agents versagt
Webanwendungen sind vorhersehbar. Gleicher Request, gleiche Antwort, gleicher Code Path. AI Agents funktionieren anders. Derselbe Input kann völlig unterschiedliche Ketten von Tool Calls auslösen, je nachdem, was das Modell in diesem Moment entscheidet.
Das erzeugt Probleme, die klassisches APM nicht erkennt.
Stille Fehler. Dein Agent liefert eine selbstsicher klingende falsche Antwort. Kein Error Code. Kein Stack Trace. Nur ein Nutzer, der falsche Informationen bekommen hat.
Kostenspirale. Ein einzelner Agent Turn kann 30.000 Input Tokens verbrauchen, wenn du System Prompt, Gesprächsverlauf, Tool Schemas und abgerufene Dokumente zusammenrechnest. Multipliziere das mit dutzenden Turns pro Task.
Loop Storms. Der Agent versucht denselben fehlschlagenden Tool Call immer wieder. Jeder Retry kostet Tokens. Kein Timeout, kein Circuit Breaker, nur eine wachsende Rechnung.
Du brauchst ai agent observability, die Verhalten trackt. Nicht nur Verfügbarkeit.
Der Open-Source Stack: OpenTelemetry, Prometheus, Grafana
Für llm observability in Self-Hosted Setups hat sich ein klarer Standard durchgesetzt. OpenTelemetrys GenAI Semantic Conventions definieren standardisierte Metrik-Namen, die Framework-übergreifend funktionieren. Zu den Contributors gehören Amazon, Google, IBM und Microsoft.
So sieht der Datenfluss aus:
| Komponente | Aufgabe |
|---|---|
| OpenTelemetry SDK | Instrumentiert deinen Agent, sendet Traces und Metriken |
| OTel Collector | Empfängt OTLP-Daten, exportiert an Backends |
| Prometheus | Scraped den Collector, speichert Time-Series Metriken |
| Grafana | Visualisiert alles, sendet Alerts |
Alle vier laufen neben deinem Agent in Docker Compose. Kein SaaS-Anbieter nötig. Deine Gesprächsdaten verlassen deinen Server nie. Im Vergleich zu bezahlten ai observability tools wie Datadog oder Honeycomb tauschst du ein schickes UI gegen volle Datenhoheit.
Sechs AI Agent Observability Metriken, die du tracken solltest
Nicht alles braucht ein Dashboard. Diese sechs fangen echte Probleme ab, basierend auf dem, was wir über ClawHosters Deployments hinweg beobachtet haben.
| Metrik | OTel Name | Warum sie wichtig ist |
|---|---|---|
| Token Usage | gen_ai.client.token.usage |
Kostenkontrolle. Aufschlüsselung nach Input vs. Output, nach Modell |
| Operation Duration | gen_ai.client.operation.duration |
End-to-End Latenz pro LLM Call |
| Time to First Token | gen_ai.server.time_to_first_token |
User Experience bei Streaming Responses |
| Tool Call Success Rate | Custom Counter | Fehlschlagende Tools verursachen Retry Loops |
| Agent Loop Iterations | Custom Counter | Erkennt außer Kontrolle geratene Reasoning Chains |
| Context Window Utilization | Custom Gauge | Über 80% bricht die Reasoning-Qualität drastisch ein |
Laut dem State of AI Agents Report 2024 von LangChain haben 89% der Organisationen mit Agents in Produktion bereits Observability Tools im Einsatz. Das ist kein Nice-to-have mehr. Das ist die Baseline.
OpenClaws eingebautes OTel Plugin
Wenn du OpenClaw auf einem ClawHosters Plan betreibst: gute Nachrichten. OpenClaw liefert ein diagnostics-otel Plugin mit, das die Instrumentierung für dich übernimmt.
Aktivieren geht mit einem Befehl:
openclaw plugins enable diagnostics-otel
OTLP Endpoint in der OpenClaw Config eintragen, neustarten, und deine Instanz beginnt Traces, Metriken und strukturierte Logs im Standard OTel Format zu exportieren. Token Counts, Cost Attribution, Execution Duration, Queue Depth, Session States. Alles dabei.
Von dort aus richtest du einen Prometheus Scrape Job auf den Metrics Endpoint des OTel Collectors und verbindest Grafana. Der SigNoz OpenClaw Monitoring Guide führt Schritt für Schritt durch das komplette Setup.
Für einen noch einfacheren Einstieg gibt es das Community-Paket openclaw-metrics. Es fügt direkt einen /metrics Prometheus Endpoint am Gateway hinzu und bringt ein fertiges Grafana Dashboard JSON mit, das rund 30 Metriken in sieben Kategorien abdeckt.
Grafana Alerting: Worauf du wirklich alerten solltest
Dashboards sind super für Exploration. Aber der echte Wert dieses Stacks ist grafana alerting, das dich aufweckt, bevor die Kosten eskalieren.
Diese Alerts solltest du einrichten:
Token Budget Threshold. Alert, wenn die täglichen Token-Ausgaben 120% deines 7-Tage-Durchschnitts überschreiten. Erkennt Prompt-Regressionen und Loop Storms früh.
Context Window Warning. Alert, wenn eine Session 80% des Context Limits des Modells erreicht. Ab diesem Punkt beginnt das Modell, frühe Instruktionen zu verlieren, und die Qualität sinkt rapide. Context Compression kann den Token-Verbrauch um 90% senken, aber nur wenn du weißt, dass sie gebraucht wird.
Tool Failure Rate Spike. Alert, wenn die Error Rate eines Tools 15% innerhalb eines 5-Minuten-Fensters überschreitet. Ein kaputtes Tool ist der häufigste Auslöser für Retry Loops.
Willst du wissen, was du noch tun kannst, um deine Instanz zu schützen? Hier ist unser Security Hardening Guide und unsere Analyse, wie du Token-Kosten um 77% senken kannst.
Häufige Fehler
Ein paar Dinge, über die Leute regelmäßig stolpern.
Volle Prompts loggen. Nicht machen. Prompts enthalten Nutzerdaten. Logge Token Counts und Metadaten, keinen Content. Wenn du vollständige Konversationen tracen musst, dann nur mit Redaction.
Statische Latenz-Schwellenwerte. LLM Response Times variieren je nach Modell, Last und Prompt-Länge. Verwende Percentile-basierte Schwellenwerte (P95, P99) relativ zu deinen eigenen Baselines. Keine fixen Zahlen.
Fehlende Model Version Labels. Wenn du von GPT-4o auf ein neueres Release upgradest, müssen deine Metriken das widerspiegeln. Jede Metrik braucht den Modellnamen und die Version als Label, damit du Regressionen erkennen kannst.
Stille Retries ignorieren. Manche Agent Frameworks wiederholen fehlgeschlagene LLM Calls automatisch, ohne sie zu loggen. Wenn dein Framework das tut, instrumentiere den Retry Path separat.
