edenfed

6 ms·

1.
by edenfed 1y ago
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, including context propagation. Without going into other tools, I hi
2.
by edenfed 2y ago
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-io/odigos
3.
Odigos (YC W23) Is Hiring Lead Product Manager(ycombinator.com)
1 points by edenfed 2y ago
4.
by edenfed 2y ago
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-and-auto
5.
Odigos (YC W23) Is Hiring Lead DevRel Engineer(ycombinator.com)
1 points by edenfed 2y ago
6.
Integrating Manual with Automatic Instrumentation(odigos.io)
16 points by edenfed 3y ago|0 comments
7.
Odigos (YC W23) Is Hiring eBPF Engineer(ycombinator.com)
1 points by edenfed 3y ago
8.
by edenfed 3y ago
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 performance
9.
by edenfed 3y ago
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 load
10.
by edenfed 3y ago
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 the data recorded via the APIs and will add it to the final t
11.
by edenfed 3y ago
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.
12.
by edenfed 3y ago
Thank you for reporting will fix ASAP
13.
by edenfed 3y ago
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 runtim
14.
by edenfed 3y ago
We have a solution for virtual thread as well. Currently working on a blog post describing exactly how. Will update once releases
15.
by edenfed 3y ago
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
16.
by edenfed 3y ago
We are currently supporting just Kubernetes environments. docker-compose, VMs, and Serverless are on our roadmap and will be ready soon
17.
by edenfed 3y ago
We also thinking on implementing fallback mechanism to automatically propagate context on the same goroutine if context.Context is not passed
18.
by edenfed 3y ago
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 used by Prometheus library is a great example why generatio
19.
by edenfed 3y ago
I recommend watching Gil Tene’s talk, I think he explains the math better than I do: https://www.youtube.com/watch?v=lJ8ydIuPFeU
20.
by edenfed 3y ago
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.
21.
by edenfed 3y ago
Nothing special, if you are working on Kubernetes its as easy as running `odigos install` CLI and pointing to your current monitoring system.
22.
by edenfed 3y ago
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.
23.
by edenfed 3y ago
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 Runnabl
24.
eBPF-based auto-instrumentation outperforms manual instrumentation(odigos.io)
202 points by edenfed 3y ago|59 comments
25.
by edenfed 3y ago
Can you try again please? It works well for me
26.
by edenfed 3y ago
Disclaimer: I am one of the maintainers Many comments complain about the complexity of using OpenTelemetry, I recommend checking out Odigos, an open-source project which makes working with OpenTelemetry much easier: https://githu
27.
Show HN: Distributed tracing for Go applications with eBPF(keyval.dev)
2 points by edenfed 3y ago|0 comments
28.
by edenfed 3y ago
Hi SergeAx, I am building Odigos, which do exactly what you asked :) We combine OpenTelemetry and eBPF to automatically generate and deliver distributed traces, metrics and logs to Grafana, DataDog and other 15+ destinations. Check it out h
29.
Keyval (YC W23) Is Hiring Founding Back End Engineer(ycombinator.com)
1 points by edenfed 3y ago
30.
Show HN: The New Odigos Language Detector(keyval.dev)
2 points by edenfed 3y ago|0 comments

More ›