VictoriaLogs vs. Loki – Benchmark-Ergebnisse

Kurz gefasst – Nach einem direkten Vergleichstest mit einer Arbeitslast von 500 GB über 7 Tage konnte VictoriaLogs die Abfragelatenz um 94 %senken, den Speicherbedarf um ca. 40 %reduzieren und verbrauchte dabei weniger als 50 % der CPU- und RAM-Ressourcen, die wir zuvor für Loki bereitgestellt hatten. Dieser Beitrag erläutert, warum wir gewechselt haben.

Hintergrund & Anforderungen

Truefoundry unterstützt Entwickler dabei, Multi-Tenant-ML-Workloads auf Kubernetes auszuführen.
Entwickler benötigen:

• Schnelle Ad-hoc-Suche
• Gute Ingestion- rate
• Live-Tailing für das Debugging.
• Minimaler operativer Aufwand – Single-Binary-Deployments bevorzugt.
• Ressourceneffizienter Betrieb auf einem 4 vCPU / 16 GiB RAM Node
• Hohes Kompressionsverhältnis bei gespeicherten Logs
• Block-Storage  > S3 bevorzugt, um den Overhead zu reduzieren. + Latenz

Loki hat uns anfangs gute Dienste geleistet, aber mit zunehmendem Volumen sahen wir Suchlatenzen von über 30 Sekunden und eine hohe I/O-Verstärkung. Dies führte zu einer Evaluierung von VictoriaLogs.

Gartner Hype Cycle for Platform Engineering 2026

Access Full 2026 Report

Was ist Loki?

Loki ist das Log-Aggregationssystem von Grafana Labs, das Logs in komprimierten Chunks speichert, begleitet von einem Index, der auf Labels (Key-Value-Paaren) basiert. Abfragen werden in LogQL formuliert und stützen sich stark auf Label-Filter, gefolgt von Zeilenfiltern.

• Stärken: enge Grafana-Integration, kostengünstiger Index, horizontal skalierbar.
• Unsere Einschränkungen: Ein reiner Label-Index bedeutet teure Full-Scan-Regex-Suchen; hohe I/O-Last bei der Chunk-Kompaktierung; Go-GC-Overhead bei hoher Ingestionsrate.

Was ist VictoriaLogs?

VictoriaLogs ist eine Log-Datenbank des VictoriaMetrics-Teams. Sie nutzt spaltenorientierte LSM-basierte Speicherung mit Indizes pro Feld, SIMD-beschleunigter Suche und SQL-artiger LogSQL- Syntax.

• Stärken: Volltextindex auf allen Tokens; Single-Binary; sehr geringer Speicherbedarf; schnelle Scans bei kaltem Cache.
• Kompromisse: kleineres Ökosystem, weniger integrierte Schnittstellen (wir leiten Daten über Vectorweiter).

Benchmark-Methodik

Abfragesuite

1. Statistiken – Gesamtzahl der Zeilen für einen Filter in den letzten 24 Stunden.
2. Die Nadel im Heuhaufen – 3-4 statische Zeilen [UNIQUE-STATIC-LOG] ID=abc123 XYZ in einem stark protokollierten Namespace über 7 Tage.
3. Negativ – Zeichenfolge, die nicht existiert (erzwingt vollständigen Scan) über 7 Tage.

🔍 Abfrageleistung

1. Statistik-Abfrage (Protokollanzahl über 24 Std.)

Zweck: Gesamtzahl der Protokollzeilen von app="servicefoundry-server"

2. Nadel-im-Heuhaufen-Abfrage (7 Tage, ~500 GB)

Zweck: Suche nach einer eindeutigen statischen Protokollzeile im truefoundry Namespace

3. Abgleich von App-Neustart-Protokollen (7 Tage) (Zusätzliche Abfrage zur Überprüfung von Schritt 2)

Zweck: Suche nach bekanntem Neustartmuster :3000 in einer kleinen Teilmenge von Protokollen (gezielte Suche auf einem einzelnen Shard)
Die Ergebnismengen wurden als identisch verifiziert.

