Why do we need production profiling at all?

Application performance isn't abstract. It's about real issues: errors, timeouts, lost users, and wasted money. But to understand what exactly is slow, it's not enough to know that "CPU is high." You need detail: which service, which method, which request, which parameters.

This is where two approaches come in:

• eBPF - ultra-lightweight, kernel-oriented profiling
• BitDive - a Java agent embedded in the application, focused on business logic

Although eBPF and BitDive operate on different levels - system and application - they both aim to answer the same question: why is production slow?

Choosing the right tool depends on whether you need a high-level system view (eBPF) or deep insight into what's happening in your code (BitDive).

The problems with eBPF they don't mention in brochures

eBPF runs at the Linux kernel level and hooks into syscalls, sockets, filesystems, and network events. But it doesn't see what your code actually does inside.

Requires root access

To run an eBPF agent, you need kernel-level access:

• Root, or capabilities like CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN
• In cloud environments, this means: negotiating with DevOps/SRE, setting up IAM, running execs into nodes, deploying DaemonSets
• Developers can't just run this themselves in 99% of real-world cases (unless it's a 4-person startup)

Host-bound visibility

If your app is spread across multiple VMs or nodes:

• eBPF can't see beyond the current kernel
• You have to install agents on every node and aggregate data manually
• This is complex and requires ops support

Lack of application-level context