topic Re: OpenTelemetry Span Sensor For OneAgent - Set Trace ID Function in Open Q&A

OpenTelemetry Span Sensor For OneAgent - Set Trace ID Function

victor_correa — Thu, 28 May 2026 20:25:29 GMT

Hi team,

We're having issues with Trace Continuity for an application that does asynchronous processing and we're trying to explore ways to have the issue addressed so we see end-to-end traces.

With the way the application processes tasks (I'm oversimplifying here) a thread writes a statement to a DB and another thread picks it up to continue processing, but Dynatrace issues a unique Trace ID for each, so we can't see the whole transaction, end-to-end, as a single trace.

We know that OTel has a "set trace ID" function that we could use - since the original TraceID is stored in the database, but we're wondering whether enabling the OTel Span Sensor feature for OneAgent would allow us to leverage the function, or if there is any other way around it.

If any of you have ran into similar issues with Trace Continuity in Asynchronous Processing applications and could share how you handled, it would be much appreciated.

Re: OpenTelemetry Span Sensor For OneAgent - Set Trace ID Function

Julius_Loman — Fri, 29 May 2026 20:53:08 GMT

The OTEL Span Sensor is for capturing OpenTelemetry spans from your application. This works along with OneAgent tracing.

In the case you describe - you can use OpenTelemetry and also still the OneAgent SDK (you don't mention a particular language, I assume it's one of the supported ones). In both cases, you need to pass the trace context from one thread to another. So you will need to extend your database calls to store the trace context (both trace id and span id, you cannot use your own identifier here as trace id). Or if it's a single process, you can store it in the memory and look it up (just thinking, I don't know you application).

Anyway, I'd recommend thinking once again if this really should be a single trace. You mention you have already a second trace (thread that picks up record in the database). So you would need to disable the sensor that starts the second trace in OneAgent features anyway. But from my point of view, you are mixing the tracing with business data. If there is a significant delay expected between producer and consumer threads, you might run into some limitations of continuing existing trace. In your case, I'd consider creating span links with OpenTelemetry instead.

If you want it in a single trace anyway, and you don't use OpenTelemetry in your application, OneAgent SDK might be easier to use (I'd probably use trace messaging in this case).

I hope this helps.

Re: OpenTelemetry Span Sensor For OneAgent - Set Trace ID Function

victor_correa — Tue, 02 Jun 2026 14:30:19 GMT

HI @Julius_Loman ,

Thanks a lot for taking the time to reply. That definitely helps with a few steps I can work towards to try and address this.

The trace IDs are stored in the data base so the "set trace id" function from OTel would do the trick just fine, but the main issue with this approach would be re-instrumenting our code with OTel - we're currently only using MicroMeter counters and Gauges to publish custom Metrics, so the work required to get OTel up and running would be significant. Any code changes have a very strict and lengthy process to get through the promotion pipeline.

I'll also start the discussion with the teams about business data versus tracing. With this application, in particular, since it calls multiple distributed micro servers depending on which flow is being executed, it's important for troubleshooting and triage purposes that we identify each of the hops and their respective metrics, but the idea of the "flow" is more business than tracing.

The Span Links option could, potentially, be a good solution here.

In any case, I have a few things to try out and work with the team, so I'll mark this as a solution as you gave me plenty to think and work through.

Once again, thanks for taking the time to share your insights.

Regards,
Victor Correa