Support OpenTelemetry Context preservation in Kotlin coroutines

[tmalinakis-vng]

Feature description

Hello, we'd like to using OpenTelemetry in our Kotlin Micronaut application. However, the OpenTelemetry Context doesn't seem to be preserved after the first coroutines suspension.

For the Open-Tracing implementation, a custom Dispatcher has been created which cannot be used for OpenTelemetry.

Are there plans to support this feature?

Thanks!

[nfode]

I ran into the same problem and could solve it by duplicating the OpenTelemetryInvocationInstrumenter and let it implement the TracingInvocationInstrumenterFactory interface like the OpenTracingInvocationInstrumenter does. Implementing the interface from my understanding enables the restoring of the OpenTelemetry-Context after suspension due to the HttpCoroutineTracingDispatcherFactory.

Here is an example repository: https://github.com/nfode/micronaut-tracing-coroutines/tree/opentelemetry
And here the "fixed" OpenTelemetryInvocationInstrumenter: https://github.com/nfode/micronaut-tracing-coroutines/blob/opentelemetry/src/main/kotlin/com/example/Instrumenter.kt

[GeitV]

Would like to have this fix as well. Any plans to implement a fix for this into the official repo?

[dstepanov]

@GeitV What version do you have? Have you tried it?

[GeitV]

I am currently running Micronaut 4.6.3 but in our Elastic APM there's just this empty void where there used to be SQL queries when we changed from blocking to flow {}.

We also discovered that SecurityService from micronaut.security won't work if the endpoint returns Flow, so feels like context is lost every time flow {} is started. Our fix was to get user info before flow, work with data using flows and later convert them to lists.

But now we have some slow queries and we actually have no clue what's going on in flow and which parts of the queries are slow, without removing flow.