4. Abgleich von Nicht-Existenz-Protokollen (7 Tage)

ZweckSuche nach einem nicht existierenden Log, was eine vollständige Datensuche auslöst
Die Ergebnismengen wurden als identisch verifiziert.

Bei der Verarbeitung von 500 GB Daten verhielt sich Loki merkwürdig. Die Ressourcen waren überlastet und die Abfrageantwort blieb stehen.

Loki vs. VictoriaLogs: Die Ergebnisse auf einen Blick

Unsere Bewertung konzentrierte sich auf drei Dimensionen, die für Plattform-Ingenieure im Arbeitsalltag wichtig sind:

1. Wie schnell erhalten wir Antworten?
2. Wie viele Ressourcen kostet diese Geschwindigkeit?
3. Wie stabil ist die Anwendung unter realer Last?

Abfrageleistung

‍

Warum dieser Unterschied? VictoriaLogs verwaltet einen Index pro Token, sodass selbst regex-ähnliche Scans indexgestützt sind. Loki hingegen filtert nach einer Label-Abfrage Zeile für Zeile, was bei einem breiten Label-Set in einen Brute-Force-Scan ausartet.

🌪️ · Ingestionsleistung

Wir haben zudem die Ingestion mit 120 Replikaten unseres getestet  flog Generator.
Die Ergebnisse waren aufschlussreich:

Loki:

Loki erreicht Spitzenwerte von 3–4 vCPU, nähert sich seinem 8-GiB-Limit und zeigt bei gleicher Arbeitslast Drosselungen

VictoriaLogs:

👉 Wichtigste Erkenntnis: VictoriaLogs lieferte 3-mal höhere Ingestionsgeschwindigkeit bei einem Verbrauch von 72 % weniger CPUund87 % weniger Arbeitsspeicher im Vergleich zu Loki.

VictoriaLogs bleibt selbst bei Ingestionsspitzen deutlich unter seinen Limits von 4 vCPU / 8 GiB

2 · Ressourcenbedarf (7 Tage Aufbewahrungsdauer)

Loki

Genutzter Arbeitsspeicher: konstante Nutzung von 6–7 GB RAM
CPU-Spitzenwert: 3 vCPU

‍

VictoriaLogs

Genutzter Arbeitsspeicher: 800 MB – 900 MB
Spitzen-CPU-Auslastung: 1,1 vCPU

3 · Praxisnahe Last (Locust 2-Minuten-Lauf bei 10 Nutzern & 2 Rampup)

Die Abfragen waren ähnlich, mit zufälligen Limits und Zeitbereichen, um Cache-Bursts zu gewährleisten.

Victoria Logs

Loki

📌 Trotz der Bewältigung von 36 % höheren RPSzeigte VictoriaLogs niedrigere p95%- und Tail-Latenzen – was beweist, dass das Indizierungsmodell unter Druck standhält, mit 3,6-fach schnellerem p99%-Perzentil

‍Dieser Test hat unsere Entscheidung bestätigt: VictoriaLogs ist nicht nur in der Theorie schneller – es skaliert unter Stress bei produktionsnahen Workloads besser.

Die Zahlen kurz zusammengefasst

• 70–94 % schneller bei gängigen Suchmustern.
• ≈40 % kleiner auf der Festplatte bei gleichem Aufbewahrungszeitraum.
• Halber Rechenaufwand, wodurch auf unseren kleinsten Knoten eine volle vCPU und ca. 1–2 GiB RAM frei werden.

Fazit: Für einen protokollintensiven, suchzentrierten Anwendungsfall ermöglicht uns VictoriaLogs, Fragen in Sekunden statt in Minuten zu beantworten und gleichzeitig die Infrastrukturkosten zu senken.

Wichtigste Ergebnisse

