In the Observability team at Canonical, we have working on COS Lite, the new Kubernetes-based observability stack.
Now, an observability stack also needs to be monitored (“Quis custodiet ipsos custodes” and all that) and, while the mechanics are pretty straightforward, that poses an interesting question in terms of end-user experience: for charms that provide monitoring-related relations to other charms, what is the most intuitive name for the relations about monitoring those charms that perform monitoring for others?
For example, let’s take the case of metrics and prometheus-k8s. Prometheus itself exposes a metrics endpoint, that either itself or (better) something else (like Grafana Agent) would scrape.
We use the metrics-endpoint
relation name for the relations between prometheus-k8s
and the other charms it will scrape. We have received feedback that that relation name is intuitive, both when reading the metadata.yaml
and from juju status
.
But how should we call the relation to scrape prometheus-k8s
itself?
self-metrics-endpoint
own-metrics-endpoint
our-metrics-endpoint
0 voters
If you have other ideas, post them below!
P.S. If you are interested in Juju and Observability, come talk to us this Friday at the Community Workshop!