Observability für KI‑Agenten selbst hosten: Ein CTO‑Entscheidungsrahmen

Ihre KI‑Agenten ertränken Sie in Telemetrie. Lang laufende Token‑Streams, Tool‑Aufrufe, Retries, Prompts, Streaming‑SSE — das summiert sich. Wenn Sie weiterhin jeden Span und jede Logzeile in ein SaaS‑APM pumpen, zahlen Sie dafür einen hohen Preis und lagern Prompts aus Ihrer VPC aus, die Sie nie außerhalb speichern wollten. Diese Woche tauchte auf Hacker News Traceway auf — ein MIT‑lizenzierter, selbst gehosteter Observability‑Stack, den Sie in Minuten deployen. Das ist keine Kuriosität. Es ist ein Signal. 2026 brauchen KI‑lastige Stacks eine Observability‑Strategie, die kostenbewusst, PII‑bewusst und portabel ist.

Was sich geändert hat: Telemetrie von KI‑Agenten ist nicht wie bei Web‑Microservices

Observability‑Anbieter wurden für Microservices optimiert: kurze Requests, gleichförmige Spans, Logs mit geringer Entropie. Agenten drehen diese Annahmen um.

• Sessions sind langlebig. Ein:e Nutzer:in startet einen agentischen Workflow, der 30–180 Sekunden Tokens streamt, ein Dutzend Tool‑Aufrufe ausführt und die gesamte Zeit ins UI zurückschreibt.
• Payloads sind sensibel. Prompts, Anhänge und Tool‑Ergebnisse enthalten oft PII, PHI, Code oder Verträge. Wenn Sie nicht nachweisen können, wo diese Daten liegen, wird Ihre Rechtsabteilung Ihnen irgendwann das Gegenteil nachweisen.
• Das Signal ist tail‑lastig. Die interessanten Fehler sind selten: Timeouts im 99,5. Perzentil, ein falsch spezifizierter Tool‑Call von hundert. Head‑basiertes Sampling verwirft genau das, was Sie brauchen. Tail‑Entscheidungen zählen.
• Clients sind First‑Class‑Citizens. Mobile‑ und Desktop‑Apps führen heute Inferenz und Tools lokal oder im LAN aus. Sie brauchen geräteübergreifende Session‑Traces, nicht nur Server‑Spans.

Klartext: Agent‑Observability ist näher an Analytics und eDiscovery als an Server‑Logs. Behandeln Sie sie auch so.

Das Kostenmodell, das Sie wirklich rechnen sollten

Sparen Sie sich die Listenpreise der Anbieter; sie ändern sich monatlich und sind bewusst intransparent. Modellieren Sie Ihre eigene Daten‑Gravitation. Hier ist eine belastbare Baseline für ein KI‑erweitertes Produkt:

• Tägliche Agent‑Sessions: 250.000
• Pro Session: 10 Tool‑Call‑Spans (~1 KB Metadaten je), 1 lang laufender Modell‑Span mit Prompt + Response (~10–50 KB komprimiert), 200–500 Token/Telemetrie‑Events (~5–15 KB komprimiert gesamt), 5–10 Log‑Einträge (~2–5 KB komprimiert)

Konservativer Roh‑Footprint pro Session: 30–70 KB. Bei 250.000 Sessions sind das 7,5–17,5 GB/Tag vor Anreicherung. Mit zusätzlichen Attributen, HTTP‑Headern und Context‑Baggage ist 2× üblich. Nennen wir es 15–35 GB/Tag Observability‑Daten.

Jetzt zu den Kosten:

