Feature Request: dynamic target discovery via URL

[r0fls]

What did you do?

N/A

What did you expect to see?

N/A

What did you see instead? Under which circumstances?

N/A

Environment

• System information:

    N/A
  

• Prometheus version:

  1.8.0

• Alertmanager version:

    N/A
  

• Prometheus configuration file:

   N/A
  

• Logs:
  N/A

It seems https://prometheus.io/blog/2015/06/01/advanced-service-discovery/#custom-service-discovery is the only way to dynamically discover targets. This is a feature request for the ability to point to a URL that returns a list of the desired prometheus targets. For example:

scrape_configs:
    target_source:
        prometheus-discovery.myurl.com

And prometheus-discovery.myurl.com would return a JSON list of targets to be added.

[brian-brazil]

You can write a small cronjob with curl to dump that file to disk.

[r0fls]

Thank you, I'm familiar with that solution. Seems it should be mentioned in the docs, outside of the blog though.

Also, would you not be open to this feature as a PR? In certain cases (e.g. kubernetes) you have to mount a shared volume to accomplish this, which seems like overkill given I would expect this to be a fairly common request.

[CAFxX]

@brian-brazil what if, for company policy, you have no access to the prometheus server to colocate something there? wouldn't an HTTP listener be a better fit for a modern tool that monitors distributed systems?

[brian-brazil]

I appreciate that many companies have bad policies, but what you should look at is fixing the policy. In this case you probably to talk to the provider of the shared Prometheus service and ask why they aren't already hooking into your company's standard SD mechanism (whatever that is), as that's core functionality of a shared Prometheus service.

We can't offer solutions to every company's self-inflicted problems, and this form of argument has little weight as it can be used for anything. We have to presume a reasonably standard Unix environment, otherwise things get weird and over-complicated fast.

[CAFxX]

It's clear we disagree on this. Probably my fault for being unable to explain the breadth of the problem.

Now, if you'll excuse me, I'll go look for the magic wand that can fix all bad policies.
（<｀▽´）―━━☆⌒*.

[cchance27]

Ran across this and don't get why it was so negatively received, The basic premise seems like a good one, instead of local file for target list, a remote url, why should someone have to write a curl script to grab an api, instead of just adding a function to allow direct requests to a api. Hell, it doesn't even have to be json, it could literally be a URL to a standard <file_sd_config> ... Just if it starts with http/https Prometheus grabs the file from the url instead of from local disk.

This would allow cool things like say librenms/nagios/pandora, or other NMS systems to provide an export of devices by OS, and Prometheus to set up a target selection that polls a third party NMS for the latest list of devices to poll, and the NMS handles snmp discovery.

Having to write a 3rd party script just to grab a file_sd_config from remote and save it locally every X minutes while easy, seems like an extra step vs just allowing for remote grabs as part of file_sd_config.

[icco]

See also https://groups.google.com/d/msg/prometheus-developers/JcE5nSbCe4k/bYSUc8atAAAJ

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