Wazuh Logcollector

What Wazuh Logcollector Does in the Collection Pipeline

Wazuh Logcollector is the endpoint-side collection layer that gathers local logs before handing them to Wazuh for analysis. In practice, that means it sits close to the source of the event, reducing the need for manual log export and making local activity available to downstream decoding, correlation, and alerting.

That placement matters because collection is the first trust boundary in the pipeline. If logs are not captured consistently at the endpoint, the rest of the platform can only analyse partial evidence, delayed data, or nothing at all.

Why Log Collection Matters for Security Monitoring

Log collection is only useful when it preserves enough context for detection logic to work. A collector that misses file paths, timestamps, process context, or database audit detail can weaken rule matching and make later investigation harder, even if the logs eventually arrive.

In a Wazuh deployment, Logcollector is part of the evidence transport path from host to platform. That makes it foundational to monitoring use cases such as host telemetry, application auditing, and database activity review, where the original event may not remain accessible for long on the source system.

For teams using Wazuh as part of an open source detection stack, the Open Source SIEM and Detection Tools Landscape Guide gives broader context on where Wazuh sits in the tooling landscape and how it fits alongside adjacent detection technologies.

How It Fits with Agents, Managers, and Decoders

Logcollector is not the analyser itself. It feeds the platform, where decoders and rules transform raw log lines into structured security events that can be searched, correlated, and alerted on. This separation is important because it keeps collection lightweight while allowing more flexible analysis later in the chain.

For endpoint coverage, the collector is usually most valuable when paired with the rest of the Wazuh stack, including the agent, manager, indexer, and dashboard. A deployment that understands those roles, and the operational trade-offs between them, is easier to size and tune correctly. The Wazuh Guide covers those components, along with ports, decoders, tuning, and compliance mappings.

Because Wazuh Logcollector is designed to forward local log sources rather than normalise them in place, the quality of downstream detection depends on the quality and completeness of what it forwards. That is why source selection, log retention, and parser coverage all affect the usefulness of the final alert stream.

Why Database Audit Logs Are a Good Use Case

MongoDB audit output is a strong example of why log collection exists at the edge. Database audit trails are often valuable for accountability, change review, and suspicious activity detection, but they are only operationally useful if they are reliably collected from the endpoint and delivered for central analysis.

When a collector forwards database audit events, defenders can correlate account activity, access patterns, and administrative actions with other host telemetry. That combination is often more useful than treating the database logs as a standalone record, because it links data access to the surrounding machine and user activity.

For that reason, Logcollector is best understood as an enabling control for visibility. It does not decide whether an event is suspicious, but it determines whether the platform has the evidence needed to make that judgment.

Related resources from NHI Mgmt Group

• What is the difference between storing security data centrally and using cross-cluster search for remote Wazuh clusters?
• Why does managing Wazuh rulesets through Git and CI/CD reduce operational risk?
• What happens when custom Wazuh rules are deployed without review or conflict checking?
• What should teams do when Wazuh shows new macOS fields as unknown in the dashboard?