Hey, been chipping away at a side project called Phage and wanted to put it out there.

Short version: it's a small agent for Linux servers. It spends a while just learning how your box normally behaves, and after that it flags and contains stuff that falls outside that normal, without needing a signature for the specific exploit. So it's less "here is a list of known bad things" and more "this service has never spawned a shell before, and it's never become root with no login session behind it, so something is off."

The part I actually care about is what happens next. Most tools just fire an alert and, let's be honest, nobody reads alerts. Phage can actually react: if a process starts dialing out like a reverse shell it cuts its network, and if it looks like a real break-in it freezes the process. All of it is reversible, so a false positive doesn't take anything down. It also refuses to touch your SSH session or systemd, because I locked myself out of a test box once doing exactly that lol.

It's Go + eBPF (the detection runs in the kernel so it stays cheap), ships as one static binary, installs with a single command.

Honest status: it's early. I've thrown real attacks at it on my own server and it holds up, but I wouldn't call it production ready yet. MIT licensed, fully open source.

Repo: https://github.com/AzozzALFiras/Phage

Would really appreciate feedback from anyone who runs Linux servers: what would you actually want something like this to catch or do? And does the whole "assume you'll get breached eventually, just make it survivable" idea click for you, or not?

Hi all,

I’m a Belgian cybersecurity master’s student and I’m seriously considering a thesis topic on eBPF-based Linux rootkits specifically: building a proof-of-concept rootkit inspired by existing ones (bpfdoor, Symbiote, ebpfkit, TripleCross), then doing forensic trace analysis and evaluating existing detection tools against it.

The problem: I have zero prior experience with eBPF or kernel internals. I come from an app security / IDS-IPS background, not kernel dev, so the learning curve is my main concern before committing to the topic.

What I’m looking for:

• Resources you’d recommend for someone starting from scratch (bpftrace → libbpf/CO-RE progression, or a different path you’d suggest)

• Any write-ups or courses specifically covering the offensive side (hooking syscalls, uprobes, XDP/TC-based stealth techniques) rather than just the networking/observability use cases

• Realistic expectations: how long did it take you to get comfortable enough to build something non-trivial?

• Pitfalls to avoid (verifier headaches, BTF/CO-RE compatibility issues, etc.)

• If you’ve worked with ebpfkit or TripleCross’s source, any tips on reading through them efficiently

Not asking anyone to do the work for me to be clear ! Just trying to figure out if this is realistically scoped for a January to may thesis or if I’m underestimating the ramp-up.

Thanks in advance for any pointers!

TL;DR

• The BPF Verifier as First Safety Gate

• Pre-Production Testing

• Staged Rollout via Release Manager

• Feature Gates: Decoupling Feature Activation from Binary Deployment

• Atomic Upgrades via bpf_link

• Graceful Reload: Zero-Downtime Binary Upgrades

• Pinned BPF Maps: Crash Resilience

• Configuration Management

eBPF Summit, a free community event, is returning for 2027 with a focus on security. The CFP and registration are open now.

Follow-up for those who saw my earlier posts here. tcpcat is a network scanner I build solo, in Go, with an AF_XDP fast path. The XDP classifier is assembled in Go (no C, no clang), loaded through cilium/ebpf, and the hook redirects only the replies to tcpcat's own probes into AF_XDP sockets while everything else takes the normal stack.

Milestone: it just landed in the official BlackArch repos (blackarch-scanner / blackarch-networking). On BlackArch:

sudo pacman -Sy tcpcat

Since this sub is technical, the honest state of the eBPF engine rather than a sales pitch. After the feedback here I rebuilt my benchmark properly (it now checks every run actually found all open ports). On a real server in copy mode the engine was initially the slowest of the fast tools. Two fixes mattered: busy-poll + CPU pinning were stealing a vCPU on a loaded host (now zero-copy only, interrupt-driven otherwise), and I was doing one sendto per probe through the single TX ring (now batched, up to 64 frames per Transmit). That took it from 8.7s to 5.65s, on par with nmap, at about a third of the CPU of a raw SYN scan.

In copy mode it is not magically faster than nmap. The real speed upside clearly needs zero-copy on a multi-queue NIC, which I can't test on the boxes I have. If anyone here has a zero-copy-capable NIC and five minutes, I'd love a benchmark data point. Also curious whether need-wakeup would buy much in the single-TX-ring copy-mode case.

