.opendistro_security hängt in „Recovery“: Warum der Wazuh Indexer oft nicht kaputt ist, sondern nur ausgebremst wird

von

Einleitung

Wenn der Wazuh Indexer einen gelben Cluster-Status zeigt und ein sensibler Systemindex wie .opendistro_security über Tage im Zustand Recovery bleibt, wirkt das schnell wie ein Sicherheits- oder Datenintegritätsproblem. In vielen Fällen ist die Ursache aber deutlich banaler: Nicht ein defekter Security-Index blockiert den Cluster, sondern die Shard-Zuweisung wird durch Recovery-Grenzwerte gedrosselt. OpenSearch unterscheidet klar zwischen Cluster-Gesundheit, Shard-Recovery und Zuweisungsentscheidungen; ein gelber Status bedeutet dabei, dass alle Primärshards aktiv sind, aber mindestens ein oder mehrere Replikas noch nicht vollständig zugewiesen wurden.

Ausgangslage / Problemstellung

Im vorliegenden Fall zeigte der Cluster einen Status yellow, bei fünf Knoten, aktiven Primärshards, keinen unassigned Shards, aber mehreren initializing shards. Parallel fiel ein Index auf, der im Dashboard beziehungsweise in der Index-Ansicht über längere Zeit als „Recovery“ sichtbar blieb. Genau diese Kombination ist wichtig: Gelb bedeutet hier nicht, dass Primärdaten fehlen, sondern dass Redundanz noch nicht vollständig hergestellt ist. OpenSearch beschreibt yellow ausdrücklich als Zustand, in dem der Cluster grundsätzlich betriebsfähig ist, aber Replikate fehlen oder noch nicht fertig zugewiesen sind.

Zusätzlich lieferte GET _cluster/allocation/explain die entscheidende Meldung: Der Knoten, der den Primärshard hält, habe bereits das Limit für outgoing shard recoveries erreicht. Genannt wurde dabei konkret cluster.routing.allocation.node_concurrent_outgoing_recoveries=4. Das ist kein Hinweis auf beschädigte Indexdaten, sondern auf eine aktive Begrenzung paralleler Replikations- oder Recovery-Vorgänge pro Quellknoten. OpenSearch dokumentiert genau diese Einstellung als Limit dafür, wie viele ausgehende Shard-Recoveries ein Node gleichzeitig bedienen darf.

Technische Analyse

Die Kernursache liegt in der Zuweisungslogik von OpenSearch. Sobald ein Primärshard bereits aktiv ist, können Replikas grundsätzlich aufgebaut werden. Wenn aber der Primär-knotenseitig nur eine begrenzte Zahl ausgehender Recoveries parallel bedienen darf, dann werden weitere Shards nicht sofort repliziert, sondern bleiben zunächst im Zustand initializing oder erscheinen in der Oberfläche als Recovery-abhängig. Die Erklärung aus allocation/explain ist in diesem Zusammenhang praktisch der Goldstandard, weil diese API genau dafür gedacht ist, Zuweisungsentscheidungen und Blocker eines konkreten Shards nachvollziehbar zu machen.

Damit wird auch verständlich, warum der Cluster trotz sichtbarer „Recovery“-Probleme nicht rot war. Ein roter Status würde mindestens einen nicht zugewiesenen Primärshard bedeuten. Hier waren die Primärshards aber aktiv; betroffen war die Fertigstellung von Replikas oder Recovery-Prozessen. Das passt exakt zur Definition von yellow.

Der betroffene Index .opendistro_security ist dabei besonders sensibel, weil Wazuh Indexer den OpenSearch Security Plugin-Mechanismus für Zugriffskontrolle nutzt. Wazuh dokumentiert, dass Benutzer, Rollen und Berechtigungen im Security-Kontext des Indexers über das Security-Plugin verwaltet werden. Deshalb wirkt ein hängender Security-Index schnell dramatischer als ein normaler Fachindex. Technisch betrachtet bleibt aber auch hier zuerst zu prüfen, ob wirklich der Index defekt ist oder nur seine Replikation beziehungsweise Zuweisung ausgebremst wird.

Wichtig ist außerdem die Abgrenzung zu typischen anderen Ursachen. Disk-Watermarks sind ein häufiger Grund, warum Replikas nicht mehr alloziert werden. Wazuh empfiehlt deshalb bei Cluster-Problemen ausdrücklich auch die Prüfung der Storage Allocation. Im konkreten Fall sprach aber die allocation/explain-Antwort klar gegen einen Speicherengpass als primäre Ursache und für eine Concurrency-Grenze bei der Recovery.

Lösung / Best Practices

Der erste richtige Schritt ist nicht blindes Neustarten, sondern das gezielte Prüfen der Zuweisungsentscheidung. Dafür ist folgender API-Aufruf der saubere Einstieg:

GET _cluster/allocation/explain

OpenSearch beschreibt diese API explizit als Werkzeug, um zu verstehen, warum ein Shard nicht alloziert wird oder warum eine Zuweisung nur verzögert erfolgt. In diesem Fall hat genau diese Abfrage die eigentliche Ursache sichtbar gemacht.

