Wazuh Logcollector is the agent-side module that gathers local log files and forwards them to the Wazuh platform for analysis. In this workflow, it collects MongoDB audit output from the endpoint so the server can correlate, decode, and alert on database activity without manual log handling.
Expanded Definition
Wazuh Logcollector is the endpoint component that watches configured local files, reads new entries, and transmits them to the Wazuh manager for parsing, correlation, and alerting. In practice, it sits inside the agent workflow rather than the central platform, which matters because collection decisions are made close to the source system where the logs are created. For a glossary term like this, the key distinction is between raw log shipping and security analysis: Logcollector only gathers and forwards data, while downstream rules, decoders, and correlation logic determine whether an event becomes actionable.
That distinction aligns with the intent of NIST Cybersecurity Framework 2.0, which treats visibility, monitoring, and response as linked governance outcomes rather than isolated tooling features. Usage in the industry is still evolving around how much preprocessing should occur on the endpoint versus centrally, so definitions vary across deployments. The most common misapplication is treating Logcollector as a complete logging strategy, which occurs when teams assume collection alone provides detection coverage without tuning decoders, retention, and alert rules.
Examples and Use Cases
Implementing Wazuh Logcollector rigorously often introduces endpoint overhead and configuration complexity, requiring organisations to weigh central visibility against the cost of maintaining file monitoring paths, permissions, and parsing expectations.
- A security team collects Linux authentication logs from multiple hosts so failed login bursts can be correlated centrally instead of inspected host by host.
- An administrator forwards MongoDB audit output from database servers to support detection of privileged query changes and administrative activity.
- Cloud workload owners monitor application logs written to local files so Wazuh can raise alerts when specific error patterns indicate abuse or service degradation.
- Incident responders preserve evidence by ensuring high-value logs are shipped before local rotation or host rebuilds remove the original records.
- Compliance teams use the agent path to standardise log ingestion across diverse systems where native forwarding options differ, then validate outcomes against the NIST Cybersecurity Framework 2.0.
These use cases depend on precise file selection, stable permissions, and a clear understanding of which events belong on the endpoint versus in the central SIEM-like workflow. If the wrong files are collected, analysts inherit noise instead of evidence, and if the right files are not collected, detections fail silently.
Why It Matters for Security Teams
For security teams, Wazuh Logcollector is important because it determines whether meaningful endpoint evidence reaches the monitoring pipeline in time to support detection and response. If collection is incomplete, inconsistent, or too narrowly scoped, correlation rules will miss events that matter, and responders may only discover the gap during an investigation. This is especially relevant where logs capture database admin actions, authentication attempts, or configuration changes that cannot be reconstructed later.
The identity and access connection is practical rather than abstract: logs often provide the only proof that a human or non-human actor used a credential, token, or service account in a certain way. When organisations rely on NHI-heavy environments, missing agent-side telemetry can leave automated activity opaque until a compromise, outage, or audit finding exposes the gap. In that sense, Logcollector supports not just monitoring but also accountability across systems that generate security-relevant records. Organisations typically encounter the operational impact only after an incident review reveals that critical endpoint logs were never forwarded, at which point Logcollector becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Log collection supports continuous monitoring of assets and events. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit events must be defined so collection tools know what to gather. |
| OWASP Non-Human Identity Top 10 | NHI telemetry depends on collecting logs that show non-human identity activity. |
Forward service-account and token-use logs so NHI behavior remains attributable.
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?
