Options for your Grafana panels when your metrics change names

March 1, 2024

In an ideal world, your metrics never change their names; once you put them into a Grafana dashboard panel, they keep the same name and meaning forever. In the real world, sometimes a change in metric name is forced on you, for example because you might have to move from collecting a metric through one Prometheus exporter to collecting it with another exporter which naturally gives it a different name. And sometimes a metric will be renamed by its source.

In a Prometheus environment, the very brute force way to deal with this is either a recording rule (creating a duplicate metric with the old name) or renaming the metric during ingestion. However I feel that this is generally a mistake. Almost always, your Prometheus metrics should record the true state of affairs, warts and all, and it should be on other things to sort out the results.

(As part of this, I feel that Prometheus metric names should always be honest about where they come from. There's a convention that the name of the exporter is at the start of the metric name, and so you shouldn't generate your own metrics with someone else's name on them. If a metric name starts with 'node_*', it should come from the Prometheus host agent.)

So if your Prometheus metrics get renamed, you need to fix this in your Grafana panels (which can be a pain but is better in the long run). There are at least three approaches I know of. First, you can simply change the name of the metric in all of the panels. This keeps things simple but means that your historical data stops being visible on the dashboards. If you don't keep historical data for very long (or don't care about it much), this is fine; pretty soon the metric's new name will be the only one in your metrics database. In our case, we keep years of data and do want to be able to look back, so this isn't good enough.

The second option is to write your queries in Grafana as basically 'old_name or new_name'. If your queries involve rate() and avg() and other functions, this can be a lot of (manual) repetition, but if you're careful and lucky you can arrange for the old and the new query results to have the same labels as Grafana sees them, so your panel graphs will be continuous over the metrics name boundary.

The third option is to duplicate the query and then change the name of the metric (or the metrics) in the new copy of the query. This is usually straightforward and easy, but it definitely gives you graphs that aren't continuous around the name change boundary. The graphs will have one line for the old metric and then a new second line for your new metric. One advantage of separate queries is that you can someday turn the old query off in Grafana without having to delete it.

Written on 01 March 2024.
« The speed of improvement in servers may have slowed down
Something I don't know: How server core count interacts with RAM latency »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Mar 1 23:33:03 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.