Viewing profile — edenfed

Speaking for Odigos (disclosure: I’m the creator), here are two significant differences between us and the other mentioned players: - Accurate distributed traces with eBPF, includi…

Definitely can relate, this is why I started an open-source project that focus on making OpenTelemetry adoption as easy as running a single command line: https://github.com/odigos-…

You can absolutely use just the OTel APIs and use something else besides the OTel SDK. Here is a blog post about how we did it with eBPF: https://odigos.io/blog/Integrating-manual-…

Interesting idea. I think that as long as you able to do processing, serializing and delivery in other process and save this work from your application runtime you should see great…

By dropped data do you mean by exceeding the size of the allocated ring buffer/perf buffer? If so this is configurable by the user, so you can adjust is according to the expected l…

You can enrich the spans created by eBPF by using OpenTelemetry APIs as usual, the eBPF instrumentation is a replacement for the instrumentation SDK. The eBPF program will detect t…

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 codi…

Thank you for reporting will fix ASAP

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 so…

We have a solution for virtual thread as well. Currently working on a blog post describing exactly how. Will update once releases

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…

We are currently supporting just Kubernetes environments. docker-compose, VMs, and Serverless are on our roadmap and will be ready soon

We also thinking on implementing fallback mechanism to automatically propagate context on the same goroutine if context.Context is not passed

Thanks for the valuable feedback! We used a constant throughout of 10,000 rps. The exact testing setup can be found under “how we tested”. I think the example you gave for the lock…

I recommend watching Gil Tene’s talk, I think he explains the math better than I do: https://www.youtube.com/watch?v=lJ8ydIuPFeU

Logs are easy and familiar API for adding additional data to your traces. They still have their place, Odigos is just adding much more context.

Nothing special, if you are working on Kubernetes its as easy as running `odigos install` CLI and pointing to your current monitoring system.

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.

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, w…

Can you try again please? It works well for me