Log monitoring is one of the primary reasons organizations deploy Wazuh. Whether you’re collecting Linux system logs, Windows Event Logs, web server logs, firewall events, or application logs, Wazuh relies on a flexible configuration file called ossec.conf to determine what data should be collected, how it should be monitored, and where it should be sent for analysis.

The ossec.conf file acts as the central configuration file for both Wazuh agents and managers.

It controls numerous platform features, but one of its most important responsibilities is configuring the Logcollector module, which continuously watches log sources for new events.

Every log that eventually becomes a security alert begins with a correctly configured ossec.conf file.

Proper log monitoring configuration has a direct impact on your organization’s visibility and detection capabilities.

Conversely, collecting unnecessary logs can increase storage requirements, consume additional CPU resources, and generate excessive false positives.

Security monitoring experts consistently emphasize that comprehensive logging is the foundation of effective threat detection.

The MITRE ATT&CK framework identifies log collection and monitoring as critical components for detecting adversary behavior across the attack lifecycle.

Throughout this guide, you’ll learn:

What ossec.conf is and how it works.
How Wazuh collects logs from different operating systems.
The most important log monitoring configuration options.
How to monitor custom application logs.
Best practices for optimizing performance.
Common mistakes to avoid.
How to validate your configuration after making changes.

By the end of this tutorial, you’ll understand how to configure ossec.conf for reliable, efficient, and scalable log monitoring in virtually any Wazuh deployment.

Related Guides:

What Is ossec.conf in Wazuh?

The ossec.conf file is Wazuh’s primary XML configuration file.

Nearly every major Wazuh component, including log collection, File Integrity Monitoring (FIM), vulnerability detection, active response, agent communication, cluster settings, and integrations, is configured through this single file.

Although Wazuh has evolved significantly from its OSSEC origins, it continues to use the ossec.conf filename for compatibility and consistency across the platform.

Purpose of the Configuration File

The primary purpose of ossec.conf is to define how Wazuh behaves.

Within this file, administrators specify:

Which logs should be monitored
Which Windows Event Channels should be collected
How often certain modules run
Network communication settings
Agent enrollment options
Security modules to enable or disable
Integration settings
Performance tuning options

Rather than hardcoding behavior into the application, Wazuh reads its operational settings from ossec.conf during startup.

Role in Wazuh Manager vs Wazuh Agent

Although both the manager and agents use an ossec.conf file, their responsibilities differ.

On the Wazuh Agent

The configuration primarily defines:

Local log collection
Windows Event monitoring
Journald monitoring
File Integrity Monitoring
Local command execution
Agent communication with the manager

In most deployments, the agent is responsible for gathering raw telemetry from the endpoint.

On the Wazuh Manager

The manager’s ossec.conf focuses on:

Receiving events from agents
Syslog listener configuration
Integrations
Active Response
Cluster configuration
Global settings
API-related modules
Centralized management

Think of the agent as the collector and the manager as the processor.

Default File Locations

The configuration file location depends on the operating system and deployment method.

Linux

Default location:

/var/ossec/etc/ossec.conf

This applies to most supported Linux distributions including:

Ubuntu
Debian
Rocky Linux
AlmaLinux
CentOS
Red Hat Enterprise Linux

Windows

Default location:

C:\Program Files (x86)\ossec-agent\ossec.conf

or on newer versions:

C:\Program Files\ossec-agent\ossec.conf

depending on the installation architecture.

Docker Deployments

Docker deployments typically mount the configuration from the host into the container.

Common location:

/var/ossec/etc/ossec.conf

inside the container.

Administrators often map this directory using Docker volumes so configuration persists after container recreation.

Related Guide: Fix Wazuh Docker Compose Deployment

XML Structure Overview

The ossec.conf file is written using XML.

The root element is:

<ossec_config>

Inside it are individual module sections.

Example:

<ossec_config>

  <localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
  </localfile>

  <syscheck>
    ...
  </syscheck>

  <client>
    ...
  </client>

</ossec_config>

Each module has its own XML block with child elements that define its behavior.

For log monitoring, the most important section is:

<localfile>

Each <localfile> block tells Wazuh:

Which log to monitor
What format it uses
Optional filters
Optional labels
Advanced processing options

Multiple <localfile> sections can be defined within the same configuration.

How Wazuh Loads Configuration Changes

Wazuh does not automatically reload ossec.conf after modifications.

Whenever you update the file, the affected Wazuh service must typically be restarted.

For Linux agents:

sudo systemctl restart wazuh-agent

For the manager:

sudo systemctl restart wazuh-manager

On Windows:

Restart the Wazuh Agent service through Services or PowerShell.

A good practice is to validate your XML before restarting to avoid syntax errors that prevent services from starting.

For production environments, experienced Wazuh administrators recommend testing configuration changes in staging before deploying them widely, especially when managing hundreds or thousands of agents through centralized configuration.

Understanding How Wazuh Log Monitoring Works

Before configuring ossec.conf, it’s helpful to understand the path a log takes from its source to a security alert.

Wazuh’s log monitoring pipeline is designed to continuously collect events from multiple sources, normalize them, forward them to the manager, and evaluate them against thousands of built-in detection rules.

Each stage of this workflow can be customized through ossec.conf, making it possible to monitor everything from operating system logs to custom application events.

Log Collection Workflow

A simplified workflow looks like this:

Log Source
      │
      ▼
Wazuh Logcollector
      │
      ▼
Local Event Processing
      │
      ▼
Encrypted Agent Communication
      │
      ▼
Wazuh Manager
      │
      ▼
Decoder
      │
      ▼
Rules Engine
      │
      ▼
Alert
      │
      ▼
Indexer
      │
      ▼
Dashboard

This modular architecture allows Wazuh to support many different log formats while applying a consistent detection pipeline.

Reading Local Log Files

The most common use case is monitoring text-based log files.

Examples include:

/var/log/auth.log
/var/log/syslog
/var/log/messages
Apache logs
Nginx logs
Application logs
Database logs
Custom software logs

Logcollector continuously watches these files for newly appended entries rather than rereading the entire file after every change, making monitoring highly efficient even for large logs.

Related Guide: How to Monitor Apache Logs with Wazuh

Monitoring Windows Event Logs

On Windows systems, Wazuh integrates directly with the Windows Event Log API instead of monitoring flat log files.

Common event channels include:

Security
System
Application
Microsoft-Windows-Sysmon
PowerShell
Windows Defender