Sobald die Ursache auf node_concurrent_outgoing_recoveries eingegrenzt ist, gibt es betrieblich zwei sinnvolle Wege. Der konservative Weg ist, die laufenden Recoveries einfach zu Ende laufen zu lassen, wenn der Cluster ansonsten stabil ist und keine weiteren Symptome zeigt. Der gelbe Zustand ist zwar unschön, aber nicht automatisch ein Ausfall. Der aktivere Weg ist die vorsichtige Anpassung der Cluster-Settings, um mehr parallele Recoveries zuzulassen. OpenSearch dokumentiert dafür sowohl die spezifische Einstellung cluster.routing.allocation.node_concurrent_outgoing_recoveries als auch den Sammelparameter cluster.routing.allocation.node_concurrent_recoveries, der eingehende und ausgehende Recoveries gemeinsam setzt.

Eine mögliche temporäre Anpassung sieht so aus:

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.node_concurrent_outgoing_recoveries": 8
  }
}

Alternativ kann beidseitig gearbeitet werden:

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.node_concurrent_recoveries": 8
  }
}

Diese Änderung sollte jedoch nur kontrolliert erfolgen. Mehr parallele Recoveries beschleunigen die Replikation, erhöhen aber gleichzeitig I/O-, CPU- und Netzwerkdruck auf den Quell- und Zielknoten. OpenSearch dokumentiert diese Settings als dynamisch änderbar, macht damit aber nicht automatisch eine pauschale Erhöhung zur Best Practice.

Danach sollte gezielt überprüft werden, ob die Initializing-Shards verschwinden und der Cluster wieder vollständig grün wird:

GET _cluster/health?pretty
GET _cat/shards?v
GET _cat/recovery?v

Wazuh verweist für den Clusterbetrieb ebenfalls auf Health- und Storage-Prüfungen, um den Zustand des Indexers sauber zu bewerten.

Wenn die Recovery trotz angehobener Concurrency nicht vorankommt, ist der nächste Schritt nicht sofort ein Löschen des Indexes, sondern eine tiefergehende Analyse mit zusätzlicher Explain-Ausgabe und gegebenenfalls einem kontrollierten Retry fehlgeschlagener Allokationen. OpenSearch dokumentiert beim Reroute-Mechanismus die Option retry_failed=true sowie dry_run=true, um solche Schritte vorab sicher zu bewerten.

Lessons Learned / Best Practices

Der wichtigste Lerneffekt aus diesem Fall ist, dass „Recovery“ nicht automatisch „kaputter Index“ bedeutet. Gerade bei Systemindizes wie .opendistro_security wird der Fehler oft zu früh als Sicherheits- oder Metadatenkorruption interpretiert. In Wirklichkeit steckt häufig eine ganz normale Allokationsbremse dahinter. Entscheidend ist deshalb immer zuerst allocation/explain und nicht die bloße Optik im Dashboard.

Ebenso wichtig ist die Unterscheidung zwischen Clusterzustand und Redundanzzustand. Ein gelber Cluster kann produktiv arbeiten, ist aber in der Ausfallsicherheit geschwächt, weil Replikate fehlen oder verzögert zugewiesen sind. Für Security- und SIEM-Umgebungen ist das betriebsrelevant, weil ein weiterer Knotenausfall in dieser Phase ein höheres Risiko darstellt.

Für den Betrieb empfiehlt sich daher ein standardisierter Prüfpfad:

  • zuerst GET _cluster/health
  • dann GET _cat/shards und GET _cat/allocation
  • anschließend GET _cluster/allocation/explain
  • erst danach Änderungen an Routing-, Recovery- oder Replikasettings

Wazuh empfiehlt in der Cluster-Verwaltung ausdrücklich, Cluster-Health und Storage-Zuweisung regelmäßig zu prüfen.

Bei größeren Clustern mit vielen Replikationsvorgängen sollte zusätzlich beobachtet werden, ob die Recovery-Limits zur tatsächlichen Infrastruktur passen. Ein Wert, der für kleinere Systeme konservativ sinnvoll ist, kann in einem Cluster mit viel freiem Storage und hoher I/O-Leistung unnötig bremsen. Die passende Einstellung ist daher betriebsabhängig und sollte nicht blind maximiert werden.

Fazit

Wenn .opendistro_security im Wazuh Indexer scheinbar fest in „Recovery“ hängt, liegt die Ursache oft nicht in einem beschädigten Security-Index, sondern in einer durch OpenSearch absichtlich begrenzten parallelen Shard-Recovery. Der entscheidende Hinweis ist in solchen Fällen die Ausgabe von GET _cluster/allocation/explain, insbesondere Meldungen zu node_concurrent_outgoing_recoveries. Wer den Fall sauber analysiert, erkennt schnell: Gelb bedeutet hier meist verzögerte Replikation statt Datenverlust. Die richtige Reaktion ist deshalb eine kontrollierte Recovery-Analyse und gegebenenfalls eine vorsichtige Anpassung der Recovery-Limits – nicht vorschnelles Löschen oder Neuaufsetzen sicherheitskritischer Systemindizes.

Quellenverweis

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/C07BZJY86G3/p1775662479567859