Wazuh-Dashboard zeigt keine neuen Alerts: Unassigned Shards durch Disk-Watermarks und Shard-Explosion im Indexer-Cluster beheben

Einleitung

Wenn ein Wazuh-Cluster plötzlich keine oder nur noch sporadisch Alerts im Dashboard anzeigt, wirkt das zunächst wie ein Problem auf den Managern oder bei Filebeat. In der Praxis liegt die Ursache jedoch sehr häufig im Wazuh Indexer (OpenSearch): Sobald Shards nicht mehr alloziert werden können oder neue Indizes nicht mehr sauber angelegt werden, bricht die Indexierung ab – und damit die Sichtbarkeit im Dashboard, obwohl die Manager weiterhin Alerts erzeugen.

Dieser Beitrag beschreibt einen typischen Incident-Fall: Alerts sind in alerts.json vorhanden, Filebeat-Verbindungen sind ok, aber der Indexer-Cluster ist „yellow“, zeigt tausende unassigned shards und verweigert die Allocation wegen Disk-Watermarks. Zusätzlich tauchen Router-Fehler auf dem Manager auf, die in der Fehlersuche oft für Verwirrung sorgen.

Ausgangslage / Problemstellung

Umgebung (vereinfacht):

Mehrere Wazuh Manager (u. a. ein separater Manager außerhalb des Clusters)
Wazuh Indexer Cluster mit 3 Nodes
Seit Freitag: kaum/keine Alerts im Dashboard
Manager erzeugen Alerts weiterhin (Bestätigung über alerts.json)
Indexer-Cluster Health:
- Status: yellow
- active_shards: 1557
- unassigned_shards: 1446
- aktive Shards insgesamt nur ~52%

Parallel dazu Fehlermeldungen auf einem Manager:

Router-Fehler beim Senden eines JSON-Messages mit einem numerischen Wert, der nicht in ein 64-bit Integer passt:
- invalid number: "18446744073709551592", constant does not fit [...]

Zusätzliche Beobachtungen im Indexer-Log:

Search Backpressure / Task cancellation
JVM GC Overhead
Fehlende/ausbleibende Tagesindizes („heute“ nicht vorhanden)
allocation/explain zeigt als Blocker: disk_threshold bei cluster.routing.allocation.disk.watermark.low=85% (zu wenig freier Speicher)

Technische Analyse

1) Warum das Dashboard „leer“ ist, obwohl Manager Alerts erzeugen

Die zentrale Kette ist:

Agent → Manager (alerts.json) → Filebeat → Wazuh Indexer (Indexierung) → Dashboard (Discover/Visualisierungen)

Wenn alerts.json weiter wächst, aber im Dashboard nichts ankommt, liegt der Fehler in der Regel in einem der beiden Abschnitte:

Filebeat kann nicht senden / wird geblockt
Indexer kann nicht (mehr) schreiben / allozieren / indizieren

In diesem Fall ist der Indexer durch Shard-Allocation-Blocker und Storage-Engpässe eingeschränkt. Das verhindert:

Anlage neuer Tagesindizes
Allocation von Replica-Shards
ggf. Rollovers/ISM-Schritte
stabile Indexierung unter Last

2) „Yellow“ mit sehr vielen unassigned shards: Shard- und Disk-Problem, nicht Manager-Problem

Zwei Befunde sind besonders aussagekräftig:

Summe aus aktiven und unassigned shards liegt bei ~3000+
allocation/explain blockiert Allocation wegen disk_threshold (Low Watermark 85%)

OpenSearch (und damit der Wazuh Indexer) allokiert ab dem „low watermark“ standardmäßig keine neuen Shards mehr auf Nodes, die über dem Grenzwert liegen. Standardwert: 85%.

Praktische Konsequenz:

Replica-Shards bleiben unassigned (Cluster bleibt „yellow“)
Je nach Situation können auch Index-Rollover, neue Index-Erstellung und Schreibpfade indirekt beeinträchtigt werden – insbesondere wenn zusätzlich hohe Heap-/GC-Last und Backpressure auftreten

3) Shard-Limit erhöhen löst das Symptom selten nachhaltig

Das Anheben von cluster.routing.allocation.total_shards_per_node kann kurzfristig helfen, wenn der Engpass wirklich nur das Shard-Limit ist. In diesem Fall war der dominante Blocker aber Disk Watermark – also „Allocation verboten“. Das erklärt, warum trotz höherem Shard-Limit weiterhin 1446 Shards unassigned bleiben.

