prometheus / prometheus/prometheus

Turn one source label into multiple target labels

Open
#12,896 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

component/service discovery help wanted kind/enhancement priority/P3
Dominant language
Go
Stars
66.1k
Forks
10.8k
Avg merge
2d 1h
Merged PRs (30d)
131

Description

Proposal

Hey

So, we have the usecase that we have one central prometheus instance and developers do not have access to the prometheus configuration. We are scraping consul for our metrics targets. While applications can provide their own labels, there is also certain data that the application doesn't know of, for example its (dynamic) id in our deployment system. What we'd like to be able to do, is to have some generic consul tag where can extract promtheus labels from.

For example with this config:

      - source_labels: [__meta_consul_tags]
        regex: "(?:^|.*?,)prom_label__(.+?)=(.+?)(?:$|,.*?)"
        action: replace
        target_label: $1
        replacement: $2

Given these consul tags:

a=b,b=c,prom_label__f=g,t=e,prom_label__z=l,l=o

I'd expect these labels in prometheus for the given target:

f=g,z=l

The workaround would be to manually list the labels for all services, which could be quite a lot.

I've already looked at the code and guess that we can easily change the regex code to use multiple matches instead of just one set of submatches. Adjusting the tests is an easy feat as well. This should imo not be a breaking change.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the regex handling code for relabeling and the related tests. Read how one source-label match currently produces target labels, then use the proposal's Consul-tag example as the expected behavior. Done means multiple matches produce the corresponding labels without breaking existing single-match behavior, with tests covering both cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, prometheus
Domain
observability
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.