Wazuh 4.11 stoppt Datenaufnahme durch Shard-Limit im Indexer: Ursachen, Sofortfix und nachhaltige Retention-Strategie

Einleitung

Wenn im Wazuh Dashboard plötzlich keine neuen Events mehr erscheinen, wirkt das zunächst wie ein Pipeline-Problem (Manager, Filebeat, Indexer, Dashboard). In der Praxis ist die Ursache häufig eine Schutzgrenze im Wazuh Indexer (OpenSearch): Sobald das Cluster das maximale Shard-Limit erreicht, scheitert die Index-Erstellung – und damit bricht die Datenaufnahme ab. Besonders in Single-Node-Setups mit täglichen Indizes und langer Aufbewahrung (Compliance) tritt dieses Problem früher oder später zwangsläufig auf.

Ausgangslage / Problemstellung

In einem Wazuh 4.11 Single-Node-Server werden keine neuen Daten mehr indexiert. Filebeat meldet:

• Validation Failed: ... cluster currently has [1000]/[1000] maximum shards open

Der Cluster-Health-Status ist yellow (ein Single Node kann Replikas nicht zuweisen), active_shards_percent_as_number liegt bei ~76% und es gibt viele unassigned_shards. Ein allocation/explain zeigt als Decider u. a. same_shard (Replika kann nicht auf demselben Node wie das Primary liegen).

Wichtiges Detail: Auch wenn pro Index nur 1 Shard konfiguriert ist, entstehen durch viele Indizes (z. B. tägliche Indizes über Monate/Jahre und mehrere Index-Pattern) sehr schnell >1000 Shards pro Node.

Technische Analyse

1) Warum die Datenaufnahme stoppt

Wazuh legt typischerweise zeitbasierte Indizes an (z. B. wazuh-alerts-4.x-YYYY.MM.DD). Wenn das Cluster beim nächsten Tageswechsel (oder beim Erstellen eines neuen Index für einen weiteren Datenstrom) einen neuen Shard anlegen müsste, greift die Sicherheitsgrenze cluster.max_shards_per_node (Standard: 1000 Shards pro Node). Dann wird die Aktion abgelehnt – genau das zeigt die Filebeat-Fehlermeldung.

2) cluster.max_shards_per_node vs. cluster.routing.allocation.total_shards_per_node

In der Praxis werden hier oft zwei Limits verwechselt:

• cluster.max_shards_per_node: Safety-Limit – blockiert neue Shards/Indizes, wenn das Maximum erreicht ist (hier 1000). Das ist der Wert, der die validation_exception auslöst.
• cluster.routing.allocation.total_shards_per_node: Allocation-Limit – begrenzt, wie viele Shards (Primary+Replica) überhaupt auf einem Node alloziert werden dürfen. Das beeinflusst die Verteilung, verhindert aber nicht zwingend die Safety-Prüfung.

Wenn nur total_shards_per_node erhöht wird, max_shards_per_node aber bei 1000 bleibt, kann das System weiterhin bei der Index-Erstellung blockieren – exakt das Symptom im Thread.

3) Warum der Cluster „yellow“ ist (und warum das nicht das eigentliche Problem ist)

Auf einem Single Node können Replikas nicht zugewiesen werden. Sobald irgendein Index number_of_replicas > 0 hat (oder Templates/Policies Replikas vorsehen), entsteht yellow und unassigned_shards. Das ist erwartbar – aber in Kombination mit zu vielen (kleinen) Indizes/Shards eskaliert es schneller. Wazuh empfiehlt für Single-Node-Indexer number_of_replicas: 0.

4) Warum „einfach Shards erhöhen“ riskant ist

Das Anheben der Limits ist ein Notnagel: Viele Shards erzeugen Overhead (Heap, Cluster-State, Segmentverwaltung). Ab einem gewissen Punkt drohen Performance-Probleme bis hin zu Out-of-Memory-Situationen – gerade auf Single Node. Deshalb sollte ein Limit-Increase nur zur Stabilisierung genutzt werden, während parallel eine dauerhafte Strategie umgesetzt wird.

Lösung / Best Practices

Die folgenden Schritte sind in der Praxis eine robuste Reihenfolge: erst wieder Datenfluss herstellen, dann Shard-Anzahl dauerhaft beherrschbar machen – ohne Compliance-Anforderungen zu brechen.

Schritt 1: Aktive Limits korrekt prüfen

So sieht man Defaults und Overrides in einer Ansicht:

GET _cluster/settings?include_defaults=true&flat_settings=true

Relevant sind insbesondere:

• cluster.max_shards_per_node
• cluster.routing.allocation.total_shards_per_node

Damit vermeiden Sie Fehlinterpretationen durch „zwei Werte im Output“.

Schritt 2: Sofortfix – beide Limits konsistent anheben (nur als Stabilisierung)

Wenn kurzfristig wieder Indizes angelegt werden müssen, müssen die Limits zusammenpassen:

PUT _cluster/settings
{
  "persistent": {
    "cluster.max_shards_per_node": "1300",
    "cluster.routing.allocation.total_shards_per_node": "1300"
  }
}

Wichtig: Das ist kein langfristiger Betriebspunkt. Es verschafft Zeit, behebt aber nicht die Ursache (zu viele zeitbasierte Indizes/Shards).

