Include supported libraries from opentelemetry-java-instrumentation in quarkus-opentelemetry

[XSAM]

Description

After I removed all the opentelemetry libs and the OpenTelemetry Agent except the quarkus-opentelemetry, which is suggested by Quarkus Opentelemetry docs

Extensions and the libraries they provide, are directly instrumented in Quarkus. The use of the OpenTelemetry Agent is not needed nor recommended due to context propagation issues between imperative and reactive libraries.

The instrumentations of quarkus core-lib are working well. But I lost the instrumentation of AWS SDK and grpc client (bring by com.ibm.etcd:etcd-java). These libs were instrumented by the OpenTelemetry Agent.

It looks like I have to choose between quarkus-opentelemetry lib and OpenTelemetry Agent. Is there any way I can keep quarkus-opentelemetry but also has the instrumentation for those non-quarkus libs?

Implementation ideas

Maybe provide an additional library called quarkus-opentelemetry-instrumentation to support all the libs that are supported in https://github.com/open-telemetry/opentelemetry-java-instrumentation?

[quarkus-bot[bot]]

/cc @brunobat (opentelemetry), @radcortez (opentelemetry)

[brunobat]

It's a bit of try and error, If you don't use native mode you can try to add particular instrumentation libraries, not the agent, but particular instrumentation libraries used by the agent. See: https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation Depending on how the instrumentation on those libraries is wired, you might get spans... The main problem is if they try to instantiate the instrumentation too early in the boot process.

[XSAM]

From https://quarkus.io/guides/opentelemetry:

Extensions and the libraries they provide, are directly instrumented in Quarkus. The use of the OpenTelemetry Agent is not needed nor recommended due to context propagation issues between imperative and reactive libraries.

Could I know the reason for not being compatible with the otel java agent in the first place?

due to context propagation issues between imperative and reactive libraries.

This could be solved by adding a mutiny interceptor.

public class UniInterceptor implements io.smallrye.mutiny.infrastructure.UniInterceptor {
    // ConfigProperty is not working in SPI.
    static final boolean enabled = Boolean.parseBoolean(System.getenv("MUTINY_INTERCEPTOR"));

    @Override
    public <T> UniSubscriber<? super T> onSubscription(Uni<T> instance,
                                                       UniSubscriber<? super T> subscriber) {
        var parentContext = Context.current();

        if (enabled) {
            return new UniSubscriber<T>() {
                @Override
                public void onSubscribe(UniSubscription subscription) {
                    try (var ignored = parentContext.makeCurrent()) {
                        subscriber.onSubscribe(subscription);
                    }
                }

                @Override
                public void onItem(T item) {
                    try (var ignored = parentContext.makeCurrent()) {
                        subscriber.onItem(item);
                    }
                }

                @Override
                public void onFailure(Throwable failure) {
                    try (var ignored = parentContext.makeCurrent()) {
                        subscriber.onFailure(failure);
                    }
                }
            };
        } else {
            return subscriber;
        }
    }
}

---

With only quarkus-opentelemetry, we will lose the instrumentation of third-party libs (I tried to use AWS SDK lib that otel provided, but it doesn't work with quarkus-opentelemetry), which makes the trace result less usefull/reliable.

My suggestion for the quarkus is to keep the compatibility of the otel java agent, as they provide most of the instrumentation for third-party libs and it is their goal to provide more. For that, quarkus can only concentrate on the otel java agent compatibility, and the users can have stable instrumentation for quarkus libs and third-party libs.

[radcortez]

Could I know the reason for not being compatible with the otel java agent in the first place?

A big issue with the agent is that it doesn't work in native mode. In Quarkus, everything that we support has to work in native. I believe there is some work to be able to support agents in native mode, but that is not yet a possibility.

Also, because the implementation agent instrumentation modifies the bytecode, including pieces of private APIs, the instrumentation may or may not work, depending on which version OTel is targeting and Quarkus is targeting.