Wazuh Indexer „yellow“ wegen unassigned Shards – was tun?

Im Thread von Ewin Loppe ging es um ein typisches Thema in Wazuh-/OpenSearch-Umgebungen: Der Cluster-Status ist gelb, einige Shards sind unassigned, und Dev Tools werfen plötzlich 403 / security_exception.

Schauen wir uns an, warum das passiert – und wie man es sauber behebt.

1. Ausgangslage: Cluster „yellow“ und unassigned Shards

Ewin hat den Clusterzustand geprüft:

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

Ausgabe (gekürzt):

{
  "cluster_name" : "wazuh-cluster",
  "status" : "yellow",
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 452,
  "unassigned_shards" : 8
}

Außerdem zeigte _cat/shards, dass es sich um .opendistro-* und .opensearch-* Indizes handelt – also Systemindizes. Für diese sah man jeweils:

• einen Shard mit STARTED
• einen zweiten mit UNASSIGNED

→ Klassischer Fall: Replik-Shards auf einem Single-Node-Cluster.

2. Warum ist der Status gelb?

Kurz:

• green = alle Primary- und Replica-Shards zugewiesen
• yellow = alle Primaries zugewiesen, aber mindestens ein Replica-Shard unassigned
• red = Primaries fehlen → kritisch

In Ewins Fall:

• number_of_nodes: 1
• unassigned_shards: 8
• alle unassigned sind Replica-Shards von Systemindizes wie .opendistro-alerting-alerts.

OpenSearch (und damit Wazuh Indexer) versucht Replica-Shards auf andere Knoten zu legen. Aber es gibt nur einen Node – also:

„a copy of this shard is already allocated to this node“ → Replica kann nicht auf denselben Node gelegt werden → bleibt unassigned → Status = yellow.

Das ist auf Einzelknoten nicht gefährlich, aber unschön – und nervig, wenn man’s sauber haben will.

3. Versuch über Dev Tools – und das 403-Problem

Ewin hat richtigerweise versucht, über Dev Tools die Anzahl der Replikas zu reduzieren:

PUT .opendistro-*/_settings
{
  "index.number_of_replicas" : 0,
  "index.auto_expand_replicas": false
}

Antwort:

{
  "error": {
    "type": "security_exception",
    "reason": "no permissions for [] and User [name=admin, backend_roles=[admin]...]"
  },
  "status": 403
}

Das wirkt kontraintuitiv: Man ist als admin im Dashboard unterwegs – und hat trotzdem keine Berechtigung, Systemindizes zu ändern.

Warum?

• Der OpenSearch-Sicherheitslayer (Security Plugin) schützt Systemindizes besonders streng.
• Der Dashboard-User admin arbeitet nicht zwingend mit denselben Rechten wie der technische Zertifikats-Admin (admin.pem).
• Für viele Low-Level-Aktionen sind Zertifikat-basierte Requests direkt am Indexer die zuverlässigere Methode.

4. Analyse der unassigned Shards

Sehr hilfreich (und von Othniel vorgeschlagen):

GET _cat/shards?v=true&h=index,shard,prirep,state,node,unassigned.reason&s=state

Und dann für ein konkretes Beispiel:

GET _cluster/allocation/explain?filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*
{
  "index": ".opendistro-alerting-alerts",
  "shard": 0,
  "primary": false
}

Antwort u. a.:

{
  "decider": "same_shard",
  "decision": "NO",
  "explanation": "a copy of this shard is already allocated to this node [...]"
}

Damit ist klar: Es handelt sich um Replica-Shards Der Indexer verweigert sie, weil der Primary schon auf demselben Node liegt.

5. Saubere Lösung auf Single-Node-Cluster: Replikas auf 0 setzen

Wenn du nur einen Indexer-Knoten hast, brauchst du keine Replikas. Im Gegenteil: auf einem Single Node sind sie sogar sinnlos.

Ziel: index.number_of_replicas = 0 für alle .opendistro-* und .opensearch-* Indizes.

Schritt 1 – Per Zertifikat direkt am Indexer arbeiten

Auf dem Indexer-Host:

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

Optional noch für .opensearch-*:

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

Wichtig:

• 127.0.0.1 → direkt auf dem Indexer
• admin.pem + admin-key.pem → technischer Superuser
• Diese Requests umgehen die RBAC-Einschränkungen, die du im Dashboard siehst.

Du solltest als Antwort jeweils etwas mit "acknowledged": true sehen.

Schritt 2 – Clusterzustand erneut prüfen

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

Wenn alles passt:

• unassigned_shards sollte 0 sein
• status bleibt auf Single Node manchmal trotzdem „yellow“, z. B. wenn es andere Spezialindices gibt – in deiner Konstellation sollten die 8 unassigned-Systemshards aber weg sein.

6. Alternative: Mehrere Indexer-Knoten statt Replika=0

Langfristig ist die robustere (und „grünere“) Variante:

• mindestens 3 Indexer-Knoten
• Replikas > 0 (typisch: 1)
• Shards werden automatisch verteilt
• Cluster kann einen Node verlieren, ohne Daten zu verlieren

Auf einem Single-Node-Cluster ist aber Replikas=0 die pragmatische und korrekte Einstellung.

7. Zusammenfassung

Problem:

• Clusterstatus yellow
• 8 unassigned_shards, alle Replica-Shards von .opendistro-* / .opensearch-*
• Dev Tools → 403 security_exception beim Ändern von Index-Settings

Ursachen:

• Single-Node-Cluster kann Replica-Shards nicht verteilen
• Dashboard-User admin darf Systemindizes nicht anpassen (RBAC)

Lösung:

1. Per Zertifikat direkt am Indexer einloggen
2. Für .opendistro-* und .opensearch-*: "index.number_of_replicas": 0
3. Cluster-Health kontrollieren

Damit sind:

• die unassigned Replica-Shards weg
• die Shard-Anzahl konsistent
• und dein Monitoring deutlich entspannter

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

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 8. 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