Wazuh All-in-One nach VM-Reboot instabil: Wazuh Indexer „request timeout“, Bootstrap-Checks (memory_lock) und API-Timeouts nachhaltig beheben

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

All-in-One-Installationen (Manager, Indexer, Dashboard auf einer VM) sind für den Einstieg bequem – im Betrieb aber empfindlich gegenüber Ressourcenkonkurrenz. Typische Symptome nach einem Reboot: Der Wazuh Indexer startet nicht mehr („service failed“, „request timeout“), Bootstrap-Checks brechen ab („memory locking requested … but memory is not locked“) und die Wazuh API läuft in zeitkritischen UI-Views (z. B. Vulnerability Detection) in Timeouts. Dieser Beitrag zeigt, wie Sie die Ursachen sauber eingrenzen und mit robusten Best Practices stabilisieren – inklusive Doku-Verweisen.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Umgebung (typisch): Eine VM mit ausreichend „Peak“-Ressourcen (z. B. 16 vCPU, 48 GB RAM, 2 TB Disk), auf der Wazuh Indexer (OpenSearch-basiert), Wazuh Server/Manager und Wazuh Dashboard gemeinsam laufen.

Symptome:

  • Nach VM Power-Off/On: wazuh-indexer startet nicht, Requests laufen in Timeouts, Service ist failed.
  • Nach Aktivierung von bootstrap.memory_lock: true: Bootstrap checks failed, Hinweis: memory locking requested … but memory is not locked.
  • Im Dashboard: Beim Öffnen datenintensiver Views (z. B. Vulnerability Detection) erscheint API timeout (klassisch: „timeout of 20000ms exceeded“), danach lädt die UI später doch oder springt zurück.

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) Indexer-Ausfall nach Reboot: Swap, mlock und Bootstrap-Checks

Der Wazuh Indexer (OpenSearch/Java) reagiert empfindlich auf Swap. Sobald das System unter Druck gerät (All-in-One: mehrere speicherhungrige Dienste gleichzeitig), kann die JVM „ausgelagert“ werden – das führt zu massiven Latenzen, Timeouts oder Startfehlern. Wazuh dokumentiert deshalb explizit, dass Indexer-Memory gelockt werden soll, damit JVM-Seiten nicht auf Disk wandern.

Der Stolperstein: bootstrap.memory_lock: true allein genügt nicht. OpenSearch fordert dann per Bootstrap-Check, dass das Betriebssystem mlock tatsächlich erlaubt. Wenn systemd/ulimit die Sperre verhindert, schlägt der Start absichtlich fehl – genau der beobachtete „bootstrap checks failed“-Fall. Wazuh beschreibt dafür die systemd-Drop-in-Konfiguration mit LimitMEMLOCK=infinity.

Zusätzlich ist in virtualisierten Umgebungen ein weiterer Klassiker: zu niedriger vm.max_map_count, was den Indexer ebenfalls nach Neustarts oder Updates stoppen kann (OpenSearch mappt viele Segmente/Files). In der Wazuh-Doku (u. a. bei Container-Deployments, aber inhaltlich auch für Hosts relevant) wird mindestens 262144 genannt – sonst kann der Indexer „fail due to limited virtual memory mapping“.

2) API-/Dashboard-Timeouts: nicht nur UI-Timeout, sondern Manager-Last

Das Dashboard hat einen Request-Timeout (Default: 20000 ms). Wenn der Manager (oder indirekt der Indexer) Anfragen nicht schnell genug bedient, endet das im UI als Timeout. Wazuh dokumentiert die Timeout-Option in den Dashboard-Einstellungen.

Wichtig: Ein höherer UI-Timeout kaschiert nur Symptome. Bei datenintensiven Features (z. B. Vulnerability Detection, große Agentenzahlen, viele Events/s) ist die nachhaltige Lösung meist horizontale Skalierung (Manager-Cluster) oder eine verteilte Installation, damit Indexer/Manager/Dashboard nicht um CPU/RAM/IO konkurrieren. Wazuh beschreibt das Upscaling über zusätzliche Server-Nodes und unterscheidet All-in-One vs. Distributed Deployment.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

A) Wazuh Indexer startet nach Reboot nicht: Diagnose-Checkliste (in Reihenfolge)

  1. Service- und Indexer-Logs prüfen
systemctl status wazuh-indexer --no-pager
journalctl -u wazuh-indexer -b --no-pager | tail -n 200
tail -n 200 /var/log/wazuh-indexer/wazuh-cluster.log
  1. Swap-Status und RAM-Druck prüfen
free -h
swapon --show
vmstat 1 5
  1. Kernel-Limit prüfen (vm.max_map_count)
sysctl vm.max_map_count

Wenn deutlich unter 262144, dauerhaft setzen (Beispiel):

echo 'vm.max_map_count=262144' > /etc/sysctl.d/99-wazuh-indexer.conf
sysctl --system

Begründung/Referenz: Zu niedrige Werte können den Indexer wegen limitierter Memory-Mappings scheitern lassen.