Wichtig: Shard-Limit-Erhöhungen sind ein „Notnagel“ und verschieben das Problem häufig nur in Richtung Heap-Druck, GC-Probleme und instabile Cluster-Performance.

4) Router-Error auf dem Manager: Separates Problem, meist nicht der Hauptgrund für fehlende Dashboard-Alerts

Der Manager-Log zeigt einen „invalid number“-Fehler bei ram_usage. Der Wert 18446744073709551592 sieht wie ein Unsigned-Overflow/Underflow aus (nahe 2^64). Solche Werte entstehen typischerweise durch fehlerhafte Datenerhebung oder fehlerhafte Typkonvertierung in Inventar-/Hardware-Info (dbsync).

Das ist unschön und sollte behoben werden (Update/Fix/Workaround), ist aber nicht die primäre Ursache dafür, dass im Dashboard gar keine Alerts erscheinen – denn Alerts werden weiterhin in alerts.json geschrieben und Filebeat kann testen, dass die Verbindung steht. Der dominante Ausfallpunkt ist hier die Indexer-Seite.

Lösung / Best Practices

Schritt 1: Eindeutig feststellen, wo die Pipeline bricht

Manager erzeugt Alerts? tail -f /var/ossec/logs/alerts/alerts.json Wenn hier kontinuierlich neue Alerts erscheinen, arbeitet analysisd grundsätzlich.
Filebeat Output testen filebeat test output „Connection works“ ist notwendig, aber nicht hinreichend. Entscheidend ist, ob Indexer Writes/Index-Create/Allocation stabil sind.
Indexer-Cluster Health + Allocation Reasons
- Cluster Health: GET _cluster/health?pretty
- Unassigned Shards erklären: GET _cluster/allocation/explain?pretty

Wenn disk_threshold blockiert, ist „Disk zuerst“ das Primärthema.

Schritt 2: Disk Watermark sofort entschärfen (Priorität 1)

Wenn Nodes über dem Low Watermark sind (z. B. nur 10–13% frei), müssen Sie Speicher freimachen oder erweitern, bevor weitere Maßnahmen sinnvoll greifen.

Option A: Speicher freimachen (schnellster Weg)

Alte wazuh-alerts-* Indizes löschen (nach Retention/Compliance-Vorgaben)
Über „Index Management > Indices“ selektiv löschen (z. B. älteste Zeiträume)

Option B: Storage erweitern

Disk vergrößern / Volume erweitern
Zusätzlichen Indexer-Node hinzufügen und Shards verteilen (empfohlen für Wachstum)

Option C: Temporär Watermarks anpassen (nur als Übergang)

Das ist riskant: Wenn die Disk wirklich voll läuft, drohen Schreibstopps und Instabilität.
Nur nutzen, um ein kurzes Zeitfenster zur Bereinigung zu gewinnen, nicht als Dauerzustand. (OpenSearch beschreibt Watermark-Verhalten und Default-Werte.)

Schritt 3: Shard-Explosion und Index-Management dauerhaft in den Griff bekommen

Wenn Sie tausende Shards auf 3 Nodes haben, ist das ein Hinweis auf:

sehr viele Tagesindizes über lange Zeit
zu viele Primärshards pro Index
unnötige Replikas (je nach HA-Anforderung)
fehlende/ineffektive Lifecycle-Policies

Empfohlene Maßnahmen:

Index Lifecycle Management (ISM) einführen oder nachschärfen
- Retention-Regeln (Delete nach X Tagen)
- Rollovers nach Größe/Alter
- optional Hot/Warm-Strategien
  Wazuh beschreibt ISM und Konfigurationsoptionen für Storage-Optimierung.
Shard-Anzahl pro Index prüfen
- Für typische Wazuh-Alert-Volumina ist oft 1 Primärshard pro Tagesindex ausreichend; mehrere Shards lohnen meist erst bei sehr hohen Datenraten oder großen täglichen Indexgrößen.
- Jede Shard kostet Heap, Filehandles und Cluster-Overhead.
Replikas bewusst setzen
- Replikas erhöhen Ausfallsicherheit, verdoppeln aber Shard-Anzahl. Wenn Disk knapp ist, ist das sofort spürbar.
- Ein „yellow“-Cluster ist häufig schlicht „Replica unassigned“, weil Replica-Shards nicht alloziert werden können (Watermark). Das ist zwar nicht „rot“, aber operational relevant.
Indexer-Node hinzufügen, wenn Retention und Volumen wachsen
- Das ist die nachhaltigste Skalierung, statt Shard-Limits hochzudrehen. Wazuh dokumentiert das Vorgehen zum Hinzufügen von Indexer-Nodes inkl. Zertifikaten und Cluster-Anpassungen.

