Allow query params for scrape endpoints.

[fabxc]

Getting different scrape contents based on query parameters can be a useful addition.

The discussion started with #674. As stated there, I would like to avoid proxying by query parameters but only use them for actual modifications. But the line gets blurry quite fast.

As the issue of the PR will be resolved by relabeling, this is not too urgent for now.

[fabxc]

With #786 this becomes reality. We need to define some rules regarding parameter names.
I'd propose:

• _.+ for exporting applications
• __.+ for anything standing between an exporting application and Prometheus
• [^_]+ for the Prometheus handler

[brian-brazil]

I think encouraging _ for applications we don't control would be tricky, and suggest this logic be put the other way around. I'd also expect that anyone passing things to endpoints is going to either be sufficiently custom that there's nothing you'd want to pass to the Prometheus handler, or you're only talking to the prometheus handler.

[fabxc]

I'm not really willing to do prefixing for fundamental parameters of the actual application in favor of some potential custom setup. Especially because it doesn't guarantee anything if we assume the user may use anything.

We can also go for 0 restrictions, given the low chance of actual collisions, and expect people to do some renaming in their reverse proxies if required.

[fabxc]

Query parameters implemented via #786.

TODO: Expose query parameters for relabeling.

[brian-brazil]

#934 added relabelling.

[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.