Transition option to keep the route for a default module about exporter_exporter

[tcolgate]

v0.5.0 includes the support for a defaultModule configuration option. I think that, in combination with the configuration for alternate paths for proxy and telemetry metrics would be enough to achieve your original request.

[tcolgate]

I'm not quite sure I understand the suggestion (the last sentence isn't quite adding up). Could you show an example config, and what the behaviour would be (how it differs from the current setup).

[anisse]

The goal would be to replace exporter_exporter's /metrics with a given module. My use case would be to replace an exporter endpoint in-place, transparently, on the same port, before adding more modules.

Before:

• exporter X (let's say node_exporter), listens on port *:9100

After:

• exporter X listens on 127.0.0.1 port 9100
• exporter_exporter listens on port 9100. All requests to /metrics are treated as if they were requests to /proxy?module=node

The config would look like this:

modules:
    node:
    method: http
    http:
       address: 127.0.0.1
       port: 9100
transition_module: node

Now in my case it's a collectd's write_prometheus that I want to replace. Unfortunately this exporter has no router replies with the metrics on any path (!). To be safe I wanted to also replace the / route, but this might be erring too much on the side of caution.

I don't know yet what to do with exporter_exporter's own /metrics route. Maybe make it available at some other path during the transition.

[tcolgate]

TBH this seems very niche. Why not:

• leave existing exporter you are already scraping at a given port /metrics in place
• add exporter_exporter on a different port
• switch scrapes to new port
• once scrapes are all migrated, disable public access to the old default scrape port.

[tcolgate]

Perhaps a better options would be for exporter_exporter to allow a default module to be configured, then you could set the --web.proxy-path=metrics --web.telemetry-path=/expexp_metrics, and I think you'd get what you want

[anisse]

I agree, it looks pretty niche. We'll probably use the exact plan you proposed since it's simpler. I would have liked something like what you proposed since it allows to do the migration in-place, but it's not a hard requirement.
Let's close this issue.