Each monitored event is converted into a standardized event before being forwarded to the manager.

This native integration provides richer metadata than exporting events into text files and supports filtering specific channels directly within ossec.conf.

Related Guides: How to Monitor Windows Event Logs Using Wazuh

Journald Integration

Modern Linux distributions frequently rely on systemd-journald instead of traditional text-based log files.

Wazuh supports collecting logs directly from Journald, allowing administrators to monitor services whose logs never appear in /var/log.

This approach is especially useful for:

Fedora
Ubuntu
Debian
Rocky Linux
Containerized workloads
Modern cloud images

Reading directly from Journald preserves structured metadata such as service names, priorities, process IDs, and timestamps.

Command Output Monitoring

Wazuh can also execute commands at scheduled intervals and treat their output as log data.

Examples include:

Network connection listings
Running processes
Installed packages
Disk usage
Custom security scripts
Cloud CLI outputs

This capability extends monitoring beyond traditional log files, enabling administrators to collect valuable operational and security information from virtually any command-line tool.

Event Forwarding to the Manager

After an event is collected, the agent packages it and securely forwards it to the Wazuh manager using encrypted communication.

The manager receives events from all enrolled agents, allowing organizations to centralize logs from:

Linux servers
Windows workstations
macOS systems
Cloud instances
Containers
Network devices

Centralization simplifies correlation across multiple systems and provides a unified view of security activity.

Rule Matching and Alert Generation

Once the manager receives an event, it passes through two major processing stages:

Decoders, which extract structured fields such as usernames, IP addresses, file paths, process names, and event IDs.
Rules, which compare the decoded event against thousands of built-in and custom detection rules to determine whether an alert should be generated.

Only after successful decoding and rule evaluation does the event appear in the Wazuh Dashboard as an alert.

This layered architecture helps reduce noise while enabling highly granular detection logic.

As security engineer and Wazuh contributor discussions frequently emphasize in the Wazuh community, high-quality log collection is only half of the equation, accurate decoders and well-tuned rules are what transform raw events into actionable security intelligence.

Related Guides:

Understanding the `<localfile>` Section

The <localfile> block is the foundation of log monitoring in Wazuh.

Every log source that Wazuh monitors, whether it’s a Linux log file, a Windows Event Log channel, a macOS log, or the output of a command, is defined using one or more <localfile> sections inside ossec.conf.

Each <localfile> entry tells the Logcollector module:

Where the log source is located
What type of log it is
How the log should be interpreted
Whether additional filtering or metadata should be applied

Without at least one properly configured <localfile> block, Wazuh has no instructions for collecting logs from the local system.

What `<localfile>` Does

The Logcollector module continuously monitors each configured source for new events.

Depending on the configuration, it can collect data from:

Plain text log files
Rotating log files
Windows Event Logs
systemd Journald
macOS logs
Named pipes
Command output
Custom application logs

Unlike traditional polling solutions, Wazuh keeps track of its reading position so it only processes newly added log entries instead of rereading the entire file each time.

This minimizes disk I/O and improves scalability, especially on busy production servers.

Required Configuration Elements

At a minimum, every <localfile> block requires two settings.

`<location>`

Specifies the path or source to monitor.

Examples:

<location>/var/log/auth.log</location>

<location>Security</location>

Depending on the platform, the location may represent:

A file path
A Windows Event Log channel
Journald
A command
A named pipe

`<log_format>`

Defines how Wazuh should interpret incoming events.

Common values include:

syslog
json
apache
iis
eventchannel
journald
command
audit
multi-line

Choosing the correct log format allows Wazuh’s decoders to properly parse the data.

For example:

<log_format>syslog</log_format>

Optional Configuration Elements

Several optional settings provide more advanced functionality.

Some of the most commonly used include:

Element	Purpose
`<alias>`	Assigns a friendly name to the log source
`<label>`	Adds custom metadata to collected events
`<query>`	Filters Windows Event Logs
`<frequency>`	Specifies how often commands execute
`<command>`	Executes a command and captures its output
`<ignore_binaries>`	Prevents binary files from being processed
`<only-future-events>`	Ignores older events when monitoring begins

These options are especially useful when monitoring complex environments or enriching log data before it reaches the manager.

Multiple `<localfile>` Entries

Most production deployments contain many <localfile> sections.

For example:

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/nginx/access.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/myapp/application.log</location>
    <log_format>json</log_format>
</localfile>

Each block is processed independently.

This modular design makes it easy to:

Add new log sources
Remove obsolete ones
Organize configurations
Troubleshoot individual log sources

Large deployments commonly define dozens, or even hundreds, of <localfile> entries through centralized agent configuration.

Processing Order

Although <localfile> entries are generally evaluated in the order they appear, each monitored source operates independently once Logcollector starts.

In practice:

Wazuh loads every <localfile> definition during startup.
A monitoring thread is created for each source.
New events are collected as they arrive.
Events are forwarded to the manager for decoding and rule evaluation.

Because monitoring occurs concurrently, administrators usually organize <localfile> entries for readability rather than performance.

A common convention is grouping entries by category:

Operating system logs
Security logs
Web server logs
Database logs
Application logs

This makes future maintenance significantly easier.

Example XML Configuration

The following example demonstrates monitoring multiple log sources using separate <localfile> blocks:

<ossec_config>

  <localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/var/log/nginx/access.log</location>
    <log_format>syslog</log_format>
  </localfile>

</ossec_config>

This configuration instructs Wazuh to monitor three independent log files simultaneously.

Configuring Log File Monitoring

Most Wazuh deployments begin by monitoring operating system and application log files.

Linux systems generate logs for authentication, kernel events, services, web servers, databases, and custom applications, all of which can provide valuable security and operational insights.

Each log source is configured by defining a separate <localfile> block within ossec.conf.

Monitoring Linux Log Files

Different Linux distributions store logs in different locations, so you’ll typically configure only the files that exist on your systems.

`/var/log/syslog`

Common on:

Ubuntu
Debian

Contains:

System events
Service messages
Kernel logs
Authentication events
Cron activity

Example:

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

`/var/log/messages`

Common on:

CentOS
Rocky Linux
AlmaLinux
Red Hat Enterprise Linux

Contains general system messages generated by the operating system and installed services.

Example:

<localfile>
    <location>/var/log/messages</location>
    <log_format>syslog</log_format>
</localfile>

`/var/log/auth.log`

One of the most important security logs on Debian-based systems.

Records events such as:

