I'm curious how this will stack up against Sysdig/Falco - https://sysdig.com/blog/sysdig-and-falco-now-powered-by-ebpf....
eBPF for the win, this is a nice approach with Odigos.
Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
21–30 of 53 posts
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#22I'm curious how this will stack up against Sysdig/Falco - https://sysdig.com/blog/sysdig-and-falco-now-powered-by-ebpf... . eBPF for the win, this is a nice approach with Odigos.
I don't think it is comparable to falco. Talk is more about security violations of the container. It is not related to distributed tracing.
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#23I'm curious how this will stack up against Sysdig/Falco - https://sysdig.com/blog/sysdig-and-falco-now-powered-by-ebpf... . eBPF for the win, this is a nice approach with Odigos.
Falco is really cool project but it focuses more on security. Odigos is focused on getting better monitoring signals from your applications, especially distributed tracing
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#24Distributed tracing really ought to be built into every web application framework. What's the value in signing over your autonomy to a framework if it isn't going to handle cross-cutting concerns like forwarding correlation IDs from the inbound request to all outbound requests triggered by that request?
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#25Distributed tracing really ought to be built into every web application framework. What's the value in signing over your autonomy to a framework if it isn't going to handle cross-cutting concerns like forwarding correlation IDs from the inbound request to all outbound requests triggered by that request?
Unfortunately not all web frameworks do this automatically. In addition sometimes you may want to propagate ID over non http connections like database drivers or even message queues.
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#26Congrats on the launch! Glad to see that you also support SigNoz as a backend.
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#27Wow, if this really works like you describe, then this is magic! > Automatic instrumentation across programming languages is not a trivial task, especially when dealing with static binaries (like the ones produced by the Go compiler). We built multiple mechanisms to make sure we inject the relevant headers in a secure and stable way. We developed a system that tracks functions and structs across different versions of…
With tech like eBPF dynamic instrumentation is surprisingly easy actually.
Still, always glad to see some innovation in this space.
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#28Very cool!
I'd imagine the challenge here is the long tail of tracing and metric needs. I'm thinking things like:
- For the JVM, do you support things like thread pools and execution contexts well? e.g. say part of serving up a response to an HTTP request means executing some async work against an execution context, does the context propagation work properly? And if so, would this work for other JVM languages, like Scala, or just Java? When I've manually instrumented apps for context propagation, it's been easy for languages like JS (Node) and PHP, but hard for languages like Scala, where there are so many different concurrency models ppl use
- Some units of work/tracing are pretty standardized, like say serving up a response to an HTTP request. But others less so, for example work triggered by job queues/events, where essentially a message on some sort of Kafka/Redis/Postgres/whatever queue triggers your app to do some work (instead of an HTTP request). I have trouble seeing how Odigos would instrument this well - e.g. even if you detect the work, how do you label related metrics well (can't just rely on HTTP method/path)? How do you measure success/failure of the job? Or if you don't try to tackle this sort of use case, would there be something like Odigos libs for manual instrumentation, where necessary?
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#29Very cool! I'd imagine the challenge here is the long tail of tracing and metric needs. I'm thinking things like: - For the JVM, do you support things like thread pools and execution contexts well? e.g. say part of serving up a response to an HTTP request means executing some async work against an execution context, does the context propagation work properly? And if so, would this work for other JVM languages, like S…
We are actually able to handle the long tail of tracing by leveraging the amazing open source community. For languages like Java we use the automatic instrumentation created by the OpenTelemetry community which is really great and support ton of libraries, you can see a list of supported libraries here: https://github.com/open-telemetry/opentelemetry-java-instrum...
This also allows us to support async tracing like doing context propagation over Kafka message is also something we support (depending on the programming language)
Re: Launch HN: Odigos (YC W23) – Instant distributed tracing for Kubernetes clusters
#30Very cool! I'd imagine the challenge here is the long tail of tracing and metric needs. I'm thinking things like: - For the JVM, do you support things like thread pools and execution contexts well? e.g. say part of serving up a response to an HTTP request means executing some async work against an execution context, does the context propagation work properly? And if so, would this work for other JVM languages, like S…
We are actually able to handle the long tail of tracing by leveraging the amazing open source community. For languages like Java we use the automatic instrumentation created by the OpenTelemetry community which is really great and support ton of libraries, you can see a list of supported libraries here: https://github.com/open-telemetry/opentelemetry-java-instrum... This also allows us to support async tracing like d…
Ah cool! So like, if I used some Open Telemetry libs for more manual instrumentation, would it "play nice" with the automated instrumentation? Like say:
- I instrument a Scala app with Odigos, and it handles say 90% of the metrics, trace spans, etc. that I want
- But I want to add some extra spans, extra metrics
- If I then explicitly add OpenTelemetry libs as dependencies, will they conflict with the automated OpenTelemetry instrumentation (e.g. no "JVM dependency hell" issues like "I manually add 2.x of this lib, but then Odigos monkey patches it to 1.x, breaking my manual instrumentation")? And is there a way for the manual instrumentation to "play nice" with the automated instrumentation, e.g. I choose destinations in the Odigos UI for where to send traces, metrics, etc., is there a way for me to sort of have my manual instrumentation automatically target the same destinations?
Obviously you guys are an early stage startup, if there's no clear answer on hand for some of these questions, I'd just have to try and see, that's totally fair too :) I do love this idea of crazy easy 1-click style instrumentation.