Logdaten mit VictoriaLogs verarbeiten
Jäger und Sammler
Veröffentlicht in Ausgabe 06/2026 - PRAXIS
Im IT-Administrator 02/26 [1] berichteten wir ausführlich über Elasticsearch und dessen Fork OpenSearch als Volltextdatenbanken für Logaggregation und -auswertung. Beide Werkzeuge liefern umfangreiche Search- und Discovery-Funktionen, basieren auf Java und arbeiten bevorzugt als Cluster mit mehreren Knoten. Ein vollständiger ELK-Stack (Elasticsearch, Logstash, Kibana) benötigt entsprechend viele Ressourcen. Nutzen Administratoren den Stack ausschließlich zur Auswertung von System- und Applikationslogs einer IT-Infrastruktur, steht mit "VictoriaLogs" [2] eine deutlich schlankere Alternative bereit. Ausgangspunkt für dessen Entwicklung war die Metrics-Datenbank "VictoriaMetrics", die sich als schlanke und performante Alternative zu Prometheus oder InfluxDB positioniert. VictoriaLogs ähnelt eher Elasticsearch, deckt aber bewusst nicht dessen vollständigen Funktionsumfang ab und konzentriert sich ausschließlich auf die Sammlung und Analyse von Logs.
Der Hersteller entwickelt beide Produkte in Go. Dadurch bestehen sie jeweils aus einem statisch gelinkten Binary ohne zusätzliche Abhängigkeiten. Laut Hersteller benötigt VictoriaLogs nur etwa ein Dreißigstel des Arbeitsspeichers und ein Fünfzehntel des Speicherplatzes von Elasticsearch. Das liegt unter anderem daran, dass VictoriaLogs Logdaten komprimiert und dabei typischerweise eine Rate von etwa 1:10 erreicht. Entsprechend genügsam fällt der Ressourcenbedarf aus: Bereits Systeme mit einer CPU und 1 GByte RAM reichen für erste Installationen aus.
VictoriaMetrics stellt beide Werkzeuge unter der Open-Source-Lizenz Apache License 2 bereit. Für zahlende Kunden existieren zusätzlich Enterprise-Versionen. Bei der Metrics-Datenbank VictoriaMetrics erweitert die Enterprise- Variante den Funktionsumfang unter anderem um Clustering, Failover und Deduplikation. Bei VictoriaLogs existiert dagegen kein funktionaler Unterschied zwischen Open-Source- und Enterprise-Variante. Der Hersteller bietet hier vor allem Managed Services und Support.
Im IT-Administrator 02/26 [1] berichteten wir ausführlich über Elasticsearch und dessen Fork OpenSearch als Volltextdatenbanken für Logaggregation und -auswertung. Beide Werkzeuge liefern umfangreiche Search- und Discovery-Funktionen, basieren auf Java und arbeiten bevorzugt als Cluster mit mehreren Knoten. Ein vollständiger ELK-Stack (Elasticsearch, Logstash, Kibana) benötigt entsprechend viele Ressourcen. Nutzen Administratoren den Stack ausschließlich zur Auswertung von System- und Applikationslogs einer IT-Infrastruktur, steht mit "VictoriaLogs" [2] eine deutlich schlankere Alternative bereit. Ausgangspunkt für dessen Entwicklung war die Metrics-Datenbank "VictoriaMetrics", die sich als schlanke und performante Alternative zu Prometheus oder InfluxDB positioniert. VictoriaLogs ähnelt eher Elasticsearch, deckt aber bewusst nicht dessen vollständigen Funktionsumfang ab und konzentriert sich ausschließlich auf die Sammlung und Analyse von Logs.
Der Hersteller entwickelt beide Produkte in Go. Dadurch bestehen sie jeweils aus einem statisch gelinkten Binary ohne zusätzliche Abhängigkeiten. Laut Hersteller benötigt VictoriaLogs nur etwa ein Dreißigstel des Arbeitsspeichers und ein Fünfzehntel des Speicherplatzes von Elasticsearch. Das liegt unter anderem daran, dass VictoriaLogs Logdaten komprimiert und dabei typischerweise eine Rate von etwa 1:10 erreicht. Entsprechend genügsam fällt der Ressourcenbedarf aus: Bereits Systeme mit einer CPU und 1 GByte RAM reichen für erste Installationen aus.
VictoriaMetrics stellt beide Werkzeuge unter der Open-Source-Lizenz Apache License 2 bereit. Für zahlende Kunden existieren zusätzlich Enterprise-Versionen. Bei der Metrics-Datenbank VictoriaMetrics erweitert die Enterprise- Variante den Funktionsumfang unter anderem um Clustering, Failover und Deduplikation. Bei VictoriaLogs existiert dagegen kein funktionaler Unterschied zwischen Open-Source- und Enterprise-Variante. Der Hersteller bietet hier vor allem Managed Services und Support.
Kompatible APIs erleichtern bestehende Logpipelines
Damit Administratoren bestehende Logpipelines weiterverwenden können, implementiert VictoriaLogs mehrere Ingest-Pipelines und unterstützt die Datenformate verschiedener etablierter Werkzeuge. Setzen Sie beispielsweise Filebeat als Logshipper ein, lässt sich der bekannte Elasticsearch-Output auch für VictoriaLogs verwenden:
output.elasticsearch:
hosts: ["http://victorialogs.my.ip:9428/insert/elasticsearch/”]
parameters:
_msg_field: "message”
_time_field: "@timestamp”
_stream_fields: "host.hostname,log.file.path”
compression_level: 1
Auch Syslog, Journald, OTP oder Loki lassen sich anbinden. In vielen Fällen benötigen Sie keinen dedizierten Log- shipper. Die unter Linux üblichen Werkzeuge wie rsyslog oder journald (mit journald-upload-Modul) können Logs direkt aufbereiten und an VictoriaLogs übertragen. Eine Konfiguration in "/etc/rsyslog.d/victoria.conf" könnte beispielsweise so aussehen:
$template VictoriaProtocol, "<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n"
*.* @@192.168.2.32:10514; VictoriaProtocol
Wichtig ist dabei das explizite "\n" am Ende jedes Logeintrags, das VictoriaLogs als Abschluss eines Logevents erwartet.
VictoriaLogs startet ohne klassische Installation
Das Binary benötigt keine klassische Installation. Sie können das Programm in einem beliebigen Nutzerkontext starten und die Konfiguration über Kommandozeilen-Parameter übergeben. Standardmäßig verwendet VictoriaLogs den Port 9428 für seine HTTP-basierten APIs. Darüber stellt das Werkzeug auch eine einfache Weboberfläche bereit, über die Sie Logs durchsuchen und mit der Abfragesprache LogQL filtern.
Damit VictoriaLogs zusätzlich Syslog- Nachrichten entgegennimmt, starten Sie das Programm mit entsprechenden Parametern. Für diesen Workshop betreiben wir die Logdatenbank als Podman-Container. Dadurch lassen sich zusätzliche Protokolle über TCP und UDP nutzen:
podman run -d -p 9428:9428 -p 10514:514/tcp -p 10514:514/udp
--name=victorialogs
-v /var/pods/victoria:/ victoria-logs-data
docker.io/victoriametrics/ victoria-logs:latest
-storageDataPath=victoria-logs-data
-httpListenAddr=:9428
-syslog.listenAddr.tcp=:514
-syslog.listenAddr.udp=:514
Alternativ lässt sich VictoriaLogs auch auf Kubernetes betreiben. In diesem Fall benötigen Sie einen geeigneten HTTP- Proxy-Forwarder für Port 9428. Direkt auf Port 514/UDP für rsyslog kann das Werkzeug dort in der Regel nicht mehr lauschen.
Neben den bestehenden Logkollektoren existiert auch "vlagent" aus dem Victoria-Log-Repository. Unserer Ansicht nach bietet dieser Agent jedoch keinen klaren Mehrwert gegenüber bereits vorhandenen Werkzeugen wie rsyslog. Zudem zeigte vlagent in unserer Testumgebung Stabilitätsprobleme. Unter anderem traten Schwierigkeiten beim Zugriff auf Ports sowie SELinux-Verletzungen auf, sodass der Agent weder nativ noch im Container zuverlässig lief. Eine bessere Alternative stellen wir im folgenden Abschnitt vor.
Grafana ergänzt VictoriaLogs als Visualisierung
Zum Elasticsearch-Stack gehört mit Kibana ein leistungsfähiges Werkzeug für Visualisierung und Analyse. Eine vergleichbare Oberfläche liefert VictoriaLogs nicht. Die Datenbank bringt lediglich eine minimalistische Weboberfläche mit, die Logs anzeigt und deren Filterung über LogQL erlaubt. Für eine erste Kontrolle oder zur Fehlersuche reicht das aus, etwa wenn Daten nicht wie erwartet in VictoriaLogs eintreffen. Für die eigentliche Visualisierung setzen VictoriaLogs und VictoriaMetrics jedoch auf Grafana. Grafana entstand ursprünglich als Werkzeug für Metriken, kann inzwischen aber auch Logs gut darstellen. Möglich machen das unter anderem Werkzeuge wie Grafana Loki sowie spezielle Panels wie "Raw Logs" oder "Tables".
Für VictoriaLogs existiert zudem ein eigenes Input-Plug-in. Es gehört nicht zur Standardinstallation von Grafana, lässt sich jedoch über den "Connections"-Tab mit wenigen Klicks nachinstallieren. Danach stehen verschiedene Visualisierungsoptionen für Logs bereit: von der Anzeige roher Logdaten über gefilterte Tabellen bis zu grafischen Auswertungen. Administratoren können über LogQL-Abfragen zudem Kennzahlen aus Logdaten ableiten. Ein Beispiel sind "Error"-Meldungen pro Sekunde. Solche Logmetriken lassen sich direkt mit Alert-Regeln verknüpfen. Grafana kann dann automatisch warnen, wenn etwa die Zahl fehlgeschlagener SSH-Anmeldungen pro Minute auf einem System stark ansteigt. Als Logviewer bietet Grafana zwar weniger Analyse- und Discovery-Funktionen als Kibana. Viele Umgebungen setzen Grafana jedoch bereits für Metriken ein. Ein gemeinsames Frontend für Metriken und Logs reicht daher in vielen Fällen völlig aus.
Vector bereitet Logdaten ressourcenschonend auf
Mit LogQL lassen sich bereits viele Auswertungen direkt auf den von rsyslog gelieferten Logs durchführen. Für komplexere Analysen ist es jedoch komfortabler, einen Data-Prepper zwischen Logquelle und VictoriaLogs einzusetzen. Im früheren Workshop zu Elasticsearch und OpenSearch nutzten wir beispielsweise eine Pipeline, die aus DNS-Serverlogs Hostnamen und IP-Adressen extrahiert und über einen GeoIP-Lookup zusätzliche Standortinformationen ergänzt. Die Pipeline (Filebeat > Kafka > Logstash > Elasticsearch) lief dabei über Kafka, sodass neben dem ELK-Stack auch andere Auswertungen auf die Daten zugreifen konnten, ohne die Logsammler auf den Clients anpassen zu müssen.
Werkzeuge wie Logstash oder Data Prepper lassen sich grundsätzlich auch mit VictoriaLogs einsetzen, da das Werkzeug ein Elasticsearch-kompatibles API bereitstellt. VictoriaLogs überzeugt jedoch mit einem geringen Ressourcenbedarf und "schwere" Java-basierte Logprozessoren würden diesen Vorteil teilweise wieder zunichtemachen. Eine deutlich schlankere Alternative stellt Vector [3] dar. Das Open-Source-Werkzeug stammt aus dem Umfeld von Datadog und bietet einen ähnlichen Funktionsumfang wie Logstash. Statt einer umfangreichen Java-Umgebung nutzt Vector jedoch ein einzelnes Binary in Rust und benötigt entsprechend deutlich weniger Ressourcen.
Vector verwendet die "Vector Remap Language" (VRL) für seine Filterpipelines. Damit lassen sich Logdaten ähnlich flexibel aufbereiten wie mit Funktionen wie "Grok" in Logstash. Für unser Setup ergibt sich daher folgende Pipeline: Filebeat > Kafka > Vector > VictoriaLogs. Die bestehende Logsammlung bleibt dabei unverändert. Gegenüber dem ELK-Workshop passen wir den Logfluss jedoch leicht an. Statt das Logfile von Pi-hole auszuwerten, lesen wir die Logeinträge des Dienstes "dnsmasq" direkt aus den Journald-Logs. Dadurch vereinfacht sich die Konfiguration des Filebeat- Logsammlers, da dieser nur noch Journald-Daten einsammeln muss.
Für die GeoIP-Auflösung benötigt Vector zunächst die GeoIP-Datenbank "GeoLite2- City.mmdb" [4] von MaxMind. In der Vector-Konfiguration binden wir diese Datenbank zunächst als Enrichment- Tabelle ein:
enrichment_tables:
geoip:
type: geoip
path: /etc/vector/GeoLite2-City.mmdb
Damit erhält Vector Zugriff auf die GeoIP-DB. Anschließend liest das Werkzeug die Daten aus dem Kafka-Topic:
sources:
kafka_journald:
type: kafka
bootstrap_servers: "192.168.2.74:9092"
group_id: vector-journald
topics:
- journals
Die eingehenden Meldungen verarbeitet anschließend der Transformer von Vector:
transforms:
remap_journald:
type: remap
inputs:
- kafka_journald
VictoriaLogs erwartet andere Feldnamen ("_msg" und "_time"), als sie Filebeat über Kafka liefert. Die Filterpipeline passt die Felder daher entsprechend an:
source: |-
._msg = del(.message)
._time = del(."@timestamp")
Enthält der Logstream Einträge mit "appname=dnsmasq", durchsucht der Filter die Meldungen nach Rückgaben wie "reply api.amazon.com is 98.82.154.190". Über reguläre Ausdrücke extrahiert die Pipeline daraus Hostname und IP- Adresse und ergänzt diese Informationen als eigene Felder im Logstream.
if .log.syslog.appname == "dnsmasq" {
parsed, err = parse_regex(._msg, r"^(?:reply|cached) (?P<name>\S+) is (?P<ip>(?:\d{1,3}\.){3}\d{1,3})$")
if err == null {
.dnsmasq.query.name = parsed.name
.dnsmasq.query.ip = parsed.ip
Und mit "parsed.ip" fragt Vector die GeoIP-Datenbank ab:
geo, geo_err = get_enrichment_table_record("geoip”, {"ip”: parsed.ip})
if geo_err == null {
.dnsmasq.query.geo.lat = geo.latitude
.dnsmasq.query.geo.lon = geo.longitude
.dnsmasq.query.geo.city = geo.city_name
.dnsmasq.query.geo.country = geo.country_name } }
Ob Sie die "Grok"-Syntax von Logstash oder die VRL von Vector bevorzugen, ist letztlich Geschmackssache. Ein praktischer Vorteil von VRL zeigte sich bereits im letzten Workshop: Das vollständige Filterstatement von Logstash ließ sich aus Platzgründen nicht vollständig abdrucken. Das spricht für die kompaktere Syntax von VRL. Am Ende der Konfiguration steht VictoriaLogs als Zielsystem:
sinks:
victoria_logs_journald:
type: http
inputs:
- remap_journald
uri: [http://localhost:9428/insert/jsonline](http://localhost:9428/insert/jsonline)
encoding:
codec: json
framing:
method: newline_delimited
method: post
Damit ist die Pipeline vollständig definiert. Nun starten wir auch Vector als Container über Podman:
podman run -d -p 8686:8686
--name=vector
-v ~/vector/vector.yaml:/etc/vector/vector.yaml:ro
-v ~/vector/GeoLite2-City.mmdb:/etc/vector/GeoLite2-City.mmdb:ro
-v /etc/timezone:/etc/timezone:ro
docker.io/timberio/vector:latest-debian
Vector benötigt keinen persistenten Speicher. Der Container liest lediglich die Konfiguration sowie die GeoIP-Datenbank ein. Für die finale Testumgebung bündeln wir beide Container in einem gemeinsamen Pod, da sie auf demselben Host laufen.
Minimale Ressourcen reichen für den Betrieb
Um zu prüfen, wie sparsam der Stack tatsächlich arbeitet, betreiben wir VictoriaLogs und Vector testweise auf einem Cubietruck. Dabei handelt es sich um einen rund zehn Jahre alten 32-Bit-ARM-Einplatinencomputer mit Dual-Core Cortex-A7 (1 GHz) und lediglich 2 GByte RAM. Trotz dieser sehr begrenzten Hardware verarbeitet das Setup im Test 1,3 Millionen Logeinträge mit etwa 1000 Events pro Sekunde. Von ursprünglich 2,15 GByte an JSON-Rohdaten bleiben auf dem Datenträger – in diesem Fall einer Micro-SD-Karte – nur rund 42 MByte übrig.
Niemand wird eine Logdatenbank produktiv auf einem 32-Bit-Einplatinencomputer betreiben. Dennoch zeigt dieser Test eindrucksvoll, wie effizient der VictoriaLogs-Stack arbeitet. Im Vergleich zum etablierten ELK-Stack benötigt er nur einen Bruchteil der Ressourcen und liefert dennoch eine überzeugende Performance. In der Praxis läuft der Stack häufig auf Kubernetes. Da VictoriaLogs primär über HTTP arbeitet, lässt sich der Zugriff dort problemlos über die üblichen Kubernetes-Router und Reverse-Proxys weiterleiten und mit SSL absichern. Die hier gezeigten Podman-Aufrufe sind zudem nahezu unverändert in Kubernetes-Deployments nutzbar.
Fazit
Die Kombination aus VictoriaLogs und Vector stellt eine interessante Alternative zu den etablierten Elastic- und Open- Search-Stacks für die Logaggregation dar. Das ELK-Ökosystem bietet zwar eine größere Zahl an Plug-ins und Erweiterungen, darunter auch kommerzielle Angebote. Zudem erreicht Grafana als Oberfläche für Logs nicht den Funktionsumfang von Kibana.
Für viele typische Aufgaben der Loganalyse reicht jedoch ein Stack aus VictoriaLogs, Vector und Grafana völlig aus. Viele Administratoren begrüßen zudem, dass sie Metriken und Logs in einer gemeinsamen Oberfläche überwachen können. Hinzu kommt die kompakte und gut strukturierte Vector Remap Language, die in vielen Fällen übersichtlicher wirkt als die komplexe Grok-Syntax von Logstash.
(jp)
Links
[1] Loganalyse mit OpenSearch und Elasticsearch: https://it-a.eu/q5p11
[2] VictoriaLogs: https://it-a.eu/q5p12
[3] Vector: https://it-a.eu/q5p13
[4] GeoLite: https://it-a.eu/q5p14