SSH logins
Failed login attempts
Sudo commands
Authentication failures
PAM activity

Example:

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

`/var/log/secure`

Equivalent to auth.log on Red Hat-based systems.

Contains:

SSH authentication
Sudo usage
Login attempts
Privilege escalation events

Configuration:

<localfile>
    <location>/var/log/secure</location>
    <log_format>syslog</log_format>
</localfile>

Apache Logs

Apache typically generates:

Access logs
Error logs

These logs help detect:

Web attacks
Directory traversal attempts
Brute-force attacks
Suspicious HTTP requests

Example:

<localfile>
    <location>/var/log/apache2/access.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/apache2/error.log</location>
    <log_format>syslog</log_format>
</localfile>

Related Guide: How to Monitor Apache Logs with Wazuh

Nginx Logs

Nginx deployments usually include:

Access logs
Error logs

Example:

<localfile>
    <location>/var/log/nginx/access.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/nginx/error.log</location>
    <log_format>syslog</log_format>
</localfile>

Monitoring these logs helps identify malicious requests, scanning activity, and application errors.

Application Logs

Custom applications often store logs in directories such as:

/opt/myapp/logs/
/var/log/myapp/
/srv/application/logs/

If the application produces JSON logs, configure the appropriate format.

Example:

<localfile>
    <location>/opt/myapp/logs/application.log</location>
    <log_format>json</log_format>
</localfile>

JSON log monitoring enables Wazuh to parse structured fields more accurately than plain text logs.

Example Configuration

A production Linux server may monitor several log sources simultaneously:

<ossec_config>

  <localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/var/log/nginx/access.log</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/opt/myapp/logs/application.log</location>
    <log_format>json</log_format>
  </localfile>

</ossec_config>

This configuration collects operating system, authentication, web server, and application logs, providing broad visibility into server activity.

Monitoring Windows Event Logs

Unlike Linux, Windows stores most security and operating system events in structured Event Log channels rather than flat text files.

Wazuh integrates directly with the Windows Event Log API, allowing it to collect rich event metadata without requiring exported log files.

To monitor a Windows Event Log channel, set the <location> value to the channel name and specify the eventchannel log format.

Security

The Security channel is the most important Windows log for security monitoring.

It contains:

Successful logons
Failed logons
Account lockouts
Privilege escalation
Group membership changes
Audit policy events

Configuration:

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

System

The System channel records operating system events such as:

Driver failures
Service starts
Shutdowns
Hardware issues
Kernel events

Configuration:

<localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
</localfile>

Application

The Application log contains events generated by installed software.

Examples include:

Database errors
IIS messages
.NET exceptions
Backup software logs
Third-party applications

Configuration:

<localfile>
    <location>Application</location>
    <log_format>eventchannel</log_format>
</localfile>

Microsoft-Windows Channels

Many Microsoft services publish dedicated event channels.

Examples include:

Microsoft-Windows-Sysmon/Operational
Microsoft-Windows-PowerShell/Operational
Microsoft-Windows-Windows Defender/Operational
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Example:

<localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
</localfile>

Monitoring Sysmon events significantly enhances endpoint visibility.

Security researcher Mark Russinovich, creator of Sysinternals and Sysmon, designed Sysmon specifically to provide detailed telemetry for threat detection that is not available in default Windows logging.

Custom Event Channels

Third-party software can create additional Event Log channels.

Examples include:

SQL Server
Exchange Server
VMware
CrowdStrike
Microsoft Defender for Identity
Custom enterprise applications

Simply reference the channel name:

<localfile>
    <location>MyApplication/Operational</location>
    <log_format>eventchannel</log_format>
</localfile>

Example Configuration

A Windows endpoint monitoring several channels may use:

<ossec_config>

  <localfile>
      <location>Security</location>
      <log_format>eventchannel</log_format>
  </localfile>

  <localfile>
      <location>System</location>
      <log_format>eventchannel</log_format>
  </localfile>

  <localfile>
      <location>Application</location>
      <log_format>eventchannel</log_format>
  </localfile>

  <localfile>
      <location>Microsoft-Windows-Sysmon/Operational</location>
      <log_format>eventchannel</log_format>
  </localfile>

</ossec_config>

This configuration provides excellent visibility into authentication, operating system activity, application behavior, and advanced endpoint telemetry.

Monitoring macOS Logs

macOS uses a combination of Apple’s Unified Logging framework and traditional text-based log files.

Wazuh supports monitoring both, allowing organizations to collect security events from Apple endpoints alongside Windows and Linux systems.

Unified Logging

Modern versions of macOS rely heavily on Apple’s Unified Logging system.

Unlike traditional log files, Unified Logging stores structured events in a centralized database.

Common sources include:

System services
Applications
Security events
Kernel messages
Network activity

Wazuh can collect these logs using supported command-based or system integrations, depending on the deployment and macOS version.

Traditional Log Files

Some applications continue to write plain text logs.

Common locations include:

/var/log/system.log
/Library/Logs/
/private/var/log/
Application-specific log directories

Configuration follows the same <localfile> syntax used on Linux:

<localfile>
    <location>/var/log/system.log</location>
    <log_format>syslog</log_format>
</localfile>

Best Practices

When monitoring macOS systems:

Prioritize security-related logs over verbose application logs.
Monitor Unified Logging where supported to capture richer event data.
Use JSON log formats when applications provide structured output.
Regularly review log volume to avoid unnecessary storage consumption.
Validate configurations after macOS upgrades, as logging behavior may change between releases.

For mixed environments, maintaining consistent logging policies across Linux, Windows, and macOS endpoints helps ensure comprehensive visibility and simplifies correlation within the Wazuh manager.

The official Apple Platform Security documentation also recommends leveraging Unified Logging for system diagnostics and security investigations.

Monitoring Multiple Log Files

Most production environments generate logs from dozens of different sources.

A single Linux server might produce operating system logs, authentication logs, web server logs, database logs, container logs, and custom application logs simultaneously.

Fortunately, Wazuh allows you to monitor as many log sources as needed by defining multiple <localfile> blocks within ossec.conf.

Each <localfile> block operates independently, making it easy to expand your monitoring configuration as your infrastructure grows.

Multiple `<localfile>` Blocks

Every log source should have its own <localfile> entry.

For example, a web server may monitor:

System logs
Authentication logs
Apache access logs
Apache error logs
Application logs
Database logs

Each source is configured separately:

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/apache2/access.log</location>
    <log_format>syslog</log_format>
</localfile>

