Beobachtbarkeit im KI-Zeitalter: Vier Monitoring-Ansätze für App, Infrastruktur, CI & LLM

Die Integration von KI in technische Systeme stellt Beobachtbarkeitslösungen vor neue Herausforderungen. Während statische Codeanalysen längst etabliert sind, fehlt es oft an dynamischen Einblicken in laufende Produktionsumgebungen. Ein CTO erklärt, wie sein Team vier spezialisierte Monitoring-Ansätze entwickelte, um KI präzise und kontextbezogen zu unterstützen – von Anwendungsmetriken bis hin zu LLM-Kostenanalysen.

Warum Standard-Logs für KI ungeeignet sind

Die meisten Beobachtbarkeits-Tools sammeln unstrukturierte Daten wie Logs, Metriken und Traces – doch genau diese Unstrukturiertheit wird zum Hindernis, sobald KI-Systeme darauf zugreifen sollen. Ungefilterte Rohdaten führen zu drei zentralen Problemen:

• Kontextüberlastung: Tausende Log-Einträge pro Sekunde füllen den Kontextspeicher von KI-Modellen und verschleiern relevante Informationen.
• Fehlende Verknüpfung: Metriken, Logs und Traces existieren oft isoliert, ohne klare Beziehungen zueinander.
• Unpräzise Abfragen: Fragen wie „Wie viel geben wir aktuell für LLM-Nutzung aus?“ lassen sich aus reinen Log-Daten nicht beantworten.

Die Lösung liegt darin, Daten vor ihrer Nutzung durch KI gezielt zu formen – ähnlich wie bei der semantischen Codeanalyse. Bei airCloset wurde dieser Ansatz auf die Beobachtbarkeit übertragen, indem vier spezialisierte Monitoring-Achsen definiert wurden, die jeweils eigene Datenstrukturen und Abfrageziele verfolgen.

Die vier Monitoring-Achsen im Detail

1\. Anwendungsbeobachtbarkeit: Einheitliche Traces und Logs

Die Grundlage bildet ein standardisierter OpenTelemetry-Stack mit:

• Traces in Tempo für verteilte Anfragen
• Logs in Loki mit strukturierten Einträgen
• Metriken in Mimir für Ressourcenüberwachung

Der Schlüssel liegt in der Konformität: Alle Anwendungen müssen dieselben Attribute (z. B. service_name, environment) in konsistenter Form ausgeben. Dadurch lässt sich eine KI-gestützte Abfrage wie

{service_name="api-gateway"} |~ "error"

nahtlos über mehrere Services hinweg ausführen – etwa zur Fehlerursachenanalyse oder Echtzeit-Überwachung.

2\. Infrastruktur: GCP-Metriken in einer zentralen Quelle

Bei cortex, der internen KI-Plattform von airCloset, werden Infrastrukturmetriken aus Google Cloud Platform (GCP) zentral in Mimir gesammelt. Dazu gehören:

• CPU- und Speichernutzung von Cloud Run
• Ausführungszeiten von Cloud Run Jobs
• Warteschlangenlatenzen von Pub/Sub
• Job-Queues aus Cloud Tasks

Durch die Zusammenführung in einer einzigen Abfrageumgebung kann KI gezielt Fragen wie

• *„Welcher Dienst verbrauchte letzte Woche die meisten CPU-Ressourcen?“"
• *„Gibt es einen Worker mit blockierter Warteschlange?“"

beantworten – ohne manuelle Datenkorrelation.

3\. CI-Pipelines: Logs als strukturierte Analysedaten

CI-Systeme wie GitHub Actions liefern zwar native Logs, doch für KI-Anwendungen sind diese oft unzureichend:

• API-Zugriffe sind langsam und erfordern komplexe Authentifizierung.
• Native UIs bieten keine programmatische Abfragemöglichkeit.

Stattdessen setzt cortex auf einen posthumen Pull-Ansatz: Alle CI-Logs werden nach Abschluss der Pipeline in Loki ingestiert. Das bietet drei Vorteile:

• Kombinierte Abfragen: CI- und Anwendungslogs lassen sich gemeinsam analysieren – etwa bei der Suche nach Testfehlern, die zu Produktionsproblemen führten.
• Strukturierte Alerts: LogQL-Abfragen wandeln CI-Fehler in maschinenlesbare Signale um.
• Natürlichsprachliche Abfragen: KI kann Fragen wie „Welche Tests sind seit einer Woche defekt?“ direkt verarbeiten.

4\. LLM-Kosten: Echtzeit-Metriken und aggregierte Ausgaben

KI-gestützte Anwendungen, insbesondere LLMs, erzeugen spezifische Herausforderungen im Monitoring:

• Token-basierte Abrechnung erfordert detaillierte Nutzungsstatistiken.
• Echtzeit-Kostenkontrolle ist entscheidend, um Budgetüberschreitungen zu vermeiden.

Bei cortex werden LLM-Nutzungsdaten in zwei Formen erfasst:

• Echtzeit-Metriken (z. B. Anfragen pro Sekunde, Antwortzeiten)
• Strukturierte Kostenaufschlüsselungen (pro Team, Modell, Projekt)

Diese Daten fließen in Mimir und ermöglichen KI-gestützte Analysen wie:

• *„Welches Team verursacht aktuell die höchsten LLM-Kosten?“"
• *„Wie entwickelt sich die Token-Nutzung im Vergleich zum Vortag?“"

Warum Getrenntes besser ist als Kombiniertes

Ein häufiger Fehler beim Aufbau KI-fähiger Beobachtbarkeitssysteme besteht darin, alle Daten in einem einzigen Backend zu sammeln – etwa durch die naive Weiterleitung von OTel-Metriken an Loki. Doch diese Herangehensweise scheitert an den unterschiedlichen Anforderungen der vier Monitoring-Achsen:

• Anwendungslogs benötigen schnelle, kontextreiche Abfragen.
• Infrastrukturdaten erfordern historische Zeitreihenanalysen.
• CI-Logs müssen nach Abschluss von Pipelines verfügbar sein.
• LLM-Metriken benötigen Echtzeit- und Aggregationsansichten.

Durch die Trennung der Datenströme nach Verwendungszweck entsteht ein flexibleres System, das KI präzise und effizient unterstützt.

Ausblick: Selbstheilende Systeme und PII-Handhabung

Die Gestaltung der Beobachtbarkeit ist nur der erste Schritt. In einem folgenden Artikel wird erläutert, wie cortex:

• Personenbezogene Daten (PII) sicher in das Monitoring integriert
• Selbstheilende Mechanismen durch KI-gestützte Alerts umsetzt
• Datenintegrationen zwischen den vier Monitoring-Achsen optimiert

Dabei steht die Herausforderung im Mittelpunkt, dynamische Systeme mit statischen Regeln in Einklang zu bringen – eine Balance, die für den KI-Einsatz in Produktionsumgebungen entscheidend ist.