• Hot‑Storage‑Compute (ClickHouse oder Tempo/ClickHouse für Traces; Loki für Logs; VictoriaMetrics für Metriken) auf moderaten Instanzen kann Trace/Log‑Payloads 8–12× komprimieren. 20–35 GB/Tag roh landen typischerweise bei 2–4 GB/Tag auf Disk für Traces/Logs und 0,5–1 GB/Tag für Metriken nach Rollups.
• Object Storage (S3/GCS) für kalte Retention kostet ~0,021–0,026 $/GB‑Monat im Jahr 2026. 1 TB monatliche kalte Traces/Logs kostet < 30 $/Monat, zuzüglich Retrieval, wenn Sie graben müssen.
• Compute: Ein 3‑Knoten‑ClickHouse‑Cluster auf General‑Purpose‑Instanzen schafft oft aggregiert 10–50 k Spans/Sekunde bei Sub‑Sekunden‑Query‑Latenz. Rechnen Sie mit 600–2.000 $/Monat je nach Region und Instanzklasse. Loki + VictoriaMetrics kosten Hunderte, nicht Tausende.

Vergleichen Sie das mit dem Versand von 15–35 GB/Tag an ein SaaS‑APM und 7–14 Tage Hot‑Retention. Ingest‑ und Retention‑Gebühren skalieren bei diesem Volumen schnell in die niedrigen fünfstelligen Beträge pro Monat — und die Privacy‑Externalitäten bleiben. Selbst hosten ist nicht „kostenlos“, aber der Crossover‑Punkt liegt niedriger, als die meisten Teams denken.

Architektur: Ein Stack, der nicht gegen Sie arbeitet

Sie brauchen kein Science‑Projekt. Sie brauchen vier Bausteine, die in Ihrer VPC laufen und End‑to‑End OpenTelemetry sprechen.

1) Instrumentierung und Datenverträge

• Standardisieren Sie auf OpenTelemetry für Traces, Logs und Metriken. Übernehmen Sie die entstehenden OpenTelemetry Semantic Conventions für AI/LLM‑Spans: Modellname, Tokens in/out, Tool‑Calls, Retry‑Zähler.
• Definieren Sie einen Datenvertrag für Prompts und Tool‑Payloads. Standardmäßig Hashes speichern, keinen Klartext. Volle Prompts/Responses nur speichern, wenn ein per‑Session‑„Debug“‑Flag gesetzt ist. Attribut pii=true anhängen, wenn ein Detektor anschlägt.
• Instrumentieren Sie Client‑Apps (Android, iOS, Desktop), damit sie Spans und Logs mit denselben Trace‑ und Nutzer/Session‑IDs emittieren. Für Android bevorzugen Sie OTLP gegenüber gRPC, um Head‑of‑Line‑Blocking in schlechten Netzen zu reduzieren.

2) Ingest und Control Plane

• OpenTelemetry Collector überall. Nutzen Sie Processor für Attribut‑Redaktion, Tail‑basiertes Sampling und Routing. Tail‑Sampling ist bei Agenten Pflicht; Sie müssen Ausreißer behalten, auch wenn die Gesamt‑QPS hoch ist.
• Event‑Budgets: Maximale Spans/Logs pro Session im Collector durchsetzen, mit harten Obergrenzen und Backpressure‑Metriken. Ein fehlverhaltender Agent darf Ihren Observability‑Tier nicht DDoS‑en.
• PII‑Leitplanken: Processor nutzen, um Attribute mit Detektor‑Treffern zu droppen und unredigierte Payloads in einen versiegelten S3‑Bucket mit 7‑Tage‑TTL zu forken, ohne UI‑Zugriff, nur IAM‑Abruf für Incidents.

3) Speicher und Abfragen

• Traces: ClickHouse‑gestütztes Tracing (z. B. über SigNoz, HyperDX oder einen leichten Router) oder Grafana Tempo kombiniert mit ClickHouse für Suchindizes. ClickHouse bietet SQL über Spans und kann zugleich Ihr Prompt‑Analytics‑Warehouse sein.
• Logs: Loki für kosteneffektive, index‑leichte Logs; Object‑Storage‑gestützte Chunks halten die Infra simpel. Wenn Sie strukturierte Logs im großen Stil abfragen müssen, streamen Sie in ClickHouse‑Tabellen mit Partitionierung nach Tag und Service.
• Metriken: VictoriaMetrics als Single‑Binary, freundlich zu hoher Kardinalität. Es komprimiert numerische Reihen aggressiv; erwarten Sie 2–5× bessere Speicherung gegenüber rohem Prometheus‑TSDB. Wenn Sie hochauflösende Gleitkomma‑Streams emittieren, erwägen Sie einen speziell für Float‑Telemetrie gebauten, verlustfreien Kompressor; Forschung wie „fc, a lossless compressor for floating-point streams“ zeigt zusätzliche 2–4×‑Gewinne bei einigen Signalen.

