Wazuh Discover zeigt keine Syslog-Events: „max shards open“ im Indexer verhindert wazuh-archives-* Indizes

Einleitung

Ein klassisches Troubleshooting-Szenario in produktiven Wazuh-Umgebungen: Syslog ist korrekt konfiguriert, Logs erscheinen in archives.json, Decoder- und Rule-Tests funktionieren – aber im Wazuh Dashboard (Discover) sind keine Events sichtbar. In vielen Fällen liegt das Problem nicht an Decodern oder Filebeat-Modulen, sondern am Wazuh Indexer selbst: Der Cluster hat das Maximum an offenen Shards erreicht und lehnt neue Indizes ab.

Dieser Beitrag zeigt, wie man das Problem sauber diagnostiziert, warum es auftritt und wie man es nachhaltig behebt – insbesondere in Umgebungen mit aktivierten archives.

Ausgangslage / Problemstellung

Syslog korrekt in ossec.conf konfiguriert
Events landen in /var/ossec/logs/archives/archives.json
wazuh-logtest und decoder-test funktionieren
Filebeat-Modul aktiviert:

filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true
    archives:
      enabled: true

Im Dashboard erscheinen jedoch keine neuen Events
Fehler: „Unable to create wazuh-archives-*“
Indexer-Fehler:

Validation Failed: 1: this action would add [3] total shards.
but this cluster currently has [2000]/[2000] maximum shards open;

Gleichzeitig sind nur wazuh-alerts-* Indizes vorhanden – keine wazuh-archives-*.

Technische Analyse

1) Unterschied zwischen alerts und archives

Wazuh unterscheidet zwei Datenpfade:

alerts.json → wazuh-alerts- Indizes*
Nur Events, die eine Regel triggern
archives.json → wazuh-archives- Indizes*
Alle empfangenen Logs (auch ohne Rule-Match)

Damit Discover „roh“ alle Syslog-Events anzeigen kann, muss archives aktiviert und korrekt indexiert sein. Die offizielle Dokumentation beschreibt diesen Mechanismus im Abschnitt Event Logging.
https://documentation.wazuh.com/current/user-manual/manager/event-logging.html#visualizing-the-events-on-the-dashboard

2) Warum keine Indizes erstellt wurden

Filebeat hat korrekt versucht, wazuh-archives-* anzulegen.
Der Indexer hat dies jedoch abgelehnt, weil das Cluster Maximum an offenen Shards erreicht war.

Beispielstatus:

max shards open: 2000/2000

Das bedeutet:

Der Cluster darf keine neuen Indizes (und damit neue Shards) mehr anlegen
wazuh-archives-* kann nicht erstellt werden
Filebeat schreibt ins Leere
Discover zeigt keine Events

3) Warum zu viele Shards problematisch sind

Standardmäßig liegt das Limit bei 1000 Shards pro Node (hier offenbar bereits erhöht).

Jeder Shard verbraucht:

Heap Memory
File Descriptors
CPU
Disk I/O

Zu viele kleine Indizes führen zu:

Langsamen Queries
Hoher Cluster-Overhead
Stabilitätsproblemen
Rejected Write Operations (wie hier)

Das einfache Erhöhen des Limits ist keine nachhaltige Lösung.

Lösung / Best Practices

Schritt 1: Aktuelle Indizes prüfen

curl -k -u admin https://localhost:9200/_cat/indices?v

Hier sieht man, welche Indizes existieren und wie viele Shards verwendet werden.

Schritt 2: Alte Indizes löschen (manuell)

Beispiel:

curl -k -u admin:admin -XDELETE https://<INDEXER_IP>:9200/wazuh-alerts-4.x-2024.10.26

Oder mit Wildcard:

curl -k -u admin:admin -XDELETE https://<INDEXER_IP>:9200/wazuh-alerts-4.x-2024.09.*

Wichtig:

Gelöschte Indizes sind unwiederbringlich verloren
Vorher ggf. Snapshot erstellen

Dokumentation:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer/migrating-wazuh-indices.html

Schritt 3: Index Lifecycle Management (ILM) einrichten

Statt manuell zu löschen, sollte eine ILM-Policy konfiguriert werden:

Warm Phase
Delete Phase nach X Tagen
Optional Snapshot vorher

Offizielle Anleitung:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

Das verhindert zukünftige Shard-Explosionen.

Schritt 4: Alternativ – Indexer Node hinzufügen

In produktiven Distributed-Setups ist Skalierung oft die saubere Lösung:

Mehr Nodes → mehr Shard-Kapazität
Höhere Resilienz
Bessere Query-Performance

Guide:
https://documentation.wazuh.com/current/user-manual/upscaling/adding-indexer-node.html

Schritt 5: Danach Neustart & Verifikation

Alte Indizes bereinigen
Prüfen:

curl -k -u admin https://localhost:9200/_cluster/health?pretty

Sicherstellen, dass wazuh-archives-* nun erstellt wird
Discover prüfen

Lessons Learned / Best Practices

Wenn Events in archives.json erscheinen, aber nicht in Discover → zuerst Indexer prüfen
„Unable to create wazuh-archives-*“ deutet fast immer auf Indexer-/Shard-Probleme hin
Shard-Limit erhöhen ist nur eine Notlösung
ILM ist Pflicht in produktiven Umgebungen
archives erzeugt erheblich mehr Indizes als alerts – Storage- und Shard-Planung muss das berücksichtigen
Distributed-Architekturen brauchen Kapazitätsplanung (Shards pro Tag × Retention)

Fazit

Das Problem lag nicht an Syslog, Decodern oder Filebeat – sondern am Wazuh Indexer, der aufgrund des maximalen Shard-Limits keine neuen wazuh-archives-* Indizes mehr anlegen konnte.

Sobald alte Indizes bereinigt oder eine ILM-Strategie implementiert wurde, konnten neue Archive-Indizes erstellt werden und die Events erschienen korrekt im Discover-Bereich.

Wer archives aktiviert, sollte zwingend Retention- und Shard-Strategie planen – sonst ist ein Shard-Limit nur eine Frage der Zeit.