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

31–40 of 61 posts

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#31

Post by rocmcd »

edenfed wrote: post #27
rocmcd wrote: post #26

Earlier quoted context omitted.

100%. Context propagation is _the_ key to distributed tracing, otherwise you're only seeing one side of every transaction. I was hoping odigos was language/runtime-agnostic since it's eBPF-based, but I see it's mentioned in the repo that it only supports: > Java, Python, .NET, Node.js, and Go Apart from Go (that is a WIP), these are the languages already supported with Otel's (non-eBPF-based) auto-instrumentation. Ap…

eBPF instrumentation does not require code changes, redeployment or restart to running applications. We are constantly adding more language support for eBPF instrumentation and are aiming to cover the most popular programming languages soon. Btw, not sure that sampling is really the solution to combat overhead, after all you probably do want that data. Trying to fix production issue when the data you need is missing…

All good points, thank you.

What's the limit on language support? Is it theoretically possible to support any language/runtime? Or does it come down to the protocol (HTTP, gRPC, etc) being used by the communicating processes?

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#32

Post by marwis »

spullara wrote: post #29
edenfed wrote: post #7

Earlier quoted context omitted.

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.

Going to be rough for supporting virtual threads then?

ScopedValue solves that problem: https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#33

Post by edenfed »

rocmcd wrote: post #31
edenfed wrote: post #27

Earlier quoted context omitted.

eBPF instrumentation does not require code changes, redeployment or restart to running applications. We are constantly adding more language support for eBPF instrumentation and are aiming to cover the most popular programming languages soon. Btw, not sure that sampling is really the solution to combat overhead, after all you probably do want that data. Trying to fix production issue when the data you need is missing…

All good points, thank you. What's the limit on language support? Is it theoretically possible to support any language/runtime? Or does it come down to the protocol (HTTP, gRPC, etc) being used by the communicating processes?

We already solved compiled languages (Go, C, Rust) and JIT languages (Java, C#). Interpreted languages (Python, JS) are the only ones left, hopefully we will solve these as well soon. The big challenge is supporting all the different runtimes, once that is solved implementing support for different protocols / open-source libraries is not as complicated.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#36

Post by phillipcarter »

rocmcd wrote: post #31
edenfed wrote: post #27

Earlier quoted context omitted.

eBPF instrumentation does not require code changes, redeployment or restart to running applications. We are constantly adding more language support for eBPF instrumentation and are aiming to cover the most popular programming languages soon. Btw, not sure that sampling is really the solution to combat overhead, after all you probably do want that data. Trying to fix production issue when the data you need is missing…

All good points, thank you. What's the limit on language support? Is it theoretically possible to support any language/runtime? Or does it come down to the protocol (HTTP, gRPC, etc) being used by the communicating processes?

FWIW it's theoretically possible to support any language/runtime, but since eBPF is operating at the level it's at, there's no magic abstraction layer to plug into. Every runtime and/or protocol involves different segments of memory and certain bytes meaning certain things. It's all in service towards having no additional requirements for an end-user to install, but once you're in eBPF world everything is runtime-and-protocol-and-library-specific.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#38

Post by zengid »

zengid wrote: post #37

Anyone from the dtrace community want to enlighten a n00b about how eBPF compares to what dtrace does?

From the hot takes in this post from 2018 [0], I may be asking a contentious question.

[0] https://news.ycombinator.com/item?id=16375938

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#39

Post by edenfed »

zengid wrote: post #37

Anyone from the dtrace community want to enlighten a n00b about how eBPF compares to what dtrace does?

I don’t have a lot of experience using dtrace, but AFAIK the big advantage of eBPF over dtrace is that you do not need to instrument your application with static probes during coding.

Re: eBPF-based auto-instrumentation outperforms manual instrumentation

#40

Post by Thaxll »

Of course it outperforms it, but it's basic instrumentation, how do you properly select the labels for example? In your application you will have custom instrumentation for business logic, so what do you do? Now you have two systems instrumenting the same app?
Post reply on HN