Wazuh Dashboard zeigt plötzlich keine neuen Logs mehr: Shard-Limit im Indexer als versteckte Ursache

von

Einleitung

Wenn im Wazuh Dashboard „von jetzt auf gleich“ keine neuen Events mehr erscheinen, wirkt das zunächst wie ein klassisches Pipeline-Problem: Filebeat, Indexer, Manager oder Dashboard „hängen“. In vielen Fällen laufen aber alle Services fehlerfrei, die Alerts liegen sogar weiterhin auf dem Manager vor – und trotzdem bleibt das Dashboard leer. Ein typischer Grund dafür ist Shard-Exhaustion im Wazuh Indexer: Das Cluster erreicht das zulässige Shard-Limit und blockiert dadurch die Aufnahme neuer Indizes bzw. Shards.

Dieser Artikel erklärt, wie sich das Problem sauber diagnostizieren lässt, warum Reboots meist nichts bringen – und welche Maßnahmen kurzfristig helfen, ohne die langfristige Stabilität zu gefährden.

Ausgangslage / Problemstellung

Symptomatik aus der Praxis:

  • Wazuh Dashboard zeigt keine neuen Logs/Alerts mehr (z. B. „Alerts count = 0“ oder „No results“).
  • Dienste laufen laut systemctl status (Manager, Indexer, Filebeat, Dashboard) „grün“.
  • Alerts sind auf dem Manager in /var/ossec/logs/alerts/alerts.log sichtbar.
  • Im Indexer existieren Indizes wie wazuh-alerts-4.x-*, aber neue Events kommen nicht mehr im Dashboard an.
  • Ein oder mehrere Reboots ändern nichts.

Genau dieses Muster passt sehr häufig zu einem Zustand, in dem der Indexer neue Shards nicht mehr anlegen/allozieren kann, weil das Shard-Limit erreicht wurde. Google Gruppen

Technische Analyse

1) Was bedeutet „Shard-Limit erreicht“?

Wazuh Indexer basiert auf OpenSearch. OpenSearch schützt Cluster vor Überlast, indem es eine Obergrenze für die Anzahl an Shards erzwingt. Wird diese Grenze erreicht, schlagen Operationen fehl, die zusätzliche Shards erzeugen würden (z. B. Index-Rollover, neue Tagesindizes, neue Replikate). docs.opensearch.org

In der Wazuh-Praxis taucht das häufig als „Maximum of 1000 shards reached“ auf – insbesondere bei Single-Node- oder kleineren Clustern und bei langen Retention-Zeiträumen. GitHub

2) Warum sieht man Alerts auf dem Manager, aber nicht im Dashboard?

Der Manager kann Alerts weiterhin lokal schreiben. Die „Lücke“ entsteht danach: Filebeat/OpenSearch-Output kann nicht mehr erfolgreich indexieren, weil das Cluster keine Shards mehr bereitstellt oder Indizes nicht mehr richtig rollovern kann. Ergebnis: Die UI zeigt nur ältere Daten; neue Alerts bleiben im „Ingest“ stecken oder werden verworfen/fehlerhaft ausgeliefert. Google Gruppen

3) Warum hilft ein Reboot selten?

Ein Reboot reduziert keine Shards. Das Limit basiert auf der Anzahl existierender Shards (Primaries + Replicas) und bleibt nach Neustart unverändert. AWS-Dokumentation

4) Typische Verstärker im Wazuh-Kontext

  • Zu viele historische Tagesindizes ohne automatisches Löschen (fehlende ILM/ISM/Retention).
  • Unpassende Shard-/Replica-Einstellungen (z. B. Replikas in Single-Node, unnötig hohe Shard-Zahl pro Index).
  • Viele Index Patterns (Alerts + Archives + ggf. weitere).
    Wazuh empfiehlt, Shards an die Clustergröße anzupassen und Lifecycle-Management zu nutzen, um alte Daten automatisiert zu entfernen.

Lösung / Best Practices

Schritt 1: Zustand verifizieren (Cluster- und Shard-Sicht)

Auf einem Indexer-Node (oder per Dev Tools im Dashboard) die Basics prüfen:

  • Cluster Health:
    • GET _cluster/health
  • Shard-/Index-Überblick:
    • GET _cat/indices/wazuh-alerts-*?v
    • GET _cat/shards?v
  • Allocation/Storage:

Wenn dabei Fehlermeldungen auftauchen, die sinngemäß „… would add [x] shards, but this cluster currently has … maximum shards …“ lauten, ist die Ursache bestätigt. Stack Overflow

