Learn Wazuh - Log Monitoring & Analysis

#Introduction

In episode 4, you successfully installed the agent and saw it appear as active in the dashboard. But that data means nothing until Wazuh actually reads, normalizes, and analyzes it. That's what we learn in this episode of the series.

Episode 5 covers log monitoring and analysis: how logcollector reads local and remote logs, how the localfile configuration works, then the complete flow from decoder, to rules, to alert. By the end of this episode, you'll be browsing events and alerts in the dashboard like a SOC analyst.

This is the episode that brings it all together — the architecture from episode 2, the server from episode 3, and the agent from episode 4 now produce real detection.

#What the Agent Collects

The Wazuh agent runs a daemon called logcollector whose single job is to read logs and forward them to the manager. By default, logcollector already reads important system files:

• /var/log/auth.log on Debian and Ubuntu.
• /var/log/messages and /var/log/secure on RPM systems.
• Windows event logs via the Windows Event Log API, in JSON format.
• Output of specific configured commands.

All these logs are sent to the manager, which processes them further. Logcollector is the main data entry point to the Wazuh platform.

#Remote Syslog Format

Besides reading local files, the Wazuh manager can also receive logs from remote devices such as firewalls and routers via remote syslog. Those devices are configured to send syslog to the manager's port 514, and the data enters the same pipeline.

sudo grep -A4 "<remote>" /var/ossec/etc/ossec.conf

The remote block on the manager side defines the protocol and port that receive syslog. With this, devices that can't have an agent installed can still be monitored — a concept you'll use in the lab with virtual devices.

#localfile Configuration in ossec.conf

Which logs the agent reads is defined by the localfile block in ossec.conf. Here's an example of adding a custom log file:

<ossec_config>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/myservice.log</location>
  </localfile>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/myapp/app.json</location>
  </localfile>
</ossec_config>

There are two important elements: location defines the file path, and log_format defines how the lines are parsed. Commonly used values:

• syslog for traditional plain-text log format.
• json for structured JSON logs, common in modern applications.
• command to collect command output periodically.
• eventlog on Windows for system event logs.

After changing ossec.conf, restart the agent so logcollector reads the new configuration. The change is applied automatically if the configuration is distributed via agent.conf.

#The Analysis Flow on the Manager

Now let's follow a single log line from the start to becoming an alert. The manager runs a layered pipeline:

log -> logcollector -> decoder -> rules -> alert -> indexer

Four key stages:

1. Logcollector on the agent reads and sends logs to the manager.
2. Decoder normalizes the log line into structured fields: who logged in, from where, what event.
3. Rules compare the decoded fields against detection patterns. If it matches a particular rule, a level and description are added.
4. Alert is generated for events that meet the threshold, then sent to the indexer for storage and searching.

It's worth emphasizing: not every event becomes an alert. Rules set the priority — a normal successful login is a different level from 10 failed login attempts in one minute. With thousands of built-in rules, Wazuh is already smart from the start, and you can add your own rules later.

#Viewing Events in the Dashboard

All of this pipeline's output can be seen in the dashboard. Open the Security events menu, then go to the Events tab — this area shows the latest alerts in real time.

A few things you can explore right away:

• The search field at the top for quick filtering.
• Alert distribution charts by rule, level, and rule group.
• The alert detail table with timestamp, rule, and description columns.
• Buttons to open the full analysis document for each alert.

Try it yourself: on the agent, fail a few logins with the wrong password, then reopen the Events page. Within seconds, an alert about repeated authentication failure will appear. That's the magic moment of a SIEM — meaningless raw logs turning into actionable warnings.

#Querying in the Indexer and Discovery

For deeper searches, the Wazuh dashboard uses Discovery, an interface that talks directly to the indexer. You can write queries like keywords in the search field to filter events.

data.win.system.eventID:4625

That query finds all Windows events with event ID 4625, which is login failure. In Discovery, you can also:

• Filter by time range with the time picker.
• Build combined queries across fields.
• Save queries for reuse.
• View the raw analysis document.

All these queries run on the data stored by the indexer — direct proof of the episode 2 architecture's power: agents collect, manager analyzes, indexer stores, dashboard presents.

#Conclusion

Episode 5 is complete, and so is the entire Learn Wazuh series. You've traveled the full journey: preparing the lab, understanding history and architecture, installing the all-in-one server, deploying the agent, and analyzing logs and viewing alerts in the dashboard.

Key takeaways:

• Logcollector is the data entry point: local logs, remote syslog, and Windows event logs.
• The localfile block in ossec.conf defines which files are read and their format.
• The analysis pipeline runs: decoder normalizes, rules evaluate, alerts are generated.
• Not every event becomes an alert — rules set the priority and level.
• The dashboard Events page shows real-time alerts, and Discovery enables deep queries.
• The JSON format makes analysis easier because fields are structured right away.

Your journey doesn't stop here. Start by adding your own rules, applying active response to block suspicious IPs, and trying the compliance modules. Happy exploring in the world of SIEM and XDR — see you in the next series!