Einleitung
Die Meldung agent buffer is full at 90% ist ein wichtiger Hinweis auf Event-Stau zwischen Wazuh Agent und Wazuh Manager. Für SIEM- und Security-Teams ist das relevant, weil ein dauerhaft gefüllter Agent-Buffer nicht nur Rauschen signalisiert, sondern im weiteren Verlauf zu verworfenen Events und damit zu Sichtbarkeitsverlust führen kann.
Ausgangslage / Problemstellung
Ein einzelner Wazuh Agent erzeugt wiederholt Warnungen, dass der Agent-Buffer zu 90 Prozent gefüllt ist. Die queue_size wurde bereits von 5000 auf 8000 erhöht, dennoch bleibt das Problem bestehen. Eine weitere Erhöhung ist wegen CPU- beziehungsweise Ressourcenlimits nicht gewünscht. Erste Filtermaßnahmen wurden bereits umgesetzt, bringen aber noch keine stabile Entlastung.
Typische Symptome sind:
agent buffer is full at 90%sowie bei weiterer Verschärfung Wazuh-Regeln für volle oder geflutete Agent-Queues, insbesondere:
rule.id: 202 # Warning level reached
rule.id: 203 # Full capacity reached
rule.id: 204 # Flooding status
rule.id: 205 # Back to normalTechnische Analyse
Die Meldung ist in erster Linie ein Agent-seitiges Congestion-Problem. Der relevante Mechanismus ist der client_buffer des Wazuh Agents. Dieser funktioniert als Leaky-Bucket-Queue: Events werden lokal gepuffert und mit einer definierten Rate an den Wazuh Manager übertragen.
Die zentralen Parameter sind:
<client_buffer>
<disabled>no</disabled>
<queue_size>5000</queue_size>
<events_per_second>500</events_per_second>
</client_buffer>queue_size definiert, wie viele Events der Agent maximal puffern kann. events_per_second definiert, wie viele Events pro Sekunde aus diesem Buffer an den Manager gesendet werden. Der Standardwert liegt bei 5000 Events Queue-Größe und 500 EPS. Die Warnung bei 90 Prozent bedeutet noch nicht zwingend Eventverlust, zeigt aber, dass der Agent schneller Events erzeugt oder sammelt, als sie abgearbeitet werden.
Wichtig ist die Abgrenzung: queue_size und events_per_second sind keine Manager-Tuning-Parameter. Sie steuern den Agent-to-Manager-Durchsatz. Eine Erhöhung kann kurzfristig helfen, verschiebt aber häufig nur das Problem, wenn die eigentliche Ursache ein zu lauter Log-Stream ist.
Typische Ursachen sind:
- ein einzelner Log-Source mit ungewöhnlich hohem Eventaufkommen
- Windows Security Events mit sehr hoher Frequenz, etwa Event ID
5156 - Anwendungen, die bei Fehlern ohne Rate-Limit massenhaft Logs schreiben
- zu breit konfigurierte Windows Eventchannel-Abfragen
- FIM auf Verzeichnissen mit sehr hoher Änderungsrate
- Monitoring von Wazuh-eigenen oder rotierenden Logpfaden, die Schleifen erzeugen können
Lösung / Best Practices
Zuerst sollte nicht weiter blind die Queue vergrößert werden. Sinnvoller ist eine strukturierte Analyse des Event-Aufkommens.
Im Wazuh Dashboard kann über die Agent-Ansicht geprüft werden, welche Logquellen besonders viele Events erzeugen. Praktisch ist der Weg über die Agent-Verwaltung, den betroffenen Agent auszuwählen und die Statistiken zu prüfen. Wenn ein einzelner Kanal oder eine einzelne Quelle deutlich heraussticht, sollte dort angesetzt werden.
Falls Alerts allein nicht zeigen, welche Events den Buffer füllen, kann temporär Archive Logging aktiviert werden. Dadurch werden auch Events sichtbar, die keine Alerts auslösen.
Beispiel für JSON-Archive:
<global>
<logall_json>yes</logall_json>
</global>Nach kurzer Analysephase sollte diese Einstellung wieder deaktiviert werden, da Archive Logging sehr viele Daten erzeugen kann.
Für normale Logdateien können ignore und restrict im jeweiligen localfile-Block verwendet werden. ignore verwirft passende Einträge, restrict lässt nur passende Einträge durch. Wenn ein Event sowohl ignore als auch restrict trifft, hat ignore Vorrang.
Beispiel:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/example.log</location>
<ignore type="PCRE2">unwanted_noise_pattern</ignore>
</localfile>Oder restriktiver:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/example.log</location>
<restrict type="PCRE2">security_relevant_pattern</restrict>
</localfile>Für Windows eventchannel sollten dagegen XPath-Queries verwendet werden, da ignore und restrict für dieses Format nicht greifen.
Beispiel: bestimmte Event IDs ausschließen:
<localfile>
<location>Security</location>
<log_format>eventchannel</log_format>
<query>Event/System[EventID != 5145 and EventID != 5156]</query>
</localfile>Beispiel: nur ein bestimmtes Event sammeln:
<localfile>
<location>System</location>
<log_format>eventchannel</log_format>
<query>Event/System[EventID=7040]</query>
</localfile>Wenn die Eventrate nachweislich legitim ist, kann events_per_second moderat erhöht werden:
<client_buffer>
<disabled>no</disabled>
<queue_size>8000</queue_size>
<events_per_second>800</events_per_second>
</client_buffer>Danach muss der Agent neu gestartet werden:
systemctl restart wazuh-agentUnter Windows:
Restart-Service -Name wazuhOb der Manager selbst Events verwirft oder nicht mehr sauber verarbeitet, lässt sich zusätzlich über die State-Dateien prüfen:
cat /var/ossec/var/run/wazuh-remoted.state | egrep "discarded|dropped"
cat /var/ossec/var/run/wazuh-analysisd.state | egrep "discarded|dropped"Diese Prüfung ist wichtig, beantwortet aber eine andere Frage: Sie zeigt Manager-seitige Drops oder Verwerfungen. Die 90-Prozent-Buffer-Warnung selbst entsteht durch den Agent-seitigen Buffer.
Lessons Learned / Best Practices
Eine volle Agent-Queue ist selten nur ein Kapazitätsproblem. Meist zeigt sie, dass ein Endpoint oder eine Logquelle deutlich mehr Events erzeugt als erwartet. Deshalb sollte die Reihenfolge immer lauten: Quelle identifizieren, Ursache beheben, Sammlung einschränken, erst danach Buffer- und EPS-Werte anpassen.
Für den Betrieb empfiehlt sich:
- Agent-Statistiken regelmäßig prüfen
- laute Eventquellen frühzeitig erkennen
- Windows Eventchannel nie unnötig breit sammeln
- FIM nicht auf hochfrequent geänderte Verzeichnisse anwenden
- Archive Logging nur temporär zur Diagnose aktivieren
queue_sizeundevents_per_secondnicht pauschal erhöhen- nach jeder Änderung auf
rule.id202, 203, 204 und 205 achten
Besonders kritisch ist rule.id: 203: Ab voller Queue werden neue Events verworfen, bis wieder Platz im Buffer entsteht. Ab diesem Punkt besteht ein reales Risiko, sicherheitsrelevante Telemetrie zu verlieren.
Fazit
Die Warnung agent buffer is full at 90% sollte nicht primär durch größere Queues gelöst werden. Sie ist ein Signal, die Eventquellen des betroffenen Agents zu analysieren und unnötiges Rauschen möglichst nah an der Quelle zu reduzieren. client_buffer, events_per_second, ignore, restrict und Windows-query sind dafür die zentralen Werkzeuge. Manager-State-Dateien helfen ergänzend zu prüfen, ob zusätzlich ein serverseitiges Verarbeitungsproblem vorliegt.
Quellen
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/p1772170585803599