4) UI und Workflows

• Grafana‑Dashboards über Metriken und Logs, Trace‑Explorer auf ClickHouse/Tempo. Halten Sie UIs einfach und an Ihren SLOs ausgerichtet, nicht an einem Anbieter‑Katalog mit 200 Widgets.
• Session Replay bei Bedarf: rrweb selbst hosten, Replays mit Trace‑IDs verknüpfen. Replays mit kurzer TTL halten und niemals PII im DOM ohne Maskierung speichern.

Privatsphäre und Compliance: Hören Sie auf, Prompts als „nur Logs“ zu behandeln

Wenn Ihre Agenten PII, PHI oder Quellcode berühren, ist Ihre Observability‑Schicht ein regulierter Datenspeicher. Handeln Sie entsprechend.

• Standardmäßig redigieren. Prompts und Responses hashen. Nur Token‑Zahlen, Dauern und Modell‑Metadaten behalten, es sei denn, ein Debug‑Flag ist vorhanden. Für gekennzeichnete Sessions die vollen Payloads in einen versiegelten Bucket mit 7‑Tage‑TTL forken.
• Regionale Datenresidenz. Daten in‑Region halten. Wenn Sie in Brazil und den US operieren, erfüllen Sie LGPD und bundesstaatliche Datenschutzgesetze, indem Sie Hot‑ und Cold‑Tiers an die richtigen Regionen und Accounts binden.
• Access Control. Keine geteilten Logins. SSO + SCIM + projektspezifisches RBAC. Attribute in der UI maskieren. Jeder Zugriff auf unredigierte Daten sollte einen eigenen Audit‑Span hinterlassen.
• Data Retention. 7 Tage hot für Traces/Logs, 30–90 Tage cold im Object Storage, 15 Monate für gerollte Metriken. Das ist gegenüber Legal vertretbar und erlaubt dennoch effektives Incident‑Management.

Performance: Latenzbudgets für die Observability selbst

Collector und Exporter laufen im Prozess oder als Sidecar; sie dürfen Ihre p99s nicht gefährden.

• Nicht blockierende OTLP‑Exporter mit Backpressure und begrenzten Queues. Über dem Event‑Budget verwerfen; Observability darf niemals Nutzer‑Requests ausbremsen.
• Tail‑Sampling‑Fenster von 1–3 Sekunden erfassen langsame Traces deterministisch, ohne nutzerseitige Latenz hinzuzufügen. Das ist entscheidend für QUIC/WebRTC‑ und SSE‑Flows; eine jüngste Linux‑Netzwerk‑Optimierung verursachte einen QUIC‑Bug, der mit Head‑Sampling unsichtbar geblieben wäre.
• Nach Session‑ID sharden in Ihrem Tracing‑Store, um Cache‑Lokalität zu verbessern und Live‑Debug‑Queries schnell zu halten.

Entscheidungsrahmen: Wann selbst hosten vs. kaufen

Nutzen Sie Trigger, nicht Bauchgefühl.

Sie sollten selbst hosten, wenn eines davon zutrifft:

• Telemetrie‑Volumen über ~15 GB/Tag über Traces/Logs/Metriken, oder Sie erwarten eine Verdopplung in zwei Quartalen.
• PII/Sensible Prompts dürfen Ihre VPC oder Region nicht verlassen, oder Legal verlangt Audit‑Trails, wer Roh‑Prompts angesehen hat.
• Agent‑Debugging braucht Session‑Korrelation über Mobile/Desktop + Backend + Tools, und Ihr SaaS‑Anbieter kann das nicht sinnvoll ausdrücken.
• Kostenvolatilität durch SaaS hat Sie bereits gezwungen, Retention oder Sampling so weit runterzudrehen, dass Engineers das Tool meiden.

