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

von

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 …