VictoriaMetrics bringt VictoriaStack für Metriken, Logs, Traces und KI-gestützte Fehlerbehebung auf den Markt

VictoriaMetrics hat VictoriaStack vorgestellt, eine Open-Source-Observability-Plattform, die seine Produkte für Metriken, Logs und verteiltes Tracing in einem aufeinander abgestimmten Betriebsmodell zusammenführt. Mit der Einführung sollen Engineering-Teams ihre Telemetrieabdeckung erweitern können, ohne ihre gesamte Monitoring-Umgebung ersetzen oder jedes Signal in dieselbe Datenbank zwingen zu müssen.

VictoriaStack vereint VictoriaMetrics für Metriken, VictoriaLogs für Logs und VictoriaTraces für Traces. Teams können die benötigten Signale einführen und später weitere ergänzen. Gemeinsame Bereitstellungswerkzeuge und die Unterstützung von OpenTelemetry helfen dabei, die Komponenten miteinander zu verbinden.

Die Ankündigung erweitert dieses Modell auch auf KI-gestützte Betriebsabläufe. Offizielle Model-Context-Protocol-Server und Agenten-Skills ermöglichen Assistenten, Telemetriedaten über den gesamten Stack hinweg zu untersuchen. Die Entscheidung, welche Änderungen umgesetzt werden, bleibt dabei den Ingenieurinnen und Ingenieuren überlassen.

Drei Signale, drei spezialisierte Datenbanken

Metriken, Logs und Traces geben Antworten auf unterschiedliche betriebliche Fragen. Metriken fassen das Verhalten über einen Zeitraum zusammen, etwa Anfrageraten, Fehlerzahlen oder den Speicherverbrauch. Logs halten Ereignisse und ihre Details fest. Verteilte Traces verfolgen eine Anfrage über mehrere Dienste hinweg und zeigen, wo Zeit verstrichen ist und wo ein Fehler aufgetreten ist.

Bei einem Vorfall bemerkt eine Ingenieurin oder ein Ingenieur möglicherweise zunächst anhand der Metriken einen Latenzanstieg, grenzt das Problem mithilfe von Traces auf einen Dienst ein und prüft anschließend in den Logs die zugrunde liegende Fehlermeldung. Werden diese Signale in einen einheitlichen Arbeitsablauf eingebunden, kann sich die Untersuchung verkürzen, ohne dass ihre Speicheranforderungen vereinheitlicht werden müssen.

Die Architekturdokumentation von VictoriaStack beschreibt unabhängige Datenbanken mit einem gemeinsamen Komponentenmodell. Jede kann als einzelne Binärdatei oder als Cluster betrieben werden, in dem Datenerfassung, Speicherung und Abfrage voneinander getrennt sind. Als Einstiegspunkt für Routing und Lastverteilung kann der Stack vmauth verwenden.

Auch die Abfrageschnittstellen bleiben spezialisiert: VictoriaMetrics verwendet das zu PromQL kompatible MetricsQL, VictoriaLogs nutzt LogsQL und VictoriaTraces unterstützt neben LogsQL auch mit Jaeger und Tempo kompatible APIs. Der koordinierte Betrieb bedeutet daher weder eine einzige Datenbank noch eine universelle Abfragesprache.

Alle drei Kerndatenbanken sind unter der Apache-2.0-Lizenz verfügbar. Das Unternehmen bietet außerdem Funktionen für den Unternehmenseinsatz und kommerziellen Support sowie den vollständig verwalteten Dienst VictoriaMetrics Cloud, der alle drei Signale unterstützt.

OpenTelemetry verbindet die Erfassungsebene

OpenTelemetry bietet ein einheitliches Vorgehen, um Anwendungen zu instrumentieren und Telemetriedaten zu exportieren. Das OTLP-Protokoll wird für Metriken, Logs und Traces in VictoriaStack unterstützt. So steht Teams ein einheitlicher Erfassungspfad zur Verfügung, auch wenn die Daten in unterschiedlichen Backends landen.

Dieser Unterschied ist wichtig, wenn eine Anwendung von wenigen Diensten zu einem verteilten System wächst. Die Instrumentierung sollte das Verhalten der Anwendung beschreiben; eine Änderung des Ziels für die Telemetriedaten sollte nicht erfordern, den Monitoring-Code jedes Dienstes neu zu entwerfen.

Der Stack unterstützt bei Bedarf auch andere Erfassungsformate. Teams, die beispielsweise bereits Metriken mit Prometheus erfassen, können dieses Ökosystem beibehalten und daneben Logs oder Tracing einführen. Die Protokollkompatibilität verringert den Migrationsaufwand; über Aufbewahrungsdauer, Kapazität und Abfragemuster muss jedoch weiterhin aus technischer Sicht entschieden werden.

Für Kubernetes-Bereitstellungen verweist VictoriaMetrics auf seinen Operator und seine Helm-Diagramme als gängige Verwaltungswerkzeuge. Ziel ist es, Bereitstellungen und Upgrades einheitlicher zu gestalten und zugleich jeden Signaltyp entsprechend seiner eigenen Arbeitslast skalieren zu können.

