Similar to Prometheus' best practices for naming directly exposed metrics, there are some conventions for naming the output metrics of recording rules. This helps keep your recording rule names consistent and predictable. However, these conventions are not interpreted or enforced in any way by Prometheus itself, so you can also choose to use a different naming scheme in your organization.

The main convention is to name metrics in three parts, separated by colons (:): <aggregation level>:<metric name>:<aggregation type>.

• A prefix that tells you what the aggregation level of the metric is, listing the relevant labels that are still present on the output metric.
• The original name of the metric that is being aggregated, with e.g. _total suffixes from counter metrics being dropped after applying a rate() function.
• The type of aggregation (dimensional aggregation, type of rate, etc.) that is being applied to the metric.

For example, a recording rule that computes the following expression:

sum by(job, path) (rate(http_requests_total{job="my-job"}[5m]))

...might have the output metric name:

path:http_requests:rate5m

The path prefix tells you that the metric is still broken up by the path label (job is implicit, as it is the same across all selected metrics), while the rate5m suffix tells you that the metric is a 5-minute rate. The sum() aggregation is implicitly assumed in an aggregated set of rates and thus not included in the rate5m part.

You can find the full list of these conventions in the Prometheus documentation.