Wazuh Agent Log-Noise reduzieren: Grenzen von und skalierbare Alternativen für Kubernetes
Einleitung
In Kubernetes-Umgebungen können Wazuh-Agenten sehr schnell große Mengen an Container- und Applikationslogs erfassen. Werden diese ungefiltert an den Wazuh Manager weitergeleitet, steigt die Last auf wazuh-analysisd, da Parsing, Decoding und Rule-Matching zentral auf Manager-Seite stattfinden. Besonders bei vielen Microservices führt Log-Noise daher nicht nur zu unnötigen Events, sondern auch zu messbaren Performance-Problemen.
Ausgangslage / Problemstellung
Ein Agent sammelt alle Dateien unterhalb eines Log-Verzeichnisses:
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/*</location>
</localfile>
Bestimmte Dateien wie logfile2.log und logfile3.log sollen ausgeschlossen werden. Mehrere <exclude>-Einträge innerhalb desselben <localfile>-Blocks funktionieren dabei nicht wie erwartet; auch eine kommaseparierte Liste ist keine gültige Syntax.
Das eigentliche Betriebsproblem ist größer: In Kubernetes entstehen laufend neue Logdateien durch Pods und Microservices. Ohne Namenskonventionen ist eine manuelle Pflege einzelner Ausschlüsse weder stabil noch skalierbar.
Technische Analyse
Die Option <exclude> in einem Wazuh-localfile-Block ist für eine einzelne Datei oder ein Wildcard-Muster vorgesehen. Sie eignet sich gut für einfache Muster wie:
<exclude>/var/logs/e*</exclude>
oder für zusammenhängende Dateinamenbereiche:
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/*</location>
<exclude>/var/logs/logfile[2-3].log</exclude>
</localfile>
Das löst aber nur Fälle mit vorhersehbaren Dateinamen. Für dynamische Kubernetes-Logs ohne einheitliches Schema ist <exclude> kein vollwertiger dynamischer Filtermechanismus auf Dateiebene.
Wichtig ist außerdem die Architektur: Der Agent sammelt und leitet Logs weiter. Die rechenintensive Verarbeitung durch Decoder und Regeln erfolgt auf dem Manager, insbesondere durch wazuh-analysisd. Eine Regel mit Level 0 reduziert zwar Alerts, verhindert aber nicht, dass das Event den Manager erreicht und dort verarbeitet wird. Bei CPU-Problemen auf dem Manager muss der Logstrom daher möglichst vor dem Versand reduziert werden.
Lösung / Best Practices
Der bevorzugte Ansatz ist eine Include-Strategie statt einer Exclude-Strategie. Anstatt alles unter /var/logs/* zu erfassen und einzelne Dateien auszuschließen, sollten nur relevante Logquellen gezielt aufgenommen werden:
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/auth.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/app-critical-*.log</location>
</localfile>
Wenn Dateinamen teilweise gruppierbar sind, können Wildcards genutzt werden:
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/payment-*.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/security-*.log</location>
</localfile>
Wenn die Auswahl nicht zuverlässig über Dateinamen möglich ist, kann <restrict> helfen. Damit verarbeitet der Agent nur Logzeilen, die einem Muster entsprechen:
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/*</location>
<restrict type="PCRE2">ERROR|WARN|CRITICAL|SECURITY</restrict>
</localfile>
Mehrere <restrict>-Einträge im selben Block wirken restriktiv: Eine Logzeile muss alle Bedingungen erfüllen. Für Ausschlüsse auf Zeilenebene kann alternativ <ignore> verwendet werden:
<localfile>
<log_format>syslog</log_format>
<location>/var/logs/*</location>
<ignore type="PCRE2">healthcheck|readinessProbe|livenessProbe</ignore>
</localfile>
Wenn Dateiebene zwingend erforderlich ist und keine stabilen Muster existieren, ist eine vorgelagerte Filter-Schicht robuster. Ein Sidecar, DaemonSet oder Log-Router kann nur relevante Logs nach /var/wazuh-logs/ schreiben oder dort Symlinks auf freigegebene Dateien pflegen. Wazuh liest dann ausschließlich diese kuratierte Quelle:
<localfile>
<log_format>syslog</log_format>
<location>/var/wazuh-logs/*</location>
</localfile>
Ein Symlink-basierter Ansatz kann besonders nützlich sein, wenn die Entscheidung auf Dateiebene getroffen wird:
mkdir -p /var/wazuh-logs
ln -s /var/logs/app-critical.log /var/wazuh-logs/app-critical.log
ln -s /var/logs/security-events.log /var/wazuh-logs/security-events.log
Damit bleibt die Wazuh-Agent-Konfiguration stabil, während die Auswahl der tatsächlich überwachten Dateien außerhalb von Wazuh automatisiert werden kann.
Lessons Learned / Best Practices
<exclude> ist kein dynamisches Policy-System für komplexe Kubernetes-Loglandschaften. Es sollte für einfache Dateinamen oder Wildcards genutzt werden, nicht für ständig wechselnde Microservice-Logs ohne Namensstandard.
Für skalierbare Umgebungen sind drei Prinzipien entscheidend: erstens klare Namenskonventionen für relevante Logs, zweitens möglichst frühe Reduktion des Logstroms, drittens Trennung zwischen Log-Routing und SIEM-Analyse. Wazuh sollte sicherheitsrelevante Daten erhalten, nicht jeden technischen Noise aus jedem Pod.
Regeln mit Level 0 sind sinnvoll zur Alert-Unterdrückung, aber keine Performance-Lösung für überlastete Manager. Wenn wazuh-analysisd bereits durch Logvolumen ausgelastet ist, muss die Menge der eingehenden Events reduziert werden.
Fazit
Für einzelne Dateien kann <exclude> mit Wildcards oder Bereichen ausreichen. Für dynamische Kubernetes-Umgebungen ist jedoch eine Include-Strategie oder eine vorgelagerte Filter-Schicht deutlich stabiler. Wer Log-Noise bereits am Agenten oder davor reduziert, entlastet den Wazuh Manager, schützt wazuh-analysisd vor unnötiger Verarbeitung und verbessert die Skalierbarkeit der gesamten SIEM-Pipeline.
Quellen
Wazuh Dokumentation: localfile / exclude https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#exclude
Wazuh Dokumentation: localfile / restrict https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#restrict
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/C07BK5RJM3R/p1772133942646419
Quelle
Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 1. Juni 2026).
Unterstützung von m.a.x. it
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