KI-Agenten können Telemetriedaten übergreifend untersuchen

VictoriaStack verfolgt beim Thema KI einen zweigleisigen Ansatz: Observability-Systeme müssen Telemetriedaten verarbeiten können, die von agentenbasierten Anwendungen erzeugt werden, und KI-Assistenten können Ingenieurinnen und Ingenieuren helfen, diese Daten zu untersuchen.

Die Dokumentation zu KI-Werkzeugen des Unternehmens beschreibt separate MCP-Server für Metriken, Logs und Traces. Sie stellen strukturierte Funktionen bereit, etwa zum Abfragen von Zeitreihen, Durchsuchen von Log-Feldern, Auffinden von Diensten und Vorgängen sowie Abrufen von Traces. Die Metrik-Integration unterstützt außerdem Untersuchungen zur Kardinalität, zum Abfrageverhalten und zur Konfiguration von Alarmen.

Das Repository mit Agenten-Skills bietet wiederverwendbare Arbeitsabläufe für Untersuchungen, die mehrere Signaltypen einbeziehen, und weitere betriebliche Aufgaben. Ein Assistent kann einem Fehlerbehebungsprozess über verschiedene Signale hinweg folgen, statt sich auf ein einzelnes Dashboard oder eine eingefügte Fehlermeldung zu stützen.

Laut Ankündigung erhalten Assistenten wie Claude Code, Codex, Cursor und interne Agenten ausschließlich Lesezugriff. Der vorgesehene Arbeitsablauf dient somit der Untersuchung: Belege sammeln, Symptome miteinander verknüpfen und eine Erklärung vorschlagen, während die Ingenieurinnen und Ingenieure entscheiden, was umgesetzt wird. Die Verbindung einer Telemetriequelle mit einem Agenten bedeutet für sich genommen nicht, dass dieser die Ursache des Problems korrekt erkannt hat.

Erfassung und Abfragen unabhängig voneinander skalieren

Der VictoriaStack-Schnellstart veranschaulicht sowohl Einzelknoten- als auch Clusterkonfigurationen. Die Docker-Compose-Demo umfasst eine OpenTelemetry-Anwendung und einen Collector, die drei Datenbanken, Grafana, vmalert und vmauth. In der Dokumentation wird ausdrücklich darauf hingewiesen, dass diese lokale Umgebung der Demonstration dient und nicht für den Produktivbetrieb gedacht ist.

Im Clustermodell sind die Komponenten für die Datenerfassung und Abfrage zustandslos und können unabhängig voneinander skaliert werden, während die Speicherkomponenten die Daten vorhalten. So lassen sich unterschiedliche Anforderungen getrennt berücksichtigen: Mehr eingehende Telemetriedaten können zusätzliche Kapazitäten für die Datenerfassung erfordern, während mehr Entwickler oder Agenten, die Untersuchungen durchführen, den Abfragebedarf erhöhen können.

Die Speicherplanung bleibt wichtig. Laut Dokumentation speichern die Datenbanken Telemetriedaten auf lokalen Dateisystemen; S3 oder Google Cloud Storage dient für Sicherungen und nicht als Abfrageebene für Objektspeicher. Außerdem wird darauf hingewiesen, dass die Anzahl der Speicher-Shards nur mit erheblichem Aufwand verringert werden kann. Diese Eigenschaften sind bei der Wahl einer Topologie und der Prognose des Wachstums zu berücksichtigen.

Ein abgestimmter Stack ohne Migration auf einen Schlag

VictoriaMetrics stellt VictoriaStack auf der KubeCon + CloudNativeCon North America 2026 vor. Gezeigt wird eine mit OTLP instrumentierte Kubernetes-Anwendung, die ihre drei Telemetriesignale an die jeweils passenden Backends sendet. Daran schließt sich ein signalübergreifender Workflow zur Fehlerbehebung an.

„Das agentische Zeitalter wird mehr Telemetriedaten und höhere Anforderungen an deren Verarbeitung mit sich bringen“, sagte Roman Khavronenko, Mitgründer und Engineering Manager von VictoriaMetrics, in der Ankündigung. VictoriaStack sei auf Skalierbarkeit und Effizienz ausgelegt, wenn dieser Bedarf wachse, erklärte er.

Das praktische Konzept setzt auf eine schrittweise Einführung: ein nützliches Ökosystem zur Datenerfassung beibehalten, fehlende Signale ergänzen und die daraus entstehenden Dienste nach einem einheitlicheren Modell verwalten. Der Wert von VictoriaStack zeigt sich darin, wie gut diese Komponenten zusammenarbeiten, wenn Telemetrievolumen und Untersuchungsbedarf steigen. Gleichzeitig behalten Teams die Kontrolle darüber, wo ihre Daten liegen und wie sich die einzelnen Signale skalieren lassen.