Bleiben Sie (vorerst) bei SaaS, wenn alles Folgende wahr ist:

• Unter 5 GB/Tag Telemetrie ohne sensible Payloads, und
• Niedrige Kardinalität bei Metriken/Logs, und
• Keine dedizierte SRE/DevEx‑Kapazität für die nächsten zwei Quartale.

Es gibt einen Mittelweg: Dual‑Write zu SaaS und selbst gehostet, während Sie Ihre Pipelines reifen lassen, dann die Default‑Route umlegen.

Implementierung: Ein 0–90‑Tage‑Plan

Tage 0–30: Baseline und Dual‑Write

• OpenTelemetry‑SDKs in Ihrem API‑Gateway, Agent‑Orchestrator und den zwei wichtigsten Tools einführen. Model‑Spans mit standardisierten Attributen emittieren.
• Einen Referenz‑Stack deployen in Ihrer Staging‑VPC: OpenTelemetry Collector → Loki + VictoriaMetrics + ClickHouse. Tools wie Traceway zeigen, dass das in Minuten steht; Production‑Härtung braucht länger, aber die Basics sind schnell.
• Dual‑Export zu Ihrem aktuellen SaaS und zu Ihrem Self‑Host‑Stack. Parität an drei goldenen Signalen und einem bekannten Incident validieren.
• Den Datenvertrag schreiben für Redaction und Debug‑Forks. In einen CI‑Check gießen: Neue Spans ohne Klassifizierungs‑Attribut lassen Builds fehlschlagen.

Tage 31–60: Produktions‑Cutover für Hot‑Paths

• Tail‑Sampling aktivieren nach Service und Fehlerrate. 100 % der Traces für Sessions mit Errors oder p99 > SLO behalten, sonst 1–5 % samplen.
• Event‑Budgets durchsetzen pro Session im Collector. Alerts auslösen, wenn Drops Schwellen überschreiten.
• PII‑Leitplanken aktiv: Maskierung in SDKs, Redaction in Collectors, Fork in versiegelten Bucket mit 7‑Tage‑TTL. Audit‑Spans bei jedem Zugriff auf Roh‑Daten.
• Dashboards und Runbooks für Ihre Top‑3‑SLOs: Prompt‑Latenz, Tool‑Call‑Erfolg, Ende‑zu‑Ende‑Session‑Zeit. Training mit zwei Mock‑Incidents und einem Live‑Game‑Day.

Tage 61–90: Optimieren und Risiken reduzieren

• Storage‑Partitionen und Retention‑Tiers tunen. Alles Ältere als 7 Tage in Object Storage verschieben. Metriken jenseits 7 Tagen auf 1–5‑Minuten‑Auflösung rollen.
• Kosten‑Leitplanken: Monatliche Budget‑Alerts für Object‑Storage‑Wachstum und ClickHouse‑CPU. Merges und Compactions so begrenzen, dass Queries nicht darben.
• Disaster Recovery: Kataloge täglich snappen, Restore in eine Scratch‑VPC testen. RTO/RPO dokumentieren und belegen.
• SaaS‑Ingestion drosseln für Logs/Traces in einem kontrollierten Fenster. Metriken noch einen Sprint spiegeln vor dem finalen Cut.

Taktiken mit schneller Amortisation

• Am Source redigieren: Verlassen Sie sich nicht auf Downstream‑Processor, um Secrets in Prompts zu säubern. Hash + Token‑Zahlen beantworten 90 % der Debug‑Fragen.
• Sampling im Session‑Scope: Ganze fehlerhafte Sessions vollständig behalten; partielle Traces sind verschwendeter Speicher.
• Nur strukturierte Logs: JSON mit trace_id und session_id. Unstrukturierte Logs nach 90 Tagen verwerfen; strukturierte Logs treiben Analytics in ClickHouse.
• Das Richtige komprimieren: Object Storage mit zstd oder parquet; Metriken mit delta‑of‑delta; float‑lastige Streams profitieren von spezialisierter, verlustfreier Kompression aus der wissenschaftlichen Datenforschung.
• On‑Call‑Ergonomie: Eine einzige Session‑Ansicht, die Prompts → Tool‑Calls → UI‑Events verknüpft, löst Incidents schneller als drei Anbieter‑Tabs.

