Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

eBPF-based auto-instrumentation outperforms manual instrumentation

odigos.io

Post reply on HN
Print view View original

1–10 of 61 posts

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#3

Post by Barakikia »

nevodavid10 wrote: post #2

This is great. Can you elaborate on how the performance is better?

Our focus was on latency. The reason we were able to cut it down was due to the fact that eBPF-based automatic instrumentation separates the recording from the processing.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#4

Post by CSDude »

Somewhat related, I mainly code in Kotlin. Adding open telemetry was just adding agent to command line args (usual Java/JVM magic most people don't like). Then I had a project in Go and I got so tired of all the steps it took (setup and ensuring each context is instrumented) and just gave up. We still add our manual instrumentation for customization, but auto-instrumentation made adoption much easier in the day 0.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#5

Post by avita1 »

How do you solve the context propagation issue with eBPF based instrumentation?

E.g. if you get a RPC request coming in, and make an RPC request in order to serve the incoming RPC request. The traced program needs to track some ID for that request from the time it comes in, through to the place where the the HTTP request comes out. And then that ID has to get injected into a header on the wire so the next program sees the same request ID.

IME that's where most of the overhead (and value) from a manual tracing library comes from.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#7

Post by edenfed »

avita1 wrote: post #5

How do you solve the context propagation issue with eBPF based instrumentation? E.g. if you get a RPC request coming in, and make an RPC request in order to serve the incoming RPC request. The traced program needs to track some ID for that request from the time it comes in, through to the place where the the HTTP request comes out. And then that ID has to get injected into a header on the wire so the next program see…

It depends on the programming language being instrumented. For Go we are assuming the context.Context object is passed around between different functions or goroutines. For Java, we are using a combination of ThreadLocal tracing and Runnable tracing to support use cases like reactive and multithreaded applications.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#8

Post by edenfed »

CSDude wrote: post #4

Somewhat related, I mainly code in Kotlin. Adding open telemetry was just adding agent to command line args (usual Java/JVM magic most people don't like). Then I had a project in Go and I got so tired of all the steps it took (setup and ensuring each context is instrumented) and just gave up. We still add our manual instrumentation for customization, but auto-instrumentation made adoption much easier in the day 0.

I think eBPF has also great potential to help JVM-based languages. Especially around performance aspects even comparing to the current java agents which use bytecode manipulation.
Post reply on HN