I would like to propose adding native support for the OpenTelemetry Protocol (OTLP) for direct export of logs and alerts in Suricata. There is already a clear demand from the community: vendors such as Coralogix publish detailed guides showing how to send Suricata logs to OpenTelemetry backends using OpenTelemetry Collector as a bridge (e.g., tailing the eve.json file). This demonstrates that users want this integration, but the current approach is unnecessarily complex and prone to failure. Relying on a separate OpenTelemetry Collector to monitor (tail) the eve.json file adds extra deployment steps, increased configuration overhead, and additional points of failure. In Kubernetes environments, this often means running another sidecar or DaemonSet just for log forwarding. Furthermore, it introduces disk I/O latency that could be eliminated with direct export. OpenTelemetry is the de facto standard for observability (CNCF project), and implementing it keeps Suricata aligned with modern infrastructure practices.
The configuration would be clean and self-contained in a dedicated block in suricata.yaml, similar to existing outputs (such as eve-log, syslog, etc.).
Furthermore, in many corporate or regulated environments, it is not possible or simply not allowed to install additional agents (such as OpenTelemetry Collector). Native support for OTLP would allow this information to be sent directly to modern observability platforms — such as Coralogix, New Relic, Splunk, Grafana Labs (Loki/Tempo/Mimir) and others — in a simple, secure and less complex way. This would give network managers and SOC teams much more options and flexibility in implementing visualisation, correlation, alerts, and dashboards, without relying on intermediate components.
I believe this functionality would greatly benefit the entire Suricata community — from small and edge deployments to large SOCs that already adopt OpenTelemetry as their observability standard.
Feel free to open a feature ticket in our ticket tracker.
I think it could be interesting, but I think your post overstates the interest. I think it’s the first time I’ve heard of it. A ticket would be assigned to community, meaning that the team will have no plans to work on it anytime soon.