we have a multi-tier system in which there's a specific tier we cannot instrument using dynatrace. The upper and lower tier are instrumented but, due to the lack of covering of the one in the middle, our tracing is broken.
What we would like to achieve is to implement OpenTelemetry on the service where DT cannot be installed and than integrate the spans generated into dynatrace.
Our side is NOT really clear how we should do that. Taking a look at the OpenTelemetry feature:
It is not clear if enabling this would require the OneAgent instrumented in the service where OpenTelemetry is active. In this case, this would not fit our use case since we cannot cover that specific service with OneAgent.
On the other end, I see the support for the W3C context headers:
And it seems more close the our use case. But it is not clear how we should enrich our application with the W3C Trace context headers. Are they added by default once we add OpenTemetry to our service?
It would be appreciated if anyone can share is experience in this case of scenarios. Thank you!
Solved! Go to Solution.
Ingesting of OpenTelemetry spans from processes on hosts not monitored by OneAgent is not yet available. I think this will cover your scenario to get full visibility.
In the meantime, you may be able to achieve the tracing by enabling the W3C headers or by the built-in X-dynaTrace header. This is independent of OpenTelemetry. If Service B honours those headers or just passes them, then OneAgent on Service C will pick it up and Dynatrace will connect those traces. You won't have any visibility on what is happening inside Service B, but you should see Service A calling Service C.
At the moment it's really about the question of what does the Service B do. If there is some logic and those headers are not passed or are filtered, then there is not much you can do at the moment.