Need a way to treat `params` as a list for scrape definitions

[hehnope]

Proposal

The primary use case is when combining blackbox_exporter and dns_sd_config; the __address__.

Another use case is if you're working with cloudwatch_exporter and specifying the region via HTTP param. If you have presence in more than one region, then you need a scrape definition for each region; instead, it's just "nicer" to create a list of http params that are scraped and treated as a single scrape definition based on the params.

Example

  - job_name: 'http-2xx'
    dns_sd_configs:
    - names:
        - "some_endpoint"
    scrape_interval: 60s
    metrics_path: /probe
    params:
      module: [http_2xx]

I initially tried to use:

params:
    target: [system1,system2,system3]

So, the idea is that:

1. dns_sd_configs is used to get the actual endpoint for blackbox_exporter.
2. Since you can send target to specify the host; then the idea is to just send that as an HTTP param.

I tried to combine both dns_sd_configs and static_configs but from what I can tell they both use __address__ and so dns_sd_config will end up getting overwritten and vice-versa. So, the idea is that instead to allow a way to "iterate" a param in params instead of combing both. Please note, I tried this and it does not work.

For example, if you use the following static config:

  - job_name: 'just-a-test'
    static_configs:
      - targets: ['localhost:33235']
    metrics_path: /probe
    params:
      targets: ['asdf', '123', '456']

Setup a nc: nc -nl 33235 and wait for prometheus to scrape you'll see:

# nc -nl 33235
GET /probe?targets=asdf&targets=123&targets=456 HTTP/1.1
Host: localhost:33235
User-Agent: Prometheus/2.4.0
Accept: text/plain;version=0.0.4;q=1,*/*;q=0.1
Accept-Encoding: gzip
X-Prometheus-Scrape-Timeout-Seconds: 30.000000

It would be nice to instead have prometheus iterate through the array and treat each one as a single request. Of course, I imagine changing the current functionality may cause breakage; so an alternative would also be ideal.

[simonpasquier]

With blackbox_exporter, the service discovery usually discover the endpoints to probe and the address of the exporter is set via relabeling so I don't see the need for this use case. See https://github.com/prometheus/blackbox_exporter#prometheus-configuration. I'm not sure about what is missing for cloudwatch_exoprter either.