Schritt 2: Kurzfristig wieder „Luft“ schaffen (saubere Varianten)

Option A (empfohlen): Alte Indizes löschen (Retention manuell)

  • Identifiziere alte wazuh-alerts-* und ggf. wazuh-archives-*.
  • Lösche zunächst die ältesten Zeiträume (nach internen Aufbewahrungsregeln).
    Das ist die nachhaltig korrekte Sofortmaßnahme: Shards werden wirklich frei. GitHub

Option B: Replikas reduzieren, falls unnötig
In Single-Node-Setups sind Replikas oft nicht sinnvoll (führen zu mehr Shards ohne Mehrwert). Eine Reduktion kann Shards sparen (Achtung: erst prüfen, ob HA-Anforderungen bestehen). Wazuh dokumentiert Indexer-Tuning u. a. über Replica-Settings. documentation.wazuh.com

Option C (nur als temporärer Workaround): Shard-Limits erhöhen
Man kann Limits im Cluster hochsetzen. Das kann kurzfristig das Indexing wieder herstellen, erhöht aber Risiko für Performance-Probleme (Heap/CPU/Segment-Overhead). Deshalb als „Notnagel“ betrachten, nicht als Dauerlösung. Opster

Wichtig: In OpenSearch ist häufig cluster.max_shards_per_node die zentrale Größe; Wazuh-Setups sehen zusätzlich häufig cluster.routing.allocation.total_shards_per_node in Troubleshootings. Beide Mechanismen zielen auf Shard-Begrenzung/Allocation ab, aber die saubere Lösung bleibt: Shard-Anzahl reduzieren und Lifecycle-Management aktivieren. docs.opensearch.org

Schritt 3: Nachhaltig verhindern – ISM/ILM aktivieren (Wazuh Index Management)

Damit der Zustand nicht wiederkehrt, braucht es automatisiertes Index Lifecycle Management:

  • Rollover nach Größe/Alter
  • Delete nach Retention (z. B. 30/90/180 Tage)
  • Optional: Warm/Cold Phasen (je nach Architektur)

Wazuh beschreibt dafür Index Lifecycle Management via ISM und verweist auf periodische Rollovers und Löschungen als Performance- und Betriebsgrundlage.

Schritt 4: Shard-Strategie an Clustergröße anpassen

Als Faustregel in Wazuh-Dokumentation: Shard-Anzahl pro Index sinnvoll dimensionieren (insbesondere bei wenigen Nodes) – unnötig viele Shards erhöhen Shard-Count und Overhead drastisch. wazuh-documentation-49-master.readthedocs.io
Zusätzlich gilt in OpenSearch-Umgebungen der Grundsatz, dass zu viele Shards pro Heap ungesund sind; auch AWS empfiehlt, Shards pro Heap-Größe zu begrenzen und Retention/Deletion ernst zu nehmen. Repost

Lessons Learned / Best Practices

  • Dashboard „leer“ ist oft ein Indexer-Problem, nicht ein Dashboard-Problem. Wenn Alerts lokal geschrieben werden, ist der Datenpfad bis zum Manager okay.
  • Shard-Limit ist eine betriebliche Kapazitätsgrenze. Reboots „heilen“ das nicht.
  • Retention ist Pflicht, nicht Kür. Ohne ISM/ILM wächst die Shard-Anzahl unweigerlich bis zur Grenze. Wazuh
  • Workaround ≠ Lösung. Das Erhöhen von Shard-Limits kann kurzfristig helfen, verschiebt aber die Kapazitätsgrenze nur nach hinten und kann Performance verschlechtern. Opster
  • Single-Node benötigt besondere Sorgfalt bei Replikas und Shard-Zahl, sonst entstehen „unsichtbar“ zu viele Shards pro Tag/Index. wazuh-documentation-49-master.readthedocs.io

Fazit

Wenn im Wazuh Dashboard plötzlich keine neuen Logs mehr auftauchen, obwohl alle Services laufen und Alerts lokal vorhanden sind, ist Shard-Exhaustion im Wazuh Indexer eine der häufigsten Ursachen. Der zuverlässige Weg zurück zur Datenaufnahme ist: Shard-Limit bestätigen, alte Indizes entfernen bzw. Shard-Anzahl reduzieren, und anschließend Index Lifecycle Management (ISM/ILM) aktivieren, damit Retention automatisch passiert. Das verhindert, dass das Problem nach Tagen oder Wochen erneut zuschlägt.

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/C07CNG3M11N/p1767670884508549