No support for OpenTelemetry Metrics API

[chris-pinola-rf]

Objectives

My hope is that this issue will serve to:

1. Assess the Datadog team's interest in supporting the OTel metrics API in dd-trace-java.
2. Provide other members of the community with workarounds for this limitation. I've shared mine below but I don't particularly like my approach and I am very open to suggestions.

Summary

dd-trace-java is currently capable of providing an SDK implementation for the OpenTelemetry tracing API, but not the metrics API. This creates a tricky situation for applications which:

1. depend on both the OTel tracing & metrics APIs to expose custom instrumentation
2. wish to use dd-trace-java's OTel tracing implementation as to not break compatibility with Datadog's proprietary trace context and therefore should avoid taking dependencies on the OTel SDK packages

In my case, these applications previously relied upon the open-telemetry/opentelemetry-java-instrumentation javaagent to provide SDK implementations for both the OTel tracing & metrics APIs.

Example

Using the latest available version of dd-trace-java, the following test passes when the DD_TRACE_OTEL_ENABLED environment variable is set to true (see docs):

import io.opentelemetry.api.GlobalOpenTelemetry
import io.opentelemetry.api.metrics.MeterProvider
import io.opentelemetry.api.trace.TracerProvider
import org.junit.jupiter.api.Assertions
import org.junit.jupiter.api.Test

// ...

@Test
fun `demonstrate lack of metrics support`() {
    val openTelemetry = GlobalOpenTelemetry.get()

    Assertions.assertFalse { TracerProvider.noop() === openTelemetry.tracerProvider }
    Assertions.assertEquals(
        "datadog.opentelemetry.shim.trace.OtelTracerProvider",
        openTelemetry.tracerProvider::class.java.name,
    )

    Assertions.assertTrue { MeterProvider.noop() === openTelemetry.meterProvider }
    Assertions.assertEquals(
        "io.opentelemetry.api.metrics.DefaultMeterProvider",
        openTelemetry.meterProvider::class.java.name,
    )
}

Workaround

In order to avoid taking a direct dependency on the OTel SDK packages from these applications, I've been working around this limitation by using the OpenTelemetry-to-Micrometer bridge in conjunction with Micrometer's OTLP exporter pointed at the Datadog Agent's OTLP endpoint.