Trade‑offs und echte Risiken

• Sie sind für SRE verantwortlich. Jemand muss Patching, Skalierung und Backups besitzen. Kernel‑ und dnsmasq‑CVEs kommen weiter; backen Sie Collector und Stores in Standard‑Images mit Auto‑Updates in Wartungsfenstern.
• Ohne harte Budgets sammeln Sie zu viel. KI‑Teams lieben Sichtbarkeit. Geben Sie Sampling‑Regler und klare Kosten; sonst wird Ihr „günstiger“ Stack teuer.
• ClickHouse ist mächtig und scharfkantig. Schlechte Schemata und Merges fressen CPU. Starten Sie mit bewährten Layouts für Spans und Logs; nicht in Prod improvisieren.

Nearshore‑Execution: So bekommen Teams das hin

Die größte Hürde ist nicht Software; es sind Policies und Plumbing. Erfolgreiche Teams kombinieren meist einen kleinen Platform‑Kern mit Nearshore‑Power. In der Praxis kann ein Zwei‑Personen‑Platform‑Team in den US plus ein Nearshore‑Pod (Brazil ist hier stark) den Stack, IaC und Datenverträge in zwei Sprints mit 6–8 Stunden Overlap aufbauen. Danach folgt inkrementelles Tuning und ein quartalsweises Kosten/Retention‑Review.

Wie „großartig“ bis Ende Q1 aussieht

• Kosten: Hot‑Tier bei 1–2 k $/Monat, Cold‑Tier unter 100 $/Monat pro TB. Keine überraschenden SaaS‑Rechnungen durch Traffic‑Spikes.
• Privacy: Prompts standardmäßig gehasht, Zugriff auf versiegelte Buckets auditiert, regionale Residenz per Policy durchgesetzt.
• Zuverlässigkeit: Trace‑Queries unter 1 Sekunde für die letzten 24 Stunden. Tail‑Sampling behält alle langsamen/fehlerhaften Sessions. Game‑Days belegen RTO < 2 Stunden, RPO < 24 Stunden.
• Dev‑Velocity: Engineers nutzen eine einzelne Session‑Ansicht zur Incident‑Lösung. Produkt‑ und Data‑Teams queryen ClickHouse für Modell‑Performance, ohne SREs nach CSVs zu fragen.

Fazit

KI‑Agenten machen Observability zugleich wertvoller und gefährlicher. Wenn Sie täglich Dutzende Gigabytes schieben und davon etwas sensibel ist, gilt der Default „zum Anbieter schicken und hoffen“ nicht mehr. Selbst hosten mit OpenTelemetry, ClickHouse/Loki/Tempo und strikten Datenverträgen ist nicht kontraintuitiv — es ist verantwortungsvolle Ingenieurskunst. Starten Sie diesen Monat mit Dual‑Write. Nächstes Quartal schlafen Sie besser, und Ihre Rechtsabteilung auch.

Wichtigste Erkenntnisse

• Agent‑Telemetrie ist tail‑lastig, lang laufend und enthält oft PII; behandeln Sie sie wie Analytics, nicht nur wie Logs.
• Der Kosten‑Crossover fürs Selbsthosten kommt ab ca. 15+ GB/Tag Traces/Logs/Metriken oder bei beliebigen PII‑Auflagen.
• Übernehmen Sie OpenTelemetry mit Tail‑Sampling, Event‑Budgets und Data‑Contracts mit Redaction by Default.
• Nutzen Sie ClickHouse/Tempo für Traces, Loki für Logs und VictoriaMetrics für Metriken; alles andere kalt in Object Storage.
• Führen Sie einen 0–90‑Tage‑Plan aus: Dual‑Write, Hot‑Paths umschalten, Leitplanken erzwingen, DR testen, dann SaaS drosseln.
• Erwarten Sie Trade‑offs: Sie besitzen SRE und Kostendisziplin; der Payoff sind geringere Ausgaben, weniger Risiko und bessere Incident‑Response.