undefined | Better HN

0 pointsyashap3y ago0 comments

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.

0 comments

2 comments · 1 top-level

edenfed3y ago· 1 in thread

Yes 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

yashapOP3y ago

Very cool, ty for the responses!

j / k navigate · click thread line to collapse