Wer Monitoring in seiner Infrastruktur ernst nimmt, kommt an Prometheus kaum vorbei. Die CNCF-Technologie hat sich als De-facto-Standard für Cloud-native Observability etabliert – und das zu Recht. Doch in den letzten Jahren hat sich eine Alternative herauskristallisiert, die vor allem für Self-Hoster und Teams mit wachsender Infrastruktur interessant ist: Victoria Metrics.

In diesem Artikel vergleiche ich beide Lösungen ehrlich, basierend auf meiner eigenen Erfahrung mit Kubernetes-Cluster-Monitoring und Homelab-Setups. Es geht nicht darum, einen „Gewinner" zu küren, sondern zu verstehen, wann welches Tool die bessere Wahl ist.

Was ist Prometheus?

Prometheus wurde 2012 bei SoundCloud entwickelt und 2016 als zweites CNCF-Projekt (nach Kubernetes) aufgenommen. Die Architektur ist einfach und elegant: Ein Scraping-Mechanismus holt Metriken von konfigurierten Endpoints, speichert sie in einer lokalen Time-Series-Datenbank (TSDB) und macht sie über PromQL abfragbar.

Stärken von Prometheus:

  • Riesiges Ökosystem: Hunderte von Exportern (Node Exporter, Blackbox Exporter, kube-state-metrics, etc.)
  • Native Kubernetes-Integration über ServiceMonitors und PodMonitors (Prometheus Operator)
  • PromQL als mächtige Abfragesprache – Industriestandard für Metriken
  • Perfekte Grafana-Integration und umfangreiche Community
  • Stabile, battle-tested Technologie seit über zehn Jahren im produktiven Einsatz

Schwächen von Prometheus:

  • Hoher Ressourcenverbrauch bei großen Installationen (RAM-intensiv)
  • Hochverfügbarkeit ist komplex – erfordert Thanos, Cortex oder Grafana Mimir
  • Long-Term-Storage nicht nativ – braucht externe Lösung oder S3-Backends
  • Standardmäßig nur 15 Tage Datenspeicherung
  • Bei hohen Kardinalitäten (viele Label-Kombinationen) schnell überfordert

Was ist Victoria Metrics?

Victoria Metrics ist ein in Go geschriebenes Time-Series-Datenbank-System und Monitoring-Tool, das 2019 von Aliaksandr Valialkin erstmals veröffentlicht wurde. Das Tool positioniert sich explizit als Drop-in-Ersatz für Prometheus, der deutlich ressourceneffizienter ist.

Es gibt zwei Hauptvarianten: VictoriaMetrics Single (Single-Node) für kleine bis mittlere Installationen und VictoriaMetrics Cluster für horizontale Skalierung mit getrennten vmstorage-, vminsert- und vmselect-Komponenten.

Stärken von Victoria Metrics:

  • 2–7× geringerer RAM-Verbrauch als Prometheus bei gleicher Last
  • Effizientere Kompression auf Disk (bis zu 70 % weniger Speicherbedarf)
  • Native Long-Term-Storage ohne externe Komponenten
  • MetricsQL als PromQL-kompatible Abfragesprache mit nützlichen Erweiterungen
  • Built-in High Availability ohne Thanos oder Cortex notwendig
  • Einfacherer Betrieb des Cluster-Modus

Schwächen von Victoria Metrics:

  • Kleinere Community als Prometheus – weniger Stack-Overflow-Antworten
  • Nicht alle Prometheus-Features 1:1 verfügbar (Recording Rules mit subtilen Unterschieden)
  • Weniger native Operator-Unterstützung für Kubernetes im Vergleich zum Prometheus Operator
  • Kommerzieller Hintergrund: Enterprise-Features kostenpflichtig

Vergleich: Performance und Ressourcenverbrauch

Dies ist der Bereich, in dem Victoria Metrics am stärksten glänzt. In meinem Kubernetes-Homelab auf einem Hetzner-CX21 (2 vCPU, 4 GB RAM) war der Unterschied deutlich spürbar:

MetrikPrometheusVictoria MetricsErsparnis
RAM-Verbrauch~1,2 GB~280 MB~77 %
Disk-Verbrauch/Tag~420 MB~145 MB~65 %
CPU-Last (idle)~8 %~2 %~75 %
Datenpunkte/Sekunde12.00012.000gleich

Diese Zahlen stammen aus einem Setup mit ca. 120 Scrape-Targets und 15.000 aktiven Zeitreihen. Bei größeren Installationen (100k+ Zeitreihen) fällt der Unterschied noch deutlicher aus. Der Grund liegt in der internen Datenkomprimierung: Victoria Metrics nutzt einen eigenen Algorithmus, der Metriken deutlich kompakter speichert als Prometheus' TSDB.

Vergleich: PromQL-Kompatibilität

Victoria Metrics unterstützt PromQL vollständig und bietet mit MetricsQL eine Obermenge davon. Das bedeutet: Alle bestehenden Grafana-Dashboards, Alerting-Regeln und Recording-Rules aus Prometheus laufen in der Regel ohne Anpassungen.

