Node_exporter: [FR] Filter '^go_*' or '^go_memstats_*' by default

[RichiH]

@SuperQ As discussed, just as a reminder.

[brian-brazil]

Hmm, #556

[SuperQ]

Yes, we have a flag for on/off. Are you thinking we need something more granular?

[brian-brazil]

That memstats are expensive is long fixed, so I don't see a reason that metric_relabel_configs wouldn't be sufficient.

[RichiH]

The thinking is around orgs which want to reduce metrics across the fleet.

Datapoint: We are talking 34 go_* metrics as of today.

[brian-brazil]

I don't think adding a flag to every Go application in existence is viable, and in general we should be encouraging runtime metrics like these to be included. This sounds more like a question for client_golang. @beorn7

[beorn7]

I am confused.

node_exporter already has the flag. Is this issue about flipping the default value of the --web.disable-exporter-metrics to true? I would say that the default behavior should be the one that works best for the naive user. And that's IMHO to leave things as is. The naive user doesn't run super large scale installations, and the naive user will only notice their need for those metrics when an incident has happened. Switching off those metrics should be an informed decision and thus not be the default. Whoever runs installations big enough so that those metrics matter should be knowledgeable enough to flip this flag.

client_golang already offers all necessary tools to include or not include go_... metrics. As discussed earlier, there is no intention for a more fine-grained selection than adding a collector or not. There is, however, the old issue about generic filtering via URL parameters, but that's not an easy one and needs quite a bit of discussion to find a good and generally agreed way, if it is at all feasible.

So what is this issue about then?

[SuperQ]

I agree with @beorn7, I think the --web.disable-exporter-metrics flag is sufficient. Users who want more granularity can use metric_relabel_configs.