Proper log collection is the foundation of an effective Wazuh deployment.
Even the most advanced detection rules are ineffective if important events never reach the Wazuh Manager.
Wazuh supports both agent-based and agentless log collection, allowing organizations to monitor endpoints, servers, cloud workloads, applications, and network devices from a single platform.
Choosing the right collection method depends on the type of system being monitored.
Endpoints typically use the Wazuh Agent, while infrastructure devices such as firewalls, switches, and routers commonly send logs using Syslog.
Agent-Based Collection
The Wazuh Agent provides the most comprehensive method of collecting logs.
Running directly on the monitored system, it continuously watches configured log sources and securely forwards new events to the Wazuh Manager with minimal latency.
Benefits of agent-based collection include:
- Near real-time log forwarding
- Secure encrypted communication
- Support for multiple operating systems
- File Integrity Monitoring (FIM)
- Endpoint inventory collection
- Vulnerability detection
- Centralized configuration management
Agent-based collection is recommended whenever an agent can be installed.
Local Log Files
Many Linux applications write logs directly to text files.
Common examples include:
/var/log/syslog/var/log/messages/var/log/auth.log/var/log/secure- Apache access logs
- Nginx error logs
- Custom application logs
The Logcollector module continuously monitors these files for new entries instead of repeatedly scanning the entire file, making collection highly efficient.
Administrators can configure Wazuh to monitor:
- Individual files
- Entire directories
- Wildcard file patterns
- Rotating log files
This flexibility makes it easy to centralize logs from both standard services and internally developed applications.
Event Channels
On Windows, logs are stored in Event Channels rather than traditional text files.
Wazuh can collect events from channels such as:
- Security
- System
- Application
- Microsoft-Windows-PowerShell/Operational
- Sysmon
- DNS Server
- Windows Defender
Each channel captures a different category of operating system activity, allowing organizations to tailor monitoring to their security and operational needs.
Related Guide: How to Monitor Windows Event Logs Using Wazuh
Journald
Many modern Linux distributions use systemd-journald instead of traditional Syslog.
Journal entries include structured metadata such as:
- Service names
- Process IDs
- User IDs
- Hostnames
- Boot sessions
- Priority levels
Monitoring Journald allows Wazuh to capture events generated by services that do not write directly to text log files.
Because Journald maintains structured event metadata, investigations often become more accurate and efficient than relying solely on plain-text logs.
Custom Logs
Organizations frequently run proprietary applications that generate unique log formats.
Wazuh can monitor virtually any custom log file, including:
- Business applications
- ERP systems
- Payment platforms
- Internal APIs
- Manufacturing systems
- Scientific software
Custom logs can be combined with custom decoders and detection rules, allowing organizations to detect application-specific security events that generic rules would otherwise miss.
Agentless Collection
Not every device supports installing a Wazuh Agent.
Infrastructure devices such as firewalls, switches, storage arrays, wireless controllers, printers, and network appliances typically forward events remotely.
Agentless collection allows these systems to participate in centralized log management without installing endpoint software.
Syslog
Syslog remains the most widely supported logging protocol for network infrastructure.
Thousands of devices support forwarding Syslog messages to a centralized server, including:
- Routers
- Firewalls
- VPN gateways
- Load balancers
- Storage appliances
- Linux servers
Wazuh can act as a centralized Syslog server, receiving logs from these devices and processing them through its decoding and rule engine.
Related Guides:
Network Devices
Centralized logging becomes significantly more valuable when network infrastructure is included.
Common monitored devices include:
- Switches
- Routers
- Wireless controllers
- IDS/IPS appliances
- Proxy servers
- DNS servers
- VPN concentrators
These logs help security teams detect:
- Unauthorized access attempts
- Configuration changes
- Network scanning
- VPN abuse
- Routing anomalies
- Service outages
Combining endpoint logs with network telemetry provides much better visibility than monitoring either source independently.
Remote Systems
Organizations often manage geographically distributed infrastructure spanning multiple offices, branch locations, cloud providers, and data centers.
Wazuh supports centralized collection from remote systems through encrypted communication, enabling administrators to manage global deployments from a single dashboard.
This centralized architecture simplifies:
- Incident response
- Compliance reporting
- Security monitoring
- Capacity planning
- Historical investigations
Supported Log Formats
One of Wazuh’s major strengths is its ability to ingest logs in numerous formats without requiring major preprocessing.
Plain Text
Plain-text logs remain the most common format for Linux applications.
Examples include:
- Apache logs
- Nginx logs
- SSH authentication logs
- Mail server logs
- Database logs
Wazuh continuously monitors these files and parses new entries in real time.
Syslog
Syslog messages typically contain:
- Timestamp
- Hostname
- Facility
- Severity
- Program name
- Message body
Because Syslog is standardized, Wazuh can efficiently process logs from a wide variety of vendors.
JSON
Modern cloud-native applications increasingly produce JSON logs.
JSON offers several advantages:
- Structured fields
- Easier parsing
- Better search performance
- Rich metadata
- Simplified integrations
Wazuh supports extracting nested JSON fields without requiring complicated regular expressions.
XML
Several enterprise platforms generate XML-based logs.
Examples include:
- Windows Event Logs
- Enterprise management platforms
- Security appliances
- Authentication services
XML parsing preserves structured event information while allowing decoders to extract relevant fields.
CSV
Although less common for real-time monitoring, CSV logs are still used by:
- Legacy business systems
- Financial applications
- Exported reports
- Industrial control systems
With appropriate decoders, CSV logs can be incorporated into the same centralized monitoring workflow.
Custom Formats
Many organizations generate proprietary log formats that don’t match existing standards.
Wazuh’s decoder framework allows administrators to create parsers for virtually any log format, ensuring internally developed applications can participate in centralized monitoring alongside commercial software.
Related Guides:
Monitoring Windows Event Logs
Windows Event Logs contain some of the most valuable forensic and security data available on Microsoft systems.
They record authentication activity, application errors, service changes, PowerShell execution, scheduled tasks, policy modifications, and countless other events that help security teams detect attacks and troubleshoot operational issues.
Because Windows stores logs in structured Event Channels rather than text files, Wazuh can collect rich event metadata such as Event IDs, usernames, process names, and security identifiers (SIDs), making detection rules more accurate than simple keyword matching.
For step-by-step configuration instructions, see How to Monitor Windows Event Logs Using Wazuh.
Event Channels
Windows organizes logs into multiple channels, each serving a different purpose.
Selecting the appropriate channels ensures comprehensive monitoring without overwhelming the system with unnecessary events.
Security
The Security channel is the most important source for security monitoring.
It records events including:
- Successful logins
- Failed logins
- Account lockouts
- User creation
- Privilege escalation
- Group membership changes
- Audit policy modifications
Many Wazuh detection rules rely on Security events to identify attacks such as brute-force attempts and credential abuse.
System
The System channel contains operating system events generated by Windows components.
Examples include:
- Driver failures
- Service starts and stops
- Hardware errors
- System shutdowns
- Boot events
- Time synchronization issues
Monitoring System logs helps correlate security incidents with infrastructure problems.
Application
Application logs capture events generated by installed software.
Examples include:
- Database errors
- Web server failures
- Backup software alerts
- Business application exceptions
- Antivirus notifications
Application events often provide valuable context during incident investigations.
PowerShell
PowerShell is widely used by both administrators and attackers.
The PowerShell Operational log records:
- Script execution
- Module loading
- Pipeline activity
- Command invocation
- Remote sessions
Monitoring these events significantly improves detection of fileless malware and post-exploitation techniques.
Microsoft security experts consistently recommend enabling advanced PowerShell logging because attackers frequently abuse PowerShell during lateral movement and privilege escalation.
Sysmon
Sysmon extends Windows logging far beyond native capabilities.
It records:
- Process creation
- Network connections
- Registry modifications
- File creation timestamps
- Driver loading
- DLL injection
- Named pipes
- DNS queries
When integrated with Wazuh, Sysmon dramatically increases endpoint visibility while supporting detection techniques mapped to the MITRE ATT&CK framework.
Configuration Best Practices
Proper configuration balances visibility with performance.
Collecting every possible event can increase storage requirements and generate excessive noise, making meaningful alerts harder to identify.
Selecting Channels
Focus on channels that provide the highest security value.
For most environments, prioritize:
- Security
- System
- Application
- PowerShell Operational
- Sysmon
Additional channels can be added as monitoring requirements evolve.
Filtering Noisy Events
Certain Event IDs occur extremely frequently and rarely provide investigative value.
Filtering unnecessary events can:
- Reduce storage usage
- Lower CPU utilization
- Improve search performance
- Reduce alert fatigue
- Simplify investigations
Filtering should always be based on operational experience rather than removing entire categories of events.
Performance Considerations
Large Windows environments may generate millions of events each day.
To maintain performance:
- Monitor only required channels
- Filter repetitive events
- Archive historical logs
- Tune OpenSearch indexing
- Monitor agent resource usage
- Regularly review retention policies
Proper tuning ensures high-volume Windows logging remains sustainable as environments grow.
Related Guide: How to Monitor Windows Event Logs Using Wazuh
Collecting Firewall Logs
Firewalls are among the most valuable sources of security telemetry because they monitor traffic entering, leaving, and moving within an organization’s network.
Their logs reveal connection attempts, blocked traffic, VPN activity, policy changes, intrusion prevention events, and application-layer filtering decisions.
When firewall logs are centralized in Wazuh, analysts can correlate network events with endpoint activity, providing a more complete picture of potential attacks.
For implementation details, see How to Collect Firewall Logs in Wazuh.
Common Firewall Platforms
Wazuh supports logs from virtually any firewall capable of exporting Syslog or structured log formats.
pfSense
pfSense is widely deployed in small and medium-sized environments.
Typical monitored events include:
- Blocked connections
- Allowed traffic
- NAT translations
- VPN connections
- DHCP events
- DNS Resolver activity
Cisco ASA
Cisco ASA devices generate detailed security logs covering:
- ACL decisions
- VPN authentication
- Interface status
- Connection tracking
- Threat detection
- Administrative actions
These logs help identify unauthorized access attempts and network policy violations.
Fortinet
Fortinet firewalls produce extensive telemetry including:
- Intrusion prevention
- Antivirus detections
- Web filtering
- SSL inspection
- Application control
- User authentication
These logs provide excellent visibility into perimeter security.
Palo Alto
Palo Alto Networks firewalls generate rich application-aware logs, including:
- Traffic logs
- Threat logs
- WildFire analysis
- URL filtering
- DNS security
- GlobalProtect VPN activity
Because of their detailed metadata, Palo Alto logs are particularly useful for threat hunting.
Sophos
Sophos Firewall exports logs covering:
- IPS detections
- VPN activity
- Web filtering
- Email protection
- Malware blocking
- User authentication
These events integrate well into centralized monitoring workflows.
MikroTik
MikroTik RouterOS devices commonly generate logs for:
- Firewall rules
- Routing changes
- DHCP
- Wireless authentication
- VPN sessions
- Administrative access
Although often used in smaller environments, MikroTik logs still provide valuable operational and security visibility.
Best Practices
Collecting firewall logs effectively requires careful configuration to maximize visibility while minimizing unnecessary noise.
Syslog Configuration
Most firewall vendors recommend forwarding logs using Syslog over TCP or UDP to a centralized logging server.
When configuring Syslog:
- Enable reliable transport where possible
- Synchronize device clocks using NTP
- Include hostname information
- Configure appropriate severity levels
- Verify firewall rules permit log forwarding
Consistent timestamps and host identification greatly simplify incident investigations.
Parsing Firewall Events
Different firewall vendors use different message formats.
Wazuh decoders extract structured information such as:
- Source IP
- Destination IP
- Source port
- Destination port
- Protocol
- Interface
- Rule name
- Action
- User identity
Proper parsing enables accurate rule matching and efficient searching.
Alert Tuning
Firewall devices often generate extremely high log volumes.
To reduce alert fatigue:
- Prioritize denied connections from external sources
- Suppress repetitive informational events
- Correlate firewall logs with endpoint alerts
- Monitor configuration changes separately
- Review rule effectiveness regularly
Organizations that continuously tune detection logic typically achieve higher signal-to-noise ratios and faster incident response.
Related Guides:
Monitoring Apache Logs
Apache is one of the most widely deployed web servers in the world, making its logs a valuable source of both operational and security information.
Every request handled by Apache leaves behind data that can help administrators identify attacks, troubleshoot application issues, monitor traffic patterns, and investigate security incidents.
When Apache logs are collected by Wazuh, they become part of the organization’s centralized security monitoring platform.
Wazuh can decode Apache events, correlate them with logs from endpoints and firewalls, and generate alerts when suspicious behavior matches predefined or custom detection rules.
For a complete setup guide, see How to Monitor Apache Logs with Wazuh.
Important Apache Logs
Apache generates several types of logs, each serving a different purpose.
Monitoring all relevant log types provides a comprehensive view of web server activity.
Access Log
The access log records every HTTP request processed by Apache.
Typical information includes:
- Client IP address
- Request timestamp
- HTTP method
- Requested URL
- Response status code
- Bytes transferred
- Referrer
- User-Agent
Access logs are often the primary source for detecting:
- Brute-force login attempts
- Web vulnerability scanning
- Suspicious crawlers
- Excessive requests
- Bot activity
- Geographic anomalies
Because every request is recorded, access logs provide detailed visibility into user behavior and attacker reconnaissance.
Error Log
The error log captures problems encountered by Apache while serving requests.
Common entries include:
- Configuration errors
- PHP exceptions
- Missing files
- Permission issues
- Backend failures
- Service startup problems
Error logs are particularly useful when correlating operational failures with security events.
For example, repeated application errors immediately following suspicious requests may indicate an attempted exploit.
SSL Log
Some Apache deployments maintain dedicated SSL or TLS logs that record encrypted connection information.
These logs may include:
- TLS handshake failures
- Certificate validation errors
- Protocol negotiation
- Cipher selection
- Client certificate authentication
Monitoring SSL-related events helps identify:
- Misconfigured certificates
- Expired certificates
- Unsupported protocol usage
- Failed secure connections
Common Detection Use Cases
Apache logs contain valuable indicators of malicious activity that Wazuh can automatically detect using built-in or custom rules.
Brute-Force Attacks
Attackers frequently attempt repeated logins against:
- WordPress
- phpMyAdmin
- Administrative portals
- Web APIs
Indicators include:
- Multiple failed authentication attempts
- Repeated requests from the same IP
- High request frequency
- Requests targeting login endpoints
Wazuh can generate alerts when repeated authentication failures exceed configurable thresholds.
Web Scanning
Automated scanners search for vulnerable applications by requesting hundreds or thousands of URLs in rapid succession.
Common indicators include:
- Requests for non-existent files
- Requests targeting known vulnerabilities
- Enumeration of administrative pages
- Rapid sequential requests
Detecting scanning activity allows defenders to investigate potential reconnaissance before exploitation occurs.
SQL Injection Attempts
Many attackers attempt SQL injection by placing malicious database commands into URLs or form parameters.
Common indicators include:
- SQL keywords in requests
- Encoded payloads
- Database error responses
- Suspicious URL parameters
While Apache itself cannot determine whether an attack succeeded, access logs often provide the earliest evidence that an application is being targeted.
Directory Traversal
Directory traversal attacks attempt to access files outside the intended web directory.
Typical request patterns include:
../- URL-encoded traversal sequences
- Requests for sensitive configuration files
- Attempts to access operating system files
Wazuh detection rules can identify many common traversal techniques before they result in successful compromise.
HTTP Errors
HTTP status codes can reveal both application problems and malicious activity.
Examples include:
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
- 500 Internal Server Error
- 503 Service Unavailable
A sudden spike in 404 responses, for example, often indicates automated vulnerability scanning or reconnaissance.
Combining HTTP error analysis with firewall and endpoint logs provides much stronger detection capabilities than analyzing web logs alone.
As the OWASP community consistently emphasizes, web server logs are a critical source of evidence during incident response because they document attacker behavior throughout every phase of a web application attack.
Related Guide: How to Monitor Apache Logs with Wazuh
Centralizing Logs with Syslog
Syslog is one of the oldest and most widely adopted logging standards in IT infrastructure.
Nearly every enterprise networking device, including routers, switches, firewalls, storage systems, load balancers, and Unix-like operating systems, supports forwarding logs using the Syslog protocol.
Configuring Wazuh as a centralized Syslog server enables organizations to aggregate logs from diverse infrastructure into a single platform for analysis, correlation, alerting, and long-term storage.
For detailed implementation instructions, see How to Configure Wazuh as a Centralized Syslog Server.
Why Use Syslog?
Syslog remains the preferred transport protocol for infrastructure logging because it is simple, lightweight, and supported by thousands of hardware and software vendors.
Centralized Log Aggregation
Instead of reviewing logs individually on each device, administrators can consolidate events into a central Wazuh deployment.
Centralized aggregation provides several advantages:
- Faster investigations
- Simplified auditing
- Unified alerting
- Historical log retention
- Cross-device correlation
- Reduced administrative overhead
This centralized visibility is particularly valuable during incident response, where analysts often need to reconstruct activity across multiple systems.
Device Compatibility
One of Syslog’s greatest strengths is its broad compatibility.
Devices commonly supporting Syslog include:
- Firewalls
- Routers
- Switches
- Wireless controllers
- VPN gateways
- Linux servers
- Storage appliances
- Hypervisors
- UPS systems
- Security appliances
Because Syslog is vendor-neutral, organizations can centralize logs from mixed environments without deploying additional collection software.
Simplified Monitoring
A centralized Syslog architecture reduces operational complexity by allowing security teams to monitor infrastructure through a single interface.
Rather than logging into individual devices, analysts can:
- Search all events centrally
- Create unified dashboards
- Correlate network and endpoint activity
- Build organization-wide alerts
- Generate compliance reports
This approach improves operational efficiency while reducing the risk of overlooking important security events.
Configuring Syslog Collection
A properly configured Syslog infrastructure ensures reliable log delivery and consistent event processing.
UDP vs TCP
Syslog supports both UDP and TCP transport.
UDP
Advantages:
- Lower overhead
- Minimal latency
- Widely supported
- Simple configuration
Disadvantages:
- No delivery confirmation
- Possible packet loss
- Less suitable for critical audit logs
TCP
Advantages:
- Reliable delivery
- Ordered transmission
- Better for compliance logging
- Reduced risk of missing events
Disadvantages:
- Slightly higher resource usage
- Connection management overhead
For environments where audit completeness is important, TCP is generally preferred over UDP.
Secure Syslog
Traditional Syslog transmits messages in plaintext.
When logs traverse untrusted networks, organizations should consider secure alternatives that encrypt traffic using TLS.
Secure Syslog helps protect:
- Authentication events
- Firewall activity
- Sensitive infrastructure logs
- Compliance data
- Administrative actions
Encrypting log traffic reduces the risk of interception or tampering during transmission.
Port Configuration
By default, Syslog commonly uses:
Some organizations deploy alternative ports for:
- Secure Syslog
- Network segmentation
- Multi-tenant deployments
- High-availability architectures
Regardless of the port selected, firewalls and network access control policies must permit traffic between sending devices and the Wazuh server.
Device Onboarding
Before forwarding logs, each device should be configured consistently.
Recommended onboarding steps include:
- Configure accurate hostnames
- Synchronize clocks with NTP
- Select appropriate log severity
- Enable required log categories
- Test log forwarding
- Verify parsing within Wazuh
Standardizing device configurations improves log quality and simplifies future troubleshooting.
Related Guides:
Troubleshooting Syslog Collection
Even a small configuration issue can prevent Syslog messages from reaching Wazuh.
Problems may occur anywhere along the logging pipeline, including the sending device, network infrastructure, operating system, or Wazuh itself.
Following a structured troubleshooting process helps isolate issues quickly while minimizing downtime.
For detailed troubleshooting instructions, see Troubleshoot Wazuh Syslog Port 514 Ingestion.
Common Problems
Port 514 Not Receiving Logs
One of the most common issues is that Wazuh is not receiving traffic on the configured Syslog port.
Possible causes include:
- Syslog listener not running
- Incorrect port configuration
- Binding to the wrong interface
- Service startup failure
Verifying that the listener is actively accepting connections is typically the first troubleshooting step.
Firewall Blocking Traffic
Network firewalls frequently block inbound Syslog traffic.
Administrators should verify:
- Inbound firewall rules
- Outbound firewall rules
- Cloud security groups
- Network ACLs
- Internal segmentation policies
Packet filtering issues are especially common when forwarding logs across different network segments.
SELinux Issues
On Linux systems with SELinux enabled, mandatory access controls may prevent services from binding to network ports or accessing required resources.
Symptoms may include:
- Listener startup failures
- Permission denied errors
- Missing incoming events
Reviewing SELinux audit logs can help identify policy restrictions affecting Syslog services.
Incorrect Device Configuration
Sending devices may be configured incorrectly.
Common configuration mistakes include:
- Wrong destination IP
- Incorrect destination port
- Disabled Syslog forwarding
- Unsupported transport protocol
- Incorrect facility selection
- Excessively restrictive severity filtering
Verifying the sender configuration often resolves collection problems quickly.
Duplicate Events
Duplicate log entries can occur when:
- Multiple forwarding paths exist
- Devices send identical logs to multiple collectors
- Log files are monitored more than once
- Multiple decoders process the same event
Also, duplicate events increase storage usage and may generate redundant alerts if not addressed.
Troubleshooting Workflow
A consistent troubleshooting methodology helps identify problems efficiently.
Verify Connectivity
Begin by confirming basic network communication between the sending device and the Wazuh server.
Verify:
- IP connectivity
- DNS resolution
- Network routes
- Firewall rules
- Port accessibility
Connectivity testing eliminates many infrastructure-related causes early in the investigation.
Confirm Listener Status
Next, verify that Wazuh or the Syslog service is actively listening on the expected interface and port.
Confirm:
- Service status
- Listening port
- Bound interfaces
- Startup logs
- Configuration syntax
Validate Device Settings
Review the sending device configuration carefully.
Ensure that:
- Destination address is correct
- Transport protocol matches
- Log categories are enabled
- Severity levels are appropriate
- Hostname configuration is correct
A simple configuration typo can prevent all logs from reaching the collector.
Inspect Wazuh Logs
The Wazuh Manager logs often provide detailed information about parsing failures, decoder issues, configuration problems, and communication errors.
Reviewing these logs can quickly identify whether events are arriving but failing during processing.
Test with Sample Events
Finally, generate known test events from the sending device.
Testing with controlled events helps verify:
- Network transport
- Syslog reception
- Event parsing
- Rule evaluation
- Dashboard visibility
Working through the pipeline step by step makes it easier to isolate the exact point of failure.
Related Guides:
Configuring Log Retention
Log retention is an essential part of any log management strategy.
While collecting logs enables real-time detection, retaining them for appropriate periods supports incident investigations, compliance audits, trend analysis, and digital forensics.
An effective retention policy balances regulatory requirements, storage costs, search performance, and operational needs.
For implementation guidance, see How to Configure Wazuh Log Retention.
Why Retention Matters
Compliance
Many regulatory frameworks require organizations to retain logs for defined periods.
Examples include:
- PCI DSS
- HIPAA
- ISO/IEC 27001
- SOC 2
- GDPR (where applicable)
Meeting retention requirements helps demonstrate accountability during audits and investigations.
Storage Management
Without retention policies, log storage grows continuously.
Effective retention planning helps organizations:
- Control storage costs
- Predict infrastructure requirements
- Prevent disk exhaustion
- Optimize OpenSearch clusters
Regularly deleting or archiving older data ensures the platform remains sustainable as log volumes increase.
Forensics
Historical logs are invaluable during incident response.
Security teams frequently investigate events that occurred weeks or months before detection.
Retaining sufficient historical data allows investigators to:
- Reconstruct attacker timelines
- Identify initial compromise
- Track lateral movement
- Determine affected systems
- Support legal or regulatory investigations
Performance
Very large indexes can negatively impact search performance.
Proper retention strategies help maintain:
- Faster searches
- Quicker dashboard loading
- Lower resource consumption
- Improved indexing efficiency
- Better cluster stability
Separating active and archived data also reduces operational overhead.
Retention Strategies
Several complementary strategies help organizations manage long-term log storage efficiently.
OpenSearch Index Lifecycle Management
OpenSearch Index Lifecycle Management (ILM) automates how indexes age over time.
Policies can automatically:
- Roll over indexes
- Move data between storage tiers
- Compress older indexes
- Delete expired data
Automation reduces administrative effort while ensuring retention policies remain consistent.
Index Rotation
Rather than storing all events in a single index, organizations typically rotate indexes on a schedule.
Common rotation intervals include:
Smaller indexes improve maintenance operations and simplify retention management.
Compression
Older log data is accessed less frequently.
Compressing historical indexes reduces disk usage while preserving searchable information.
Compression is particularly valuable in environments generating terabytes of log data each month.
Archiving
Logs that are no longer needed for daily operations can be archived to lower-cost storage.
Archived logs remain available for:
- Compliance requests
- Historical investigations
- Legal discovery
- Long-term auditing
Automated archiving helps reduce operational storage costs while preserving important records.
Long-Term Storage
Organizations with strict regulatory requirements often retain logs for multiple years.
Long-term storage solutions may include:
- Object storage
- Cold storage tiers
- Backup repositories
- Offline archival systems
A layered storage strategy allows frequently accessed data to remain searchable in OpenSearch while older logs are preserved in more economical storage platforms.
Improving Log Quality
Collecting large volumes of logs does not automatically improve security.
In fact, excessive noise can overwhelm analysts, increase storage costs, and make genuine threats more difficult to identify.
High-quality logging focuses on collecting relevant events, reducing unnecessary data, and ensuring logs contain enough context for accurate detection and investigation.
Wazuh provides several mechanisms to improve log quality, including filtering, custom decoders, rule tuning, and log enrichment.
Regularly reviewing log sources and detection logic helps maintain a high signal-to-noise ratio as your environment evolves.
Reducing Noise
Reducing unnecessary log data allows security teams to focus on meaningful events while improving system performance.
Ignore Unnecessary Logs
Not every log generated by an operating system or application provides security value.
Examples of low-value events include:
- Routine informational messages
- Successful health checks
- Scheduled maintenance tasks
- Frequent service status updates
- Application debug logs in production
Carefully excluding these events reduces storage requirements and simplifies investigations.
Filter Repetitive Events
Some events occur thousands of times each day without indicating malicious activity.
Common examples include:
- Successful user logins
- Routine service startups
- Scheduled backup jobs
- Periodic synchronization tasks
Filtering repetitive events prevents dashboards from becoming cluttered while preserving higher-value security data.
Exclude Temporary Files
Applications often generate temporary logs that provide little long-term value.
Examples include:
- Cache files
- Temporary directories
- Installer logs
- Session files
- Development artifacts
Excluding these files reduces unnecessary file monitoring and lowers resource consumption.
Tune Decoders
Decoders determine how raw log data is interpreted.
Well-designed decoders:
- Extract relevant fields
- Ignore unnecessary data
- Normalize inconsistent formats
- Improve downstream rule matching
Organizations monitoring custom applications should periodically review decoder performance as log formats evolve.
Optimize Rules
Detection rules should balance sensitivity and specificity.
Overly broad rules can generate false positives, while overly restrictive rules may miss genuine threats.
Regular rule tuning should include:
- Reviewing frequently triggered rules
- Adjusting thresholds
- Suppressing known benign activity
- Updating rule logic for new attack techniques
Maintaining accurate detection logic reduces analyst fatigue and improves incident response.
Improving Detection Accuracy
High-quality logs become significantly more valuable when they include consistent structure and rich contextual information.
Structured Logging
Structured logging stores events using standardized fields instead of unstructured text.
Benefits include:
- Faster searching
- Improved filtering
- Consistent parsing
- Easier dashboard creation
- Better correlation
JSON has become the preferred format for many modern applications because it provides structured, machine-readable data.
Custom Decoders
Commercial software often includes built-in decoders, but internally developed applications typically require custom parsing logic.
Custom decoders allow organizations to extract application-specific fields such as:
- Customer IDs
- Transaction identifiers
- Session tokens
- Business workflow states
- API endpoints
This additional context improves both investigations and automated detections.
Custom Rules
Custom rules extend Wazuh beyond its default detection capabilities.
Examples include:
- Monitoring proprietary applications
- Detecting organization-specific attack patterns
- Identifying unauthorized administrative actions
- Monitoring sensitive business processes
Tailoring rules to the organization’s environment significantly improves detection accuracy.
Log Enrichment
Log enrichment adds valuable context before or during analysis.
Examples include:
- Asset ownership
- Geographic information
- Threat intelligence reputation
- User department
- Business criticality
- MITRE ATT&CK mappings
Enriched logs enable analysts to prioritize incidents more effectively and reduce investigation time.
Performance Optimization for Large Log Volumes
As organizations grow, their logging infrastructure must scale to handle increasing numbers of endpoints, applications, and network devices.
High-volume environments may process millions of events per day, making performance optimization essential for maintaining timely detection and responsive search capabilities.
Optimizing Wazuh involves scaling the collection infrastructure, tuning OpenSearch, and monitoring the health of the entire ingestion pipeline.
Scaling Log Collection
Scaling should be planned before log volumes begin affecting system performance.
Distributed Agents
Deploying Wazuh Agents across monitored systems distributes collection workloads close to the data source.
This approach offers several benefits:
- Lower network overhead
- Near real-time event forwarding
- Reduced centralized processing
- Improved scalability
Distributed collection also minimizes the risk of losing events during temporary network interruptions.
Load Balancing
Large deployments often distribute agent traffic across multiple Wazuh Managers using load balancers.
Benefits include:
- Higher availability
- Improved fault tolerance
- Better workload distribution
- Simplified maintenance
Load balancing also allows organizations to expand capacity incrementally as monitoring requirements grow.
Clustered Managers
Wazuh supports clustered manager deployments that improve scalability and resilience.
A clustered architecture enables:
- Shared workload processing
- High availability
- Simplified scaling
- Reduced single points of failure
This architecture is particularly beneficial for enterprise environments managing thousands of monitored systems.
Optimizing OpenSearch
Because OpenSearch stores and indexes processed events, its performance has a direct impact on dashboard responsiveness and investigation speed.
Shard Sizing
Choosing an appropriate shard size helps balance indexing performance and search efficiency.
Too many small shards increase cluster overhead, while excessively large shards can slow queries and recovery operations.
Shard planning should account for:
- Daily log volume
- Retention period
- Available hardware
- Expected growth
Regular index reviews help maintain optimal shard distribution.
Index Templates
Index templates define settings applied to newly created indexes.
Proper templates ensure:
- Consistent mappings
- Correct analyzers
- Efficient storage settings
- Standardized lifecycle policies
Maintaining standardized templates reduces administrative complexity in large deployments.
Heap Sizing
OpenSearch relies heavily on Java Virtual Machine (JVM) memory.
Insufficient heap allocation can lead to:
- Slow searches
- Long garbage collection pauses
- Node instability
- Cluster performance degradation
Heap sizing should follow OpenSearch recommendations while leaving sufficient memory available for the operating system’s file cache.
Storage Optimization
Efficient storage management improves both performance and cost efficiency.
Best practices include:
- Compressing older indexes
- Using Index Lifecycle Management (ILM)
- Separating hot and warm storage tiers
- Monitoring disk utilization
- Removing obsolete data
These strategies help maintain consistent performance as data volumes grow.
Preventing Log Bottlenecks
Even well-designed environments can experience bottlenecks if log volume exceeds processing capacity.
Continuous monitoring helps identify issues before they impact detection.
Rate Limiting
Some applications can generate extremely high event rates during errors or attacks.
Rate limiting helps prevent:
- Queue overflow
- Resource exhaustion
- Excessive indexing
- Alert floods
It should be used carefully to avoid suppressing genuinely important security events.
Queue Tuning
Internal event queues temporarily buffer incoming logs.
Proper queue sizing helps absorb short bursts of activity while maintaining smooth event processing.
Queue performance should be monitored regularly to identify sustained backlogs.
Monitoring Ingestion
Organizations should continuously monitor ingestion metrics such as:
- Events per second
- Queue depth
- Indexing latency
- Agent communication delays
- Processing failures
Early detection of ingestion slowdowns prevents gaps in monitoring coverage.
Capacity Planning
Capacity planning should account for future growth rather than current workloads alone.
Important considerations include:
- Endpoint growth
- New applications
- Additional cloud services
- Compliance-driven retention increases
- Seasonal traffic patterns
Regular performance assessments help ensure that the logging infrastructure continues to meet operational requirements.
Security Best Practices
Log data often contains sensitive information about users, systems, applications, and security events.
Protecting this data is essential to prevent attackers from tampering with evidence or accessing confidential information.
Organizations should secure the entire logging pipeline, from collection through storage and access, while aligning retention and protection policies with applicable regulatory requirements.
Protecting Log Integrity
TLS Encryption
Encrypt log traffic whenever it traverses untrusted or shared networks.
TLS helps protect logs from:
- Interception
- Tampering
- Session hijacking
- Man-in-the-middle attacks
Encryption is particularly important when forwarding logs between remote offices, cloud environments, and centralized Wazuh deployments.
Secure Agent Communication
Wazuh Agents communicate securely with the Wazuh Manager using encrypted channels.
Organizations should:
- Keep certificates current
- Rotate credentials periodically
- Remove inactive agents
- Monitor agent enrollment
Protecting agent communication ensures that collected events remain trustworthy.
Authentication
Administrative access should require strong authentication.
Recommended practices include:
- Multi-factor authentication (MFA)
- Strong password policies
- Role separation
- Regular credential reviews
- Secure API authentication
Restricting privileged access reduces the risk of unauthorized modifications to logging infrastructure.
Access Control
Not every user requires unrestricted access to log data.
Role-based access control (RBAC) should limit permissions according to operational responsibilities.
Typical roles include:
- Security analysts
- Incident responders
- Compliance auditors
- System administrators
- Read-only investigators
Least-privilege access reduces both insider risk and accidental changes.
Compliance Considerations
Many organizations deploy Wazuh to support regulatory compliance requirements.
Although Wazuh can assist with compliance monitoring, organizations remain responsible for implementing policies and controls that satisfy the applicable standard.
PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) requires organizations handling payment card data to:
- Collect security logs
- Monitor privileged activity
- Retain audit records
- Review logs regularly
Centralized logging helps demonstrate these controls during compliance assessments.
HIPAA
Healthcare organizations subject to HIPAA should retain audit logs that record access to systems containing protected health information (PHI).
Monitoring authentication events, administrative activity, and system changes supports audit requirements and incident investigations.
ISO 27001
ISO/IEC 27001 emphasizes logging and monitoring as part of an organization’s information security management system (ISMS).
Maintaining centralized logs supports:
- Security monitoring
- Incident response
- Continuous improvement
- Risk management
SOC 2
Organizations pursuing SOC 2 certification commonly implement centralized logging to demonstrate:
- Security monitoring
- Change tracking
- Access auditing
- Incident detection
Comprehensive logging provides evidence that security controls operate as intended.
GDPR
The General Data Protection Regulation (GDPR) requires organizations processing personal data to implement appropriate technical and organizational safeguards.
When logs contain personal information, organizations should consider:
- Data minimization
- Access restrictions
- Defined retention periods
- Secure deletion
- Encryption where appropriate
Balancing security monitoring with privacy obligations is an important aspect of GDPR compliance.
Common Wazuh Logging Issues
Even well-designed Wazuh deployments occasionally experience logging problems.
Most issues stem from configuration errors, resource constraints, parser mismatches, or infrastructure bottlenecks rather than software defects.
A systematic troubleshooting approach helps identify root causes quickly and restore reliable log collection.
Missing Logs
Missing events are often caused by:
- Disabled log collection
- Incorrect file paths
- Network connectivity problems
- Agent communication failures
- Firewall restrictions
- Misconfigured Syslog forwarding
When investigating missing logs, verify each stage of the ingestion pipeline from the source system to the Wazuh Dashboard.
Duplicate Events
Duplicate logs may occur when:
- Multiple agents monitor the same file
- Syslog forwarding is configured more than once
- Multiple collection methods overlap
- Duplicate decoders process identical events
Reviewing collection policies helps eliminate unnecessary duplication.
High CPU During Log Collection
High CPU usage commonly results from:
- Excessive log volume
- Inefficient custom rules
- Complex regular expressions
- Monitoring unnecessary files
- Large decoder workloads
Reducing noisy logs and optimizing detection rules often resolves CPU-related issues.
High Disk Usage
Rapid storage growth may indicate:
- Excessive retention periods
- Duplicate indexing
- Large volumes of debug logs
- Inefficient index lifecycle policies
Regular storage reviews help maintain sustainable disk utilization.
Related Guide: How to Configure Wazuh Log Retention
Delayed Log Ingestion
Delays between event generation and dashboard visibility may result from:
- Network congestion
- Queue backlogs
- OpenSearch indexing delays
- Resource exhaustion
- Heavy search workloads
Monitoring ingestion latency helps identify bottlenecks before they affect detection capabilities.
Incorrect Event Parsing
Logs that are parsed incorrectly often produce incomplete or inaccurate fields.
Common causes include:
- Vendor format changes
- Unsupported log versions
- Malformed events
- Incorrect decoder selection
Regular validation ensures detection rules continue operating as expected after application updates.
Decoder Failures
Custom decoders may fail because of:
- Syntax errors
- Incorrect regular expressions
- Unexpected log formats
- Missing parent decoders
- Configuration conflicts
Testing decoder changes before production deployment reduces the risk of processing failures.
Rule Matching Problems
Events may fail to trigger alerts when:
- Required fields are missing
- Decoder output is incomplete
- Rule conditions are overly restrictive
- Severity thresholds are too high
- Rules execute in an unexpected order
Periodically reviewing detection logic and testing representative log samples helps maintain accurate alerting.
Related Guides:
Common Wazuh Logging Issues
Even in well-architected deployments, Wazuh log pipelines can experience disruptions due to configuration drift, infrastructure constraints, or changes in log formats.
Most issues are not caused by Wazuh itself, but by mismatches between data sources, network conditions, and processing capacity.
A structured troubleshooting approach, starting at the source and moving through collection, processing, and indexing, typically resolves the majority of logging problems quickly.
Missing Logs
Missing logs indicate that events are not reaching the Wazuh Manager or are being dropped during processing.
Common causes include:
- Agent not running or disconnected
- Incorrect file paths in log configuration
- Syslog forwarding misconfiguration
- Firewall blocking traffic to port 514
- Network segmentation issues
- Disabled log collection modules
When investigating missing logs, validate each stage of the pipeline: source generation → transport → ingestion → decoding → indexing.
Related Guides:
Duplicate Events
Duplicate events inflate storage usage and can distort detection accuracy.
Typical causes include:
- Multiple agents monitoring the same log source
- Syslog forwarding configured to multiple destinations
- Overlapping file monitoring rules
- Reprocessing of rotated logs
- Redundant decoder pipelines
Eliminating duplication requires reviewing both agent configuration and centralized Syslog ingestion paths.
High CPU During Log Collection
High CPU usage usually indicates inefficient log processing or excessive event volume.
Common contributors:
- Overly broad file monitoring patterns
- High-frequency noisy logs
- Complex regular expressions in decoders
- Inefficient custom rules
- Burst traffic from Syslog sources
Optimizing filters and reducing unnecessary log sources often resolves CPU spikes.
High Disk Usage
Excessive disk consumption is typically related to retention or indexing policies.
Common causes include:
- Long retention periods without lifecycle management
- Large volumes of debug or verbose logs
- Lack of index rotation
- Duplicate event ingestion
- Inefficient compression settings
Reviewing storage growth trends helps prevent unexpected capacity exhaustion.
Delayed Log Ingestion
Latency between event generation and visibility in the Wazuh Dashboard can impact incident response.
Common causes include:
- Queue backlogs in Wazuh Manager
- OpenSearch indexing delays
- Network congestion
- Agent communication lag
- CPU or memory saturation
Monitoring ingestion throughput and queue depth is essential for identifying bottlenecks early.
Incorrect Event Parsing
Incorrect parsing leads to incomplete or misclassified events, reducing detection accuracy.
Typical causes include:
- Log format changes from vendors
- Unsupported application versions
- Malformed or truncated logs
- Misconfigured decoders
- Incorrect field extraction logic
Regular validation of decoders against real-world log samples helps prevent parsing drift.
Decoder Failures
Decoder failures occur when Wazuh cannot interpret incoming log structures.
Common issues include:
- Broken regular expressions
- Missing parent decoder references
- Unexpected log schema changes
- Syntax errors in custom decoders
Testing decoder updates in a staging environment is strongly recommended before production deployment.
Rule Matching Problems
Rule matching issues result in missing alerts or incorrect classifications.
Common causes include:
- Missing decoded fields required by rules
- Overly strict rule conditions
- Incorrect rule ordering or inheritance
- Misconfigured thresholds
- Changes in log structure affecting matching logic
Periodic rule audits ensure detection logic remains aligned with evolving infrastructure.
Wazuh Log Management Best Practices
A well-designed Wazuh deployment is not defined by the number of logs it collects, but by how effectively it filters, processes, and retains meaningful security data.
Following best practices ensures scalability, performance, and reliable detection across all monitored systems.
Collect only necessary logs
Collecting everything increases noise and resource usage without improving security visibility.
Focus on:
- Authentication events
- Privilege changes
- Network activity
- Security-relevant application logs
- System and kernel events
Avoid unnecessary debug or verbose logging in production environments.
Standardize log formats where possible
Standardization improves parsing efficiency and reduces decoder complexity.
Best practices include:
- Using JSON for application logs
- Aligning timestamp formats
- Consistent hostname conventions
- Uniform field naming
Standardization simplifies correlation across heterogeneous systems.
Use secure log transport
Log integrity is critical for trustworthy security monitoring.
Use secure transport mechanisms such as:
- TLS-encrypted Syslog
- Encrypted agent communication
- Secure API channels
- Certificate-based authentication
This prevents tampering and interception of sensitive security data.
Regularly review log retention policies
Retention requirements change over time due to regulatory updates, storage constraints, and operational needs.
Regular reviews help ensure:
- Compliance alignment
- Cost optimization
- Efficient storage utilization
- Proper forensic coverage
Related Guide: How to Configure Wazuh Log Retention
Tune rules to reduce false positives
Excessive false positives reduce analyst efficiency and increase alert fatigue.
Improve rule quality by:
- Adjusting thresholds
- Suppressing known benign behavior
- Refining conditions
- Updating rule logic for new attack patterns
Continuous tuning ensures alerts remain actionable.
Monitor ingestion performance
Log ingestion should be continuously monitored to detect bottlenecks early.
Key metrics include:
- Events per second
- Queue depth
- Indexing latency
- Agent connectivity
- OpenSearch performance
Early detection of performance degradation prevents data loss.
Archive historical logs
Not all logs need to remain in hot storage.
Archiving enables:
- Lower storage costs
- Long-term retention compliance
- Reduced OpenSearch load
- Efficient historical investigations
Cold storage solutions are ideal for long-term archival data.
Test new log sources before production deployment
New log sources should always be validated before full-scale deployment.
Testing ensures:
- Correct parsing
- Accurate decoding
- Proper rule matching
- Acceptable performance impact
Staging environments reduce the risk of introducing noisy or malformed data into production.
Continuously review storage utilization
Log volumes grow over time, often unexpectedly.
Ongoing monitoring helps:
- Prevent disk exhaustion
- Optimize index lifecycle policies
- Adjust retention windows
- Forecast infrastructure needs
Capacity planning should be an ongoing process rather than a one-time setup.
Frequently Asked Questions (FAQ)
Question: What is Wazuh log management?
Wazuh log management is the process of collecting, normalizing, analyzing, and storing logs from endpoints, servers, network devices, and applications to detect security threats and operational issues in real time.
Question: What types of logs can Wazuh collect?
Wazuh can collect logs from Windows, Linux, macOS, Syslog devices, firewalls, web servers, cloud platforms, and custom applications.
Question: Does Wazuh support Windows Event Logs?
Yes. Wazuh natively collects Windows Event Logs including Security, System, Application, PowerShell, and Sysmon channels.
Question: Can Wazuh collect Syslog messages?
Yes. Wazuh can act as a centralized Syslog server and ingest logs from a wide range of network and infrastructure devices.
Question: Can Wazuh collect firewall logs?
Yes. Wazuh supports firewall logs from platforms such as pfSense, Cisco ASA, Fortinet, Palo Alto, Sophos, and MikroTik.
Question: Does Wazuh support Apache access and error logs?
Yes. Wazuh can monitor Apache access logs, error logs, and SSL-related logs for security and operational analysis.
Question: How do I configure centralized logging in Wazuh?
Centralized logging is typically configured using Syslog forwarding for network devices and Wazuh Agents for endpoints, combined with decoders and rules for processing.
Related Guide: How to Configure Wazuh as a Centralized Syslog Server
Question: Why is Wazuh not receiving Syslog messages on port 514?
Common causes include firewall blocking, incorrect device configuration, service not listening on port 514, or network connectivity issues.
Related Guide: Troubleshoot Wazuh Syslog Port 514 Ingestion
Question: How long should I retain Wazuh logs?
Retention depends on compliance requirements, but common ranges are 30 days to several years depending on industry regulations and forensic needs.
Question: Can Wazuh handle high-volume log ingestion?
Yes. Wazuh can scale to handle high event volumes when properly configured with optimized indexing, clustering, and resource allocation.
Question: Does Wazuh support custom log formats?
Yes. Custom decoders and rules allow Wazuh to parse virtually any structured or unstructured log format.
Question: What is the difference between decoders and rules?
Decoders extract structured fields from raw logs, while rules evaluate decoded data to determine whether an alert should be generated.
Question: How do I reduce unnecessary log noise?
Noise reduction can be achieved by filtering low-value events, tuning rules, excluding unnecessary logs, and standardizing log sources.
Question: Can Wazuh be used for compliance log retention?
Yes. Wazuh supports long-term log storage and integration with retention policies required for standards such as PCI DSS, HIPAA, and ISO 27001.
Conclusion
Wazuh log management provides a unified framework for collecting, processing, analyzing, and retaining security and operational logs across diverse IT environments.
By centralizing log data, organizations gain real-time visibility into security events, improved incident response capabilities, and stronger compliance alignment.
Key Takeaways
- Wazuh centralizes logs from endpoints, network devices, applications, and cloud platforms into a unified security platform.
- Effective log management depends on proper collection, decoding, rule tuning, and retention policies.
- Syslog and agent-based collection form the backbone of scalable log ingestion architectures.
- Performance, storage, and detection accuracy must be continuously optimized as environments grow.
Building a Scalable Wazuh Log Management Strategy
A scalable strategy involves:
- Structured log collection across all infrastructure layers
- Efficient parsing using decoders and rules
- Centralized indexing in OpenSearch
- Tiered retention and archiving strategies
- Continuous performance monitoring and tuning
Continuous Monitoring, Tuning, and Retention Optimization
Wazuh deployments are not static systems.
They require ongoing refinement to maintain effectiveness.
Regular tuning of rules, decoders, and storage policies ensures the platform continues to provide high-fidelity security visibility without excessive noise or resource overhead.
Related In-Depth Guides
Be First to Comment