Adding additional log sources is as simple as creating another <localfile> block.

Organizing Configurations

As the number of monitored logs grows, the ossec.conf file can become difficult to maintain.

A good practice is to group related log sources together.

For example:

Operating system logs
Authentication logs
Web server logs
Database logs
Container logs
Custom applications

Adding XML comments also improves readability:

<!-- Operating System Logs -->

<!-- Web Server Logs -->

<!-- Application Logs -->

Well-organized configurations reduce troubleshooting time and simplify future maintenance.

Avoiding Duplicate Monitoring

One common mistake is monitoring the same log file multiple times.

For example:

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

This configuration can result in duplicate events being forwarded to the manager, leading to:

Duplicate alerts
Increased storage usage
Higher CPU utilization
More difficult investigations

Similarly, avoid monitoring both a raw application log and the same events after they have already been forwarded into syslog unless duplicate ingestion is intentional.

Performance Considerations

Monitoring additional logs naturally increases resource usage.

Factors that affect performance include:

Number of monitored files
Event generation rate
Log size
Parsing complexity
Network bandwidth
Rule processing on the manager

To maintain good performance:

Monitor only logs that provide security or operational value.
Remove obsolete log sources.
Prefer structured logs (such as JSON) where possible.
Avoid monitoring temporary or debug logs in production.

According to the Wazuh documentation, reducing unnecessary data collection improves overall scalability and helps the rules engine focus on meaningful events.

Example Configuration

The following configuration monitors several common log sources:

<ossec_config>

    <!-- Operating System -->
    <localfile>
        <location>/var/log/syslog</location>
        <log_format>syslog</log_format>
    </localfile>

    <!-- Authentication -->
    <localfile>
        <location>/var/log/auth.log</location>
        <log_format>syslog</log_format>
    </localfile>

    <!-- Web Server -->
    <localfile>
        <location>/var/log/nginx/access.log</location>
        <log_format>syslog</log_format>
    </localfile>

    <!-- Application -->
    <localfile>
        <location>/opt/myapp/application.log</location>
        <log_format>json</log_format>
    </localfile>

</ossec_config>

Using Different Log Formats

The <log_format> setting tells Wazuh how to interpret incoming data.

Choosing the correct format is critical because it determines which decoders are used and how fields are extracted for rule matching.

Different log sources require different formats.

`syslog`

The syslog format is the most commonly used option.

Typical sources include:

Linux system logs
Authentication logs
Network devices
Firewalls
Apache
Nginx

Example:

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

`json`

Many modern applications produce structured JSON logs.

Examples include:

Docker applications
Kubernetes workloads
Cloud-native services
REST APIs
Custom software

Example:

<localfile>
    <location>/opt/myapp/application.json</location>
    <log_format>json</log_format>
</localfile>

JSON enables Wazuh to extract individual fields without relying on complex regular expressions.

`eventchannel`

Used exclusively for Windows Event Logs.

Example:

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

This format interfaces directly with the Windows Event Log API.

`command`

The command format periodically executes a command and captures its output.

Example:

<localfile>
    <command>netstat -tulpn</command>
    <log_format>command</log_format>
    <frequency>300</frequency>
</localfile>

This runs every five minutes.

Useful for monitoring:

Running processes
Network connections
Disk usage
Installed packages

`full_command`

Unlike command, the full_command format treats the entire command output as a single event rather than splitting it into individual lines.

Example:

<localfile>
    <command>ps aux</command>
    <log_format>full_command</log_format>
    <frequency>600</frequency>
</localfile>

This is useful when downstream decoders expect the complete output.

Multi-Line Logs

Some applications generate events spanning multiple lines.

Examples include:

Java stack traces
Python exceptions
.NET exceptions

Example:

<localfile>
    <location>/opt/app/error.log</location>
    <log_format>multi-line</log_format>
</localfile>

Grouping related lines into a single event preserves context and improves detection accuracy.

Custom Application Logs

If an application produces plain text logs that don’t match a predefined format, Wazuh can still collect them.

Example:

<localfile>
    <location>/opt/application/logs/security.log</location>
    <log_format>syslog</log_format>
</localfile>

If the log format is unique, you may also need to create a custom decoder.

Monitoring Custom Application Logs

Many of the most valuable security events originate from internally developed applications rather than the operating system.

Wazuh can monitor virtually any application log, provided the application writes events to a file or another supported log source.

Java Applications

Java applications commonly use logging frameworks such as:

Logback
Log4j 2
java.util.logging

Typical log location:

/opt/application/logs/application.log

Example:

<localfile>
    <location>/opt/application/logs/application.log</location>
    <log_format>syslog</log_format>
</localfile>

Python Applications

Python applications often log using the built-in logging module.

Example:

<localfile>
    <location>/var/log/python-app/app.log</location>
    <log_format>syslog</log_format>
</localfile>

If the application outputs JSON:

<log_format>json</log_format>

is usually the better choice.

Node.js Applications

Node.js applications frequently generate JSON logs through libraries such as Winston or Pino.

Example:

<localfile>
    <location>/srv/nodejs/logs/application.json</location>
    <log_format>json</log_format>
</localfile>

Structured logging generally results in more accurate field extraction and easier correlation.

Docker Container Logs

Docker stores container logs by default in:

/var/lib/docker/containers/

However, many organizations instead forward container logs to:

journald
Fluent Bit
Filebeat
Syslog

Monitoring the centralized destination is usually preferable to watching individual container log files because container IDs and file paths change frequently.

Related Guide: How to Monitor Kubernetes Using Wazuh

Custom Enterprise Software

Many commercial and in-house applications generate audit logs containing:

User logins
Administrative actions
Configuration changes
API requests
Failed authentication attempts

These logs often contain high-value security information and should be included in your monitoring strategy whenever possible.

Example Configurations

Monitoring several custom applications might look like this:

<localfile>
    <location>/opt/java/logs/application.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/srv/python/api.log</location>
    <log_format>json</log_format>
</localfile>

<localfile>
    <location>/srv/node/logs/access.json</location>
    <log_format>json</log_format>
</localfile>

This configuration enables Wazuh to collect telemetry from multiple application stacks using the most appropriate parser for each log source.

Monitoring Rotating Log Files

Most production systems rotate logs regularly to prevent them from consuming excessive disk space.

Utilities such as logrotate rename, compress, archive, and recreate log files automatically.

Wazuh’s Logcollector is designed to handle these changes with minimal interruption, allowing continuous monitoring even after a rotation occurs.

