Einleitung
Ein kontinuierlicher Anstieg der Shard-Anzahl kann in Wazuh-Umgebungen langfristig zu erheblichen Betriebsproblemen führen. Besonders bei Single-Node-Installationen mit OpenSearch als Wazuh Indexer ist die verfügbare Shard-Kapazität begrenzt. Wird das konfigurierte Limit erreicht, können keine weiteren Indizes angelegt werden. Dadurch besteht das Risiko, dass neue Security-Events nicht mehr zuverlässig indexiert und für die Analyse bereitgestellt werden.
Eine häufige Ursache ist eine unvollständige Index State Management (ISM)-Konfiguration: Während bestimmte Wazuh-Indizes nach Ablauf ihrer Aufbewahrungsfrist automatisch gelöscht werden, wachsen andere Indexfamilien unbemerkt weiter.
Dieser Artikel erläutert anhand einer Wazuh-4.14-Installation, warum die Anzahl aktiver Shards trotz funktionierender Retention Policy kontinuierlich steigen kann, wie sich nicht verwaltete Indizes identifizieren lassen und welche Besonderheiten bei Systemindizes und Replikaten zu beachten sind.
Ausgangslage / Problemstellung
Die betroffene Umgebung besteht aus einem einzelnen Wazuh-Indexer-Knoten mit folgenden Eigenschaften:
| Parameter | Wert |
|---|---|
| Wazuh-Version | 4.14 |
| Indexer-Knoten | 1 |
| Datenknoten | 1 |
| Clusterstatus | Yellow |
cluster.max_shards_per_node | 1300 |
| Aktive Primary Shards | 1045 |
| Aktive Shards insgesamt | 1045 |
| Unassigned Shards | 5 |
| Verwendete Shards inklusive unzugewiesener | 1050 |
| Rechnerisch verbleibende Shard-Kapazität | 250 |
| Shards pro regulärem Index | 1 |
| Gewünschte Replikate | 0 |
| Aufbewahrungsdauer für Alerts | 365 Tage |
Die Anzahl aktiver Shards steigt durchschnittlich um drei pro Tag. Gleichzeitig sinkt die verbleibende Kapazität.
Prognose der verbleibenden Shard-Kapazität
Vereinfachtes Szenario bei unverändertem Nettozuwachs von drei Shards pro Tag.
070140210280Tag 0Tag 20Tag 40Tag 60Tag 80Tag 84
Bei unverändertem Wachstum wäre die rechnerisch verfügbare Kapazität nach etwa 84 Tagen erschöpft. Der tatsächliche Zeitpunkt hängt unter anderem von der Indexerstellung, Löschvorgängen und der Shard-Zählweise ab.
Die bestehende ISM-Richtlinie
Für die automatische Bereinigung existiert bereits eine ISM-Policy mit dem Namen delete_indices_older_1year.
Die relevante Konfiguration lautet:
{
"policy": {
"description": "Delete indices older than one year",
"default_state": "open",
"states": [
{
"name": "open",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "365d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"wazuh-alerts-*"
],
"priority": 100
}
]
}
}Die Richtlinie funktioniert für Alert-Indizes grundsätzlich wie vorgesehen. Der älteste vorhandene Alert-Index ist ungefähr ein Jahr alt:
wazuh-alerts-4.x-2025.10.09Damit liegt zunächst kein offensichtlicher Fehler im Löschmechanismus selbst vor.
Das eigentliche Problem: Die Richtlinie verwaltet ausschließlich Indizes, deren Namen dem Muster wazuh-alerts-* entsprechen. Andere Indexfamilien werden durch diese Vorlage nicht automatisch erfasst.
Technische Analyse
1. Warum eine funktionierende Retention Policy nicht ausreicht
Wazuh verwendet unterschiedliche Indexfamilien, um Sicherheitsereignisse, Betriebsdaten und weitere Informationen zu speichern.
Dazu gehören beispielsweise:
| Indexfamilie | Funktion |
|---|---|
wazuh-alerts-* | Sicherheitsalarme und erkannte Ereignisse |
wazuh-archives-* | Archivierte Ereignisse, sofern aktiviert |
wazuh-monitoring-* | Monitoring-Informationen |
wazuh-statistics-* | Statistikdaten |
Diese Indizes können unabhängig voneinander entstehen und unterschiedliche Lebenszyklen besitzen.
Wird täglich ein neuer Index mit einem Primary Shard angelegt, erhöht sich die Shard-Anzahl zunächst um eins. Bei mehreren täglichen Indexfamilien kann der Zuwachs entsprechend größer ausfallen.
Im beschriebenen Cluster sind 1045 Primary Shards aktiv. Unter der vereinfachten Annahme eines täglichen Alert-Index mit 365 Tagen Aufbewahrung entfallen ungefähr 365 Shards auf Alerts.
Damit bleiben rechnerisch rund 680 Primary Shards, deren Herkunft überprüft werden muss.
Diese 680 Shards müssen nicht zwangsläufig vollständig aus unverwalteten Indizes stammen. Auch Systemindizes, zusätzliche Indexmuster oder abweichende Shard-Konfigurationen können dazu beitragen.
2. ISM-Templates gelten nicht automatisch für sämtliche Indizes
Der entscheidende Konfigurationsabschnitt lautet:
"ism_template": [
{
"index_patterns": [
"wazuh-alerts-*"
],
"priority": 100
}
]Dieses Template sorgt dafür, dass neu angelegte, passende Indizes automatisch der ISM-Policy zugeordnet werden.
Indizes wie wazuh-archives-4.x-* werden damit nicht erfasst.
Wichtig ist außerdem die Unterscheidung zwischen einer ISM-Policy und einem ISM-Template:
- Die Policy definiert den Lebenszyklus eines Index, einschließlich Übergängen und Löschaktionen.
- Das ISM-Template bestimmt, welchen neu erstellten Indizes diese Policy automatisch zugewiesen wird.
- Bereits existierende Indizes erhalten eine neu hinzugefügte Policy-Zuordnung nicht automatisch rückwirkend.
Gerade der letzte Punkt ist relevant: Eine Erweiterung der Indexmuster allein behebt nicht zwingend den bereits aufgebauten Shard-Bestand.
3. Warum ein Single-Node-Cluster Yellow anzeigen kann
Neben der steigenden Shard-Anzahl meldet der Cluster fünf unzugewiesene Shards.
Die Diagnose zeigt:
.opensearch-control-center
.opendistro-alerting-config
.opensearch-alerting-config-lock
.opendistro-alerting-alert-history-2026.09.07-000017
.opendistro-alerting-alert-history-2026.10.07-000018Alle fünf betroffenen Shards besitzen die Kennzeichnung:
prirep: r
state: UNASSIGNED
unassigned.reason: CLUSTER_RECOVEREDDas r kennzeichnet einen Replica Shard.
In einem Cluster mit nur einem Datenknoten kann OpenSearch einen Replica Shard nicht auf demselben Knoten wie dessen Primary Shard platzieren.
Deshalb bleiben diese Replikate unzugewiesen, obwohl die jeweiligen Primary Shards verfügbar sein können.
Der Cluster erreicht in dieser Situation typischerweise den Status Yellow statt Green.
Eine Besonderheit ist die Index-Template-Konfiguration:
{
"index": {
"number_of_shards": "1",
"number_of_replicas": "0",
"auto_expand_replicas": "0-1"
}
}Obwohl number_of_replicas auf 0 gesetzt ist, sollte auto_expand_replicas separat geprüft werden. Diese Einstellung kann die gewünschte Replikazahl abhängig von der Knotenzahl verändern. Außerdem gelten die gezeigten Einstellungen nicht zwangsläufig für sämtliche internen OpenSearch-Indizes.
Die tatsächlichen Einstellungen jedes betroffenen Index sind daher entscheidend.
Lösung / Best Practices
Die nachhaltige Lösung besteht aus zwei Maßnahmen: Zunächst müssen alle relevanten Indexfamilien in das Lifecycle Management aufgenommen werden. Anschließend sollten die unzugewiesenen Replikate geprüft und die Replikation passend zur Clusterarchitektur konfiguriert werden.
Schritt 1: Sämtliche Indizes identifizieren
Zunächst muss geklärt werden, welche Indizes tatsächlich vorhanden sind.
Über die Dev Tools im Wazuh Dashboard:
GET _cat/indices?v&h=health,status,index,pri,rep,docs.count,store.size&s=indexAuch versteckte und interne Indizes sollten bei der Bestandsaufnahme berücksichtigt werden:
GET _cat/indices/*?expand_wildcards=all&v&h=index,pri,rep,store.sizeDie Ausgabe zeigt unter anderem die Namen, Primary Shards, Replikate und Speichergrößen.
Besonders wichtig sind Indexfamilien, für die täglich neue Indizes angelegt werden.
Zur gezielten Prüfung können die bekannten Wazuh-Muster abgefragt werden:
GET _cat/indices/wazuh-alerts-*?v
GET _cat/indices/wazuh-archives-*?v
GET _cat/indices/wazuh-monitoring-*?v
GET _cat/indices/wazuh-statistics-*?vNicht vorhandene Muster können eine entsprechende Fehlermeldung liefern. Das ist bei optionalen Indexfamilien unproblematisch.
Schritt 2: ISM-Zuordnungen kontrollieren
Anschließend wird geprüft, ob die jeweiligen Indizes durch ISM verwaltet werden.
Beispiel:
GET _plugins/_ism/explain/wazuh-archives-*Ein Index ohne zugewiesene Policy kann beispielsweise folgende Information zurückgeben:
{
"policy_id": null
}Das bedeutet, dass der Index aktuell nicht durch die gewünschte ISM-Policy verwaltet wird.
Bei einer korrekt zugewiesenen Richtlinie sollte unter anderem die Policy-ID erkennbar sein:
{
"policy_id": "delete_indices_older_1year"
}Zusätzlich sollten der aktuelle ISM-State, die nächste Aktion und mögliche Fehlermeldungen überprüft werden. Eine zugewiesene Policy allein garantiert noch nicht, dass der Löschvorgang erfolgreich ausgeführt wird.
Schritt 3: ISM-Template erweitern
Für Indexfamilien mit identischen Aufbewahrungsanforderungen kann die bestehende Policy erweitert werden.
Beispielsweise:
"ism_template": [
{
"index_patterns": [
"wazuh-alerts-*",
"wazuh-archives-*",
"wazuh-monitoring-*",
"wazuh-statistics-*"
],
"priority": 100
}
]Die Änderung erfolgt über:
Index Management → State management policies → Bestehende Policy bearbeiten
Alternativ lässt sich die Policy über die OpenSearch-API aktualisieren. Bei API-basierten Updates müssen die vollständige Policy-Struktur sowie die erforderlichen Versionsparameter berücksichtigt werden.
Wichtig: Die Erweiterung sollte nur erfolgen, wenn alle aufgenommenen Indexfamilien tatsächlich dieselbe Aufbewahrungsfrist benötigen und keine andere Lifecycle-Richtlinie bereits dafür zuständig ist.
Eine pauschale 365-Tage-Retention ist nicht für jede Indexfamilie sinnvoll.
Schritt 4: Unterschiedliche Retention-Zeiträume festlegen
Für größere Umgebungen empfiehlt sich eine differenzierte Aufbewahrungsstrategie.
| Indexfamilie | Beispiel-Retention | Begründung |
|---|---|---|
| Wazuh Alerts | 365 Tage | Sicherheitsanalysen und Compliance |
| Wazuh Archives | 30–90 Tage | Potenziell hohes Datenvolumen |
| Wazuh Monitoring | 30 Tage | Kurzfristige Betriebsdiagnose |
| Wazuh Statistics | 30–90 Tage | Operative Auswertungen |
Diese Werte sind Beispiele und müssen anhand der tatsächlichen Compliance-Anforderungen, forensischen Bedürfnisse und Speicherkapazitäten festgelegt werden.
Insbesondere Archive können sicherheitsrelevante Rohereignisse enthalten, die nicht vollständig in Alert-Indizes abgebildet werden. Eine zu kurze Aufbewahrungsfrist kann die spätere Rekonstruktion von Sicherheitsvorfällen erschweren.
Für kürzere Retention-Zeiträume empfiehlt sich eine separate Policy.
Beispiel einer 90-Tage-Policy für Archive:
{
"policy": {
"description": "Delete Wazuh archives after 90 days",
"default_state": "open",
"states": [
{
"name": "open",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "90d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"wazuh-archives-*"
],
"priority": 100
}
]
}
}Die Policy kann über den entsprechenden API-Endpunkt erstellt werden:
PUT _plugins/_ism/policies/delete_archives_after_90dAls Request Body wird die vollständige JSON-Konfiguration verwendet.
Achtung: Die Policy löscht den gesamten Index nach Erreichen des konfigurierten Indexalters. Dieses Alter wird nicht automatisch anhand des Datums im Indexnamen berechnet. Vor der produktiven Aktivierung muss geprüft werden, ob das Indexalter mit der gewünschten Datenaufbewahrung übereinstimmt.
Schritt 5: Bereits existierende Indizes nachträglich verwalten
Eine Änderung des ISM-Templates betrifft grundsätzlich die automatische Zuordnung bei der Erstellung neuer Indizes.
Bereits vorhandene Indizes müssen separat berücksichtigt werden.
Für Archive mit einer Aufbewahrungsfrist von 365 Tagen:
POST _plugins/_ism/add/wazuh-archives-*
{
"policy_id": "delete_indices_older_1year"
}Bei Verwendung der separaten 90-Tage-Policy:
POST _plugins/_ism/add/wazuh-archives-*
{
"policy_id": "delete_archives_after_90d"
}Dabei gilt: Die Befehle sind Alternativen, nicht zwei aufeinanderfolgende Schritte.
Vor der Ausführung sollte überprüft werden, welche Indizes vom Wildcard-Muster erfasst werden. Insbesondere bei alten Archiv-Indizes kann die Zuweisung einer Retention Policy dazu führen, dass diese bei der nächsten ISM-Verarbeitung gelöscht werden.
Bereits verwaltete Indizes sollten nicht unkontrolliert einer anderen Policy zugewiesen werden. Für einen Policy-Wechsel ist der vorgesehene ISM-Änderungsmechanismus zu verwenden.
Nach der Zuweisung wird der Status kontrolliert:
GET _plugins/_ism/explain/wazuh-archives-*Damit lässt sich feststellen, ob die gewünschten Indizes verwaltet werden und ob der Löschprozess ordnungsgemäß abläuft.
Schritt 6: Unassigned Shards identifizieren
Nachdem die Retention-Konfiguration korrigiert wurde, sollten die fünf unzugewiesenen Shards untersucht werden.
Der folgende Befehl liefert die relevanten Informationen:
GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason&s=stateIm beschriebenen Fall betrifft das ausschließlich Replica Shards interner OpenSearch-Indizes.
Die Replikationseinstellungen lassen sich gezielt prüfen:
GET .opendistro-alerting-config/_settings?flat_settings=trueDabei sind insbesondere folgende Werte relevant:
index.number_of_replicas
index.auto_expand_replicasAuch die anderen vier betroffenen Indizes sollten entsprechend geprüft werden.
Schritt 7: Replikate in einer Single-Node-Umgebung deaktivieren
In einer echten Single-Node-Installation kann es sinnvoll sein, die Replikazahl dieser Indizes auf null zu setzen.
Beispiel:
PUT .opendistro-alerting-config/_settings
{
"index": {
"number_of_replicas": 0,
"auto_expand_replicas": "false"
}
}Die Einstellung auto_expand_replicas wird ausdrücklich deaktiviert, damit die gewünschte Replikazahl nicht durch eine automatische Anpassung verändert wird.
Entsprechend können die übrigen betroffenen Indizes nach Prüfung ihrer aktuellen Konfiguration angepasst werden.
PUT .opensearch-control-center/_settings
{
"index": {
"number_of_replicas": 0,
"auto_expand_replicas": "false"
}
}Die Änderung sollte nur erfolgen, wenn die verwendete OpenSearch-Version und die jeweiligen Plugins diese Einstellung für die betroffenen Systemindizes unterstützen.
Sicherheitsrelevante Besonderheit
Bei diesen Indizes handelt es sich nicht um gewöhnliche Wazuh-Alert-Indizes.
Einige davon speichern Konfigurations- und Zustandsinformationen für OpenSearch Alerting oder andere interne Funktionen.
Besonders relevant sind:
.opendistro-alerting-config: Konfigurationen für Alerting-Funktionen..opensearch-alerting-config-lock: Interne Koordinierungsinformationen..opensearch-control-center: Interner Systemindex, dessen Verfügbarkeit für Verwaltungsfunktionen relevant sein kann.
Eine Deaktivierung der Replikation reduziert die Redundanz dieser Daten.
Bei einem einzelnen Knoten ist ohnehin keine Replikation auf einen unabhängigen Datenknoten möglich. Die Änderung kann daher die fünf unzugewiesenen Replikate beseitigen und den Clusterstatus auf Green bringen, sofern keine weiteren Probleme bestehen.
Green bedeutet in diesem Fall jedoch nicht hochverfügbar.
Fällt der einzige Datenknoten aus, können sowohl Sicherheitsdaten als auch interne Konfigurationsinformationen vorübergehend oder dauerhaft nicht verfügbar sein.
Bei einer späteren Erweiterung auf mehrere Datenknoten muss die Replikationsstrategie erneut überprüft werden.
Schritt 8: Clusterstatus kontrollieren
Nach den Änderungen sollte der Clusterstatus erneut abgefragt werden:
GET _cluster/health?prettyBei erfolgreich zugewiesenen Primary Shards und ohne unzugewiesene Replikate ist beispielsweise folgende Situation zu erwarten:
{
"cluster_name": "wazuh-cluster",
"status": "green",
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"unassigned_shards": 0
}Anschließend empfiehlt sich eine erneute Prüfung der Shard-Verteilung:
GET _cat/indices?v&h=index,pri,rep,store.size&s=indexDie Entwicklung sollte über mehrere Tage beobachtet werden.
Eine erfolgreiche Bereinigung zeigt sich nicht zwingend sofort an einer deutlich sinkenden Shard-Anzahl. Entscheidend ist, dass neu angelegte Indizes durch ablaufende Retention-Fristen langfristig ausgeglichen werden.
Lessons Learned / Best Practices
1. Shard-Limits nicht als dauerhafte Problemlösung erhöhen
Die Erhöhung von cluster.max_shards_per_node von einem niedrigeren Wert auf 1300 verschafft lediglich zusätzliche Kapazität.
Sie beseitigt weder eine fehlerhafte Retention-Konfiguration noch unnötig viele kleine Indizes.
Jeder Shard verursacht Verwaltungsaufwand und benötigt Ressourcen für Metadaten, Suchoperationen und Indexverwaltung.
Die optimale Shard-Anzahl hängt von der tatsächlichen Hardware, Heap-Größe, Indexgröße und Abfragelast ab.
Die Elasticsearch-Dokumentation beschreibt beispielsweise die Nachteile von Oversharding und empfiehlt eine an der Workload orientierte Shard-Strategie. Diese allgemeinen Prinzipien sind auch für OpenSearch relevant, die konkreten Versions- und Implementierungsdetails müssen jedoch separat geprüft werden.
Elasticsearch Labs+1
2. Shard-Anzahl und Shard-Größe gemeinsam überwachen
Eine geringe Shard-Anzahl ist nicht automatisch besser.
Sehr große Shards können Wiederherstellungsprozesse und Suchoperationen erschweren. Sehr kleine Shards verursachen dagegen häufig unverhältnismäßig viel Verwaltungsaufwand.
Für das Monitoring sind insbesondere folgende Kennzahlen relevant:
| Kennzahl | Bedeutung |
|---|---|
| Active Shards | Aktuell zugewiesene Shards |
| Unassigned Shards | Nicht platzierte Shards |
| Shards pro Datenknoten | Verteilung und Ressourcenbelastung |
| Indexgröße | Tatsächlicher Speicherbedarf |
| JVM Heap Usage | Speicherbelastung des Indexers |
| ISM-Fehler | Fehlgeschlagene Lifecycle-Aktionen |
| Indexwachstum pro Tag | Frühindikator für Kapazitätsprobleme |
Für viele Elasticsearch-Workloads werden Shard-Größen zwischen 10 und 50 GB als Orientierung genannt. Dieser Bereich ist keine starre Vorgabe für Wazuh, sondern muss anhand der konkreten Anforderungen bewertet werden.
Elastic Docs+1
3. Neue Indexfamilien regelmäßig auf ISM-Zuordnung prüfen
Neue Wazuh-Versionen, Integrationen oder aktivierte Funktionen können zusätzliche Indizes erzeugen.
Deshalb sollte regelmäßig geprüft werden, ob neue Indexfamilien entstanden sind und welche Retention-Regeln dafür gelten.
Eine sinnvolle Betriebsroutine umfasst die Bestandsaufnahme sämtlicher Indizes, die Kontrolle der ISM-Zuordnungen und die Überwachung von fehlgeschlagenen Lifecycle-Aktionen.
Dabei sollten interne OpenSearch-Systemindizes ausdrücklich von normalen Event- und Monitoring-Indizes unterschieden werden.
Systemindizes dürfen nicht pauschal mit einer allgemeinen Löschrichtlinie versehen werden.
4. Replikation an der tatsächlichen Clusterarchitektur ausrichten
Eine Replica-Konfiguration muss zur verfügbaren Infrastruktur passen.
In einer Single-Node-Installation können Replikate nicht auf einem unabhängigen Knoten platziert werden. In einem Multi-Node-Cluster können sie dagegen einen wesentlichen Beitrag zur Ausfallsicherheit leisten.
Daher sollte die Replikation nicht allein mit dem Ziel konfiguriert werden, einen grünen Clusterstatus zu erreichen.
Gerade bei Alerting- und Verwaltungsindizes ist die Verfügbarkeit der gespeicherten Konfigurationen wichtig.
Bei produktiven Security-Plattformen mit hohen Verfügbarkeitsanforderungen sollte eine geeignete Multi-Node-Architektur geprüft werden.
5. Retention und Backup voneinander trennen
Eine ISM-Policy ist kein Backup.
Sie regelt, wann Daten aus dem aktiven Indexer entfernt werden. Sie schützt nicht vor Hardwareausfällen, fehlerhaften Konfigurationsänderungen oder versehentlichem Löschen.
Besonders bei Single-Node-Installationen sind daher regelmäßige, überprüfte Backups und ein dokumentierter Wiederherstellungsprozess erforderlich.
Vor größeren ISM-Änderungen sollte zudem feststehen, welche Daten für Sicherheitsanalysen, Incident Response oder regulatorische Nachweise erhalten bleiben müssen.
Fazit
Eine kontinuierlich steigende Shard-Anzahl in Wazuh 4.14 ist nicht zwangsläufig ein Hinweis auf einen Defekt des Indexers oder eine fehlerhafte ISM-Engine.
Häufig liegt die Ursache darin, dass die vorhandene Retention Policy nur einen Teil der tatsächlich erzeugten Indizes verwaltet.
Im beschriebenen Fall funktionierte die 365-Tage-Retention für wazuh-alerts-* bereits. Andere Indexfamilien waren jedoch nicht von der automatischen Policy-Zuweisung erfasst.
Die nachhaltige Lösung besteht darin, sämtliche relevanten Indexfamilien zu identifizieren, passende Aufbewahrungsrichtlinien zu definieren und bestehende Indizes kontrolliert in das Lifecycle Management aufzunehmen.
Die zusätzlich vorhandenen fünf unzugewiesenen Replikate waren ein separates Problem der Single-Node-Architektur. Ihre gezielte Deaktivierung kann den Clusterstatus verbessern, ersetzt jedoch keine redundante Infrastruktur.
Entscheidend für einen stabilen Wazuh-Betrieb ist somit nicht die möglichst großzügige Konfiguration des Shard-Limits, sondern ein abgestimmtes Zusammenspiel aus Index Lifecycle Management, Shard-Sizing, Replikationsstrategie und kontinuierlichem Monitoring.
Quellen und weiterführende Informationen
Die folgenden Ressourcen erläutern die technischen Grundlagen zu Shard-Größen, Replikation und Kapazitätsplanung. Die Elastic-Dokumentation dient dabei als ergänzende Architekturreferenz; für konkrete Wazuh-Indexer-Konfigurationen sind die jeweiligen OpenSearch- und Wazuh-Versionen maßgeblich.
1. Elasticsearch – Shard and Node Size Best Practices
2. Elasticsearch – Size Your Shards
3. Elasticsearch – Shards and Replicas: A Practical Guide
4. OpenSearch – Index State Management
5. Wazuh – Index Lifecycle Management
Mehr zu Wazuh …
Mehr zum Wazuh Ambassador Program …
https://wazuh.slack.com/archives/C0A933R8E/p1791469363608199