Adding a new relabel_config action: 'translate'

[fr0stbyte]

Proposal

Use case. Why is this important?

Add a new relabel_config action that will convert a substring from the target label into another substring for all occurrences.

The most obvious use case is when a certain characters from a metric names need to change in order to adjust to the exported store format, or user's preference.

I have seen that the general recommended approach is to address this issue in the exporter, but
a) not all exporters are easy configurable especially for this problem
b) character translation will need to be implemented for each exporter independently.

I understand that this can't solve all cases, but can solve for a majority of them, leaving the exporters solve only their very limited usecases that can't be addressed using the translation.

I took the liberty of building a POC in https://github.com/fr0stbyte/prometheus/tree/fr0stbyte/relabel_translate

I know there are things that can be improved upon in that branch, but I wanted to get the conversation started.

[brian-brazil]

Thanks for you suggestion. Can you explain more about your use case?

It is the responsibility of an exporter to produce valid and useful Prometheus metrics, and that include providing good metric names. This sort of thing should only be the case when you have no control over the code, which is not the case with an exporter.

[fr0stbyte]

Thanks for the prompt response and sorry for the delay in my response, I was in vacation.
It seems like a common pattern among the exporters to change the metric name in a form or another to adjust for their backend requirements. My proposal is to lift some of that in a transform so that will help
a) with some of the more basic transformations that aren't covered by the other relabel functions
b) reduce the complexity of the exporters as the functionality seems to be relatively common

I understand that it is the responsibility of the exporter to do the right thing about the metric names, but otoh there are the other relabel functions that could arguably be moved in the exporters as well.

[brian-brazil]

The primary purpose of metric_relabel_configs is to fix bad metrics that you don't have an alternative for. Having to use it out of the box would be a bad user experience, especially if you have a (recommended) setup where you're trying to use one scrape config for many many different types of applications.

If there's a transform that should be done across all metrics coming from an exporter by all users, that belongs in the exporter - not as an additional task for every single user of that exporter.

[brian-brazil]

This has gone stale, and doesn't make sense generally.