eBPF mode (zero-code)

The sensor is a per-node DaemonSet, installed by the Helm chart and on by default, that observes every service on the cluster without touching application code:

Container	What it does
obi	OpenTelemetry eBPF Instrumentation — zero-code traces + RED metrics for every HTTP/gRPC service
otel-agent	Node collector — zero-config log collection (tails every container's stdout/stderr, adds Kubernetes metadata, derives the service name from the workload)

What you get for free

• Service map (who talks to whom — edges derived from zero-code traces)
• RED metrics (Rate, Errors, Duration) per service
• Logs for every pod, correlated to traces where a trace_id is present

Per-edge network flows (bytes now; RTT and retransmits later) come from OBI's built-in network feature, enabled by config on the same sensor.

Requirements

• Linux kernel ≥ 5.8 with BTF for the eBPF containers. A preflight initContainer checks each node and warns loudly but never blocks — on unsupported nodes, log collection keeps working while zero-code tracing is unavailable.
• The OBI container runs privileged by default for reliability across container runtimes. Set sensor.obi.privileged=false to use a least-privilege capability set instead (kernel ≥ 5.11; see Security).

Tuning (Helm values)

Value	Default	Effect
sensor.enabled	true	The whole DaemonSet on/off
sensor.obi.enabled	true	Zero-code traces + RED on/off
sensor.obi.privileged	true	Privileged vs capability-set security context
sensor.agent.logs.enabled	true	stdout/stderr log collection on/off
sensor.nodeSelector / sensor.tolerations	—	Node placement

The platform's own namespace is always excluded from collection, and HTTP route cardinality is bounded by heuristic route grouping.

When to add OTLP

eBPF can't see inside a process. For DB statements, business attributes and custom spans, add an OTLP SDK and use the OTLP bridge. eBPF and OTLP spans share the same storage and service identity.