At this moment, we have an issue with all instrumentation that supports duration metrics based on the stable semantic convention. When using the stable semantic convention opt-in feature, duration histogram data points are recorded in seconds, but histogram buckets are still defined in ms, which leads to a wrong calculation and presentation of percentiles.

The plan is: with the merge of open-telemetry/opentelemetry-python#4361, we can move forward and add the advisory explicit_bucket_boundaries_advisory parameter for duration histograms of already migrated HTTP instrumentation that uses the stable semantic convention.

explicit_bucket_boundaries_advisory = [0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10]

HTTP_SERVER_REQUEST_DURATION
HTTP_CLIENT_REQUEST_DURATION

Instrumentations

• opentelemetry-instrumentation-flask opentelemetry-instrumentation-flask: add explicit http duration buckets for stable semconv #3523
• opentelemetry-instrumentation-django opentelemetry-instrumentation-django: add explicit http duration buckets for stable semconv #3524
• opentelemetry-instrumentation-falcon opentelemetry-instrumentation-falcon: add explicit http duration buckets for stable semconv #3525
• opentelemetry-instrumentation-wsgi opentelemetry-instrumentation-wsgi: add explicit http duration buckets for stable semconv #3527
• opentelemetry-instrumentation-asgi opentelemetry-instrumentation-asgi: add explicit http duration buckets for stable semconv #3526
• opentelemetry-instrumentation-urllib opentelemetry-instrumentation-urllib: add explicit http duration buckets for stable semconv #3519
• opentelemetry-instrumentation-requests requests: support explicit_bucket_boundaries_advisory in duration metrics #3464
• opentelemetry-instrumentation-urllib3 opentelemetry-instrumentation-urllib3: add explicit http duration buckets for stable semconv #3518

Related issues:

• OTEL_SEMCONV_STABILITY_OPT_IN latency buckets too big #3011