Make the set of labels consistent within each metric exported by Linkerd
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 11.5k
- Forks
- 1.4k
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 53
Description
## Feature Request
### What problem are you trying to solve?
Make the set of labels consistent within each metric exported by Linkerd.
Per the [Prometheus doc](https://prometheus.io/docs/instrumenting/writing_exporters/#labels), a single metric should always be exported with the same set of labels.
Prometheus' `client_golang` enforces this requirement in `prometheus.Registry`:
https://github.com/prometheus/client_golang/blob/673e4a177a5816096fb34777d8006fd138dbab2f/prometheus/desc.go#L35-L39
To put it another way, the set of metrics and labels exported by the Linkerd proxy would not be permitted in `client_golang`, for example:
```
response_total{
namespace="linkerd"
deployment="linkerd-controller",
}
response_total{
namespace="linkerd"
statefulset="linkerd-controller",
}
```
Additionally, if we want to answer the question: "What deployments are calling my service?", we need to query Prometheus like this:
```
response_total{
deployment!="",
dst_deployment="linkerd-controller",
dst_namespace="linkerd"
}
```
### How should the problem be solved?
Introduce new labels:
- `workload`
- `name`
- `dst_workload`
- `dst_name`
#### Current example
```
response_total{
deployment="linkerd-web",
dst_deployment="linkerd-controller",
}
```
#### Proposed example
```
response_total{
workload="deployment",
name="linkerd-web",
dst_workload="deployment",
dst_name="linkerd-controller",
}
```
### How would users interact with this feature?
This change would be transparent, provided existing labels were maintained. It would enable users to re-export and interact with Linkerd metrics in a Prometheus-standard way. For example, "What deployments are calling my service?" becomes:
```
response_total{
workload="deployment",
dst_workload="deployment",
dst_name="linkerd-controller",
dst_namespace="linkerd"
}
```
Relates to #4101.
/cc @adleong @grampelberg
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no implementation files or tests; start by locating the Linkerd proxy metric export path and the definitions for response_total and related metrics. Compare label sets across workload kinds, then verify that each metric uses consistent workload, name, dst_workload, and dst_name labels while preserving existing labels.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes, prometheus
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100