Wazuh Log Management: What Logs to Collect

Why a Log Strategy Comes Before Collection

Wazuh is an open-source security platform that combines SIEM and XDR capabilities. It analyses logs in real time through decoders and rules, runs file integrity monitoring (FIM), performs vulnerability detection, and triggers active response. Every one of those capabilities depends on the right logs arriving at the manager in the first place.

The most common Wazuh deployment mistake is collecting either too little or too much. Collect too little and the rules engine has nothing to alert on, so genuine intrusions produce silence. Collect everything indiscriminately and the indexer fills with low-value events that inflate storage cost, slow searches and bury real alerts under noise.

A log strategy answers three questions before any agent is installed: what are we trying to detect, which sources contain that evidence, and what volume will those sources generate. Answering them up front turns log management from an afterthought into a deliberate engineering decision that the rest of the SOC depends on.

Agent vs Agentless Collection

Wazuh supports two collection models. The Wazuh agent is a lightweight process installed on Windows, Linux, macOS, Solaris, AIX and HP-UX endpoints. It reads local log files and event channels, runs FIM and rootcheck, performs security configuration assessment (SCA), and forwards everything to the manager over an encrypted channel on port 1514. The agent is the preferred method because it gives the richest telemetry and supports active response back to the endpoint.

Agentless collection covers everything that cannot run an agent: network firewalls, switches, routers, hypervisors, printers, and many appliances. These devices forward events to the Wazuh manager (or a dedicated collector) over syslog, typically UDP or TCP port 514. The manager ingests the stream through its remote syslog configuration and processes it with the same decoders and rules pipeline used for agent data.

Wazuh also ingests data through API-based integrations rather than syslog. Cloud sources such as AWS CloudTrail, Azure, Google Cloud, Office 365 and GitHub are pulled through dedicated modules configured on the manager. The vulnerability detection and CIS-benchmark SCA modules generate their own telemetry from agent inventory data.

The practical rule is simple: install the agent wherever you can, fall back to syslog for network and appliance devices, and use the cloud integration modules for SaaS and cloud platform logs.

Windows Log Sources Worth Collecting

On Windows endpoints the Wazuh agent reads Event Log channels directly using the eventchannel log format, which is far more efficient than the legacy eventlog format and preserves the full structured XML of each event.

The channels that earn their keep are the Security channel (logon and logoff, account management, privilege use, object access, policy change), the System channel (service installs, driver and time changes), the Application channel, and the Microsoft-Windows-PowerShell/Operational channel for script-block and module logging. PowerShell logging in particular catches a large share of modern fileless attacks.

For deeper visibility, deploy Sysmon and collect the Microsoft-Windows-Sysmon/Operational channel. Sysmon adds process creation with full command lines and hashes, network connections, image loads, file creation and registry changes. Wazuh ships decoders and rules for Sysmon, and the combination underpins most credible Windows threat detection.

Linux and Application Log Sources

On Linux the agent collects logs through the localfile configuration in the agent ossec.conf or, better, pushed centrally from the manager. The essentials are the authentication log (/var/log/auth.log or /var/log/secure) for SSH and sudo activity, the system log, and the auditd stream for syscall-level visibility into command execution and file access.

Application logs matter as much as operating system logs. Collect web server access and error logs (Nginx, Apache), database logs, reverse proxy and WAF logs, and application logs from your own services. Web access logs are the primary evidence for web attacks, credential stuffing and reconnaissance, and Wazuh has decoders for the common web server formats.

Wazuh can also run commands periodically through the command and full_command modules and treat the output as a log source. This is useful for collecting state that is not written to a file, such as listening ports, loaded kernel modules or the output of a custom script.

Signal Versus Noise: What to Leave Out

Not every log deserves a place in the indexer. High-volume, low-value sources, such as verbose debug logging, successful health-check probes, repetitive load-balancer pings and chatty application info messages, can dominate ingestion while contributing almost nothing to detection.

Wazuh gives you several levers to control noise. At the source you can configure the application to log at an appropriate level. In the pipeline you can write rules that match expected, benign patterns and set them to a low level so they are recorded but never alert, or use rule options to discard known-noise events before they consume an alert slot. The manager also de-duplicates and correlates through composite and frequency rules so that a thousand identical failures become one meaningful alert.

A useful discipline is to separate the events you store from the events you alert on. You may keep web access logs for forensic and compliance reasons while only alerting on the subset that matches attack signatures. The decision about what to alert on belongs to the rules; the decision about what to retain belongs to the storage strategy.

Sizing Ingestion: EPS and GB per Day

Before production you should estimate two numbers for every source: events per second (EPS) and gigabytes per day. EPS drives manager and indexer CPU sizing; gigabytes per day drives storage and retention planning. The two together tell you whether a single-node deployment is enough or whether a distributed cluster is required.

A workable estimation method is to sample real volume. Onboard a representative server, let it run for 24 hours, and read the actual event count and index size from the Wazuh dashboard. Multiply by the number of similar endpoints and add headroom for peak activity and incident bursts, which can be several times the baseline.

As a rough planning anchor, a typical Windows server with Sysmon can generate tens of millions of events per day, while a quiet Linux server might produce a few hundred thousand. Network devices vary enormously with traffic. Always plan for growth: estimate at current volume, then size the cluster and storage with comfortable margin so the deployment does not need re-architecting six months later.

Once you have the per-day volume, the next decisions, how long to keep data and on what storage tier, belong to the retention and storage strategy. Sizing ingestion is the input to that plan.