Langsame Log-Ingestion beim täglichen Wazuh-Indexwechsel analysieren

von

Einleitung

Wazuh erzeugt standardmäßig tägliche Indizes für Alerts und Archives. Dieser Mechanismus sorgt für übersichtliche Datenhaltung und ermöglicht effiziente Retention Policies über ILM. In größeren Umgebungen fällt jedoch häufig auf, dass rund um den täglichen Indexwechsel kurzzeitig eine erhöhte Latenz oder langsamere Ingestion auftritt.

Besonders betroffen sind oft Archive-Indizes mit hohem Eventvolumen. Die Ursache liegt nicht in einem einzelnen Prozess, sondern in mehreren gleichzeitig stattfindenden Operationen auf Manager-, Filebeat- und Indexer-Ebene.

Ausgangslage / Problemstellung

In einer verteilten Wazuh-Umgebung mit mehreren Nodes tritt täglich zur lokalen Uhrzeit des Indexwechsels eine deutliche Verlangsamung der Ingestion auf. In diesem Fall:

  • täglicher Indexwechsel gegen 05:00 Uhr
  • verzögerte Ingestion bis etwa 05:20–05:30 Uhr
  • danach automatische Normalisierung
  • besonders sichtbar bei wazuh-archives-*

ILM-Policies existieren bereits, weshalb nicht das Anwachsen alter Indizes das Problem darstellt. Ziel war vielmehr zu verstehen, welche internen Prozesse während des täglichen Index-Rotationszeitpunkts tatsächlich stattfinden und welche davon Ressourcen verbrauchen.

Technische Analyse

Die tägliche Indexrotation wird nicht direkt vom Wazuh Indexer gesteuert, sondern primär durch Filebeat und die Wazuh-Ingest-Pipelines.

Relevant sind insbesondere folgende Dateien:

Alerts:

/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json

Archives:

/usr/share/filebeat/module/wazuh/archives/ingest/pipeline.json

Dort definiert der date_index_name-Processor die tägliche Indexbildung:

{
  "date_index_name": {
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "{{fields.index_prefix}}",
    "index_name_format": "yyyy.MM.dd",
    "ignore_failure": false
  }
}

Die Logik funktioniert folgendermaßen:

Sobald das erste Event mit einem neuen Datum eintrifft, erzeugt Filebeat automatisch einen neuen Zielindex wie:

wazuh-alerts-4.x-2026.02.27

oder

wazuh-archives-4.x-2026.02.27

Parallel dazu laufen mehrere ressourcenintensive Prozesse.

1. Filebeat-Rotation

Filebeat rotiert interne Zustände und verarbeitet gleichzeitig weiterhin eingehende Events. Dazu gehören:

  • Aktualisierung interner Offsets
  • Rotieren der lokalen Alert-/Archive-Dateien
  • Öffnen neuer Write-Handles
  • Schließen alter Handles
  • interne Queue-Operationen

Zusätzlich werden ältere lokale Dateien komprimiert oder verschoben.

Betroffen sind insbesondere:

/var/ossec/logs/alerts/

und

/var/ossec/logs/archives/

Diese Operationen erzeugen zusätzliche CPU- und Disk-I/O-Last auf dem Wazuh Manager.

2. OpenSearch / Indexer Index-Erstellung

Parallel dazu muss der Wazuh Indexer den neuen Tagesindex initialisieren.

Dabei passieren mehrere interne Cluster-Operationen:

  • Anwendung der Index-Templates
  • Erstellung der Shards
  • Zuweisung von Primaries und Replicas
  • Aktualisierung der Cluster-Metadaten
  • Refresh- und Segment-Initialisierung
  • mögliche ILM-Initialisierung
  • Cache-Neuberechnung

Gerade Archive-Indizes erzeugen hohe Last, da dort erheblich mehr Dokumente pro Minute verarbeitet werden als bei Alerts.

3. Zeitgleich aktive ILM-Prozesse

Falls ILM aktiv ist, können genau zu diesem Zeitpunkt zusätzlich laufen:

  • Rollovers
  • Delete-Phasen
  • Segment-Merges
  • Snapshot-Prozesse
  • Force-Merge-Operationen

Diese konkurrieren direkt mit der neuen Index-Erstellung um:

  • CPU
  • Disk I/O
  • JVM Heap
  • Threadpools

