Dynamic Relabel of Label Names

[nikgrok]

Hey guys,

I seem to be having issues dynamically relabeling the the label name based on regex. I'm not sure if this was meant to be supported, but I hope we can works something out.

Example

- source_labels: ['__meta_consul_tags']
      regex: 'SomeRegex'
      target_label:  '$1'
      replacement:   '$2'

Basically, we would like to give users the ability to put in a consul tag that we can transform into a label.
Consul Tag: lbl-httpport-8080
Preferred Output: httpport="8080"

[fabxc]

As valid label names do not contain $ we could even add this to the replace action without breaking anything.

@brian-brazil thoughts?

[brian-brazil]

Yeah, that'd make sense. The jmx exporter supports similar.

One note is that this will only allow you to set a single label in this manner, though a few relabel rules with the right regexes should do the trick.

[fabxc]

Doesn't that defeat the purpose? If I allow only one, it's only usable in a meaningful way if I know the label anyway – thus, I don't need the feature anymore.

Most people posting their Consul SD config are encoding label/value pairs into Consul tags. Without allowing multiple per relabeling rule there is no way of getting those out again.

[nikgrok]

I would also prefer to have that as well.
You can see our tags that we grab from consul., in theory, we'd like to
give users the ability to the hyphenated fields into labels.
In the below case, I image our users using the below labels.
httpsPort=null
cluster=chi2
configRevision=28441
Environment=prod
httpPort=8080
owner=infra

ConsulTags=",all,chi2,prod,owner-infra,revision-284417,httpsPort-null,cluster-chi2,configRevision-28441,environment-prod,httpPort-8080,"

On Mon, Sep 21, 2015 at 3:01 PM, Fabian Reinartz notifications@github.com
wrote:

Doesn't that defeat the purpose? If I allow only one, it's only usable in
a meaningful way if I know the label anyway – thus, I don't need the
feature anymore.

Most people posting the config a encoding label/value pairs into Consul
tags. Without allowing multiple per relabeling rule there is no way of
getting those out again.

—
Reply to this email directly or view it on GitHub
#1099 (comment)
.

[brian-brazil]

Doesn't that defeat the purpose? If I allow only one, it's only usable in a meaningful way if I know the label anyway – thus, I don't need the feature anymore.

You can do one per relabelling. As long as you don't want an unbounded number of labels (10 is probably fine) it'll work.

[fabxc]

That's the most hacky and unsatisfying solution possible for a common use case. You haven't said yet why one relabeling config must not generate more than one label.

[brian-brazil]

I was talking in terms of the proposed solution, you thought that this limited things to one label total.

If we want to allow multiple output labels we'll need to figure out the syntax. Relabelling is already fairly complex for users, I'm a bit hesitant to make it even more complex - and we generally don't allow configuration options that can be handled instead via a configuration management system.

[fabxc]

This is not something handled by the configuration management. People get a dynamic list of labels (encoded in Consul tags) from their very much dynamic Consuls.

If you refer to the possibility of letting the configuration management yield 20 relabel configs doing the same, that's not a "solution".

[jimmidyson]

This would also be very useful for Kubernetes SD to convert __meta_kubernetes_service_label_<name> to Prometheus labels.

[fabxc]

For that one the labelmap action type would work, no? (The source of the whole misery is that Consul doesn't support labels.)

[jimmidyson]

Oops yes - remember now :)

[brian-brazil]

If you refer to the possibility of letting the configuration management yield 20 relabel configs doing the same, that's not a "solution".

That's what I'm referring to, that achieves the desired result so it is a valid solution and is inline with our previous decisions relating to configuration. We have to be careful of perfectly catering with a feature for every use case, as that will end up with so many options that it ultimately makes the service harder to use rather than easier.

Also given that all regex are anchored, I believe that's the only solution as we can't have multiple matches. Even if we were did allow multiple labels to be output, they have to come from different capture groups which doesn't help here as they'd all be the same two capture groups.

[pete0emerson]

+1 to adding dynamic labeling. The consul case is exactly ours as well. Split on : and set the left side to the target_label and the right side to the replacement.

    - source_labels: ['__meta_consul_tags']
      regex:         '.*,(.*?):(.*?),.*'
      target_label:  '$1'
      replacement:   '$2'

[beorn7]

I guess #2078 has fixed this.

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