19 Jul 2019 06:20 AM - last edited on 14 Dec 2021 06:38 AM by MaciejNeumann
is it possible to use both Dynatrace and Jaeger? Or do we risk to meet any stability issues?
Solved! Go to Solution.
As I see Jaeger is working on container and process level. You should pick one at the time.
Do you say "you should pick one at the time" because you are aware they are not compliant? Or is it just your guess?
We are deploying dynatrace across multiple client environments. Always there was restriction that if there is anything that is instrumenting application processes, should be uninstalled because of possible issues. The same story is here. It may work, but for safety it's better idea to avoid such duplicated monitoring.
Hi @David D. - I'm curious, what is the use case that require you to use Dynatrace and Jaeger at the same time? Can you provide a little bit more background?
One use case that we are aware of is transitioning from Jaeger to Dynatrace, e.g. one team at a time. W3C trace context support can help with that, see: https://www.dynatrace.com/news/blog/distributed-tracing-with-w3c-trace-context-for-improved-end-to-e...
Hi @Sonja C.,
I have been looking into the W3C trace context support in DT. I am not quite sure if our usecase is supported with the W3C trace context, and if there is any preview subscriptions required. I can see that the W3C trace context is in EA. But there is also 1.177 | Cross-environment tracing in preview - is that required in our usecase?
We have a Manged Application instrumented with Agentless Monitoring. This application have a backend connected to a microservice environment that is entirely OneAgent monitored.
Due to vendor constraints we are not able to install OneAgent on the Manged Application - and hence we are loosing traceability between the MangedApplication and the OneAgent environment.
We are looking into the W3C trace context support - could enable us to regain the traceability to all communication with the OneAgent monitored environment.
Here we are thinking OpenTracing with Jaeger or something similar. Important thing here is that it is something that enables the W3C trace context and enables OneAgent to correlate with the user actions from the Agentless monitoring.
Is that something that is supported?
I'm curious - which technology are you using in your managed application? maybe this is something we will be able to support in the future.
trace context support is available as early adopter feature for all the environments. You can simply go to Settings / Server-side service monitoring / Deep monitoring / Distributed tracing and you need to switch the configuration to enable trace context.
This means that all services monitored by Dynatrace will use W3C trace context HTTP headers. If a transaction starts somewhere and is not monitored by Dynatrace, when arriving in a Dynatrace monitored environment, the same trace context header will be re-used.
I hope this helps!
Hi @Sonja C.,
Sounds promising, the tech-stack is not the point here but instead the fact that the site is running under a 3rd party manged vendor - hence we cannot install OneAgent on the servers.
One question though - we have injected the js Agentless monitoring. Is the Agentless monitoring also using W3C trace context? And is there a way we can extract the tracecontext on the servers on our backend servers and pass that along to downstream services/api that exists in an OneAgent environment. And that way enable end2end purepath in the Agentless Appliation?
Have looked into the OpenKit - and guess we could leverage that to enable full purepaths - but would like it included in the Agentless Application instead.