4. Clusterweite Shard-Allokation

In größeren Clustern entsteht zusätzliche Last durch:

  • Rebalancing
  • Replica-Allokation
  • Cluster-State-Updates

Besonders bei vielen kleinen Daily-Indizes kann das den Cluster-Manager stark belasten.

Lösung / Best Practices

Der wichtigste Schritt ist zunächst die Korrelation der Verzögerung mit den tatsächlichen Cluster- und Systemmetriken.

Während des Problemzeitraums sollten folgende Werte überwacht werden:

Indexer:

GET _cluster/health
GET _cat/thread_pool?v
GET _cat/nodes?v
GET _cat/shards?v
GET _nodes/stats

Wichtig sind insbesondere:

  • JVM Heap
  • Disk Wait
  • Queue-Größe
  • Bulk Thread Pool
  • Write Rejections
  • Merge-Zeiten

Auf dem Wazuh Manager:

iostat -xz 1
iotop
htop

Besonders relevant:

  • hohe %iowait
  • hohe CPU durch Filebeat
  • erhöhte Queue-Latenzen

Für Archive-Ingestion helfen häufig folgende Optimierungen.

Separate Retention für Archives

Archive-Indizes wachsen deutlich schneller als Alerts. Eigene ILM-Policies reduzieren die Last:

wazuh-alerts-*
wazuh-archives-*

sollten unterschiedliche Aufbewahrungszeiten haben.

Replikate reduzieren

Gerade bei hohem Archive-Volumen:

{
  "index.number_of_replicas": 0
}

für Archive-Indizes kann die Last deutlich reduzieren.

Shard-Anzahl optimieren

Zu viele kleine Shards erzeugen unnötige Cluster-Last.

Faustregel:

  • wenige große Shards statt vieler kleiner
  • Daily Archives nicht über-sharden

ILM-Zeitfenster verschieben

Delete- oder Force-Merge-Operationen sollten nicht exakt zum Tageswechsel laufen.

Filebeat-Ressourcen prüfen

Filebeat kann bei hohem Volumen selbst zum Bottleneck werden:

  • Queue-Größe
  • Bulk Size
  • Worker-Anzahl
  • Disk-I/O

sollten überprüft werden.

Lessons Learned / Best Practices

Der tägliche Indexwechsel ist kein einfacher „Rename“-Prozess, sondern ein Zusammenspiel mehrerer ressourcenintensiver Operationen auf allen Ebenen der Wazuh-Architektur.

Besonders häufig unterschätzt werden:

  • Segment-Merges
  • ILM-Operationen
  • Disk-I/O durch lokale Rotation
  • Shard-Allokation
  • JVM-Heap-Spitzen

Archive-Indizes sind fast immer deutlich kritischer als Alerts, weil dort wesentlich höhere Eventraten auftreten.

Die zeitliche Korrelation mit dem Indexwechsel bedeutet außerdem nicht zwangsläufig, dass ausschließlich die Index-Erstellung selbst das Problem verursacht. Oft überlagern sich mehrere Prozesse exakt in diesem Zeitfenster.

Ein häufiges Muster:

  • neuer Index wird erstellt
  • alte Segmente werden gemerged
  • ILM löscht alte Indizes
  • Filebeat rotiert Dateien
  • Bulk-Queues steigen an
  • Disk-I/O erreicht Limits

Das erklärt die typischen 15–30 Minuten verzögerter Ingestion.

Fazit

Die tägliche Wazuh-Indexrotation erzeugt kurzfristig erhöhte Last auf Manager-, Filebeat- und Indexer-Seite. Besonders Archive-Indizes können während dieses Zeitfensters deutlich langsamer ingestiert werden.

Die Hauptursachen sind:

  • gleichzeitige Filebeat-Rotation
  • neue Index-Erstellung
  • Shard-Allokation
  • ILM-Operationen
  • Segment-Merges
  • hohe Disk-I/O-Last

Die beste Gegenmaßnahme besteht darin, Archive-Workloads gezielt zu optimieren, ILM zeitlich zu entzerren und die Cluster- sowie Diskmetriken während des kritischen Zeitfensters detailliert zu überwachen.

Quellen

Wazuh-Dokumentation: Index lifecycle management
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C07CCCCGHHP/p1772081305544459