Skip to main content
OpenSRE uses eBPF (extended Berkeley Packet Filter) to observe execution behavior directly from the Linux kernel. This approach enables high-fidelity visibility with minimal overhead, while maintaining strong safety and security guarantees. This page explains why eBPF is used, what OpenSRE observes, what it does not observe, and how security is enforced.

​
Why OpenSRE uses eBPF

Traditional observability approaches depend on logs, metrics exporters, or application-level instrumentation. These methods rely on what software chooses to expose and often miss behavior in short-lived processes, external binaries, or between metric collection intervals. eBPF allows OpenSRE to observe execution where it actually happens, at the boundary between user processes and the operating system. Using eBPF, OpenSRE can:
  • Observe syscalls, scheduling events, and I/O activity
  • Track process lifecycles across containers and hosts
  • Capture execution behavior without modifying application code
  • Work across languages, frameworks, and binaries
This makes eBPF well suited for scientific and ML workloads that rely on many heterogeneous tools.
How OpenSRE works: observing execution at the kernel level using eBPF

​
Safety model

eBPF programs are subject to strict safety constraints enforced by the Linux kernel. OpenSRE’s use of eBPF follows these principles:
All eBPF programs are validated by the kernel verifier before execution. Programs that fail verification cannot run.
eBPF programs run in a restricted environment and cannot access arbitrary memory or crash the kernel.
OpenSRE does not load kernel modules or modify kernel code.
OpenSRE attaches only to well-defined kernel hooks such as system call boundaries and scheduler events.
These guarantees are provided by the kernel itself and apply regardless of how OpenSRE is configured.

​
What OpenSRE observes

OpenSRE observes execution metadata, not application data.

CPU & scheduling

CPU usage and scheduling behavior

Memory

Memory usage and peak memory

I/O activity

Disk and network I/O activity

Process lifecycle

Process start, stop, and parent–child relationships

Container context

Container, namespace, and cgroup context
This data is used to reconstruct execution timelines and resource usage patterns.

​
What OpenSRE does not observe

OpenSRE explicitly does not collect:
  • Application payloads or scientific input/output data
  • File contents or data values
  • Source code or function-level execution traces
  • Environment variables or secrets
  • Application- or domain-level interpretation of what a command does
While OpenSRE can observe which binaries and commands were executed, it does not inspect the data those commands operate on or infer application semantics.

​
Data handling and isolation

OpenSRE separates data collection from analysis.
  • Execution signals are captured locally and processed into structured telemetry
  • Only metadata required for analysis is transmitted
  • Payload data is never inspected or exported
  • Correlation is based on operating system identifiers (PIDs, cgroups, namespaces)
This design minimizes data exposure while preserving execution insight.

​
Performance considerations

OpenSRE’s eBPF-based collection is designed to minimize overhead:

Low latency

eBPF probes execute in kernel space with low latency

Efficient filtering

Event filtering reduces data volume at the source

Scales well

Collection overhead remains low even with many short-lived processes

No re-runs

No pipeline re-runs are required to obtain telemetry
Measured overhead depends on workload characteristics but is typically low enough for continuous use in production environments.

​
Security boundaries

OpenSRE is intentionally scoped.
It does not:
  • Modify application behavior
  • Control execution or scheduling
  • Start, stop, or change resources
  • Replace IAM, RBAC, or cloud security controls
Security ownership remains with the operating system, container runtime, and cloud provider. OpenSRE observes execution behavior within those boundaries.

​
When to read this page

This page is most relevant if you:
  • Need to understand how OpenSRE observes execution safely
  • Operate in regulated or security-sensitive environments
  • Evaluate eBPF-based tooling for production systems
  • Want clarity on what data OpenSRE does and does not collect

OpenSRE/collect
Implementation details

OpenSRE/tune
Execution analysis and optimization

OpenSRE/sweep
Cloud waste discovery