Wazuh-Indexer im Status „yellow“: Wenn Replica-Shards deinen Single-Node-Cluster blockieren

Aus maxTechCorner

Ein „yellow“ Cluster-Status im Wazuh-Indexer (OpenSearch) sorgt oft für Unruhe: Läuft noch alles? Gehen Daten verloren? Muss ich mir Sorgen machen?

Im Fall von Johan Ekenlycka war die Situation typisch für viele All-in-one- oder Single-Node-Wazuh-Setups: Der Cluster lief, aber:

  • Status: yellow
  • Einige Shards waren unassigned
  • Plattenplatz war völlig in Ordnung
  • max_shards_per_node war bereits hochgedreht

Schauen wir uns an, was genau passiert ist – und wie das Problem sauber gelöst wurde.

1. Ausgangssituation: Gelber Cluster, genügend Speicher

Johan nutzt:

  • Wazuh 4.10
  • Einen einzelnen Indexer-Node
  • 200 GB Platte, ~50 % belegt

Cluster-Health sah so aus: 

"status": "yellow",
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 1366,
"active_shards": 1366,
"unassigned_shards": 32

Die unassigned Shards betrafen ausschließlich „Meta-Indizes“:

  • .opendistro-ism-managed-index-history-*
  • .opendistro-ism-config
  • .opendistro-job-scheduler-lock
  • security-auditlog-*

Also keine „normalen“ Wazuh-Indices wie wazuh-alerts-*, sondern die internen Indizes von Index State Management (ISM) und Security/Audit.

2. Diagnose: Warum sind die Shards unassigned?

Ein Blick auf die Erklärung per _cluster/allocation/explain zeigte: 

"can_allocate": "no",
"allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",
"deciders": [
  {
    "decider": "enable",
    "decision": "NO",
    "explanation": "replica allocations are forbidden due to cluster setting [cluster.routing.allocation.enable=primaries]"
  },
  {
    "decider": "same_shard",
    "decision": "NO",
    "explanation": "a copy of this shard is already allocated to this node"
  }
]

Außerdem waren folgende Cluster-Settings gesetzt: 

"cluster": {
  "routing": {
    "allocation": {
      "enable": "primaries"
    }
  },
  "max_shards_per_node": "3000"
}

Was bedeutet das?

  • allocation.enable = primaries →Nur Primary Shards dürfen neuen Nodes zugewiesen werden, keine Replicas.
  • Der einzige Node im Cluster (Single-Node-Setup) hat bereits die Primaries.
  • Die betroffenen Indizes haben Replica-Shards, die nirgendwo hin können:

Sie dürfen nicht auf denselben Node (wegen same_shard)

  • Es gibt keinen zweiten Node
  • Und allocation.enable=primaries blockiert Replikate ohnehin

Ergebnis: Die Primaries laufen, aber die Replikate bleiben unassigned → Cluster-Status: yellow.

3. Wichtige Erkenntnis: Replica-Shards auf einem Single-Node-Cluster sind sinnlos

Jakub Pacowski brachte es auf den Punkt:

Da du nur einen Indexer-Node hast, kannst du keine Replikate sinnvoll zuweisen. Lösung: Replica-Anzahl auf 0 setzen.

Auf einem Single-Node-Cluster bringen Replikate:

  • keine Redundanz (es gibt ja nur einen Node)
  • aber zusätzliche Shard-Overhead, Zuweisungsfehler und gelben Status

4. Die Lösung: Replica-Anzahl auf 0 setzen

Um das Problem zu lösen, wurden für die .opendistro-*-Indizes (und später auch für den Security-Audit-Index) die Replica-Shards deaktiviert.

Beispiel-Befehl (auf dem Indexer-Node)

curl \
  --cert  /etc/wazuh-indexer/certs/admin.pem \
  --key   /etc/wazuh-indexer/certs/admin-key.pem \
  --cacert /etc/wazuh-indexer/certs/root-ca.pem \
  -X PUT "https://127.0.0.1:9200/.opendistro-*/_settings" \
  -H 'Content-Type: application/json' \
  -d '{
    "index.number_of_replicas": 0,
    "index.auto_expand_replicas": false
  }'

Anschließend: 