Schritt 4: Backpressure, Heap und GC-Warnungen ernst nehmen

Warnungen wie „SearchBackpressureService“ und „JvmGcMonitorService overhead“ sind typisch, wenn:

zu viele Shards
Heap zu klein / JVM unter Druck
zu hohe Query-Last (Dashboards, Discover, Saved Searches)
I/O-Engpässe und Segment-Merges

Kurzfristig helfen:

Disk/Shard-Problem lösen (reduziert Heap-Druck)
Query-Last reduzieren (Dashboard-Refresh, große Zeitbereiche vermeiden)
Ressourcen pro Indexer-Node erhöhen (RAM/Heap), sofern möglich

Langfristig helfen:

ILM/ISM + Retention
Shard-Strategie
Skalierung durch zusätzliche Nodes

Schritt 5: Manager-Router-Error sauber behandeln (separat, aber sinnvoll)

Der „invalid number“ Fehler kann dazu führen, dass bestimmte Inventory-/Hardware-Info-Events nicht verarbeitet werden. Für die Alert-Pipeline ist das meist nicht kritisch, aber:

Lognoise erschwert Troubleshooting
einzelne Datentypen fehlen oder werden nicht synchronisiert

Pragmatische Best Practices:

Agent und Manager auf konsistente, aktuelle Patchstände bringen (Bugfixes werden häufig in Minor-Releases adressiert)
Prüfen, ob der betroffene Datentyp (Hardware/Inventory) auf dem Agent/Manager notwendig ist; ggf. temporär deaktivieren, bis ein Fix eingespielt ist
Nach der Indexer-Stabilisierung separat analysieren, ob es einen bekannten Bug zur ram_usage-Berechnung im Inventory-Modul gibt (ansonsten reproduzierbares Sample isolieren)

Wichtig: Dieses Problem erklärt nicht die „leeren“ Dashboards – das tun die Disk-Watermarks und unassigned shards deutlich besser.

Lessons Learned / Best Practices

Wenn alerts.json gefüllt wird, aber das Dashboard leer bleibt, ist der Indexer der erste Verdächtige.
Filebeat-„test output“ reicht nicht; Allocation/Write-Fähigkeit des Indexers ist entscheidend.
Disk Watermarks sind ein harter Blocker für Shard-Allocation.
Standardmäßig verhindert OpenSearch ab 85% Disk-Nutzung (low watermark) die Allocation bestimmter Shards.
Shard-Limits erhöhen ist kein Ersatz für Kapazitäts- und Lifecycle-Management.
Ohne Retention/ISM wächst die Shard-Anzahl weiter und verschärft Heap/GC-Probleme.
Implementieren Sie ISM/Retention früh.
Wazuh stellt dafür konkrete ISM-Ansätze bereit, um Storage zu optimieren und Indizes automatisiert zu managen.
Planen Sie horizontale Skalierung des Indexers.
Zusätzliche Indexer-Nodes sind oft die nachhaltigste Lösung, wenn Volumen und Retention steigen.

Fazit

In Multi-Manager-/Multi-Indexer-Wazuh-Umgebungen sind „fehlende Alerts im Dashboard“ häufig kein Manager- oder Filebeat-Problem, sondern ein Indexer-Kapazitätsproblem. Ein „yellow“-Cluster mit vielen unassigned shards und disk_threshold-Blockern ist ein klares Signal: Der Indexer kann Shards nicht mehr alloziieren und gerät unter Speicher- und Ressourcenstress.

Die Reihenfolge der erfolgreichen Fehlerbehebung ist in der Praxis:

Indexer-Disk wieder unter Watermarks bringen (löschen/erweitern/node hinzufügen)
Shard-Anzahl und Retention mit ISM stabilisieren
Heap/GC/Backpressure als Folgeeffekte reduzieren
Manager-Router-Fehler separat bereinigen (Update/Workaround)

So werden neue Tagesindizes wieder zuverlässig erstellt, die Indexierung stabilisiert und Alerts im Dashboard erscheinen wieder kontinuierlich.