DISK CRITICAL trotz 95 GB frei: Wenn /var wegen Inodes und Wazuh-Indexer-Queue (wazuh-states-vulnerabilities) explodiert

von

Einleitung

In Wazuh-Umgebungen mit vielen Agents kann „Disk Critical“ auf Worker-/Manager-Nodes plötzlich auftreten, obwohl df -h noch zweistellige Gigabytes an freiem Speicher zeigt. Der Grund ist häufig nicht der freie Platz, sondern ein Inode-Exhaustion (z. B. inode=99%) – ausgelöst durch sehr viele Dateien in Wazuh-Queues oder RocksDB/Indexer-Connector-Verzeichnissen. In diesem Beitrag geht es um ein konkretes Muster: gigantische Belegung unter /var/ossec/queue/indexer/wazuh-states-vulnerabilities-* bei vergleichsweise kleinem tatsächlichem Index im Wazuh Indexer – und wie man das sauber diagnostiziert und stabil behebt, ohne Datenverlust zu riskieren.

Ausgangslage / Problemstellung

  • Alarm: DISK CRITICAL - free space: /var 94 GB (10% inode=99%)
  • /var hat insgesamt ~767 GB, frei sind ~95 GB → Platz ist da, aber Inodes sind nahezu aufgebraucht.
  • Auffälliges Verzeichnis: /var/ossec/queue/indexer/wazuh-states-vulnerabilities-wazuh_cluster/ ~ 542 GB
  • Gleichzeitig ist die entsprechende Vulnerability-Detection-State-Indexgröße im Indexer deutlich kleiner (Beispiel aus dem Thread: < 6 GB).
  • Im Verzeichnis liegen u. a. LOG.old.* Dateien, die aber nur im MB-Bereich sind → nicht der Haupttreiber.

Der Wunsch „Daten in diesem Verzeichnis archivieren“ deutet zusätzlich darauf hin, dass das Verzeichnis als „Datenspeicher“ missverstanden wird – dabei ist es in Wirklichkeit Teil der Wazuh-Queue-/Connector-Mechanik.

Technische Analyse

1) Warum „95 GB frei“ trotzdem kritisch ist: Inodes vs. Bytes

inode=99% bedeutet: Das Dateisystem kann kaum noch neue Dateien/Verzeichnisse anlegen – unabhängig davon, wie viel Speicherplatz frei ist. Genau das passiert, wenn Prozesse massenhaft kleine Dateien erzeugen (z. B. RocksDB .sst/LOG/WAL-Dateien oder Queue-Fragmente).

2) Was ist /var/ossec/queue – und warum ist Löschen gefährlich?

Wazuh verwendet /var/ossec/queue als zentrales Arbeitsverzeichnis für interne Queues, temporäre Daten und die Kommunikation zwischen Komponenten. Das Verzeichnis ist „kritisch für den Betrieb“; bei Verlust/Manipulation kann nicht nur Funktionalität ausfallen, es kann auch Daten verloren gehen, die noch nicht persistent verarbeitet/gespeichert wurden.

3) Warum ausgerechnet wazuh-states-vulnerabilities-* so groß werden kann

Vulnerability Detection (VD) korreliert Software-Inventar mit CVE-Feeds und schreibt den Zustand (State) zur Abfrage/Visualisierung in den Indexer. Wazuh dokumentiert, dass erkannte Vulnerabilities über den Indexer Connector an den Wazuh Indexer weitergeleitet werden (standardmäßig aktiviert).

Der kritische Teil: Unter /var/ossec/queue/indexer/... hält Wazuh lokal eine Queue und persistente Zwischenablage vor, damit Events zuverlässig in den Indexer gelangen. Wenn dieser „Abfluss“ gestört ist (Performance, Auth, Backpressure, Bug/Loop), kann das Verzeichnis immer weiter wachsen – inklusive sehr vieler Dateien, was direkt auf Inodes schlägt.

In Community-Fällen wurde beschrieben, dass .sst-Dateien im Queue-Verzeichnis stark anwachsen; eigentlich sollten nicht verarbeitete Elemente bei funktionierender Indexer-Anbindung „über die Zeit“ abgebaut werden. In bestimmten Fällen konnte die Verarbeitung jedoch in einen Loop geraten; als Fix/Abhilfe wurde ein Upgrade (z. B. ab 4.10.0) genannt.

Lösung / Best Practices

Die richtige Reihenfolge ist entscheidend: erst diagnostizieren, dann gezielt handeln. „Einfach löschen“ ist hier der schnellste Weg zu Datenverlust oder inkonsistentem Zustand.

Schritt 1: Inode-Hotspot exakt lokalisieren

Auf dem betroffenen Node:

  • Inodes prüfen:
    • df -i /var
  • Top-Verursacher finden:
    • sudo find /var/ossec/queue -xdev -type f | wc -l
    • sudo find /var/ossec/queue/indexer -xdev -type f | wc -l
    • sudo du -h --max-depth=2 /var/ossec/queue/indexer | sort -h

Wenn der Dateizähler im indexer/wazuh-states-vulnerabilities-*-Pfad explodiert, ist das fast immer der Kern des Problems.

