Scaling real-time file monitoring with eBPF: How we filtered billions of kernel events per minute

File integrity monitoring must provide more than proof that a file changed: security teams need to know how, why, and by whom it changed. Datadog found that filesystem scans, inotify, and auditd could not provide sufficient context, reliability, or scalability. An eBPF-based approach delivered kernel-level visibility into processes and containers, but required extensive filtering and edge processing to handle more than 10 billion events per minute.

Why Traditional Monitoring Falls Short

• Periodic scans can miss changes that are made and reverted between scans.
• Scans show that a file changed, but not the process, container, or mechanism responsible.
• inotify lacks the system-level context needed to correlate file events with processes and containers.
• auditd offers richer information but can impose significant performance overhead and struggle under heavy load.

eBPF for Context-Rich File Monitoring

• eBPF observes file activity directly in the Linux kernel in real time.
• Events can include:
  • The modified file
  • The process that triggered the change
  • The container in which the process ran
  • Additional security-relevant metadata
• This context makes events more useful for investigations than simple “file changed” notifications.

Scaling at the Agent and Backend

• Datadog observed more than 10 billion file-related events per minute across its infrastructure.
• Each serialized event was approximately 5 KB, making unrestricted transmission infeasible—potentially several terabytes per second.
• Sending every event would also overload Agents through excessive CPU, memory, serialization, and network usage.
• Agent-side rules filter events locally, discarding noise before transmission.
• This reduced the stream to roughly one million events per minute while preserving detection coverage.

Filtering Events in the Kernel

• A basic architecture loads eBPF programs into the Agent, observes system activity, writes events to a ring buffer, and evaluates them in user space.
• Sensitive workloads can generate up to 5,000 relevant syscalls per second.
• Initial implementations risked ring-buffer backlogs and dropped events, creating security blind spots.
• Datadog moved as much evaluation as possible into eBPF programs to reduce the number of events reaching user space.
• The Agent could then perform a deeper second-stage evaluation before forwarding events to the backend.

Two-Stage Evaluation: Approvers and Discarders

• eBPF’s safety constraints limit computation, especially on older Linux kernels.
• The system therefore separates evaluation into:
  • In-kernel filtering: Lightweight decisions that quickly approve or discard events.
  • User-space evaluation: More complex analysis using richer context, correlations, and logic unsuitable for the kernel.
• This design balances kernel safety and performance with the need for detailed security detection.

Datadog’s approach shows that scalable FIM requires combining eBPF’s deep visibility with aggressive filtering at the edge and in the kernel. The practical recommendation is to keep expensive analysis in user space while rejecting irrelevant events as early as possible.