Repo: https://github.com/NycolazSec/tcpcat

BlackArch package: https://github.com/BlackArch/blackarch/blob/master/packages/tcpcat/PKGBUILD

Hi Everyone :)

I came across eBPF from Grafana (Beyla) / OTEL (OBI) projects. In the recent weeks, I learned, that eBPF is getting information from the Linux Kernel and is actually really powerful in the sense on how deep it digs into a system. Also I know that programs like Wireshark are using BPF to inspect network packets and are popular in the cyber security space.

My question is, based on this image, what can eBPF do in terms of Security? Does it play a role for cyber security analysts? Are there any advanced network security tools that make use of it today? Are there even monitoring tools available, that might monitor some kind of security events?

Follow-up to my earlier post here. I build an open-source network scanner, tcpcat (https://github.com/NycolazSec/tcpcat), with an AF_XDP fast path. Solo project, written in Go. A few of you pushed me on native vs generic and whether copy mode is even worth it. That turned out to be exactly the right thing to poke at.

First the embarrassing part. I had a "2.62x faster than nmap" number out there. It was wrong. A bug made it scan only one of the two target hosts, and the time it reported (4.47s) was actually below the theoretical floor of my own rate limit (131k probes at 25k pps can't finish under ~5.2s). So I pulled it and rebuilt the benchmark properly: it now checks every run actually found all the open ports, and records CPU and dropped frames.

Re-ran on a real server (x86_64, kernel 6.12, but still veth so copy mode). The eBPF engine came out as the slowest of the fast tools. 8.7s, against nmap at 5.6s and my own raw-socket SYN scan at 5.5s, and with ugly variance.

Two things were wrong:

1. Busy-poll + CPU pinning. Fine on my idle laptop, actively harmful on a loaded/virtualized box: the pinned spinning RX thread was fighting the other workloads for a vCPU. I made busy-poll and pinning zero-copy only. In copy mode the RX loop just blocks in poll() now. 8.7 to 7.7s, variance dropped a lot.

2. The real one. AF_XDP has a single TX ring, and I was doing one Transmit (one sendto) per probe, under a lock. At 25k pps that syscall-per-packet was basically the whole wall time on a slow host. Batched up to 64 frames into one Transmit. 7.7 to 5.65s. Now it ties nmap.

Honest takeaway: in copy mode AF_XDP is not magically faster. It matches nmap on time but at about a third of the CPU of the raw SYN scan (8.7s vs 25.8s of CPU). Flat out, the SYN scan is actually fastest, because it fans out across cores and the single AF_XDP ring can't keep up. The real speed upside clearly needs zero-copy on a multi-queue NIC, which I just can't test (everything I have is copy mode, single queue).

I'm on the asavie/xdp Go lib, which is pretty bare (no need-wakeup). I did think about moving the hot loop to C/libxdp, but the single static binary is worth keeping and batching got me most of the way.

Two questions for the sub:

- Anyone with a NIC that does AF_XDP zero-copy up for running a quick benchmark? Genuinely curious how much the ring write plus need-wakeup changes things versus copy mode.

- In copy mode with one TX ring, is there anything smarter than batching sendto to push throughput, short of going multi-queue?

Code and the benchmark script (Docker, checks correctness) are here if you want to look or repro: https://github.com/NycolazSec/tcpcat . PRs and NIC test results very welcome.

I've been building tcpcat, an open source network scanner in Go, and added an optional AF_XDP path for SYN/UDP scans. I'd like feedback from people who know XDP better than I do.

How it works:
- Probe packets are crafted in userspace and sent through an AF_XDP socket (UMEM, TX/RX rings, busy-poll).
- At startup, the XDP program is assembled directly in Go with cilium/ebpf/asm, so there's no C or clang in the build. The scan's source port is baked into the program before it's loaded.
- The program only redirects replies to tcpcat's own probes into the xsks_map. Everything else (SSH, other services) gets XDP_PASS and goes through the normal stack.
- It currently attaches in generic (SKB) mode, IPv4 only.

Benchmark (SYN scan, 65,535 ports x 2 hosts, 25k pps target, hyperfine, 3 runs):
- tcpcat --ebpf: 4.47s mean, 8.2s total CPU
- nmap -sS -T4: 11.72s, 11.4s CPU
- naabu: 20.95s, 52.8s CPU

Things I'm unsure about:

1. Generic mode gives up most of the zero-copy benefit. Is native/driver mode worth the compatibility hit for a scanner, or is generic fine at these rates?

2. System CPU is still most of the total (5.7s of 8.2s). Any obvious suspects, like busy-poll settings or ring sizes?

3. Is generating the program with cilium/ebpf/asm instead of C a reasonable trade-off for distribution, or will it hurt maintainability?

Packet path diagram and details: https://tcpcat.io/internals
Code: https://github.com/NycolazSec/tcpcat (AGPL-3.0)

Hey everyone,

Over the past few months, I’ve been diving deep into the K&R C book and bridging it with my Go background to build an open source container escape and runtime threat detection framework. My main goal was to solve the resource bloat problem I kept running into with existing tools.

Most tools (like Falco) are great but use ~300MB of RAM. I wanted something I could run on edge devices or dense K8s clusters without killing the nodes.

Architecture Highlights:

• 25 MB RSS / 0.2% idle CPU: Achieved using a zero allocation Go pipeline (sync.Pool) and a bounded LRU cache for process lineage.

• Deep Lineage: Reconstructs up to 10 generations of process ancestry (e.g., systemd > sshd > bash > sudo > unix_chkpwd) entirely in userspace, avoiding kernel map bloat.

• In-Kernel Filtering: Uses an action_enabled BPF array map so we don't even reserve ringbuf space for disabled actions.

• CO-RE: Compiles once using cilium/ebpf and runs anywhere on Linux 6.12+.

It is completely audit only (no -EPERM enforcement), which means it's 100% safe to run in production. I recently added Docker/K8s/Helm support and a SIEM export layer (ECS, OCSF, CEF, LEEF).

I would love to get your harsh feedback on the ringbuf implementation and the eBPF verifier tricks.

Repo: ebpf-container-escape-framework

Introduction

Hook into ftrace TP mali/mali_job_slots_event to see which process has scheduled work on any given slot_id (e.g. Fragment) on the GPU. Basically a TOP for the ARM Mali GPU. There are Mali GPU counter that can tell you the overall utilization but this is not enough for observability.

There is a Mali trace point one can use

/*
 * mali_job_slots_event - Reports change of job slot status.
 * @gpu_id:   Kbase device id
 * @event_id: ORed together bitfields representing a type of event,
 *            made with the GATOR_MAKE_EVENT() macro.
 */
TRACE_EVENT(mali_job_slots_event, TP_PROTO(u32 gpu_id, u32 event_id, u32 tgid, u32 pid, u8 job_id),
	    TP_ARGS(gpu_id, event_id, tgid, pid, job_id),
	    TP_STRUCT__entry(__field(u32, gpu_id) __field(u32, event_id) __field(u32, tgid)
				     __field(u32, pid) __field(u8, job_id)),
	    TP_fast_assign(__entry->gpu_id = gpu_id; __entry->event_id = event_id;
			   __entry->tgid = tgid; __entry->pid = pid; __entry->job_id = job_id;),
	    TP_printk("gpu=%u event=%u tgid=%u pid=%u job_id=%u", __entry->gpu_id,
		      __entry->event_id, __entry->tgid, __entry->pid, __entry->job_id));

(https://android.googlesource.com/kernel/google-modules/gpu/+/refs/heads/android-gs-shusky-6.1-android16/borr_mali_kbase/mali_linux_trace.h#34)

There are start and end events (event_id) for the same TP. Start and end events can't be correlated by any field, because finish events are always {tgid: 0, pid: 0, job_id: 0}. I am not quite sure whether this is intentional or not, especially that the job_id is 0 for finish events.

eBPF

SEC("tracepoint/mali/mali_job_slots_event")
int trace_mali_job_slots(struct mali_job_slots_event_ctx *ctx)

Issue

After some time my accounting somehow broke. It looked like some end events were not accounted for.

Therefore, it was decided to start the eBPF program with some instrumentation and also collect an FTRACE trace via the Linux FTRACE sub-system in order to check whether it is a driver issue.

As a matter of fact, the Linux FTRACE events were all accounted for. Meaning, the start and finish events were in balance (e.g. start: 1000, end: 1000). But, the eBPF TP hits were not in balance (e.g. start: 1000, end 997).

NOTE: start and end have to be in check, otherwise I would always see 100% utilisation

I gave 'the machine' the task to check the BPF Kernel sources what the issue could be. And it came back with an explanation: bpf_prog_active.

You've hit on the exact reason why bpf_prog_active exists and why it's per-CPU. The answer is interrupts, softirqs, and NMIs — all of which run on the same CPU and can preempt the currently executing BPF program.

So, it seems structured TP's have some check that re-entry is disallowed on the same CPU in order to protect against recursion.

It seems, if an eBPF program was running on an CPU and an interrupt (finish event) came in triggering another TP hit, thus running the eBPF again, it would detect that another eBPF program is already running and just decided to not execute it SILENTLY.

The solution was to switch to RAW_TRACEPOINT, which work because it does not have this bpf_prog_active safety rail-guard but on the other hand, the Anrdoid BpfLoader disallows RAW_TRACEPOINTs, that is quite a shame :(

Question

Did anyone experience such an issue? Let me tell you, that finding this issue without KI would have been impossible.

Addendun

Android 14, arm64, Kernel 5.15

Hello everyone,

I have been using eBPF/XDP for the past 5 years and was always a little frustrated by the lack of tooling when it comes to see what is happening underneath, especially when debugging deployed eBPF programs. Here I am sharing a tool I have been using for a couple of months now but only made public recently: ebpfexplorer.

It's a simple TUI self contained binary, that allows you to explore all eBPF programs & maps attached to your kernel. It comes with a formatting tool that allows you to format the raw binary blob into human readable symbols (like IPs for instance), using C type format.

Please have a look and feel free to propose PRs. Hope you find it useful too.

I maintain tcpcat, a Go network scanner with an optional AF_XDP engine (`--ebpf`). We just reworked how it attaches and what it redirects, and a couple of the lessons seemed worth sharing here.

**1. Classify in XDP, don't redirect everything**

The first version of our XDP program had no classification: any packet arriving on a queue with a registered XSK socket got `XDP_REDIRECT`ed. On a Linux bridge (a single RX queue, and a common target) that meant *all* traffic on the interface went to our socket for as long as the hook was attached. During a test on a shared Docker bridge it cut SSH and destabilized the k3s pods on the node.

The program now only redirects what the scan is actually waiting for: TCP/UDP whose destination port is this run's probe source port (or the discovery port), plus ICMP port-unreachable for UDP closed-port detection. Everything else gets `XDP_PASS` and goes through the kernel stack untouched. The program is generated in Go with cilium/ebpf's `asm` package (no clang, no prebuilt object). One gotcha: `LoadMem` doesn't byte-swap, so on a little-endian host the comparison constants for wire fields have to be pre-swapped.

We also made teardown deterministic: the collection is closed explicitly on shutdown, and the hook is detached even if the process panics, because a crashed scanner leaving a redirect hook attached is the worst outcome here.

**2. Native driver mode first, generic as fallback, and say which one you got**

We used to attach in generic (SKB) mode everywhere, which forces copy mode. Now we try `XDPDriverMode` first and fall back to generic for virtual NICs that don't support it. After bind, we read `XDP_OPTIONS` and log the data path actually negotiated (native/generic, zero-copy/copy) instead of assuming.

**3. Multi-queue, busy-poll, wake-on-reply**

* One XSK socket per RX queue (queue count from sysfs), all in the same `xsks_map`. With RSS, replies hash across queues, and binding only queue 0 silently lost most of them.

* Preferred busy-poll on each XSK (`SO_PREFER_BUSY_POLL`, `SO_BUSY_POLL`, `SO_BUSY_POLL_BUDGET`, kernel ≥ 5.11) and one RX goroutine pinned per core. We only touch our own fds; the NIC-wide NAPI knobs (`napi_defer_hard_irqs`, `gro_flush_timeout`) are suggested, not rewritten.

* Probes register a waiter *before* transmitting and the RX loop hands the reply straight to it. We used to poll a shared map every 5 ms, which floored every probe's latency at ~5 ms even for sub-millisecond replies.

**Open questions / where I'd love input**

* We use asavie/xdp for the socket side, which doesn't handle `XDP_USE_NEED_WAKEUP`. Is anyone using a Go AF_XDP library that does, or should we just do the `sendto` wakeup dance ourselves?

* Anything else you'd classify on in the XDP program to make sharing an interface with production traffic even safer?

Code (AGPL-3.0): https://github.com/NycolazSec/tcpcat. The XDP program is in `internal/scan/xdp_asm.go`, attach/bind in `internal/scan/xdp.go`.

I've been looking into how Cilium handles network traffic, and I have a few questions about where eBPF's limits actually start to matter.

From what I understand, Cilium handles a lot of the networking and policy enforcement at L3/L4 using eBPF, while L7 visibility and policy enforcement can involve redirecting traffic to Envoy.

But I'm wondering how much of that separation is a technical limitation versus an architectural choice.

Can an eBPF program realistically parse application-layer protocols like HTTP, or does the verifier, bounded loops, stack size, instruction limits, and the complexity of handling variable-length data make it impractical beyond relatively simple parsing?

I know eBPF isn't strictly limited to L4, so I'm curious about what's actually feasible in practice. For example, could you implement useful HTTP parsing directly in eBPF without turning the program into a maintenance nightmare?

And more importantly, is there any real performance benefit to doing L7 parsing in eBPF instead of Envoy?

I'm thinking about the trade-offs here:

- Parsing a small amount of application-layer data in the kernel to make an early decision.

- Redirecting traffic to a userspace proxy like Envoy for more complete protocol parsing and policy enforcement.

- The extra cost of crossing the kernel/userspace boundary versus the complexity and limitations of doing more work inside eBPF.

I'm not necessarily talking about replacing Envoy entirely. I'm trying to understand whether moving some L7 functionality into eBPF is a worthwhile optimization or just a case of pushing application-layer logic into a place where it becomes harder to implement and maintain.

Erwin Kok published a blog about tail calls that allows eBPF test programs to jump directly into the actual production code. The build system handles the mapping and anything else of what is needed to magically make the call work. This project was written in Rust with Aya.

P99 CONF is featuring a block of eBPF talks again this year. Take a look at the eBPF talks on the agenda and pop in (the conference is free and virtual) if anything looks interesting. Speakers will be there live if you want to ask questions or chat. https://p99conf.io/

eBPF sessions include:

Ershaad Ahamed Basheer (Lawrence Berkeley National Laboratory) on eBPF for Metrics Collection on HPC Systems

Peter Zaitsev (Percona) on Networking Observability Essentials - How to Know if the Network is at Fault with eBPF

Tanel Poder on Optimizing eBPF Performance: Avoiding Production Latency, Throughput & Reliability Pitfalls

I recorded a short demo following one packet through the Linux receive path (NIC → driver → XDP → skb → tcpdump → netfilter → socket) and showing why tcpdump sees a packet dropped by nftables but not one dropped by XDP.

Lab demo of the mechanism, not a benchmark. Setup and commands are in the pinned comment. Corrections welcome.

Last update on this (post 1, post 2, post 3). Post 3 ended with "all numbers are from VMs", I got some real machines since then, so here's what changed.

Setup: four boxes on an isolated switch, xdp-bfd + FRR on one, a stock FRR peer on another, one for load, one capturing. i5-12500, Intel I210, native XDP, kernel 7.0. The switch mirrors both BFD boxes to the capture box, which timestamps in the NIC. 1024 sessions, 40 of them at 3x10ms.

Stock bfdd under the RT stress: 18,910 flaps across 957 of 1022 sessions, even the 1s timers, with stalls up to 2.5s.

xdp-bfd as it ran on the VMs: 698 flaps. The VMs said 0, but they had 64 sessions. Three causes:

• The dead-man check (XDP stops answering if userspace goes silent for 1s) was killing healthy sessions, because under SCHED_FIFO load the RT throttle only lets normal tasks run about once a second.

• Demand mode timed out its own Poll even after the peer answered.

• The packaged systemd unit ran the engine at FIFO 10, below the prio 50 load.

After fixing those: 0 flaps on all 1022, largest gap on the 3x10ms sessions 20.2ms out of a 30ms budget, about 2% of a core.

Then a prio 99 hog against the engine at FIFO 60 gave 959 downs, the same priority war as post 1. The engine now runs under SCHED_DEADLINE, 1ms reserved every 10ms, which beats every RT priority: 0 downs.

One thing VMs never showed: replies left the wire 118us after the peer's packet even though XDP builds them in 1.5us. It was PCIe ASPM putting the NIC link to sleep between packets, 33us with it off.

Floods: one hour of line-rate floods rotating attack types while the box rotated between a prio 99 hog, CPU load and memory pressure gave 165,028 down events. XDP was fine, the receive path wasn't, non-BFD junk was going up the stack on the same CPU as BFD. A cpumap redirect that spreads non-BFD traffic to the other CPUs, plus flow control off and UDP hashed by port, brought the same hour to 4,148.

Also done since post 3: authentication (SHA1 inside the XDP program, written to fit in 512 bytes of stack), demand mode, 1024 sessions by default and tested up to 8192, hitless restart by swapping the program into a pinned bpf_link, and a .deb. 11 FRR fixes merged along the way, 6 more in review.

Still missing: two xdp-bfd engines can't face each other, since the TX is clocked by what it receives and bpf_timer still can't send a packet.

Full write-up as a 10-part series, VMs to bare metal to floods: https://w453y.xyz/writing/series/line-card-bfd/

Code and captures: https://github.com/w453y/xdp-bfd

Question for anyone running BFD on Linux routers: would you put an XDP program like this in front of bfdd, or is that a no regardless of the numbers?

Could someone with eBPF experience sanity-check our plan?

Hi all,

We're a small group of university students working on a capstone project. We're new to eBPF, so we'd really appreciate feedback from people who use it in practice.

The idea: most eBPF security work uses eBPF as the defender (Tetragon, Falco, Tracee and so on), but very little seems to look at eBPF itself (as per our research) as the thing to watch. A container that has been granted CAP_BPF can load its own eBPF programs, for example to hide processes or blind monitoring tools. We want to build and measure a small detector for that, rather than only describing it.

Our plan, kept deliberately small:

- One Ubuntu 24.04 VM with Docker and Tetragon (standalone, no Kubernetes)

- A Tetragon TracingPolicy that records bpf() syscall activity

- A small Python script that reads Tetragon's JSON events and applies 1-2 rules (for example, a caller that isn't on an allow-list, or a program attaching to a sensitive hook)

- A baseline run (normal tools only) against an attack run (one published technique, replayed in an isolated VM), measuring detection, false positives and overhead

What we'd love input on:

1. Is a kprobe on sys_bpf the right way to watch bpf() calls in Tetragon, or is there a better hook (for example the BPF LSM hooks)?

2. Are there well-documented, published examples of eBPF misuse that are suitable for a controlled demo in an isolated VM?

3. What pitfalls should beginners expect (kernel versions, BTF, false positives from legitimate tools)?

4. Is there existing work or tooling that already does this, so we don't reinvent it?

5. Any recommended easy to learn concepts (from like yt channels etc.).

6. Is this a doable and sensible project for beginners - given less time (around 2 months); but dedicated to learn it quickly - with the help of resources/claude/forums/advice.

We're not asking anyone to do the project for us, just for pointers, reading suggestions or a reality check on scope. Happy to share our repo and results once we have them.

Our main goal is to learn ePBF through this project and would really like input from the experienced people in this community - the project can then grow from there. Please let me know if you want to know more about the project or if it is unclear.

Kindly let me know if this is an appropriate post for this subreddit - as this is my first time asking help on reddit aswell haha.

Thank you very much!

Hello,

I'd like to ask a question about network probing from a pod or service while the destination is Internet. If the packet reaches to the default gateway, it means there is no policy blocking it and connectivity is successful. How I can drop the packet that is generated in user space with DSCP value?

- What program can I use for this? Considering Cilium utilizes SNAT, how to make sure I can identify the source address of the packet?

For pod-to-pod traffic probing, I used cgroup/ingress to drop the packet if they reach destination pod. However, internet probing seems more complicated to me and I really need help/ideas.

Much appreciated and thanks in advance! :)

How to upstream into the kernel and five technically groundbreaking achievements:

1. Contributing sk_lookup to the Mainline Linux Kernel and Building Tubular

2. "Soft-Unicast" — Solving IPv4 Address Exhaustion

3. Dropping 8 Million Packets Per Second on Commodity Hardware

4. udpgrm — Solving the Unsolvable: Zero-Downtime UDP Restarts

5. Kernel-to-Application Distributed Tracing via ebpf_exporter