Einleitung
In Single-Node-Installationen von Wazuh 4.11 taucht regelmäßig ein scheinbar alarmierender Zustand auf: Der Indexer zeigt yellow, obwohl Daten ingestiert werden, Primär-Shards aktiv sind und nur bestimmte Indizes betroffen sind. Besonders häufig betrifft das die security-auditlog-*-Indizes, die mit number_of_replicas = 1 angelegt wurden. Technisch ist das zunächst kein Ausfall, sondern ein Replikationsproblem: In einem Cluster mit nur einem Datenknoten können Replikat-Shards nicht zugewiesen werden, weil OpenSearch Primär- und Replikat-Shard nicht auf demselben Node platziert. Ein gelber Zustand bedeutet daher, dass alle Primär-Shards verfügbar sind, aber mindestens ein Replikat unassigned ist.
Ausgangslage / Problemstellung
Die gezeigte Umgebung ist ein klassischer Wazuh-Single-Node-Indexer. Der Cluster meldet zwar active_primary_shards: 776, gleichzeitig aber unassigned_shards: 240 und nur rund 76 % aktive Shards. In der Indexliste sind fast ausschließlich security-auditlog-*-Indizes gelb, jeweils mit pri=1 und rep=1, während andere Indizes wie wazuh-alerts-* bereits mit rep=0 grün laufen. Das ist ein starkes Indiz dafür, dass nicht die Daten selbst fehlen, sondern ausschließlich nicht platzierbare Replikate offen sind. Genau dieses Verhalten beschreibt OpenSearch für gelbe Clusterzustände: Primär-Shards sind vorhanden, Replikate aber nicht zugewiesen.
Hinzu kommt ein zweiter Effekt, der in der Praxis oft missverstanden wird: Wer vor einigen Monaten die Replikate auf 0 gesetzt hat, ändert damit nicht automatisch alle bereits existierenden Indizes dauerhaft über die gesamte Historie hinweg. Index-Templates initialisieren Einstellungen für neu angelegte Indizes, nicht rückwirkend für alte. Bestehende Indizes müssen separat per Settings-Update angepasst werden.
Technische Analyse
Das zugrunde liegende Verhalten ist OpenSearch-seitig konsistent. Ein Single-Node-Cluster kann keine Replikat-Shards allokieren, wenn ein Index mit number_of_replicas: 1 erstellt wurde. Der Cluster bleibt dann yellow, obwohl die Primärdaten vollständig nutzbar sind. Das ist also kein Hinweis auf beschädigte Primärdaten, sondern auf fehlende Redundanz, die in einer Ein-Knoten-Topologie ohnehin nicht realisierbar ist.
Für die konkrete Fragestellung sind zwei Ebenen zu unterscheiden. Erstens die bestehenden security-auditlog-*-Indizes. Deren Replikazahl lässt sich per Update Settings API ändern, weil number_of_replicas eine dynamische Index-Einstellung ist und daher im laufenden Betrieb angepasst werden kann. Zweitens die zukünftigen security-auditlog-*-Indizes. Deren Default-Verhalten wird über ein passendes Index-Template gesteuert. Ohne Template-Anpassung werden neue Tagesindizes weiterhin mit unerwünschten Replikaten erstellt, auch wenn alte Indizes bereits korrigiert wurden.
Genau deshalb hatte die bisherige Änderung „vor ein paar Monaten“ keine Wirkung auf alte Indizes: Templates wirken nur beim Anlegen neuer Indizes. Wenn also security-auditlog-2025.05.29 bis security-auditlog-2026.02.xx bereits mit rep=1 existieren, bleiben sie so, bis sie explizit per Settings-Update umgestellt werden.
Architektonisch ist außerdem wichtig, dass yellow in einem Single-Node-Betrieb zwar oft nur kosmetisch wirkt, aber trotzdem operative Nachteile haben kann. Ein dauerhaft gelber Cluster kaschiert echte Allokationsprobleme, weil „gelb“ dann als Normalzustand wahrgenommen wird. Zudem deutet die große Zahl historischer Audit-Indizes darauf hin, dass Retention und Lifecycle-Management nicht konsequent begrenzt wurden. Wazuh empfiehlt für den Indexer den Einsatz von Index State Management, um Rollovers, Retention und Löschregeln kontrolliert umzusetzen.
Lösung / Best Practices
Für einen Single-Node-Wazuh-Indexer ist die richtige Vorgehensweise zweistufig: zuerst die vorhandenen security-auditlog-*-Indizes korrigieren, danach die Erzeugung zukünftiger Indizes absichern.
Für bereits vorhandene Audit-Indizes ist die naheliegende API-Anfrage korrekt:
PUT /security-auditlog-*/_settings
{
"index": {
"number_of_replicas": 0
}
}
Diese Änderung greift auf bestehenden Indizes, weil number_of_replicas dynamisch ist. Damit verschwinden die unassigned replica shards dieser Indizes, sofern keine anderen Ursachen für gelbe Zustände existieren.
Für zukünftige Indizes sollte zusätzlich ein passendes Template gesetzt oder korrigiert werden, damit neue security-auditlog-*-Tagesindizes nicht erneut mit rep=1 entstehen. Inhaltlich ist der vorgeschlagene Ansatz richtig: ein Template für das Pattern security-auditlog-* mit number_of_replicas: 0. OpenSearch-Templates definieren Standard-Settings für künftige Indizes, die auf das Pattern matchen.
Ein modernes Beispiel im OpenSearch-Stil sieht so aus:
PUT /_index_template/security-auditlog
{
"index_patterns": ["security-auditlog-*"],
"template": {
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0
}
},
"priority": 100
}
Wichtig ist hier weniger die exakte API-Variante als die inhaltliche Absicherung: Alle zukünftigen Audit-Log-Indizes müssen mit rep=0 erzeugt werden, solange nur ein einziger Datenknoten existiert.
Parallel dazu sollte der aktuelle Zustand verifiziert werden. Praktisch sind dabei drei Prüfungen:
GET /_cluster/health
GET /security-auditlog-*/_settings
GET /_cat/shards/security-auditlog-*?v
Die erwartete Zielkonstellation ist: number_of_replicas = 0 auf Altindizes, keine unassigned Replikate mehr für security-auditlog-*, und idealerweise ein grüner Clusterzustand, sofern nicht andere System- oder Spezialindizes weiterhin mit Replikaten bestehen bleiben. OpenSearch weist allerdings selbst darauf hin, dass in Single-Node-Szenarien ein gelber Zustand grundsätzlich erwartbar ist, sobald irgendein Index Replikate verlangt.
Der zweite nachhaltige Baustein ist Lifecycle Management. Die große Zahl historischer Audit-Indizes zeigt, dass nicht nur die Replikazahl, sondern auch Retention relevant ist. Wazuh dokumentiert ISM explizit als Mechanismus, um Indexalter, Größe und Löschregeln automatisiert zu steuern. Gerade Audit-Daten wachsen in Single-Node-Umgebungen oft unscheinbar, weil sie pro Tag nur klein wirken, sich über Monate aber zu vielen Shards und Indizes aufsummieren.
Lessons Learned / Best Practices
Die wichtigste Erkenntnis ist, dass ein gelber Clusterzustand auf einem Single Node nicht automatisch ein Incident ist. Solange nur Replikate unassigned sind und alle Primär-Shards aktiv bleiben, sind die Daten nutzbar. Trotzdem sollte man den Zustand nicht dauerhaft ignorieren, weil ein „immer gelb“ echte Probleme später schlechter sichtbar macht.
Ebenso wichtig ist die Trennung zwischen bestehenden und zukünftigen Indizes. Wer nur ein Template anpasst, löst das Problem für künftige Tagesindizes, aber nicht für die bereits erzeugten security-auditlog-*-Indizes. Wer nur bestehende Indizes patched, verhindert den Rückfall nicht. Erst die Kombination aus _settings für Altbestände und Template für Neuanlagen ist dauerhaft sauber.
Für Single-Node-Betrieb gilt außerdem eine nüchterne Best Practice: Replikate bringen dort keinen Verfügbarkeitsgewinn. Redundanz entsteht erst durch zusätzliche Datenknoten. Wer echte Hochverfügbarkeit für Audit-Logs braucht, benötigt eine Multi-Node-Architektur statt kosmetischer Green-Optimierung auf einem Einzelknoten. Dass OpenSearch Primär- und Replikat-Shards nicht auf demselben Node platziert, ist genau der Grund, warum rep=1 auf einem Single Node technisch ins Leere läuft.
Schließlich sollte Audit-Logging immer mit einer Retention-Strategie gekoppelt werden. Viele kleine Tagesindizes sind auf Dauer kein kostenloses Designmuster. Auch wenn jeder einzelne Index klein ist, erhöhen viele historische Indizes die Zahl der Shards, erschweren Übersicht und führen in kleinen Umgebungen schneller zu Betriebsgrenzen. Wazuhs ISM-Dokumentation ist hier der richtige Einstiegspunkt.
Fazit
Ja, für einen Wazuh-Indexer mit nur einem Node ist es technisch sinnvoll, die security-auditlog-*-Indizes auf number_of_replicas: 0 zu setzen. Die von dir vorgeschlagene Änderung an /_settings ist der richtige Weg für bestehende Indizes. Zusätzlich muss ein passendes Index-Template dafür sorgen, dass neue Audit-Log-Indizes ebenfalls ohne Replikat angelegt werden. Der gelbe Status war hier sehr wahrscheinlich kein Datenverlust, sondern das erwartbare Ergebnis nicht zuweisbarer Replikate auf einem Einzelknoten. Nachhaltig sauber wird die Umgebung aber erst dann, wenn sowohl Replikate als auch Retention für security-auditlog-* bewusst gesteuert werden.
Quellenverweis
Wazuh Dokumentation – Index lifecycle management
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.htmlOpenSearch Dokumentation – Cluster health
https://docs.opensearch.org/latest/api-reference/cluster-api/cluster-health/OpenSearch Dokumentation – Cluster allocation explain
https://docs.opensearch.org/latest/api-reference/cluster-api/cluster-allocation/OpenSearch Dokumentation – Update settings
https://docs.opensearch.org/latest/api-reference/index-apis/update-settings/OpenSearch Dokumentation – Index templates
https://docs.opensearch.org/latest/im-plugin/index-templates/
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/C0A933R8E/p1771230334413179