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

von

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