Kurz gesagt: OpenObserve 1.0.0 erweitert die Observability-Plattform um Funktionen für LLM- und Agenten-Anwendungen. Bewertungen, Experimente sowie Agenten- und Service-Graphen sollen helfen, Qualität, Kosten und Fehler in mehrstufigen KI-Workflows systematisch nachzuvollziehen. Zugleich kommen neue SLO-, Alarmierungs- und Monitoring-Funktionen hinzu.
Wenn KI-Agenten falsche oder unerwartete Ergebnisse liefern, ist die Ursache häufig schwer zu finden. Mit Version 1.0.0 will OpenObserve genau dort ansetzen: Die neue „AI Observability“ soll Telemetriedaten aus KI-Anwendungen erfassen, Ergebnisse bewerten und Abhängigkeiten innerhalb komplexer Agenten-Workflows sichtbar machen.
OpenObserve ist eine in Rust entwickelte Cloud-native Observability-Plattform für Logs, Metriken und Traces. Teams können Telemetriedaten zentral speichern, durchsuchen und miteinander korrelieren. Neben SQL unterstützt die Plattform PromQL für Metrikabfragen; für die Datenhaltung kommen Parquet und Objektspeicher zum Einsatz.
KI-Workflows bewerten und vergleichen
Zu den zentralen Neuerungen gehören Bewertungen für einzelne Traces und komplette Sitzungen. Hinzu kommen Warteschlangen und Datensätze für menschliche Annotationen sowie ein Playground, in dem sich Aufgaben ausführen und bewerten lassen.
Experiment-Workflows sollen außerdem verschiedene Varianten eines LLM- oder Agenten-Prozesses vergleichbar machen. Dadurch können Teams Änderungen an Prompts oder Modellen nicht nur anhand von Antwortzeiten und Kosten beurteilen, sondern zusätzlich definierte Qualitätskriterien berücksichtigen.
Ein erweiterter Agenten- und Service-Graph stellt Abhängigkeiten zwischen Diensten und KI-Komponenten dar. So lassen sich Agentenaufrufe mit verwendeten Modellen, Tools und nachgelagerten Diensten verknüpfen. Das kann die Fehlersuche in mehrstufigen Abläufen erleichtern, weil sich einzelne Verarbeitungsschritte besser einordnen lassen.
Die Release Notes nennen darüber hinaus zeitabhängige Modellpreise, Kosten- und Vergleichsansichten für Experimente sowie einen hochverfügbaren Modus für den o2-ai-Agenten. Allerdings stehen nicht zwangsläufig alle genannten Funktionen in jeder Produktvariante zur Verfügung: OpenObserve unterscheidet zwischen Open-Source- und Enterprise-Komponenten.
Mehr Kontrolle über Dienste und Alarme
Auch klassische Monitoring-Aufgaben werden mit Version 1.0 ausgebaut. Neue Service Level Objectives unterstützen Burn-Rate-Alarme, mit denen sich erkennen lässt, wie schnell ein definiertes Fehlerbudget verbraucht wird. Dadurch kann beispielsweise frühzeitig auffallen, dass ein Verfügbarkeitsziel bei unveränderter Fehlerrate voraussichtlich verfehlt wird.
Zusammengesetzte Alarmregeln können mehrere Teilalarme miteinander kombinieren. Eine SQL-Abfrage kann künftig mehrere Alarme bedienen. Zusätzlich führt OpenObserve eine Pending-Phase ein: Ein Fehlerzustand muss zunächst für eine festgelegte Zeit bestehen, bevor eine Alarmierung ausgelöst wird. Kurzzeitige Ausreißer lassen sich dadurch besser von anhaltenden Problemen unterscheiden.
Neu sind außerdem eine Alarmbibliothek, Exportmöglichkeiten für Terraform und OpenTofu sowie eine Oberfläche für Datenbank-Monitoring. Synthetic Monitoring für automatisierte Prüfungen von Endpunkten oder Browser-Abläufen wird laut Changelog vollständig in die Open-Source-Ausgabe verlagert.
Schnellere Abfragen und wichtige Upgrade-Änderungen
Für PromQL nennt OpenObserve mehrere Optimierungen bei Labels, Zeitreihen, Range-Funktionen und Aggregationen. Eine globale Cache-Struktur für Serienlabels sowie Begrenzungen beim Speicherbedarf indexierter Metriken sollen Abfragen effizienter machen. Konkrete Vergleichswerte zur Leistungssteigerung liefert das Release allerdings nicht.
Auch Trace-Suche und Dashboards wurden erweitert. Ein neuer Zeitindex soll organisationsweite Abfragen über mehrere Trace-IDs beschleunigen. Span-Ereignisse und Ausnahmen erscheinen direkt auf der Trace-Zeitleiste, während Tabellenzellen in Dashboards einen eingebetteten Logs-Explorer öffnen können.
Vor einem Upgrade sollten Administratoren mehrere inkompatible Änderungen prüfen. Unter anderem ersetzt eine auf Tantivy basierende TopK-Implementierung die bisherigen distinct_values_*-Streams. Action-Skripte samt Action-Server sowie trace_list_index entfallen, die Knotenrolle AlertManager heißt künftig Scheduler, und der nicht authentifizierte Endpunkt /config liefert keine internen Deployment-Informationen mehr aus.
Für Teams, die KI-Agenten produktiv betreiben, rückt damit neben klassischer Systemüberwachung zunehmend die Qualität einzelner KI-Entscheidungen in den Fokus. Wer Entwicklungen rund um KI-Infrastruktur, Agenten und Monitoring kompakt verfolgen möchte, findet im Newsletter „Beratung-KI“ regelmäßig weitere Einordnungen.
Effizienz durch Innovation: Teile der textlichen und visuellen Ausgestaltung dieser Seite wurden durch generative KI-Systeme unterstützt.