Defining recording rules

    Prometheus supports two types of rules which may be configured and then evaluated at regular intervals: recording rules and . To include rules in Prometheus, create a file containing the necessary rule statements and have Prometheus load the file via the rule_files field in the Prometheus configuration. Rule files use YAML.

    The rule files can be reloaded at runtime by sending SIGHUP to the Prometheus process. The changes are only applied if all rule files are well-formatted.

    To quickly check whether a rule file is syntactically correct without starting a Prometheus server, install and run Prometheus’s promtool command-line utility tool:

    If there are any syntax errors or invalid input arguments, it prints an error message to standard error and exits with a 1 return status.

    Recording rules allow you to precompute frequently needed or computationally expensive expressions and save their result as a new set of time series. Querying the precomputed result will then often be much faster than executing the original expression every time it is needed. This is especially useful for dashboards, which need to query the same expression repeatedly every time they refresh.

    Recording and alerting rules exist in a rule group. Rules within a group are run sequentially at a regular interval. The names of recording rules must be . The names of alerting rules must be valid label values.

    1. groups:
    2.   [ - <rule_group> ]

    A simple example rules file would be:

    1. # The name of the group. Must be unique within a file.
    2. name: <string>
    4. [ interval: <duration> | default = global.evaluation_interval ]
    6. rules:
    7.   [ - <rule> ... ]

    <rule>

    The syntax for recording rules is:

    The syntax for alerting rules is:

    1. # The name of the alert. Must be a valid label value.
    2. alert: <string>
    4. # The PromQL expression to evaluate. Every evaluation cycle this is
    5. # evaluated at the current time, and all resultant time series become
    8. # Alerts are considered firing once they have been returned for this long.
    9. # Alerts which have not yet fired for long enough are considered pending.
    10. [ for: <duration> | default = 0s ]
    12. # Labels to add or overwrite for each alert.
    13. labels:
    14.   [ <labelname>: <tmpl_string> ]
    16. # Annotations to add to each alert.
    17.   [ <labelname>: <tmpl_string> ]