curl \
  --cert  /etc/wazuh-indexer/certs/admin.pem \
  --key   /etc/wazuh-indexer/certs/admin-key.pem \
  --cacert /etc/wazuh-indexer/certs/root-ca.pem \
  "https://127.0.0.1:9200/_cluster/health?pretty"

Nach diesem Schritt:

  • Cluster-Status wechselt von yellow → green
  • unassigned Shards verschwinden
  • alles läuft stabil

Johan bestätigte:

„Thanks, this did indeed solve the issue. Had to do the same settings change to an opensearch audit log shard.“

5. Nebenbaustelle: max_shards_per_node hochgedreht

Ein weiterer wichtiger Punkt im Thread: Die Einstellung cluster.max_shards_per_node war von 1000 auf 3000 erhöht worden.

Das ist ein häufiger Reflex:

„Cluster meckert über Shards? Dann stellen wir das Limit eben höher!“

Kurzfristig mag das helfen – langfristig ist es gefährlich:

  • Jeder Shard kostet RAM, Filehandles, CPU
  • Zu viele kleine Indizes/Shards machen den Indexer langsam
  • Resourcenverbrauch steigt dramatisch an, bevor das Limit nochmals erreicht wird

Jakub und Kevin warnten beide:

  • max_shards_per_node erhöhen sollte nur eine temporäre Notlösung sein
  • Besser:

Shard-Anzahl reduzieren

  • Retention/ILM/ISM-Policies anpassen
  • ggf. zusätzliche Indexer-Nodes einführen

Kevin verwies zusätzlich auf einen ausführlichen Blogpost zum Thema „Shard Exhaustion“ in Wazuh-Umgebungen – lesenswert für alle, die All-in-one-Setups oder stark gewachsene Cluster betreiben.

6. Best Practices für Single-Node- und Small-Cluster-Wazuh-Installationen

Aus dem Thread lassen sich ein paar klare Empfehlungen ableiten:

6.1 Replica-Shards auf Single-Node-Cluster deaktivieren

Für System-Indizes wie:

  • .opendistro-*
  • .plugins-ml-*
  • security-auditlog-*

auf einem Single-Node-Cluster:

  • index.number_of_replicas = 0
  • index.auto_expand_replicas = false

6.2 Shard-Anzahl im Blick behalten

  • max_shards_per_node nicht einfach immer weiter erhöhen
  • lieber:

Datenhaltung prüfen (wie viele Tage/Wochen brauche ich wirklich?)

  • Indexpattern zusammenführen
  • evtl. Shardanzahl pro Index reduzieren (z. B. von 5 auf 1, wenn wenig Daten)

6.3 Cluster-Health regelmäßig prüfen

  • _cluster/health?pretty
  • _cat/indices?v
  • _cluster/allocation/explain bei Problemen

So erkennt man:

  • unassigned Shards
  • zu viele Indizes/Shards
  • auffällige System-Indizes

6.4 Langfristig: Skalierung planen

Wenn:

  • Agents, Events und Datenvolumen wachsen
  • Dashboards immer langsamer werden
  • Indexer-CPU und Heap am Limit sind

dann ist der richtige Weg:

  • weitere Indexer-Nodes hinzufügen
  • Sharding-Strategie überdenken
  • nicht nur Settings „höher drehen“

7. Fazit

Der Fall von Johan zeigt sehr anschaulich:

  • Ein gelber Wazuh-Indexer-Cluster ist nicht immer ein Storage- oder Hardwareproblem.
  • Oft steckt schlicht eine Replica-Konfiguration dahinter, die nicht zum Setup passt – insbesondere bei Single-Node-Installationen.
  • Die Lösung war vergleichsweise simpel:

Replica-Anzahl für .opendistro-* und Audit-Indizes auf 0 setzen

  • auto_expand_replicas deaktivieren
  • Cluster-Health erneut prüfen

Gleichzeitig ist der Thread eine Warnung davor, max_shards_per_node als Dauerlösung hochzudrehen. Shard-Exhaustion ist ein realer Feind von Performance und Stabilität – und lässt sich nur durch bewusste Sharding- und Retention-Strategien wirklich in den Griff bekommen.

https://wazuh.slack.com/archives/C0A933R8E/p1763980736524649

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 20. Dezember 2025).

Unterstützung von m.a.x. it

Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Wazuh-Indexer_im_Status_„yellow“:_Wenn_Replica-Shards_deinen_Single-Node-Cluster_blockieren&oldid=2987“