Ability to define targets via Prometheus scape configuration

[jessegonzalez-life360]

It does not look like this exporter supports defining multiple scrape targets using Prometheus scrape configurations. Has anyone found a solution or workaround that would allow you to do this? Our goal is to limit the number of containers we run per pod, and due to the elasticity of our environment, updating the --phpfpm.scrape-uri argument and restarting this exporter on instance scaling would still require some engineering effort.

Our first thought was to create a simple rest service that would invoke the php-fpm_exporter get command with the target scrape URI, but was thinking a solution that follows the multi-target exporter pattern may be valuable.

Is this something others would find value in?

scrape_configs:
  ## config for the multiple php-fpm targets that the exporter will scrape
  - job_name: 'php_fpm_exporter_targets'
    static_configs:
      - targets:
        - tcp://php-fpm-host1:9000
        - tcp://php-fpm-host2:9000
        - tcp://php-fpm-hostx:9000
    metrics_path: /status
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: php-fpm-exporter:9253

[davehayes]

I would also find value in this. Right now I have to use extra long strings who's length is proportional to the number of sites on the box. This runs into ARG_MAX, shell length limits, and other ideas.

To provide a bit of a use case, we have servers with 80-100 different PHP sites on them, some of which are running different versions of PHP. In order to monitor each one's PHP FPM usage (the goal), we need to specify -each- socket path as an argument (with a semi-colon and the PHP-FPM status path) . We can't (e.g.) use a wildcard .

In fact, a wildcard glob would be a simple solution to address my use case.