Zur Deprecation-Warnung
Die Meldung zur Deprecation von opendistro.index_state_management.history.number_of_replicas ist in diesem Kontext typischerweise nicht blockierend – sie weist darauf hin, dass ein historisches ISM/„opendistro“-Setting künftig entfernt wird. Entscheidend für die Datenaufnahme ist hier das Shard-Limit (Validation Exception), nicht diese Warnung.

Schritt 3: Replikas in Single-Node-Setups konsequent auf 0 setzen

1. Für bestehende Indizes (Beispiel-Pattern anpassen):

PUT wazuh-alerts-4.x-*/_settings
{
  "index": {
    "number_of_replicas": 0
  }
}

2. Für zukünftige Indizes über Templates absichern (damit nicht später wieder Replikas entstehen). Wazuh beschreibt den sauberen Weg über ein angepasstes Template (u. a. index.number_of_shards: 1 und index.number_of_replicas: 0).

Das reduziert zwar nicht die Anzahl der Primär-Shards (die bleiben bei 1 pro Index), verhindert aber, dass zusätzlich Replika-Shards die Situation verschärfen und den Cluster dauerhaft „yellow“ halten.

Schritt 4: Shard-Anzahl dauerhaft senken – ohne 2-Jahres-Compliance zu verlieren

Wenn „zwei Jahre online“ Pflicht ist, ist Index-Design der Hebel:

• Weg von „ein Index pro Tag“ hin zu Rollover nach Größe/Zeit (z. B. alle 10–30 GB oder wöchentlich/monatlich).
  Ergebnis: statt ~730 Indizes pro Datenstrom (2 Jahre täglich) vielleicht nur noch 24–104 Indizes – und damit drastisch weniger Shards.
• Index Lifecycle Management (ISM/ILM) aktivieren:
  • Hot-Phase: write + rollover
  • Warm/Cold: read-only, ggf. force-merge (wenn passend)
  • Delete: nur wenn Compliance es erlaubt
    Das Ziel ist nicht „löschen um jeden Preis“, sondern kontrollierte Indexgrößen und ein planbarer Shard-Footprint.
• Snapshots/Backups für Compliance:
  Wenn „online im Wazuh Dashboard“ nicht zwingend gleichbedeutend ist mit „im selben Indexer-Cluster“, sind Snapshots der saubere Weg, um alte Daten revisionssicher vorzuhalten und trotzdem den operativen Cluster klein zu halten.

Schritt 5: Skalierungsoption – zweiten Indexer-Node hinzufügen

Wenn das Datenvolumen und die Aufbewahrung feststehen, ist horizontale Skalierung oft die nachhaltigste Lösung: Mehr Daten-Nodes erhöhen den Shard-Spielraum und entlasten Heap/IO. Für produktive, compliance-getriebene Retention ist ein Single Node häufig strukturell am Limit, sobald mehrere Datenströme (Alerts, Audit, Custom Indices) parallel laufen.

Lessons Learned / Best Practices

• Shard-Budget vor Retention planen: Zwei Jahre tägliche Indizes multiplizieren sich schnell über mehrere Index-Pattern. „1 Shard pro Index“ hilft nur, wenn die Anzahl der Indizes kontrolliert wird.
• Single Node = Replikas 0: Alles andere produziert zwangsläufig unassigned_shards und unnötigen Shard-Overhead.
• Limit-Erhöhung ist nur ein Wartungsfenster: cluster.max_shards_per_node hochzusetzen verhindert den akuten Stillstand, verschiebt aber das Problem und erhöht das Crash-Risiko bei knappen Ressourcen.
• Rollover statt Tagesindizes: Für Compliance-„online“ ist eine sinnvolle Indexgröße entscheidender als eine Kalendergranularität.
• Betrieblich absichern: Monitoring auf Shard-Anzahl, Heap, Segment/Index-Count, sowie regelmäßige Kontrolle von Templates/Policies, damit Replikas und Shards nicht „zurückwandern“.

Fazit

Der Fehler „maximum shards open [1000]/[1000]“ ist ein klassischer Indexer-Schutzmechanismus: Ist das Shard-Limit erreicht, stoppt die Index-Erstellung – und Wazuh nimmt keine neuen Daten mehr an. Kurzfristig hilft das konsistente Anheben von cluster.max_shards_per_node (und ggf. total_shards_per_node) sowie das Setzen von Replikas auf 0 im Single-Node-Betrieb. Nachhaltig lösen lässt sich das Thema jedoch nur über ein Shard-sparendes Index-Design (Rollover/ISM) und/oder Skalierung des Indexer-Clusters, damit zwei Jahre Compliance-Retention nicht dauerhaft mit einem immer weiter wachsenden Shard-Footprint kollidiert.

Quellenverweise (Copy & Paste)

• https://bluewolfninja.com/2025/11/01/understanding-and-remediating-wazuh-indexer-shard-exhaustion/
• https://wazuh-blog.max-it.de/wazuh-dashboard-zeigt-ploetzlich-keine-neuen-logs-mehr-shard-limit-im-indexer-als-versteckte-ursache/
• https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-tuning.html
• https://docs.opensearch.org/latest/install-and-configure/configuring-opensearch/cluster-settings/
• https://docs.aws.amazon.com/opensearch-service/latest/developerguide/bp-sharding.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/C0A933R8E/p1770968788811219