Separate Tracing APIs into a dedicated artifact without pulling in metrics apis

[Emily-Jiang]

Is your feature request related to a problem? Please describe. MicroProfile community would like to adopt OpenTelemetry tracing not the metrics for the immediate future. At the moment, the opentlelemetry-api artifact has both tracing and metrics in the archive, which means the metrics APIs will be visible to the end users but MicroProfile won't support them as MicroProfile has MicroProfile Metrics to manage the metrics.

Describe the solution you'd like I would like to have a separate artifact for OpenTelemetry tracing, which just contains the tracing APIs. A possible artifact id: opentelemetry-api-tracing. This artifact just contains tracing apis not metrics apis. It seems Tracing apis do not depend on metrics apis. It might be feasible to do so.

Describe alternatives you've considered We discussed on today's call. One possible solution is to build a bridge to bridge OpenTelemetry Metrics to MicroProfile Metrics. However, MicroProfile Metrics is a separate feature and some customers might only specify Tracing. When they discovers they could use OpenTelemetry metrics and they go ahead calling the api without realising they need to also bring MicroProfile Metrics, and obvious it will not work. This could cause a lot of confusion.

Additional context Hopefully this will just a package issue not adding too much overhead.

[jkwatson]

If we were to make this change, there could definitely be an impact on users who were vetoing transitive dependencies for some reason. I suspect that might be an acceptably small number of users, but it is a possible breaking change for some.

[anuraaga]

Hi @Emily-Jiang - currently there is strong coupling between the OpenTelemetry API and the OpenTelemetry instrumentation ecosystem. Notably, instrumentation records both traces and metrics for libraries with a single entrypoint and needs access to both, which we accomplish with our OpenTelemetry object exposing the APIs together. OpenTelemetry is a solution to provide users with the three pillars of observability and we want to make it as easy as possible to do so.

We aren't comfortable creating a situation where OpenTelemetry users don't have access to instrumentation because they aren't using the full API and think we need to find a solution for MicroProfile users that will let them use instrumentation as well. Would bridging the OpenTelemetry API to MicroProfile metrics be OK for this?

Alternatively or in addition, an implementation of MeterProvider could be used that logs a warning when used instead of only being a no-op if the latter seems to cause confusion.

// Not public
final class MicroProfileOpenTelemetry implements OpenTelemetry {
  // Set to an SdkTracerProvider
  private final TracerProvider;

  private final MeterProvider = new MeterProvider {
    // All methods implemented to log a warning and pointer on how to initialize the OpenTelemetry metrics SDK, or MicroProfile metrics / OTel -> MicroProfile metrics bridge
}

[Emily-Jiang]

Would bridging the OpenTelemetry API to MicroProfile metrics be OK for this?

@anuraaga The problem is that in MicroProfile, Tracing and Metrics and separate. If I use MicroProfile Telemetry Tracing, with the current coupling between the OTel Tracing and Metrics, it mandates the enablement of MicroProfile Metrics, which is problematic.

[anuraaga]

@Emily-Jiang I think this will have to be handled with documentation in MicroProfile then. OpenTelemetry instrumentation expects the entire API, even if parts are no-op if a user isn't using that functionality, so that could probably be explained. One thing to keep in mind may be that it is unlikely that a user would use only tracing and not metrics in practice, metrics is the more widely used telemetry type, so the impact of that caveat may not be so large.

[Emily-Jiang]

@anuraaga in my use case, I have other metrics plugged in so I only want to use OpenTelemetry Tracing. Metrics would be provided by MicroProfile Metrics not OpenTelemetry Metrics for the time being.

[kenfinnigan]

I'd agree with @anuraaga. The problem should be solved with documentation in MicroProfile making it clear that only the Tracing APIs are supported from the OpenTelemetry API dependency.

[Emily-Jiang]

From the above conversation, it seems that 3 pillars (metrics, tracing and logging) are strongly coupled.