WildFly 28.0.1.Final jdbc-instrumentation

[Roland Spindelbalker-Davila]

Hi,

we are currently in the process of upgrading to WildFly 28.0.1.Final and we ran into some problems with the integration of the open-telemetry jdbc-instrumentation.

We are using the wildfly-jar-maven-plugin to build a bootable JAR starting a modular WildFly. Along with some of the standard layers, we also have a custom feature pack we use to add our default configuration as well as some additional JARs like DB drivers.

Previously, we facilitated the jdbc-instrumentation by simply adding the OpenTelemetry JDBC driver via our feature pack and using it. (see here https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/jdbc/library).

This did work because the old implementation of the opentelemetry subsystem did immediately create the OpenTelemetry object and also registered it as global tracer (via GlobalOpenTelemetry).

Now, the subsystem only creates the configuration, and the OpenTelemetry object is only created on demand by the producer in smallrye-opentelemetry once it is injected somewhere (and it's also not registered as global anymore).

Due to that, the driver retrieves a default OpenTelemetry object via GlobalOpenTelemetry, which is then used throughout its life, and no DB related traces are exported to the collector configured in the opentelemetry subsystem.

We had a similar problem with opentracing, but there the driver did reload the GlobalTracer instance on each access, so we could switch the global instance once our application was deployed. That isn't possible now either, since it's not allowed to change the GlobalOpenTelemetry object once it has been registered.
And even if we circumvented that the driver does not reload it after the first access anyways, so we're out of luck there too.

So finally, here are my questions:

Do you have any idea, or preferred solution how JDBC instrumentation can be integrated into the tracing done by the WildFly opentelemetry subsystem? How would you suggest to integrate it in our setup?

Is there a reason why the OpenTelemetry object configured via the opentelemetry subsystem is not registered as global anymore? From our point of view it would make sense to have the single OpenTelemetry instance that is configured and managed by the server available as global instance.

Thank you upfront for your help and insights

Best regards

Roland Spindelbalker-Davila