Hi all,
Currently, the prometheus metrics are of the form namer:xx
and rt:xx
and so on. I think we should have a linkerd_
prefix for all the metrics. Is this something that was considered or if not, can be considered?
Thanks,
Amit.
Hi all,
Currently, the prometheus metrics are of the form namer:xx
and rt:xx
and so on. I think we should have a linkerd_
prefix for all the metrics. Is this something that was considered or if not, can be considered?
Thanks,
Amit.
Hi @amitsaha – I don’t think that’s been considered before, but it might be possible to make the prefix configurable. Out of curiosity, do most other project who export to prometheus also use unique prefixes? I was under the impression that you could use the job
label to distinguish metrics coming from linkerd from the rest of the metrics in your system. So for instance with this scrape config:
scrape_configs:
- job_name: 'linkerd'
metrics_path: /admin/metrics/prometheus
You could query for linkerd metrics with something like jvm:heap:used{job="linkerd"}
.
yes, that’s what we do at SoundCloud, too. Using labels to select metrics is more robust; i.e. you might have different kinds of linkerd (or some other service) running in the org, and labels let you specify which one(s) you want.
We can certainly do that. However, a prefix like linkerd_
makes sense (I think). The prometheus docs has this on metrics naming
For metrics specific to an application, the prefix is usually the application name itself.
A prefix I think servers two purposes:
labels
for).Cool, that all makes sense. I’d say it’s worth opening an issue in the linkerd repo to track it. This is the type of feature that we’d gladly accept as a contribution from the community, but am not sure it will get prioritized independently. For backwards compatibility, the prefix should be configurable, with the default being no prefix.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.