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: [RFE] Feature request to retrieve charm revision operator#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.