Consider reducing number of built-in discovery methods in 2.0

[mdlayher]

Akin to the deprecation of specific read and write paths for other databases, I think it could make sense to reduce the number of built-in discovery methods for Prometheus.

It seems that almost all of the discovery methods could be eliminated, with the exception of file discovery.

This could reduce maintenance burden and encourage the use of separate services which deal with service discovery for specific discovery methods like Kubernetes, EC2, Azure, etc.

These more focused services could expose a file on disk in the format that Prometheus understands. Perhaps it makes sense to have a HTTP and protobuf generic discovery method just like generic read and write as well. This could probably be more extensible and elegant than relying on file discovery for everything.

I'm very curious to hear the thoughts of the maintainers about this proposal. It would enable closing out a decent number of issues and also remove quite a few dependencies from the repository.

[juliusv]

I feel ya from a maintenance standpoint, but IMO that would be too tough on users. We already force them to run separate binaries for so many things, and something as fundamental as SD mechanisms we should support to a reasonable degree (like what we have right now, but not many more) out of the box IMO.

[mdlayher]

Seems fair to me. I'll close this out.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.