B) Memory Locking korrekt aktivieren (und Bootstrap-Check „memory not locked“ beheben)

Wazuh beschreibt dafür einen klaren Dreiklang: OpenSearch-Setting, systemd Limit, Heap-Size.

  1. Memory Lock einschalten
    Datei: /etc/wazuh-indexer/opensearch.yml
bootstrap.memory_lock: true
  1. systemd: LimitMEMLOCK freigeben (entscheidend gegen „memory is not locked“)
mkdir -p /etc/systemd/system/wazuh-indexer.service.d/

cat > /etc/systemd/system/wazuh-indexer.service.d/wazuh-indexer.conf << 'EOF'
[Service]
LimitMEMLOCK=infinity
EOF
  1. Heap sauber dimensionieren (All-in-One besonders wichtig)
    Datei: /etc/wazuh-indexer/jvm.options

Empfehlung (praxisnah für 48 GB RAM All-in-One):

  • Indexer Heap nicht mehr als ~50% des RAM
  • unter 32 GB bleiben (Compressed Oops, GC-Charakteristik)
  • Xms = Xmx setzen (kein Heap-Resizing zur Laufzeit)

Beispiel:

-Xms22g
-Xmx22g

Wazuh betont u. a., dass Xms und Xmx identisch sein sollen, um Performance-Degradation zu vermeiden.

  1. Reload & Restart
systemctl daemon-reload
systemctl restart wazuh-indexer
  1. Verifizieren, dass mlock aktiv ist
    Wazuh beschreibt die Verifikation über den mlockall-Status in den Indexer-Node-Infos.
    (Je nach Setup wird das typischerweise via API/Nodes-Info geprüft.)

Side-Effect (wichtig): Wenn Sie Memory Lock erlauben, aber das System real zu wenig RAM hat (oder der Heap zu groß ist), kann das System stärker unter Druck geraten. Deshalb Heap begrenzen und All-in-One-Ressourcen fair verteilen (Indexer darf nicht alles „aufsaugen“).

C) Dashboard/API-Timeouts bei Vulnerability Detection & Co.

  1. Dashboard Request Timeout korrekt einordnen
    Der Default liegt bei 20000 ms; die Einstellung steuert, wie lange das Dashboard auf eine API-Antwort wartet.
    Ein höherer Wert kann kurzfristig helfen, ist aber kein Ersatz für ausreichende Manager-/Indexer-Kapazität.
  2. Manager-Lastindikatoren im Betrieb überwachen (Dropping vermeiden)
    In All-in-One-Umgebungen ist es essenziell, ob Events verworfen werden (Sicherheitsrisiko: fehlende Alerts/Detections). Zwei praxistaugliche Indikatoren:
  • /var/ossec/var/run/wazuh-analysisd.state → events_dropped
  • /var/ossec/var/run/wazuh-remoted.state → discarded_count

Diese Werte sollten dauerhaft 0 sein.

  1. Skalieren statt „Timeout hochdrehen“
    Für größere Event-Lasten ist die belastbarste Maßnahme, zusätzliche Wazuh Server/Manager Nodes hinzuzufügen und das Deployment zu verteilen. Wazuh beschreibt das horizontale Upscaling (All-in-One und Distributed) in der Cluster-Dokumentation.
    Das reduziert API-Latenzen, verhindert Drops und gibt Ihnen Kontrolle über CPU/RAM pro Komponente.

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • All-in-One ist kein Skalierungsmodell. Spätestens bei Vulnerability Detection, hoher Agentenzahl oder intensiven Queries sollte der Schritt zu Distributed Deployment und/oder Server-Cluster früh geplant werden.
  • Indexer-Betriebssystem-Guards dauerhaft setzen:
    • bootstrap.memory_lock: true + systemd LimitMEMLOCK=infinity konsequent umsetzen.
    • vm.max_map_count dauerhaft korrekt setzen (mind. 262144).
  • Heap-Disziplin: Xms=Xmx, nicht >50% RAM, nicht >32 GB – besonders kritisch, wenn Manager und Dashboard ebenfalls RAM benötigen.
  • Timeouts sind ein Symptom, kein Zielwert. Dashboard-Timeout kann man konfigurieren, aber die nachhaltige Stabilität kommt aus Ressourcen- und Architekturmaßnahmen.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn der Wazuh Indexer nach einem VM-Reboot mit Timeouts und „service failed“ ausfällt, liegt die Ursache häufig nicht in „Wazuh selbst“, sondern in OS-/Runtime-Guards (Swap/mlock, Limits, Kernel-Parameter) und in der Ressourcenkonkurrenz einer All-in-One-VM. Mit korrekt aktivierter Memory-Lock-Konfiguration samt systemd-Limit, sinnvoll dimensioniertem Heap und sauber gesetztem vm.max_map_count eliminieren Sie die typischen Bootstrap- und Startfehler. Für wiederkehrende API-Timeouts gilt: UI-Timeout erhöhen kann helfen – nachhaltig wird es erst mit Skalierung (zusätzliche Manager-Nodes) und einer verteilten Architektur.

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