Einige Unterschiede gibt es trotzdem zu beachten:

  • extrapolate() und einige statistische Funktionen verhalten sich in MetricsQL etwas anders
  • Subqueries haben leicht abweichendes Verhalten bei Randwerten
  • Die name-Label-Behandlung ist in bestimmten Fällen anders

Für 95 % der Anwendungsfälle ist die Kompatibilität kein Problem. Kritisch wird es nur bei sehr komplexen, auf Prometheus-Interna zugeschnittenen Recording-Rules.

Vergleich: Kubernetes-Integration

Prometheus hat hier klar die Nase vorne: Der Prometheus Operator ist seit Jahren bewährt, ServiceMonitor- und PodMonitor-CRDs sind der Standard in vielen Helm-Charts, und kube-prometheus-stack bietet Prometheus, Grafana und AlertManager als All-in-One-Paket.

Victoria Metrics schließt die Lücke zunehmend: Der VictoriaMetrics Operator unterstützt auch ServiceMonitor-CRDs (Kompatibilität!), der vmoperator kann Prometheus-Objekte nativ lesen, und der Betrieb des Stacks ist bei ähnlicher Feature-Abdeckung einfacher.

Die Empfehlung für Kubernetes: Wer bereits kube-prometheus-stack nutzt, kann Victoria Metrics zunächst als Remote-Write-Target verwenden, um Long-Term-Storage hinzuzufügen – ohne vollständige Migration.

Vergleich: Hochverfügbarkeit und Long-Term-Storage

Hier ist der Unterschied philosophisch:

Prometheus: Single-Node by Design. Für HA braucht man entweder Thanos (Sidecar + Query-Layer + Block-Storage/S3 – komplex, aber battle-tested), Cortex (ähnlich, stärker auf Multi-Tenant ausgelegt) oder Grafana Mimir (neuerer Ansatz, ebenfalls S3-basiert).

Victoria Metrics: HA ist eingebaut. Die Cluster-Version hat native Replikation, und auch die Single-Node-Version kann einfach skaliert werden. Long-Term-Storage funktioniert lokal oder über S3 ohne externe Komponenten. Für Self-Hoster ohne Cloud-Storage-Budget ist Victoria Metrics hier klar im Vorteil.

Migration: Von Prometheus zu Victoria Metrics

Eine Migration ist überraschend unkompliziert:

  1. Victoria Metrics starten – entweder Single-Node oder Cluster
  2. Prometheus Remote Write aktivieren – in der prometheus.yml einen remote_write-Endpoint zu VictoriaMetrics hinzufügen
  3. Parallel laufen lassen – beide Systeme scrapen für eine Übergangszeit
  4. Grafana umschalten – Datasource von Prometheus auf VictoriaMetrics umzeigen
  5. Historische Daten migrieren (optional) – mit vmctl oder promtool
  6. Prometheus dekommissionieren

Die größte Herausforderung ist Schritt 4: Wenn Recording-Rules produktiv genutzt werden, sollte man diese einzeln testen. Alerting-Regeln lassen sich in VictoriaMetrics direkt als vmalert-Konfiguration nutzen.

Wann Prometheus, wann Victoria Metrics?

Prometheus ist die richtige Wahl, wenn:

  • Du auf einem bestehenden kube-prometheus-stack-basierten Setup aufbaust
  • Dein Team bereits tiefe PromQL-Erfahrung hat und keine Migration-Kosten will
  • Du AlertManager für komplexes Alerting nutzt und an das Ökosystem gebunden bist
  • Dein Cluster relativ klein ist (unter 50.000 aktive Zeitreihen)
  • Enterprise-Support-Garantien oder kommerzielle Backing erforderlich sind

Victoria Metrics ist die richtige Wahl, wenn:

  • Ressourceneffizienz entscheidend ist (kleines VPS, Homelab, Kostendruck)
  • Du Long-Term-Storage ohne Thanos-Komplexität brauchst
  • Deine Infrastruktur wächst und der Prometheus-RAM-Bedarf zum Problem wird
  • Du keine starke Bindung an bestimmte Prometheus-Interna hast
  • Du einen einfacheren Stack mit weniger Komponenten bevorzugst

Fazit

Prometheus und Victoria Metrics sind keine Konkurrenten im klassischen Sinne – Victoria Metrics hat sich bewusst als Drop-in-Ersatz positioniert und profitiert vom Prometheus-Ökosystem. Die Entscheidung hängt am Ende von zwei Faktoren ab: Ressourcen und Ökosystem-Bindung.

Wer mit begrenztem RAM oder Budget arbeitet, wird Victoria Metrics lieben. Die Einsparungen sind real und messbar. Wer tief in der Prometheus-Operator-Welt steckt, sollte abwägen, ob der Migrationsaufwand den Gewinn überwiegt – oder Victoria Metrics zunächst als Remote-Write-Target hinzufügt.

Meine persönliche Empfehlung: Neue Installationen direkt mit Victoria Metrics starten. Für bestehende Prometheus-Setups lohnt sich die Migration ab ca. 50.000 aktiven Zeitreihen oder wenn Ressourcenkosten ein Thema werden.

Weiterführende Artikel

Verwandte Technologien im Techradar