Einleitung
Eine hohe Event-Drop-Rate ist eines der kritischsten Symptome in einer Wazuh-Umgebung. Sie bedeutet nicht nur verlorene Logs, sondern potenziell verpasste Sicherheitsereignisse, unvollständige Korrelationen und eingeschränkte Forensik. Gerade in Umgebungen mit vielen Agents, Firewalls oder stark loggenden Anwendungen stößt der Wazuh-Manager schnell an seine Grenzen. Dieser Artikel erklärt, wie Event Drops entstehen, wie man sie korrekt analysiert und welche offiziell dokumentierten Maßnahmen zur Reduzierung zur Verfügung stehen.
Ausgangslage / Problemstellung
In der Wazuh-Community wird regelmäßig berichtet, dass im Dashboard eine hohe Anzahl dropped events angezeigt wird. Typische Begleiterscheinungen:
- Alerts fehlen trotz bekannter Ereignisse
- Der Manager reagiert verzögert
- Die Anzahl „received events“ liegt deutlich über den „processed events“
Die zentrale Frage lautet: Wie lassen sich diese Drops reduzieren, ohne sicherheitsrelevante Logs zu verlieren?
Technische Analyse
Was bedeutet „Event Drop“ in Wazuh?
Event Drops entstehen primär im wazuh-analysisd-Daemon. Dieser verarbeitet eingehende Logs, dekodiert sie, wendet Regeln an und erzeugt Alerts. Kann der Daemon die eingehenden Events nicht schnell genug abarbeiten, werden Events verworfen, um einen vollständigen Stillstand zu verhindern.
Wazuh stellt hierfür interne Statistiken bereit, die über die API bzw. Dev Tools abrufbar sind.
Analyse der Drop-Statistiken
Über das Wazuh Dashboard lassen sich detaillierte Zahlen abrufen:
Pfad im Dashboard:
Hamburger-Menü → Server management → Dev Tools
Abfrage:
GET /manager/daemons/stats?daemons_list=wazuh-analysisd
Die Ausgabe zeigt unter anderem:
- Anzahl empfangener Events
- Anzahl analysierter Events
- Anzahl verworfener Events
Diese Werte sind die wichtigste Grundlage für jede weitere Optimierung.
Quelle:
https://documentation.wazuh.com/current/user-manual/api/reference.html
Häufige Ursachen für hohe Drop-Rates
1. Ressourcenengpässe auf dem Wazuh-Manager
Der analysisd-Daemon ist CPU- und speicherintensiv. Reichen die Ressourcen nicht aus, steigt die Drop-Rate zwangsläufig.
Empfohlene Prüfungen:
- Arbeitsspeicher
free -h - CPU-Last
top - Plattenplatz
df -h
Sind CPU dauerhaft ausgelastet oder Speicher knapp, kann analysisd Events nicht mehr rechtzeitig verarbeiten.
Quelle:
https://documentation.wazuh.com/current/user-manual/installation/requirements.html
2. Übermäßig viele oder „laute“ Logquellen
Ein häufiger Grund für Drops sind einzelne Agents oder Logquellen, die sehr große Mengen gleichartiger Events erzeugen, etwa:
- Debug- oder Verbose-Logs
- Firewall-Logs ohne Vorfilter
- Fehlkonfigurierte Anwendungen mit Log-Loops
In der analysisd-Statistik lässt sich oft erkennen, welche Module oder Quellen besonders viele Events erzeugen.
3. Fehlende Filterung auf Agent-Seite
Alle ungefilterten Logs müssen vom Manager verarbeitet werden. Ohne Vorfilterung steigt die Last exponentiell mit der Anzahl der Agents.
Wazuh unterstützt explizit die Filterung direkt auf Agent-Seite, um unnötige Events gar nicht erst an den Manager zu senden.
Quelle:
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html
4. Skalierungsgrenzen einer Single-Manager-Architektur
In größeren Umgebungen stößt ein einzelner Wazuh-Manager strukturell an seine Grenzen – selbst bei ausreichender Hardware. Hohe Event-Raten sind ein klares Signal, dass horizontale Skalierung notwendig wird.
Lösung / Best Practices
1. Events gezielt analysieren statt blind optimieren
Der erste Schritt ist immer die Auswertung von:
GET /manager/daemons/stats?daemons_list=wazuh-analysisd
Nur wer weiß, wie viele Events ankommen und wo sie verloren gehen, kann sinnvoll optimieren.
2. Filterung auf Agent-Seite umsetzen
Die effektivste Maßnahme gegen Drops ist das Unterdrücken nicht benötigter Logs direkt auf dem Agent:
- Einschränkung von Logpfaden
- Nutzung von
exclude-Optionen - Reduzierung von Debug- oder Verbose-Logs
Diese Konfigurationen erfolgen über ossec.conf im <localfile>-Block.
Quelle:
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html
3. Manager-Ressourcen korrekt dimensionieren
Stelle sicher, dass der Wazuh-Manager den empfohlenen Hardware-Anforderungen entspricht – insbesondere bei steigender Agent-Zahl oder hohen Log-Raten.
Quelle:
https://documentation.wazuh.com/current/user-manual/installation/requirements.html
4. Horizontale Skalierung einplanen
Wenn alle Logs sicherheitsrelevant sind und nicht gefiltert werden dürfen, bleibt nur die Skalierung:
- Hinzufügen weiterer Wazuh-Manager-Nodes
- Nutzung eines Manager-Clusters
- Separate Skalierung von Manager und Indexer
Wazuh dokumentiert dieses Vorgehen explizit für produktive Umgebungen mit hoher Last.
Quelle:
https://documentation.wazuh.com/current/user-manual/configuring-cluster/index.html
Lessons Learned / Best Practices
- Event Drops sind ein Last-Symptom, kein Bug.
- Analyse ohne die
analysisd-Statistiken führt zu falschen Schlussfolgerungen. - Agent-seitige Filterung ist der wirkungsvollste Hebel zur Lastreduktion.
- Ein Single-Manager-Setup skaliert nur bis zu einem gewissen Event-Volumen.
- Hohe Drop-Rates sollten als Skalierungsindikator verstanden werden, nicht nur als Konfigurationsproblem.
Fazit
Eine hohe Event-Drop-Rate in Wazuh ist immer ein Warnsignal: Entweder ist der Manager überlastet, die Logquellen sind zu laut oder die Architektur skaliert nicht mehr ausreichend. Wazuh stellt mit analysisd-Statistiken, Agent-seitiger Filterung und Cluster-Architekturen alle notwendigen Mittel bereit, um dieses Problem kontrolliert zu lösen. Entscheidend ist, Drops nicht zu ignorieren, sondern sie als Anlass für sauberes Log-Design und gezielte Skalierung zu nutzen.
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/p1767331686689109