imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

2026-09-15T00:00:00Z

Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

Neue Seite

== 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 <code>wazuh-archives-*</code>

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:

<syntaxhighlight lang="text">
/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json
</syntaxhighlight>

Archives:

<syntaxhighlight lang="text">
/usr/share/filebeat/module/wazuh/archives/ingest/pipeline.json
</syntaxhighlight>

Dort definiert der <code>date_index_name</code>-Processor die tägliche Indexbildung:

<syntaxhighlight lang="text">
{
"date_index_name": {
"field": "timestamp",
"date_rounding": "d",
"index_name_prefix": "{{fields.index_prefix}}",
"index_name_format": "yyyy.MM.dd",
"ignore_failure": false
}
}
</syntaxhighlight>

Die Logik funktioniert folgendermaßen:

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

<syntaxhighlight lang="text">
wazuh-alerts-4.x-2026.02.27
</syntaxhighlight>

oder

<syntaxhighlight lang="text">
wazuh-archives-4.x-2026.02.27
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
/var/ossec/logs/alerts/
</syntaxhighlight>

und

<syntaxhighlight lang="text">
/var/ossec/logs/archives/
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
GET _cluster/health
GET _cat/thread_pool?v
GET _cat/nodes?v
GET _cat/shards?v
GET _nodes/stats
</syntaxhighlight>

Wichtig sind insbesondere:

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

Auf dem Wazuh Manager:

<syntaxhighlight lang="text">
iostat -xz 1
iotop
htop
</syntaxhighlight>

Besonders relevant:

* hohe <code>%iowait</code>
* 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:

<syntaxhighlight lang="text">
wazuh-alerts-*
wazuh-archives-*
</syntaxhighlight>

sollten unterschiedliche Aufbewahrungszeiten haben.

=== Replikate reduzieren ===

Gerade bei hohem Archive-Volumen:

<syntaxhighlight lang="text">
{
"index.number_of_replicas": 0
}
</syntaxhighlight>

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 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 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.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program]

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

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/langsame-log-ingestion-beim-taeglichen-wazuh-indexwechsel-analysieren/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 9. Juni 2026).

== Unterstützung von m.a.x. it ==
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]

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

imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)