OpenObserve zeigt, warum KI-Agenten falsche Antworten geben

Mit Version 1.0.0 veröffentlicht OpenObserve seine erste allgemein verfügbare 1.x-Ausgabe. Im Mittelpunkt steht eine neue Observability-Umgebung für LLM- und Agenten-Anwendungen: Sie soll Telemetrie erfassen, Ausgaben bewerten und Fehler in mehrstufigen KI-Workflows nachvollziehbar machen. Außerdem baut das Release das Alarmierungs- und SLO-Angebot aus, nimmt Synthetic Monitoring in die Open-Source-Ausgabe auf und verspricht schnellere PromQL-Abfragen.

OpenObserve ist eine in Rust entwickelte, Cloud-native Observability-Plattform für Logs, Metriken und Traces. Sie richtet sich an Teams, die Telemetriedaten zentral ablegen, durchsuchen und korrelieren wollen. Neben SQL unterstützt das Projekt PromQL für Metrikabfragen; die Datenhaltung setzt auf Parquet und Objektspeicher. Weitere Information bietet die Projektdokumentation.

KI-Workloads mit Bewertungen und Experimenten beobachten

Version 1.0 führt nach Angaben der Entwickler „AI Observability“ als zentrale Funktion ein. Sie umfasst Bewertungen für Traces und Sitzungen, Warteschlangen und Datensätze für menschliche Annotationen sowie einen Playground. Dort lassen sich Aufgaben ausführen und bewerten. Experiment-Workflows sollen es ermöglichen, Varianten eines LLM- oder Agenten-Workflows vergleichbar zu testen. Das ist etwa dann hilfreich, wenn Teams Prompt- oder Modelländerungen nicht nur nach Antwortzeit und Kosten, sondern auch anhand definierter Qualitätskriterien beurteilen wollen. Die vollständigen Release Notes zu OpenObserve 1.0.0 nennen außerdem zeitabhängige Modellpreise und einen hochverfügbaren Modus für den o2-ai-Agenten.

Zu den Neuerungen zählt auch ein ausgebauter Agenten- und Service-Graph. Er soll Abhängigkeiten zwischen Diensten und KI-Komponenten sichtbar machen. Damit lassen sich etwa Aufrufe eines Agenten mit den beteiligten Modellaufrufen, Tools und nachgelagerten Diensten in Beziehung setzen. Die Release Notes führen zudem Fehlerkorrekturen für die Darstellung von LLM-Diagrammen, Kosten- und Vergleichsansichten für Experimente sowie die Normalisierung von Modellnamen im Service-Graphen auf.

Nicht alle im Changelog erwähnten Funktionen stehen zwangsläufig in jeder Variante des Produkts bereit: Die Entwickler unterscheiden dort explizit zwischen Änderungen am Open-Source-Code und Enterprise-Komponenten.

Neue SLOs, zusammengesetzte Alarme und Datenbank-Monitoring

Für den Betrieb klassischer Dienste ergänzt OpenObserve Service Level Objectives (SLOs) mit Burn-Rate-Alarmen. Ein solcher Alarm bewertet, wie schnell ein Fehlerbudget aufgezehrt wird. Er kann beispielsweise früh warnen, wenn ein Dienst sein monatliches Verfügbarkeitsziel bei der aktuellen Fehlerrate deutlich vor Monatsende verfehlen würde. SLOs können nun auch PromQL verwenden und zeitlich segmentierte Ziele abbilden.

Bei Alarmen kommen zusammengesetzte Regeln hinzu, die mehrere Teilalarme verbinden. Außerdem kann eine SQL-Abfrage künftig mehrere Alarme versorgen, und Regeln erhalten eine Pending-Phase: Ein Zustand muss dann zunächst für eine konfigurierte Dauer anhalten, bevor OpenObserve alarmiert. Das kann kurzzeitige Ausreißer entschärfen. Eine Alarmbibliothek soll vorbereitete Regeln anzeigen und gebündelt installieren; Alarme und SLOs lassen sich zudem als Terraform- oder OpenTofu-Konfiguration exportieren.

Neu ist auch eine Oberfläche für Datenbank-Monitoring. Beim Synthetic Monitoring, also automatisierten Prüfungen von Endpunkten oder mehrstufigen Browser-Abläufen, verschiebt das Projekt die Funktion laut Changelog vollständig in die Open-Source-Ausgabe. Hinzu kommen Super-Cluster-Unterstützung und Änderungen an der nutzungsbasierten Abrechnung nach Prüfschritten.

PromQL-Optimierungen und Folgen für Upgrades

Die Entwickler nennen mehrere Optimierungen für PromQL-Abfragen. Dazu gehören Änderungen an der Verarbeitung von Labeln und Zeitreihen, eine globale Cache-Struktur für Serienlabels sowie eine effizientere Auswertung von Range-Funktionen und Aggregationen. Zudem begrenzt OpenObserve den Speicherbedarf beim Zusammenführen indexierter Metriken. Konkrete Vergleichswerte liefert das Release allerdings nicht.

Auch bei Traces und der Suche baut Version 1.0 aus. Ein neuer Zeitindex soll Trace-Abfragen über mehrere IDs und organisationsweite Zeiträume beschleunigen. Span-Ereignisse und Ausnahmen erscheinen auf der Trace-Zeitleiste. Für Dashboards überarbeitet das Projekt den Abfrageeditor; Tabellenzellen können einen eingebetteten Logs-Explorer öffnen.

Administratoren sollten vor einem Upgrade die inkompatiblen Änderungen beachten. OpenObserve ersetzt die bisherigen distinct_values_*-Streams durch eine TopK-Implementierung auf Basis von Tantivy. Die Action-Skripte samt Action-Server sowie die Funktion trace_list_index entfallen. Zudem heißt die Knotenrolle AlertManager künftig Scheduler; interne Deployment-Informationen liefert der nicht authentifizierte Endpunkt /config nicht mehr aus. Die Entwickler haben außerdem die ORM-Zugriffe in getrennte Lese- und Schreib-Clients aufgeteilt und damit die SQLite-Schreibsperre abgelöst.