- Product Introduction
- Purchase Guide
- Getting Started
- Integration Guide
- Scrape Configuration Description
- Custom Monitoring
- EMR Integration
- Java Application Integration
- Go Application Integration
- Exporter Integration
- Elasticsearch Exporter Integration
- Kafka Exporter Integration
- MongoDB Exporter Integration
- PostgreSQL Exporter Integration
- Nginx Exporter Integration
- Redis Exporter Integration
- MySQL Exporter Integration
- Consul Exporter Integration
- Memcached Exporter Integration
- Integration with Other Exporters
- CVM Node Exporter
- Apache Exporter Integration
- Health Check
- Instructions for Installing Components in the TKE Cluster
- Cloud Monitoring
- Read Cloud-Hosted Prometheus Instance Data via Remote Read
- Agent Self-Service Access
- Pushgateway Integration
- Security Group Open Description
- Operation Guide
- Practical Tutorial
- Terraform
- FAQs
- Service Level Agreement
- TMP Policy
- Product Introduction
- Purchase Guide
- Getting Started
- Integration Guide
- Scrape Configuration Description
- Custom Monitoring
- EMR Integration
- Java Application Integration
- Go Application Integration
- Exporter Integration
- Elasticsearch Exporter Integration
- Kafka Exporter Integration
- MongoDB Exporter Integration
- PostgreSQL Exporter Integration
- Nginx Exporter Integration
- Redis Exporter Integration
- MySQL Exporter Integration
- Consul Exporter Integration
- Memcached Exporter Integration
- Integration with Other Exporters
- CVM Node Exporter
- Apache Exporter Integration
- Health Check
- Instructions for Installing Components in the TKE Cluster
- Cloud Monitoring
- Read Cloud-Hosted Prometheus Instance Data via Remote Read
- Agent Self-Service Access
- Pushgateway Integration
- Security Group Open Description
- Operation Guide
- Practical Tutorial
- Terraform
- FAQs
- Service Level Agreement
- TMP Policy
A recording rule allows you to calculate some commonly used or complex metrics in advance and then store the calculated data in new data metrics. In this way, querying the calculated data will be faster and easier than querying the original data. This is very suitable for dashboard scenarios and can solve the problems of complicated user configuration and slow query.
Recording rules exist in the form of rule group, and rules in the same group are executed sequentially at a certain interval. Rule names must conform to the corresponding Prometheus specification.
Generally, a rule file is as follows:
groups:[ - <rule_group> ]
Below is a simple example of recording rule:
groups:- name: examplerules:- record: job:http_inprogress_requests:sumexpr: sum by (job) (http_inprogress_requests)
Rule Group
# A rule group name must be unique in the same filename: <string># Rule detection interval[ interval: <duration> | default = global.evaluation_interval ]rules:[ - <rule> ... ]
Rule
The recording rule syntax is as follows:
# The generated new metric name, which must be validrecord: <string># PromQL expression. Each calculated data entry will be stored in the new metric name `record`expr: <string># The label to be added or overwritten in the data to be storedlabels:[ <labelname>: <labelvalue> ]
Recommended Name Format
The recommended format for naming recording rules is
level:metric:operations.level: indicates the recording level and the output label of the rule.
metric: indicates the metric name.
operations: indicates the list of operations applied to the metric.
Example:
- record: instance_path:requests:rate5mexpr: rate(requests_total{job="myjob"}[5m])- record: path:requests:rate5mexpr: sum without (instance)(instance_path:requests:rate5m{job="myjob"})
Yes
No
Was this page helpful?