Support charm_revision and charm_channel labels

[amandahla]

Enhancement Proposal

Request

Visualize each published charm revision/channel.

What we have today from Juju Topology labels

• model name, model uuid, Application name and unit identifier.

What we want

• charm revision and charm channel.

It could be new labels or a static metric similar to pg_static from PostgreSQL exporter. Example here.

Requires

• information available via charm/ops.

Requested:

• Ops: https://github.com/canonical/operator/issues/1255
• Juju (environment variable): https://bugs.launchpad.net/juju/+bug/2077124

[simskij]

I'm not entirely convinced, as this would introduce unbound index keys (high cardinality labels), which could impact performance negatively. @sed-i, @lucabello, @MichaelThamm, @Abuelodelanada, wdyt?

[Abuelodelanada]

I'm not entirely convinced, as this would introduce unbound index keys (high cardinality labels), which could impact performance negatively. @sed-i, @lucabello, @MichaelThamm, @Abuelodelanada, wdyt?

From my point of view introducing channel as a new label is not that bad since it is a fixed set of values (edge, beta, candidate and stable)

On the other hand introducing revision which is an auto-increment value may lead to a cardinality bomb. As fas as I understand, every new revision will create a new time series.

[amandahla]

Creating a metric (charm_revision/charm_channel something) would work too.

[sed-i]

From Prometheus Up & Running (page 97), you'd be able to get what you're looking for by propagating INFO metric labels with on + group_left.

For example, given

from prometheus_client import Info

info_metric = Info("python_info", "Python platform information")
info_metric.labels(dict(impl="CPython",major="3",minor="5",patch="2",version="3.5.2"))

# HELP python_info Python platform information
# TYPE python_info gague
python_info{impl="CPython",major="3",minor="5",patch="2",version="3.5.2"} 1.0

Because the value of info metrics is always 1, we can propagate labels from it to up:

up
* on(instance, job)    # only up metrics that have the same job, instance labels
  group_left(version)  # many-to-one match: copy the version label over
python_info

Now all python versions will be added to the up metric.

We could use the same idea for charm_revision and charm_channel.

# HELP charm_info Charmhub revision of installed charm
# TYPE charm_info gague
charm_info{charm_revision="42", charm_channel="beta", juju_....}

The question becomes about the machinery for pushing that metric to prometheus.