[prometheusreceiver] Consider separating prom service discovery from the receiver module

[dashpole]

Component(s)

receiver/prometheus

Describe the issue you're reporting

The prometheus receiver currently imports all service discovery implementations supported by Prometheus. A previous analysis from a Google team that used the collector found that this increased the binary size and memory footprint by ~50 Mb (although that may have changed).

It should be possible for distributions to exclude service discovery implementations they don't need. However, this will break any users currently relying on those.

While doing this, we should ensure that existing distributions (e.g. contrib) continue to support all of the existing service discovery implementations they support today, and we should make sure other distributions built using the OpenTelemetry Collector Builder have a mechanism to include them as well.

The question I don't have an answer to is: Is there a way to add an import (without it being a collector "component") to an OCB manifest? Or do we need to wrap this in an "extension" or something like that to make it work. (cc @braydonk)

@open-telemetry/prometheus-interoperability

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

• receiver/prometheus: @Aneurysm9 @dashpole @ArthurSens @krajorama

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[braydonk]

The question I don't have an answer to is: Is there a way to add an import (without it being a collector "component") to an OCB manifest? Or do we need to wrap this in an "extension" or something like that to make it work.

Without something like Go module replacement black magic, I believe making it an extension would be the only way to make this possible.

I haven't looked at the Service Discovery code so not 100% sure, but the general concept does sound like something that belongs in an extension; we have some precedent for components hooking only into particular types of extensions like auth extensions or the encoding extension so it wouldn't be too weird to have a section of the prometheusreceiver config that will fail validation if the configured extension isn't the right type. However it may be very difficult to change the config to work with extensions in a way that isn't a breaking config change.

[dashpole]

I essentially just need to be able to add:

import _ "github.com/prometheus/prometheus/discovery/install"

Somewhere in the final binary. If I have to put that line in an extension, I guess we can do that.

Note that users wouldn't need to use the extension in any way. Once that import statement is anywhere in the final binary, all of the service discovery implementations would be available to the prometheus receiver.

[braydonk]

Ah I see. I don't think there's quite precedence for something like this but the extension still feels like the right spot. It seems intuitive enough to say that if you want service discovery functionality, configure something like:

extensions:
  prometheusservicediscovery: # name pending

service:
  extensions: [prometheusservicediscovery]

This way users can opt not to include it in their OCB config to avoid linking it into the binary at all. There might be something I'm not seeing, but every other method I can think of still requires the package be linked into the binary, and I didn't see the team's analysis but there is a good chance the mere presence of the package in the binary is a chunk of the RSS footprint.

[dashpole]

Right. Users wouldn't need to put anything in their yaml, since the import statement itself registers the service discovery implementations via init(). This is just about what is included in the binary.