Wazuh is one of the most widely deployed open-source security platforms. It runs agents on your servers, collects security events, and stores them in Elasticsearch. The problem is the same one every SIEM has: a wall of alerts that someone has to manually triage.
BitSentry’s Wazuh integration connects directly to your Wazuh Elasticsearch indices, pulls security alerts, and feeds them into the same root cause analysis pipeline that handles application errors.
What the integration does
Wazuh stores security alerts in Elasticsearch indices (typically wazuh-alerts-*). BitSentry queries these indices directly and pulls alert data including:
- Agent information (which server triggered the alert)
- Rule description (what Wazuh detected)
- Timestamps
- Full log payloads
- Alert severity
This data becomes another signal in BitSentry’s investigation pipeline, alongside application errors from Sentry and SSH log analysis.
Two query modes
The integration supports two ways to pull data:
Search mode lets you run Elasticsearch query_string queries against Wazuh indices. If you know what you’re looking for (a specific rule ID, agent name, or time window), this gives you direct access.
Collector mode runs date-based collection with agent filtering. You specify a time range and optionally include or exclude agents by name pattern. Useful for scheduled ingestion where you want all alerts from your production fleet over the last hour, minus your development machines.
Both modes return paginated results (default 100 per page, configurable up to 1000) with full source data.
How it connects
BitSentry authenticates with Wazuh using basic auth (username and password) to get a session token. Then it queries the Elasticsearch indices directly using their own credentials (which can be separate from the Wazuh API credentials).
This two-layer auth setup matches how most Wazuh deployments work: the Wazuh API handles management, and the underlying Elasticsearch handles data queries.
Health checks run before each query to verify connectivity. If your Wazuh deployment is unreachable, BitSentry shows the error immediately instead of silently dropping alerts.
Why this matters
Most ops teams handle application errors and security alerts in separate workflows. Sentry errors go to the dev team, Wazuh alerts go to the security team, and nobody connects the two when a security event causes an application failure.
BitSentry puts both signals in the same investigation. When a server starts throwing 500 errors and Wazuh simultaneously detects a brute-force attempt on the same host, the AI and the responder see that context together instead of triaging two separate queues.
Setting it up
- Add your Wazuh API URL and credentials in BitSentry’s integration settings
- Add your Elasticsearch index URL and credentials (if different from the Wazuh API)
- Configure the index pattern (defaults to the Wazuh 4.x dated form
wazuh-alerts-4.x-{date}; you can override withwazuh-alerts-*or any other pattern) - Set up agent filters if you want to include or exclude specific servers
BitSentry verifies connectivity to both the Wazuh API and Elasticsearch during setup. If either connection fails, you’ll know immediately.
When to use this
The Wazuh integration is most useful for teams that:
- Run Wazuh in production and want security alerts correlated with application errors
- Need to triage security events faster than manually reading Kibana dashboards
- Want a single investigation pipeline for both ops and security incidents
If your Wazuh deployment generates hundreds of alerts per day and your team doesn’t have a dedicated security analyst triaging them full-time, this integration turns that alert volume into root cause analysis you can act on.