How do I get the value of a metric label into a dashboard panel rather than the number?

It is awkward because of a design decision in the metrics model: a time series is a set of labels plus a stream of numbers, and the query language returns numbers. Labels identify a series; they are not values you can select.

The pattern that exists for exactly your case is the info metric: a series whose value is always 1 and whose labels carry the information. Version numbers, build identifiers and machine metadata are almost always published this way.

So the value being 1 is not a bug, it is the convention — the 1 means "this combination of labels exists".

Getting the label onto a panel is then a display problem rather than a query problem, and there are two routes.

Route one: let the panel render the label. Most panels let you set the displayed name from the series labels using a template with the label name in braces. For a stat panel showing a version string, this is the whole answer — the number is hidden and the label is the text.

Route two: transformations. Take the query result as a table, then use transformations to pull the label into a column, join it against another query if you need to attach it to real values, and hide the columns you do not want. This is the route when you want the label alongside a genuine measurement — a table of machines with their version and their current load.

The join is the part worth learning. Two queries, one giving the metadata and one giving the numbers, joined on a shared label, gets you the table people usually want and it is not obvious that transformations can do it.

What does not work is trying to make the query return a string. The language has no way to do it, and time spent there is wasted.

A trick worth knowing for combining an info metric with a real one in a single query: multiply by the info series and use the label grouping to carry the labels across.

The general shape is to take your measurement and multiply it by the info metric using a grouping that keeps the identifying label. The value is unchanged because the info metric is 1, and the result now carries the extra labels.

It looks like a hack and it is the standard idiom, precisely because labels travel with the series. Once you have seen it, a lot of dashboards that seemed impossible become straightforward.

The caveat is that if the info series is ever missing for a machine, the multiplication drops that machine entirely — which is a silent gap rather than an error, and it is worth knowing when a row disappears.

Worth saying what not to do, because people arrive at it: do not put high-cardinality values into labels to make them available.

Every distinct combination of label values is a separate series, stored and indexed separately. Putting a request identifier, a user identifier or a timestamp in a label multiplies your series count and will eventually take the metrics system down.

If you need per-request detail, that is what logs and traces are for. Metrics are for things with a small, bounded set of values.