Feature idea summary

We need to have a better idea about what is necessary to move from apps.plugin to ebpf.plugin. To take this final decisions, it was suggested we have a benchmark with both plugins, as suggestion we received the following papers/benchmark to move in front :

https://github.com/cloudflare/ebpf_exporter/tree/master/benchmark
https://publications.polymtl.ca/3816/1/2018_Gebai_Survey_analysis_kernel_userspace_tracers.pdf

The measurements that need to be taken are:

• A base-line load that saturates the testing system.
• The same load with eBPF enabled to determine the reduction in capacity (e.g. syscalls) during the test.
• The same load with apps plugin to determine the reduction in capacity during the test.

The eBPF load is expected to scale with the number of tracing events in the system, the apps plugin load is expected to scale with the number of active processes in the system. Care must be taken to determine what the breakevens are in the trade-offs between these two approaches.

Note: the eBPF plugin is not currently a complete replacement for all of the functionality in apps plugin and this must be taken into account during the comparison.

Note: stress-ng will probably function well as a load generator for the benchmarking.

Expected result

• Benchmarking results that show the cost of tracing that is more accurate than the raw latency of executing the probe - i.e. it accounts for the differences in cache state and context switching by measuring the system under load.
• Benchmarking results that show the cost of apps plugin parsing as the number of active processes scales.
• A way to compare the two to make a decision.