distributedtracing: export Prometheus metrics via OTLP

[Munken]

Why the changes in this PR are needed?

Users running OPA as a sidecar alongside an OpenTelemetry collector currently need a
dedicated OTel sidecar just to scrape OPA's Prometheus /metrics endpoint. This PR
lets OPA push its Prometheus metrics directly to an OTel collector via OTLP, eliminating
that extra sidecar and simplifying deployment (see #7591).

What are the changes in this PR?

• Use the OTel Prometheus bridge
  to read from OPA's existing prometheus.Registry and export metrics through a
  periodic OTLP exporter (gRPC or HTTP), reusing the same distributed_tracing
  address and TLS configuration as traces.
• Two new config fields under distributed_tracing:
  • metrics (bool, default false) — opt-in to push Prometheus metrics via OTLP.
  • metrics_export_interval_ms (int, default 60000) — interval between exports.
• Expose Gatherer() on the Prometheus provider so the registry can be passed to the bridge.
• Graceful shutdown of the MeterProvider on server stop.
• Unit tests for config parsing, defaults, and validation.
• E2E test with a mock OTLP HTTP collector that verifies http_request_duration_seconds arrives.
• Documentation updates in configuration.md.

Notes to assist PR review:

• The feature is fully opt-in; metrics: false by default means zero impact on existing deployments.
• It is not possible to enable metrics without also enabling tracing. This is because type is what enables tracing.
• The implementation follows the "good enough" approach discussed in Export metrics via OTLP #7591 — bridging
  existing Prometheus metrics rather than rewriting them with the OTel SDK.
• metrics_export_interval_ms is validated to be a positive value.
• All OTel dependencies are aligned at v1.40.0 to match the existing trace exporter versions.

Further comments:

• Discussion and design context: Export metrics via OTLP #7591
• AI tools (Claude Code) were used to assist with this PR. The author has reviewed
  and understands all changes per the project's
  AI guidelines.

[Munken]

Also tested manually tested with

distributed_tracing:
    type: http
    address: localhost:4318
    encryption: "off"
    metrics: true
    metrics_export_interval_ms: 5000

Local otel stack:

docker-compose:

services:
  # Jaeger for storing traces
  jaeger:
    image: jaegertracing/jaeger:2.10.0
    ports:
      - '16686:16686' # Web UI
      - '4317' # OTLP gRPC
      - '4318' # OTLP HTTP

  # Prometheus for storing metrics
  prometheus:
    image: prom/prometheus:v3.5.0
    ports:
      - '9090:9090' # Web UI
      - '4318' # OTLP HTTP
    command:
      - --web.enable-otlp-receiver
      # Mirror these flags from the Dockerfile, because `command` overwrites the default flags.
      # https://github.com/prometheus/prometheus/blob/5b5fee08af4c73230b2dae35964816f7b3c29351/Dockerfile#L23-L24
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus

  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.135.0
    volumes:
      - ./otel-collector-config.yml:/etc/otelcol-contrib/config.yaml
    ports:
      - '4318:4318' # OTLP HTTP ( exposed to the host )
      - '4317:4317' # OTLP gRPC ( exposed to the host )
    depends_on:
      - jaeger
      - prometheu

otel-config

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlp/jaeger:
    endpoint: jaeger:4317
    tls:
      insecure: true
  otlphttp/prometheus:
    endpoint: http://prometheus:9090/api/v1/otlp
  debug:
    verbosity: detailed
  # verbosity: normal

processors:
  batch:

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [pprof, zpages, health_check]
  pipelines:
    traces:
      receivers: [otlp]
      exporters:
        - otlp/jaeger
        # Enable debug exporter to see traces in the logs
        #- debug
      processors: [batch]

    metrics:
      receivers:
        - otlp 
      processors: [batch]
      exporters:
        - otlphttp/prometheus
        # Enable debug exporter to see metrics in the logs
        - debug

[netlify]

✅ Deploy Preview for openpolicyagent ready!

Name	Link
🔨 Latest commit	9b771d6
🔍 Latest deploy log	https://app.netlify.com/projects/openpolicyagent/deploys/69d65f5e3125e50008395ca7
😎 Deploy Preview	https://deploy-preview-8450--openpolicyagent.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[sspaink]

What do you think of changing this to something like metrics_export: "OTLP"? Might be other protocols in the future we could support and using a boolean would force us to add a new config option. Would also be nice if it was more explicit that this config option enables OTLP exporting.

[Munken]

In that case I would suggest using metrics_export: otlp/grpc or metrics_export: otlp/http. That way it can be enabled without also enabling tracing.

[sspaink]

That seems like a good idea to me 👍

[Munken]

Found a downside, the type is coupled to the address via the port eg 4317 for grpc and 4318 for http.

So if we want full flexibility to set these independently that it should probably be moved out of the tracing config section.

Alternatively, one could add a metrics_adress but then we are almost there.

[Munken]

@sspaink I've pushed a new commit that seperates the metrics export from the tracing.
There is some overlap in config though, so I've seperated the shared logic also.

Main downside with this approach is that one has to potentially config TLS twice.

[sspaink]

Having to configure TLS twice isn't great, but I do think this new approach will make it easier to make changes in the future that makes it worth it. Thanks for updating it!

[Munken]

We could introduce a common section that both inherent from. Would also move the service name there

[sspaink]

Would still need to support the TLS in the tracing section for backwards compatibility though. I don't think it is required for this change so could be in a separate PR. If you are up for the challenge a common section could be helpful.

[sspaink]

LGTM, thanks for working on this. Just a nit regarding the copyright headers.

[Munken]

LGTM, thanks for working on this. Just a nit regarding the copyright headers.

Thanks!

I applied the suggestion.
Merge at your discretion.