open-telemetry/opentelemetry-ebpf-instrumentation

What happened ProcessTracer.log (pkg/ebpf/tracer.go) is assigned exactly once, lazily, inside Run(): https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/v0.12.2/pkg/ebpf/tracer_linux.go#L112 func (pt *ProcessTracer) Run(...) { pt.log = ptlog().With("type", pt.Type) ... Run() is invoked asynchronously and, for a "generic"-type tracer, exactly once — the first time traceAttacher's shared reusableTracer is created for a node (any non-language-instrumented process — shell scripts, coreutils, busybox multi-call binaries, etc. — shares one ProcessTracer). Any code path that calls into pt.log before that Run() goroutine has actually executed its first line dereferences a nil *slog.Logger and panics — the whole process crashes with an unrecovered panic (exit code 2). Two call sites in UnlinkExecutable can hit this: func (pt *ProcessTracer) UnlinkExecutable(info *exec.FileInfo, generation uint64) { ... i, ok := pt.Instrumentables[key] if !ok { pt.log.Warn("U

Component OBI (eBPF instrumentation) What happened? Context: #2431 The verifier fails when CAP_PERFMON is missing and the full verifier log is dumped to stdout What did you expect to happen? A clear error message signaling the missing capability should be printed out Steps to reproduce / OBI configuration Relevant logs Additional context No response Version No response Kernel version No response OS / Distribution No response Deployment None

There are known offsets of embedded Go struct types or offsets of the Go slice length and size, which are referenced just as 8 or 16 in the code. We should declare these are known constants and use them through out the Go BPF code, instead of 8. 8 is confusing because people reading the code may think it's an offset we should be pulling from the offsets map.

Functions like detectGenericProtocol and detectHeuristicProtocol are synchronously invoked between ringbuf reads (invoked deep inside rbf.parse ) and might take some CPU time doing a check after another. It might be contributing to the RingBufForwarder not being able to read all the messages under some high-load scenarios. I'd suggest creating a user-configurable option that would let the user defining the actual protocols we should check and don't look for the ones that are not in that map. By default, we would check for all the protocols but users noticing ringbuffer drops could decide whether not to check protocols they know they aren't going to instrument in their system. For minimal impact, we could use maps.Bits implementation.

Analogous to Net O11y packet stats: https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/main/bpf/netolly/flows.c#L173C1-L174C1 We could add a set of two metrics: total ringbuffer attempts and failed ringbuf writes. This would allow monitoring whether OBI ringbuf reader is not able to read/parse at the pace spans are produced.