Wazuh log data collection from Windows, Linux and network devices

A log event in Wazuh passes through four components before it appears as an alert an analyst can search. The path starts where the event is produced. A Wazuh agent installed on a Windows or Linux endpoint reads local log sources and forwards them to the Wazuh server. A network device that cannot run an agent sends syslog to a listener, which also feeds the server. The server performs the analysis, and the Wazuh indexer, a full-text search and analytics engine, stores the resulting alerts. The Wazuh dashboard is the web interface where teams query those alerts. Each stage can fail on its own, so the team needs to know which stage to inspect when an expected alert is missing.

Analysis happens in two steps on the server. First, decoders match the incoming event and extract fields such as the source, the user or the action, depending on the log format. Second, rules evaluate those fields and decide whether the event raises an alert and at what severity. The order matters. A rule can only test fields that a decoder has produced, so the rules for a Windows event channel, a journald stream, a macOS unified log feed or a syslog source all depend on a decoder for that format matching the messages your devices actually send. Before writing custom rules, confirm which decoders ship with your release and which ones your sources need.

A missing decoder is one of the most common reasons a source appears to work but produces nothing useful. The event can reach the server and even be recorded, yet it arrives as an undecoded message with no fields a rule can read. No rule matches it, so no alert is raised. Teams should not assume the pipeline will report this condition. To test a source, send a representative event from each log type and check three things: that the event arrives, that it is decoded into the fields you expect, and that a rule raises the alert you intended. Repeat this test after every change to a source's log format, because a software update can alter messages that an existing decoder no longer matches.

Where collection settings live affects who changes them and how. The Wazuh server can run as a cluster to scale horizontally, and it manages agent configuration and upgrades remotely. Some collection behavior is therefore set centrally on the server and pushed to agents, while other settings sit on the endpoint itself. Before the build starts, decide which team owns each layer, how changes are reviewed, and how a change is tested on a small group of endpoints before wider rollout. Ask how your version applies agent configuration from the server to your endpoint groups, and confirm how a cluster node handles agents that connect to a different node.

Alerts and raw events are not the same thing, and the path described above only guarantees that alerts are searchable in the dashboard. Whether every raw event is kept, for how long and in what form is a separate decision that depends on your configuration and storage. Confirm the archive behavior in the documentation for your release before you commit to a retention or compliance position. Ask your team to answer four questions: whether unmatched events are archived, where the archive is written, who can read it, and how an investigator would search it when an alert never fired. Those answers determine whether a missing decoder can be traced later from raw data.

A custom application log usually needs a decoder and one or more rules before its events are useful in Wazuh. Without a decoder, the Wazuh server stores the raw line but cannot pull out fields such as user, source address, action or status, so rules have nothing reliable to match. Plan this work as an engineering task with its own review and testing, not as a configuration change made after the logs start arriving. The Wazuh server analyzes agent data with decoders and rules, so the decoder is the first place where a log format becomes data the platform can search and alert on.

The work starts with sampling real log lines. Collect lines from every event type the application writes, across normal operation, errors, retries and rotation, and ask the application team which fields are stable and which change between releases. For each field, decide how it will be extracted, what its name will be in the Wazuh data model, and which rule conditions will depend on it. Then map those fields to the specific rules that will raise alerts. Keep a short written table of field, source pattern, rule and owner, because this table is what the next reviewer will use to judge whether a later change is safe.

Testing needs representative lines, including malformed ones. Build a test set from sampled lines, edge cases such as empty fields, unexpected characters, truncated lines and lines from older log versions, and confirm which lines decode, which fail and which decode to wrong fields. Failing lines should be visible rather than silently dropped. Confirm the decoder syntax, the log test tooling and the rule testing procedure in the Wazuh documentation for your exact version, since these details change between releases in the 4.14 line.

Version the decoder and rule files in the same repository that holds the agent and server configuration, and deploy them through the same review path. A change to a log format can break existing decoders in ways that look healthy at first, for example when a renamed field stops matching and an alert quietly stops firing. Keep the test set under version control with the files, run it before every deployment, and record which application release each decoder version was written for. Ask whether a rollback path exists for a bad decoder, and how long it would take to restore the previous files on every server in a cluster.

The central decision is whether a source needs only the events that Wazuh rules evaluate, or the full stream of raw events kept for later use. The Wazuh server decodes incoming events and checks them against rules, and matching events become alerts stored in the Wazuh indexer. That path answers detection questions well, but an event that matches no rule is not kept as an alert. Archiving is a separate output that preserves the raw stream, which matters when the question is what happened on a host, not whether a known pattern fired. Confirm in the documentation for your release how the archive output is enabled, where the files are written, and how long they are kept before anything rotates or removes them.

Four factors usually drive the decision. The first is regulatory retention: the framework your organization is assessed against may require particular logs to be kept for a stated period. Ask your compliance lead to name the sources and the period, then check whether alerts alone would satisfy that requirement. The second is forensic need. Investigators often need events that never matched a rule, such as failed logons from a workstation that later showed suspicious activity with no alert. The third is storage growth from high-volume sources, such as busy domain controllers, verbose firewalls or Linux hosts with broad audit rules. Measure daily volume per source over a representative period before deciding. The fourth is replay. When a new rule is written, archived raw events let you test it against historical data instead of waiting for similar activity to recur.

Decide per source with a short checklist and record the answers. Who needs the raw events, and for which question? Does a stated retention requirement name this source? What is the measured daily volume over a representative period? Will a new rule need to be tested against history? Does the event contain personal or regulated data that needs restricted access? Who owns the decision, and when is it reviewed? A source can be alert-only while another is archived in full. For example, an illustrative firewall feed might be archived for forensic use while a low-value application log is kept only as alerts. Write the outcome per source so auditors and operators can see the reasoning later.

Archiving everything has costs that extend beyond disk space. Storage grows with every archived event and must be sized for the full retention period, not for the current month. Indexing load can rise if archived data is also indexed for search, so confirm in the documentation whether archive output is only stored or also loaded into the indexer for your release. Access-control scope also widens, because more raw content means more people and systems can reach sensitive fields. Apply the same role restrictions, encryption at rest and backup controls to the archive location that you apply to alerts. Ask any implementation partner to show the storage and indexing estimate for each source in writing, with the assumptions stated.