How should we call relations for monitoring COS charms

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!

For exposing Prometheus’ own metrics endpoint relation how about

        interface: prometheus_scrape

@bthomas but how would you call the relation to push Prometheus logs using the loki_push_api relation interface? logging-diagnostics? Maybe then a better proposal would be metrics-diagnostics (with dash, not underscore, for consistency with other relation names :D)

How about some thing along the lines of

        interface: loki_push_api

My main point being to use the phrase “diagnostics” to distinguish “self-monitoring” from “monitoring”.

Thank you for voting! We’re going with self-* for all self-monitoring relations.