How Wazuh Detects Rotated Logs

Rather than monitoring only a filename, Wazuh tracks the underlying file so it can recognize when a log has been rotated and a new file has been created.

This allows Logcollector to:

Continue reading the old file until all pending entries have been processed.
Detect the newly created log.
Resume monitoring automatically.

In most cases, no manual intervention is required.

logrotate Integration

On Linux, log rotation is commonly managed by logrotate.

A typical rotation process:

Rename the current log.
Create a new empty log.
Compress older logs.
Delete expired archives.

Because Wazuh is designed to work with standard rotation behavior, it integrates seamlessly with most logrotate configurations.

Preventing Duplicate Events

Improper rotation settings or manual file copying can occasionally lead to duplicate ingestion.

To reduce the risk:

Avoid copying active logs.
Rotate using rename operations instead of copy-and-truncate where possible.
Verify applications reopen log files after rotation.
Test custom rotation scripts before production deployment.

Common Rotation Issues

Administrators occasionally encounter issues such as:

Missing events after rotation
Duplicate events
Permission problems
Incorrect ownership on new log files
Applications continuing to write to renamed files

These problems are usually caused by the logging application or the rotation configuration rather than Wazuh itself.

Best Practices

To ensure reliable monitoring:

Use standard logrotate configurations whenever possible.
Maintain consistent file permissions after rotation.
Avoid manually deleting active log files.
Test rotation behavior after deploying new applications.
Periodically verify that Wazuh continues receiving events following scheduled rotations.

These practices help ensure uninterrupted visibility while minimizing the risk of missed or duplicated events.

Filtering Logs Before Processing

Collecting every available log is rarely the best approach.

Excessive logging increases storage consumption, CPU utilization, network traffic, and alert fatigue without necessarily improving security.

Filtering logs before they are processed helps ensure that Wazuh focuses on high-value events.

Ignoring Unnecessary Logs

Not every log deserves continuous monitoring.

Examples that are often excluded include:

Temporary debug logs
Installer logs
Highly verbose development logs
Test application output
Transient cache logs

Reducing low-value telemetry allows the rules engine to spend more time analyzing meaningful events.

Restricting Monitored Files

Only monitor files that support your security, compliance, or operational objectives.

For example:

Monitor:

Authentication logs
Audit logs
Administrative activity
Security software
Web server access logs

Avoid monitoring:

Temporary directories
Backup files
Rotated archives
Application cache files

A focused monitoring strategy is easier to maintain and troubleshoot.

Reducing Noise

Excessive event volume can make genuine threats harder to identify.

Methods for reducing noise include:

Monitoring only required Event Log channels.
Collecting production logs instead of debug logs.
Using structured JSON logs where available.
Creating custom rules to suppress known benign activity.

Related Guide: How to Reduce False Positives in Wazuh

Improving Performance

Filtering unnecessary log sources provides several measurable benefits:

Lower CPU usage on agents
Reduced network bandwidth consumption
Smaller index sizes
Faster searches
Improved dashboard responsiveness
Better rule evaluation performance

Security practitioners, including those contributing to guidance from the Center for Internet Security (CIS), emphasize collecting logs that support detection and compliance objectives while avoiding excessive, low-value telemetry that can overwhelm analysts.

Performance Best Practices

A well-designed log monitoring configuration should provide comprehensive visibility without overwhelming your Wazuh infrastructure.

Collecting every available log may seem like the safest approach, but it often leads to increased CPU usage, higher storage requirements, excessive network traffic, and alert fatigue.

The following best practices help maximize detection capabilities while maintaining good performance.

Monitor Only Required Logs

Start by identifying the log sources that provide meaningful security or operational value.

Common high-priority logs include:

Authentication logs
Operating system logs
Firewall logs
Web server logs
Database audit logs
Security software logs
Critical application logs

Avoid monitoring logs that rarely contain actionable information, such as temporary debugging files or verbose development logs.

Collecting fewer, higher-quality events generally produces better detection results than collecting everything indiscriminately.

Avoid Duplicate Configurations

Each log source should be monitored only once.

Duplicate <localfile> entries can result in:

Duplicate alerts
Higher CPU usage
Increased index size
Additional network traffic
More difficult investigations

Before adding a new <localfile> block, verify that the same log isn’t already being collected elsewhere.

This is particularly important in environments that forward logs through Syslog, Fluent Bit, Filebeat, or Logstash.

Separate High-Volume Logs

Some applications generate thousands of events per minute.

Examples include:

Reverse proxies
Load balancers
DNS servers
Web servers
Kubernetes clusters
API gateways

Rather than enabling every available log, focus on the ones most useful for security monitoring.

For example:

Monitor Apache error logs continuously.
Monitor access logs when detecting attacks is required.
Avoid collecting verbose debugging logs unless actively troubleshooting.

This reduces unnecessary processing while preserving important security telemetry.

Monitor Archive Directories Carefully

Avoid monitoring directories that contain archived or compressed logs.

Examples include:

