Skip to main content

eBPF

Signals Provided
  • Metrics - Performance metrics from applications and infrastructure
  • Symptoms - Automatic symptom detection from metrics, traces, and external monitoring systems
  • Traces - Distributed traces for service dependency discovery and communication monitoring

eBPF (extended Berkeley Packet Filter) is a cutting-edge Linux kernel technology that allows safe, efficient, and programmable data collection at runtime. It enables deep observability into your system and application behavior without modifying code or adding performance overhead.

Causely leverages OpenTelemetry eBPF instrumentation, powered by Grafana Beyla, to automatically extract rich telemetry data from your services. This zero-effort integration provides actionable insights into service interactions, latencies, and system performance—with zero changes to application code.

How It Works​

Causely's eBPF-based instrumentation follows a streamlined process:

  1. The system inspects running applications to determine which technologies they use.
  2. Once application characteristics are identified, eBPF uprobes are attached to specific user-space functions to capture application-level information, for example HTTP or gRPC calls.
  3. These probes generate events related to the application's traffic, which are then converted into OpenTelemetry metrics and traces.
  4. The collected telemetry is sent to the mediator, which will perform symptom detection, topology discovery and local processing and then send distilled insights to the Causely engine.

This approach supports multiple programming languages including Go, Java, .NET, NodeJS, Python, Ruby, Rust, and more—without requiring any code modifications or language-specific agents.

To learn more about how the automatic instrumentation works, see the Grafana Beyla documentation.

Technical Implementation​

Uprobe-Based Instrumentation​

Causely's eBPF instrumentation uses uprobes exclusively to intercept specific user-space functions within your applications. This approach:

  • Attaches probes to application-level functions (HTTP handlers, gRPC calls, database clients)
  • Does not hook into kernel networking callbacks or the packet datapath
  • Does not act as a CNI or critical network infrastructure component
  • Does not intercept or modify network packets

The instrumentation may inject trace context headers (such as W3C Trace Context) into outgoing requests to enable distributed tracing. However, it does not intercept, block, or route network traffic at the kernel level.

This design choice is intentional. Kernel-level network interception (kprobes on network syscalls) can introduce per-packet latency and increase blast radius. By instrumenting at the application layer, Causely captures the telemetry needed for causal analysis without impacting network connectivity or acting as a critical path component.

Beyla is built on the OpenTelemetry eBPF Instrumentation (OBI) project, which removed kprobe-based collection in favor of uprobe-only approaches (PR #752).

Performance Characteristics​

  • No per-packet overhead: Probes fire on application-level function calls, not network packets
  • Targeted instrumentation: Only specific functions are instrumented, not all syscalls
  • Minimal CPU impact: Overhead is proportional to application request rate, not network traffic volume
  • Fail-safe design: If an agent fails, applications continue to function normally—there is no impact to traffic flow

Configuration​

For automatic instrumentation of Java applications the HotSpot JVM supports dynamic agent loading, allowing you to attach the OpenTelemetry Java agent at runtime, no eBPF required. To enable this functionality modify the causely-values.yaml configuration:

agent:
  beyla:
    global_config:
      ebpf:
        # Enables Java instrumentation with the OpenTelemetry JDK Agent
        use_otel_sdk_for_java: true
    otel_traces_export:
      endpoint: http://mediator.causely:4317

eBPF-based scraping is enabled by default in Causely deployments. If you wish to disable it, you can modify the causely-values.yaml configuration:

scrapers:
  bpf:
    enabled: false
note

If your application is already instrumented with OpenTelemetry, the agent will detect this and not instrument it again.