opentelemetry-collector icon indicating copy to clipboard operation
opentelemetry-collector copied to clipboard

[telemetry] Simplify disabling of prometheus endpoint for internal telemetry metrics

Open pirgeo opened this issue 6 months ago • 2 comments

As it is now possible to export internal telemetry metrics via OTLP, scraping the Prometheus metrics from the collector is no longer the only way to get that data. Since users will likely export via both export paths, they might want to disable the Prometheus endpoint.

Have a look at the instantiation code today. You have two ways of disabling the Prometheus endpoint:

  1. Set service: telemetry: metrics: level: none. However, this will immediately return a noop MeterProvider and thus disable all exporting (including OTLP-based exporting).
  2. Set service: telemetry: metrics: address: "" (to an empty string). The code checks whether the string in the address is longer than 0 characters. However, having to know that only the empty string disables the additional Prometheus exporter feels unintuitive to me and makes the collector config confusing to read if you don't know exactly why you need to specify an empty string.

Describe the solution you'd like If another exporter is explicitly defined, the Prometheus exporter is automatically disabled. However, it can be explicitly added alongside the OTLP exporter if required.

Describe alternatives you've considered I am opening this issue to discuss possible solutions. Here are a few I came up with

  • Setting the address to null explicitly should disable the Prom exporter
  • Similarly, setting the address to "none" or "disabled" should turn off the exporter. I don't like this option, though, as it uses magic strings and is not intuitive.
  • Turning the Prometheus exporter off by default if another exporter is explicitly configured
  • Deprecating the service: telemetry: metrics: address: configuration option and requiring Prometheus exporters to be explicitly set up so they follow the same structure as the OTLP exporters. This could break backward compatibility, though, so we might need to introduce a feature gate.

pirgeo avatar Aug 20 '24 08:08 pirgeo