3 ms·
Very 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 th
by yashap 4y ago
Very 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?
- edenfed 4y agoWe 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-instrumentation/tree/main/instrumentation 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)
- yashap 4y agoAh 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.
- edenfed 4y agoYes exactly. Odigos plays nice with manual instrumentation, meaning distributed traces will include both automatic and manual spans. Currently there is no way to point manual instrumentation to the destination selected in Odigos but we working on it and should release it soon. Most SDKs have a concept of no-op exporter that way Odigos will be able to pick up the manually created traces and deliver them to the chosen backend
- yashap 4y agoVery cool, ty for the responses!