/var/log/archive/
/var/log/old/
/var/log/*.gz

Monitoring archived logs can lead to:

Duplicate ingestion
Large bursts of historical events
Unnecessary CPU consumption
Increased disk I/O

Instead, monitor only the active log file generated by the application.

Reduce Unnecessary Command Executions

If you’re using the command or full_command log formats, avoid executing expensive commands too frequently.

For example, running large inventory or process-listing commands every few seconds can significantly increase CPU utilization.

Instead:

Increase the <frequency> interval.
Limit command output where possible.
Execute only commands that provide useful security information.

This reduces system overhead while maintaining visibility.

Balance Detection and Performance

An effective Wazuh deployment balances visibility with efficiency.

Ask yourself:

Does this log improve threat detection?
Will anyone investigate alerts generated from it?
Is the log excessively verbose?
Can the same information be obtained from another source?

Security engineers generally recommend prioritizing high-value telemetry over raw log volume.

High-quality logs combined with well-tuned detection rules typically produce better results than simply collecting more data.

Test Before Production Deployment

Before deploying changes across hundreds or thousands of endpoints:

Validate the XML syntax.
Monitor CPU utilization.
Review memory usage.
Confirm expected alerts are generated.
Verify no duplicate events appear.
Monitor index growth.

Testing in a staging environment significantly reduces the risk of disrupting production systems.

Example ossec.conf Configurations

The exact ossec.conf configuration depends on the role of the system being monitored.

A web server requires different log sources than a database server or Kubernetes node.

The following examples illustrate common deployment scenarios.

Basic Linux Server

A typical Linux server monitors operating system and authentication logs.

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

Suitable for:

Ubuntu
Debian
General-purpose Linux servers

Windows Server

Windows servers commonly monitor the primary Event Log channels.

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

<localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
</localfile>

<localfile>
    <location>Application</location>
    <log_format>eventchannel</log_format>
</localfile>

Web Server

A web server benefits from monitoring operating system logs alongside web server activity.

<localfile>
    <location>/var/log/nginx/access.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/nginx/error.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

Database Server

Database servers often monitor database-specific logs in addition to operating system logs.

<localfile>
    <location>/var/log/mysql/error.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

Depending on the database platform, you may also monitor audit logs, slow query logs, or transaction logs if they support your monitoring objectives.

Docker Host

A Docker host typically collects operating system logs along with container log output.

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/lib/docker/containers/container.log</location>
    <log_format>json</log_format>
</localfile>

Many organizations instead centralize container logs using Fluent Bit or Journald before sending them to Wazuh, which simplifies configuration and scales better as containers are created and removed.

Related Guide: Fix Wazuh Docker Compose Deployment

Kubernetes Node

Kubernetes worker nodes generate logs from the operating system, kubelet, container runtime, and workloads.

Example:

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/containers/*.log</location>
    <log_format>json</log_format>
</localfile>

Monitoring container logs alongside host logs provides broader visibility into both infrastructure and workloads.

Related Guide: How to Monitor Kubernetes Using Wazuh

Validating Your Configuration

After modifying ossec.conf, you should always verify that the configuration is valid before relying on it in production.

Even a small XML syntax error can prevent the Wazuh agent or manager from starting correctly.

Validation helps ensure your new log sources are loaded successfully and prevents unexpected interruptions to monitoring.

XML Syntax Validation

Because ossec.conf uses XML, syntax errors such as missing closing tags, improperly nested elements, or invalid characters can cause configuration failures.

Before restarting Wazuh:

Verify every opening tag has a matching closing tag.
Confirm XML elements are properly nested.
Check for accidental duplicate elements or malformed syntax.

Many administrators also use XML-aware editors that automatically highlight syntax issues.

Using `wazuh-control`

On Linux installations, the wazuh-control utility can be used to manage Wazuh services.

For example:

sudo /var/ossec/bin/wazuh-control restart

This restarts the appropriate Wazuh components so the updated configuration is loaded.

Some modern Linux distributions instead rely on systemctl to manage services, depending on how Wazuh was installed.

Restarting Wazuh Services

Configuration changes are not applied until the affected service is restarted.

Examples:

Restart the agent:

sudo systemctl restart wazuh-agent

Restart the manager:

sudo systemctl restart wazuh-manager

On Windows, restart the Wazuh Agent service through Services or PowerShell.

Checking Configuration Loading

After restarting Wazuh, verify that the configuration loaded successfully.

Look for:

Successful service startup
No XML parsing errors
No Logcollector initialization failures
No missing file warnings
No permission errors

Any problems detected during startup should be resolved before relying on the new configuration.

Reviewing Startup Logs

The primary log for diagnosing startup issues is:

/var/ossec/logs/ossec.log

Review the log for messages indicating:

Logcollector started successfully
Configuration loaded
Monitored files opened
XML errors
Missing files
Permission problems

The official Wazuh documentation recommends reviewing ossec.log whenever configuration changes do not behave as expected.

Confirming Monitored Files

Finally, verify that each configured log source is actively being monitored.

Confirm:

The file exists.
Wazuh has permission to read it.
New log entries are appearing.
Events are reaching the manager.
Alerts are generated when expected.

Performing this validation immediately after deployment reduces the likelihood of unnoticed gaps in log collection.

Testing Log Monitoring

After configuring log monitoring, verify that Wazuh is actually collecting, decoding, and alerting on the expected events.

A configuration that loads successfully is only useful if it produces the expected security telemetry.

Testing each monitored log source before moving to production helps identify missing permissions, incorrect paths, decoder issues, or rule configuration problems.

Generate Test Events

The simplest way to test monitoring is to create real events that should be captured.

Examples include:

Logging in through SSH.
Executing a sudo command.
Restarting a service.
Accessing a web server.
Creating authentication failures.
Triggering an application error.

These actions generate authentic log entries that exercise the full Wazuh processing pipeline.

Create Sample Log Entries

For custom application logs, manually append a test message.

Example:

2026-07-17 14:22:15 ERROR User authentication failed for admin from 192.168.10.55

After writing the entry, verify that it appears in Wazuh.

This approach is especially useful when testing newly added <localfile> configurations.

Verify Alerts Appear

Open the Wazuh Dashboard and confirm that the generated events appear in:

Security Events
Discover
Dashboards
Alert views

If events are visible, the collection pipeline is functioning correctly.

Confirm Rule Matching

Collection alone does not guarantee successful detection.

Verify that:

The correct decoder parsed the event.
Expected fields were extracted.
The appropriate rule matched.
The expected alert level was assigned.

If no rule matches, you may need to adjust existing rules or create custom ones.

Related Guides:

Review Archives and Alerts

If alerts are not appearing, determine whether the event reached the manager.

Compare:

Raw archived events.
Decoded events.
Generated alerts.

This helps isolate whether the issue is related to collection, decoding, or rule processing.

Troubleshooting Failed Tests

If testing does not produce the expected results, work through the following checklist:

Verify the log file path is correct.
Confirm the <log_format> matches the log type.
Ensure the Wazuh service has permission to read the file.
Check ossec.log for Logcollector or XML errors.
Confirm the event matches an existing rule.
Verify the event is reaching the manager if testing from an agent.
Ensure the dashboard is connected to the correct index.

Taking a systematic approach makes it much easier to determine whether the problem lies in log collection, event decoding, rule evaluation, or dashboard visualization.

Common ossec.conf Log Monitoring Problems

Even with a properly designed ossec.conf configuration, administrators may encounter issues where logs are missing, alerts are not generated, or the Wazuh agent consumes excessive resources.

Most log monitoring problems are caused by configuration mistakes, permission issues, incorrect formats, or misunderstanding how Wazuh processes events.

The following troubleshooting steps cover the most common issues encountered when configuring Wazuh log collection.

Logs Not Being Collected

One of the most common problems is adding a <localfile> configuration but not seeing any events in the Wazuh Dashboard.

Common causes include:

Incorrect log file path.
The file does not exist.
The application is not generating new logs.
The Wazuh agent was not restarted after configuration changes.
The wrong <log_format> was selected.
The agent is not connected to the manager.

Start troubleshooting by checking:

sudo tail -f /var/ossec/logs/ossec.log

Look for messages related to:

Logcollector startup.
File monitoring initialization.
Permission errors.
Invalid configurations.

You can also verify that the log file is receiving new entries:

sudo tail -f /var/log/auth.log

If new entries appear in the file but not in Wazuh, the problem is likely within the Wazuh collection pipeline.

Incorrect File Permissions

Wazuh requires permission to read every monitored log source.

For example:

<localfile>
    <location>/var/log/custom/application.log</location>
    <log_format>syslog</log_format>
</localfile>

If the Wazuh agent cannot access the file, events will not be collected.

Check permissions:

ls -l /var/log/custom/application.log

Common fixes include:

Adding the Wazuh user to the appropriate group.
Adjusting file permissions.
Configuring ACL permissions.
Ensuring applications create logs with readable permissions.

Be careful when modifying permissions on security-sensitive logs such as authentication files.

Invalid XML Syntax

Because ossec.conf uses XML, even a small formatting mistake can prevent Wazuh from loading the configuration.

Common XML errors include:

Missing closing tags.
Incorrect nesting.
Invalid characters.
Duplicate root elements.

Example invalid configuration:

<localfile>
    <location>/var/log/syslog</location>

The missing closing tag causes parsing failure.

Always validate changes before restarting Wazuh.

Wrong Log Format

Selecting the wrong <log_format> prevents Wazuh from correctly interpreting events.

Example:

<localfile>
    <location>/var/log/application.json</location>
    <log_format>syslog</log_format>
</localfile>

If the file contains JSON data, the correct configuration should be:

<localfile>
    <location>/var/log/application.json</location>
    <log_format>json</log_format>
</localfile>

Incorrect formats can result in:

Parsing failures.
Missing fields.
Failed decoder matching.
Missing alerts.

Duplicate Log Entries

Duplicate alerts usually occur when the same log source is collected multiple times.

Common causes include:

Duplicate <localfile> blocks.
Monitoring both local logs and forwarded copies.
Multiple log forwarding pipelines.

Example:

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>/var/log/syslog</location>
    <log_format>syslog</log_format>
</localfile>

Remove duplicate entries and restart the agent.

Log Rotation Issues

Log rotation can cause unexpected behavior when applications rename, compress, or recreate log files.

Common symptoms:

Missing events after rotation.
Duplicate events.
Monitoring stopped after rotation.

Troubleshooting steps:

Confirm the application creates a new log file after rotation.
Check ownership and permissions of the new file.
Review ossec.log.
Avoid monitoring archived .gz files.

High CPU Usage

Excessive CPU usage from Wazuh agents is often caused by collecting too much data.

Common causes:

Monitoring high-volume logs.
Collecting debug logs.
Running commands too frequently.
Processing duplicate events.
Monitoring large directories.

Solutions include:

Removing unnecessary <localfile> entries.
Increasing command execution intervals.
Filtering unnecessary events.
Monitoring only security-relevant sources.

Missing Alerts

A collected event does not always become an alert.

The processing pipeline is:

Log Source
     ↓
Logcollector
     ↓
Decoder
     ↓
Rules Engine
     ↓
Alert

If the event is collected but no alert appears, possible causes include:

No matching decoder.
No matching rule.
Incorrect event format.
Rule level too low.
Custom application requires custom rules.

Use:

/var/ossec/bin/wazuh-logtest

to test how Wazuh processes an event.

Security Best Practices

A properly configured ossec.conf file is critical for maintaining reliable monitoring, but protecting and maintaining that configuration is equally important.

Because configuration files define what security telemetry is collected, unauthorized modifications could create blind spots or disable important monitoring capabilities.

Limit Monitored Files

Avoid collecting every available log source.

A focused configuration improves:

Detection quality.
Performance.
Storage efficiency.
Analyst productivity.

Prioritize:

Authentication logs.
Security audit logs.
Administrative activity.
Critical application logs.

Avoid unnecessary:

Debug files.
Temporary files.
Cache directories.
Historical archives.

Protect Configuration Files

The ossec.conf file contains important security settings and should be protected from unauthorized changes.

Recommended protections:

Restrict administrative access.
Monitor configuration changes.
Maintain backups.
Audit file modifications.

Linux example:

sudo chmod 640 /var/ossec/etc/ossec.conf

Restrict File Permissions

Only authorized administrators should modify Wazuh configuration files.

Recommended ownership:

root:wazuh

Avoid making configuration files writable by:

Regular users.
Applications.
Service accounts.

Improper permissions can introduce security risks and accidental configuration changes.

Use Version Control

Store configuration templates in version control systems such as Git.

Benefits include:

Change tracking.
Rollback capability.
Review workflows.
Configuration history.

For enterprise deployments, version-controlled ossec.conf templates allow consistent configurations across thousands of endpoints.

Document Configuration Changes

Every modification should include documentation:

What changed.
Why it changed.
Who approved it.
When it was deployed.
Expected impact.

Regularly Audit Monitored Logs

Log requirements change as infrastructure evolves.

Regular reviews should verify:

Important systems are monitored.
Retired applications are removed.
New applications are included.
Compliance requirements are satisfied.

Periodic audits prevent outdated configurations from creating security gaps.

Keep Wazuh Updated

Regular updates provide:

Security patches.
New detection rules.
Improved integrations.
Bug fixes.
Performance improvements.

Keep these components updated:

Wazuh agents.
Wazuh managers.
Wazuh indexers.
Wazuh dashboards.

Related Guide: How to Upgrade a Wazuh Agent

Real-World Example

Scenario

A company wants to centralize security monitoring across hundreds of Linux servers, Windows endpoints, web servers, and internally developed applications.

The organization operates a mixed environment containing:

Ubuntu and Red Hat servers.
Windows enterprise endpoints.
Public-facing web servers.
Internal business applications.
Containerized workloads.

Each platform generates different types of security telemetry.

Challenge

Each system generates logs in different formats and locations.

Examples:

Linux servers:

/var/log/syslog
/var/log/auth.log

Windows systems:

Security Event Channel.
System Event Channel.
PowerShell logs.

Applications:

JSON API logs.
Java application logs.
Custom audit files.

The security team needs a standardized approach that:

Collects important security events.
Supports different log formats.
Avoids unnecessary data collection.
Does not overwhelm the Wazuh manager.

Solution

The organization creates standardized ossec.conf templates containing multiple <localfile> definitions.

Examples:

Linux:

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

Windows:

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

Applications:

<localfile>
    <location>/opt/application/security.json</location>
    <log_format>json</log_format>
</localfile>

The team also:

Removes unnecessary logs.
Validates configurations before deployment.
Tests alerts.
Uses Ansible to distribute configurations consistently.

Result

The organization achieves:

Centralized Log Collection Across All Endpoints

Security teams gain visibility across:

Servers.
Workstations.
Applications.
Containers.

Improved Threat Detection Through Comprehensive Visibility

Important security events are collected and analyzed through Wazuh detection rules.

Reduced False Positives by Monitoring Only Relevant Logs

Removing unnecessary telemetry improves alert quality and reduces analyst workload.

Lower Resource Usage Through Optimized Configurations

Focused collection reduces:

Agent CPU usage.
Network traffic.
Index storage requirements.

Simplified Maintenance With Standardized ossec.conf Templates

Version-controlled templates allow administrators to quickly deploy consistent configurations across large environments.

Frequently Asked Questions (FAQ)

Question: Where is the ossec.conf file located in Wazuh?

The default location depends on the operating system.

Linux:

/var/ossec/etc/ossec.conf

Windows:

C:\Program Files (x86)\ossec-agent\ossec.conf

Docker deployments typically use:

/var/ossec/etc/ossec.conf

inside the container.

Question: Do I Need to Restart Wazuh After Editing ossec.conf?

Yes.

Wazuh loads configuration during startup, so changes require restarting the affected service.

Agent:

sudo systemctl restart wazuh-agent

Manager:

sudo systemctl restart wazuh-manager

Question: What Is the Purpose of the `<localfile>` Section?

The <localfile> section defines which logs Wazuh should monitor and how those logs should be interpreted.

It specifies:

Log location.
Log format.
Optional filtering settings.

Question: Can Wazuh Monitor Multiple Log Files Simultaneously?

Yes.

You can create multiple <localfile> blocks for different sources.

Example:

<localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
</localfile>

Each block is monitored independently.

Question: How Do I Monitor JSON Logs Using ossec.conf?

Use:

<log_format>json</log_format>

Example:

<localfile>
    <location>/var/log/application.json</location>
    <log_format>json</log_format>
</localfile>

Question: Can I Monitor Windows Event Logs With ossec.conf?

Yes.

Use the eventchannel format.

Example:

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

Question: Does Wazuh Automatically Detect Log Rotation?

Yes.

Wazuh handles normal log rotation scenarios, including files recreated by common rotation tools such as logrotate.

However, incorrect rotation configurations can still cause duplicate or missing events.

Question: How Do I Verify That Wazuh Is Collecting Logs Correctly?

Check:

/var/ossec/logs/ossec.log

Then:

Generate a test event.
Verify it appears in the dashboard.
Confirm the rule match.

Question: What Happens If ossec.conf Contains Invalid XML?

Wazuh may fail to start or ignore invalid configuration sections.

Always validate XML syntax before restarting services.

Question: How Can I Reduce Unnecessary Log Collection in Wazuh?

Reduce collection by:

Removing unused <localfile> entries.
Ignoring debug logs.
Avoiding archive monitoring.
Filtering high-volume sources.
Collecting only security-relevant events.

Conclusion

The ossec.conf file is the foundation of log monitoring in Wazuh.

It determines what data is collected, how events are interpreted, and how security telemetry flows from endpoints to the Wazuh manager.

By correctly configuring <localfile> entries, organizations can monitor:

Linux system logs.
Windows Event Logs.
macOS events.
Web servers.
Databases.
Custom applications.
Container environments.

Administrators must select meaningful sources, choose the correct log formats, optimize performance, validate configurations, and regularly test monitoring capabilities.

As infrastructure changes over time, regularly reviewing and testing ossec.conf configurations helps maintain continuous visibility and ensures security teams can detect threats quickly and accurately.

How to Configure ossec.conf for Log Monitoring in Wazuh

What Is ossec.conf in Wazuh?

Purpose of the Configuration File

Role in Wazuh Manager vs Wazuh Agent

Default File Locations

Linux

Windows

Docker Deployments

XML Structure Overview

How Wazuh Loads Configuration Changes

Understanding How Wazuh Log Monitoring Works

Log Collection Workflow

Reading Local Log Files

Monitoring Windows Event Logs

Journald Integration

Command Output Monitoring

Event Forwarding to the Manager

Rule Matching and Alert Generation

Understanding the <localfile> Section

What <localfile> Does

Required Configuration Elements

<location>

<log_format>

Optional Configuration Elements

Multiple <localfile> Entries

Processing Order

Example XML Configuration

Configuring Log File Monitoring

Monitoring Linux Log Files

/var/log/syslog

/var/log/messages

/var/log/auth.log

/var/log/secure

Apache Logs

Nginx Logs

Application Logs

Example Configuration

Monitoring Windows Event Logs

Security

System

Application

Microsoft-Windows Channels

Custom Event Channels

Example Configuration

Monitoring macOS Logs

Unified Logging

Traditional Log Files

Best Practices

Monitoring Multiple Log Files

Multiple <localfile> Blocks

Organizing Configurations

Avoiding Duplicate Monitoring

Performance Considerations

Example Configuration

Using Different Log Formats

syslog

json

eventchannel

command

full_command

Multi-Line Logs

Custom Application Logs

Monitoring Custom Application Logs

Java Applications

Python Applications

Node.js Applications

Docker Container Logs

Custom Enterprise Software

Example Configurations

Monitoring Rotating Log Files

How Wazuh Detects Rotated Logs

logrotate Integration

Preventing Duplicate Events

Common Rotation Issues

Best Practices

Filtering Logs Before Processing

Ignoring Unnecessary Logs

Restricting Monitored Files

Reducing Noise

Improving Performance

Understanding the `<localfile>` Section

What `<localfile>` Does

`<location>`

`<log_format>`

Multiple `<localfile>` Entries

`/var/log/syslog`

`/var/log/messages`

`/var/log/auth.log`

`/var/log/secure`

Multiple `<localfile>` Blocks

`syslog`

`json`

`eventchannel`

`command`

`full_command`

Using `wazuh-control`

Question: What Is the Purpose of the `<localfile>` Section?