> ## Documentation Index > Fetch the complete documentation index at: https://opensre.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # eBPF and security > How Tracer observes execution safely and securely Tracer 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 Tracer observes, what it does not observe, and how security is enforced. ## Why Tracer 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 Tracer to observe execution where it actually happens, at the boundary between user processes and the operating system. Using eBPF, Tracer 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 Tracer works: observing execution at the kernel level using eBPF ## Safety model eBPF programs are subject to strict safety constraints enforced by the Linux kernel. Tracer'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. Tracer does not load kernel modules or modify kernel code. Tracer 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 Tracer is configured. ## What Tracer observes Tracer observes execution metadata, not application data. CPU usage and scheduling behavior Memory usage and peak memory Disk and network I/O activity Process start, stop, and parent–child relationships Container, namespace, and cgroup context This data is used to reconstruct execution timelines and resource usage patterns. ## What Tracer does not observe **Tracer 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 Tracer 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 Tracer 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 Tracer's eBPF-based collection is designed to minimize overhead: eBPF probes execute in kernel space with low latency Event filtering reduces data volume at the source Collection overhead remains low even with many short-lived processes 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 Tracer 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. Tracer observes execution behavior within those boundaries. ## When to read this page This page is most relevant if you: * Need to understand how Tracer observes execution safely * Operate in regulated or security-sensitive environments * Evaluate eBPF-based tooling for production systems * Want clarity on what data Tracer does and does not collect Tracer/collect
Implementation details Tracer/tune
Execution analysis and optimization Tracer/sweep
Cloud waste discovery