Schritt 2: Sicherstellen, dass der Indexer-Connector wirklich abarbeiten kann

Da VD-Daten via Indexer Connector weitergeleitet werden, muss die Verbindung/Verarbeitung stabil sein.

Praktische Checks:

  • Wazuh-Logs auf Indexer-Connector-/Queue-Warnungen prüfen (z. B. Auth/Timeout/Backpressure).
  • Indexer-Seite: Cluster health, Schreiblast, Disk-Watermarks, Shard-Zustand, ISM/Retention (falls aktiv) prüfen.

Wenn der Indexer „hängt“ oder Writes nicht sauber annimmt, wächst die lokale Queue zwangsläufig weiter.

Schritt 3: Nicht „archivieren“, sondern korrekt „retention“ auf Indexer-Ebene planen

Das Verzeichnis /var/ossec/queue/indexer/... ist keine Archivablage. Archiv/Retention gehört auf die Indexer-Datenebene (Snapshots/ISM/Index-Rollover), nicht in die Manager/Worker-Queue. Die Queue muss klein bleiben, sonst gefährdet sie den Betrieb (Inodes, Performance, Drops).

Schritt 4: „LOG.old.*“ einordnen – und nur das löschen, was wirklich ungefährlich ist

Im Thread waren LOG.old.* im MB-Bereich – sie erklären keine 542 GB. Das spricht dafür, dass:

  • entweder extrem viele .sst/DB-Fragmente existieren,
  • oder eine Loop-/Cleanup-Problematik vorliegt.

Wichtig: Selbst wenn einzelne Log-Rotation-Dateien oft löschbar wirken: Das ist ohne Kontext (RocksDB/Queue-State) nicht die eigentliche Lösung. Der Fokus muss auf „warum wird nicht abgebaut?“ liegen (Indexer-Anbindung, Bug, Loop).

Schritt 5: Read-only Analyse des lokalen RocksDB/Queue-DB-Inhalts

Im Thread wurde als nächster Schritt vorgeschlagen:

  • ldb --db=/var/ossec/queue/indexer/wazuh-states-vulnerabilities scan

Das ist ein typischer Weg, um zu sehen, ob die DB „unplausibel“ wächst oder z. B. viele Duplikate/Endlosschleifen-Indikatoren enthält. (Wichtig: nur read-only/scan, keine “repair/compact” Aktionen ohne Herstellerfreigabe.)

Schritt 6: Upgrade als strategischer Fix (wenn bekannte Growth/Loop-Symptome vorliegen)

Wenn das Muster „Queue wächst dauerhaft“ oder „viele .sst Dateien“ passt, ist ein Upgrade auf eine Wazuh-Version mit Fixes in diesem Bereich oft der nachhaltigste Weg. Community-Hinweise nennen konkrete Fälle, in denen ein Loop-bedingtes Wachstum behoben wurde und ein Upgrade empfohlen wird.

Schritt 7: Operative Sofortmaßnahmen, wenn /var akut „kippt“

Wenn die Partition kurz vor „no space left on device“ steht (Inodes!), braucht es manchmal sofort Luft:

  • Temporär VD-Frequenz/Last reduzieren (weniger gleichzeitige Scans, Feed-Update-Interval prüfen), um die Erzeugung neuer Queue-Elemente zu dämpfen.
  • Verzeichnis auf ein anderes Filesystem verlagern und per bind mount zurückbinden (wie im Thread angedeutet), um /var zu entlasten, ohne zu löschen. Das ist ein gängiger Linux-Workaround, wenn kurzfristig mehr Inodes/Platz auf einer anderen Partition verfügbar sind.

Lessons Learned / Best Practices

  • Inodes sind eine eigene Ressource: Monitoring sollte df -i genauso umfassen wie df -h.
  • /var/ossec/queue ist Betriebszustand, kein Archiv: Löschen kann Daten kosten und Komponenten destabilisieren.
  • VD skaliert mit Agent-Zahl: Bei 800+ Agents müssen Disk und I/O (Manager/Worker und Indexer) entsprechend dimensioniert werden; Wazuh verweist explizit darauf, dass Hardware-Anforderungen stark vom Umfang (Endpoints/Workloads) abhängen.
  • Wenn lokale Queue viel größer ist als der eigentliche Index: Das ist ein starkes Signal für Abflussprobleme (Indexer-Connector, Backpressure) oder bekannte Growth-/Loop-Probleme → zielgerichtet analysieren und ggf. upgraden.

Fazit

„Disk Critical trotz 95 GB frei“ ist bei Wazuh-Worker-Nodes mit großem VD-Footprint häufig ein Inode-Problem, ausgelöst durch massenhaft Dateien in /var/ossec/queue/indexer/wazuh-states-vulnerabilities-*. Das Verzeichnis ist keine Archivdatenbank, sondern Teil der zuverlässigen Event-/State-Weiterleitung zum Indexer. Die sichere Vorgehensweise ist: Inode-Hotspot lokalisieren, Indexer-Connector-Abfluss sicherstellen, lokale DB/Queue read-only analysieren (z. B. ldb scan), und bei Growth-/Loop-Symptomen konsequent auf eine Version mit Fixes upgraden – statt blind zu löschen.

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/p1768918039272519