1. Volltextindizierung ist entscheidend – Der Token-basierte Index von VictoriaLogs macht das zeilenweise Filtern per Brute-Force überflüssig.
2. Speicherlayout – Spaltenorientierte Speicherung und LSM reduzieren den Speicherbedarf auf der Festplatte und die Anzahl der Festplattenzugriffe massiv.
3. Speichereffizienz – Wir haben ca. 2 GiB RAM pro Knoten eingespart, was eine dichtere Planung ermöglicht.
4. Betriebliche Einfachheit – Beide sind als Single-Binary verfügbar, aber VictoriaLogs erforderte keinerlei manuelle Anpassungen, um diese Werte zu erreichen.

Fazit

Bei Workload-Profilen mit vielen Ad-hoc-Textsuchen lieferte VictoriaLogs um eine Größenordnung schnellere Abfragen und Einsparungen bei den Materialkosten. Loki bleibt eine hervorragende Wahl, wenn eine enge Grafana-Integration und labelbasierte Abfragen im Vordergrund stehen, aber VictoriaLogs ist jetzt unser Standard für Cluster mit hoher Ingest-Rate, die auf Entwickler ausgerichtet sind.

Referenzen

• Loki-Dokumentation
• VictoriaLogs-Dokumentation
• Promtail-Dokumentation
• Vector-Dokumentation
• Alloy-Dokumentation
• Grafana Alloy-Konfigurator

Häufig gestellte Fragen

Was ist der Hauptunterschied zwischen VictoriaLogs und Loki?

Der entscheidende Unterschied zwischen VictoriaLogs und Loki liegt in der fortschrittlichen Token-Indizierung und der spaltenorientierten Speicherung von VictoriaLogs. Dies ermöglicht eine deutlich schnellere Abfrageleistung und einen wesentlich geringeren Ressourcenverbrauch im Vergleich zur reinen Label-Indizierung von Loki, die oft zu langsameren Volltext-Suchvorgängen und einem höheren operativen Aufwand bei der Protokollverwaltung führt.

Ist VictoriaLogs schneller als Loki?

Ja, in unseren strengen Benchmarks zeigte VictoriaLogs eine überlegene Geschwindigkeit gegenüber Loki. Im Vergleich zwischen VictoriaLogs und Loki konnte VictoriaLogs die Abfragelatenz um 94 % senken und bei komplexen Abfragen eine 12-mal schnellere Suchgeschwindigkeit erzielen. Zudem bot es eine dreifach höhere Ingestionsleistung, was es deutlich effizienter macht.

Was ist der Standard-Port für VictoriaLogs?

Beim Vergleich von VictoriaLogs und Loki sind Details zur Einrichtung hilfreich. VictoriaLogs verwendet standardmäßig Port 8428 für seine HTTP-API und Scraping-Endpunkte. Über diesen Port erfolgt der Zugriff auf die Log-Datenbank und die Interaktion mit ihr. Auch wenn unser Blog den Fokus auf Leistung legt, ist das Verständnis der Grundlagen für die Bereitstellung, wie etwa der Standard-Port, für die Systemkonfiguration entscheidend.

Wie sehen die Benchmark-Ergebnisse für VictoriaLogs im Vergleich zu Loki aus?

In Benchmarks, die VictoriaLogs und Loki vergleichen, lieferte VictoriaLogs eine überlegene Leistung. Es erreichte eine Reduzierung der Abfragelatenz um 94 %, verringerte den Speicherbedarf um etwa 40 % und verbrauchte weniger als 50 % der zugewiesenen CPU- und RAM-Ressourcen. VictoriaLogs zeigte zudem einen dreifach höheren Ingestionsdurchsatz, was es äußerst effizient macht.

Was ist besser: VictoriaLogs oder Loki?

In unserem Benchmark-Vergleich zwischen VictoriaLogs und Loki erwies sich VictoriaLogs als überlegen. Es reduzierte die Abfragelatenz um 94 %, den Speicherbedarf um 40 % und verbrauchte über 50 % weniger CPU/RAM. TrueFoundry in den USA hat sich aufgrund der gesteigerten Leistung und Effizienz bei der Verwaltung von ML-Workloads für VictoriaLogs entschieden.