Agreed. using bpf can eliminate some of the requirements for packet captures. Computing the metrics on the host, also eliminates the network traffic of exporting logs or pcaps to for instance splunk. [1]

Brendan Gregg wrote a book that digs really deep into the bpf system. [2] I recommend you check it out if you need to do real work fast.

[1]: https://docs.splunk.com/Documentation/StreamApp/7.2.0/Deploy... [2]: http://www.brendangregg.com/bpf-performance-tools-book.html

BPF for packet capture predates BPF for system instrumentation, and libpcap itself is under the hood an elaborate, optimizing BPF compiler.

Current convention is to refer to eBPF as BPF, and where referring to the Original BPF as cBPF. This is why Brendan's book is "BPF Performance Tools"

"Then in 2013, Alexei Starovoitov completely reshaped it, started to add new functionalities and to improve the performances of BPF. This new version is designated as eBPF (for “extended BPF”), while the former becomes cBPF (“classic” BPF). New features such as maps and tail calls appeared. The JIT machines were rewritten. The new language is even closer to native machine language than cBPF was. And also, new attach points in the kernel have been created." [1]

[1]: https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into...