Recording rule — Prometheusda oldindan belgilangan so‘rovni muntazam bajarib, natijasini yangi time series sifatida saqlash qoidasidir. U murakkab yoki katta hajmdagi PromQL hisoblarini har dashboard ochilganda qayta bajarish o‘rniga tayyor agregatga aylantiradi. Natija odatiy metric kabi so‘raladi, retention va remote write jarayoniga ham qo‘shilishi mumkin.
Bajarilish tartibi
Qoidalar rule group ichida joylashadi. Har group evaluation interval bo‘yicha ishga tushadi va ichidagi qoidalarni konfiguratsiya tartibida baholaydi. Oldingi recording rule natijasi keyingi qoida ifodasida ishlatilishi mumkin. Evaluation timestamp Prometheus rejalashtirgan vaqtga tegishli bo‘lib, xom samplelarning aynan kelish vaqtiga teng bo‘lishi shart emas.
groups:
- name: api-rates
interval: 30s
rules:
- record: job:http_requests:rate5m
expr: sum by (job) (rate(http_requests_total[5m]))
Bu qoida har job uchun besh daqiqalik request tezligini saqlaydi. Yangi nom hisobning mazmuni va aggregation labelini tushunarli ifodalaydi.
Nomlash va label semantikasi
Prometheus amaliyotida recording rule nomi level:metric:operations shakliga yaqin yozilishi mumkin. Bu majburiy sintaksis emas, balki natijaning qaysi aggregation darajasi va amal bilan olinganini ko‘rsatadigan konvensiya. Noto‘g‘ri nom dashboard muallifini aggregatni xom counter deb talqin qilishga olib keladi.
sum by amali faqat ko‘rsatilgan labelarni qoldiradi. Kerakli region yoki status labeli yo‘qotilsa, keyinchalik natijani o‘sha o‘lcham bo‘yicha ajratib bo‘lmaydi. Aksincha, pod yoki instance kabi tez o‘zgaruvchi labelni saqlash recording rule foydasini kamaytiradi va cardinalityni yuqori qoldiradi.
Samaradorlik
Recording rule hisoblash xarajatini evaluation vaqtiga ko‘chiradi. Ko‘p dashboard bir xil murakkab querydan foydalansa bu sezilarli tejash beradi. Ammo har yozilgan natija yangi series va storage xarajatidir. Faqat kam ishlatiladigan so‘rovni oldindan saqlash umumiy resursni oshirishi mumkin.
Evaluation muddati group intervaldan uzun bo‘lsa keyingi sikllar kechikadi. Prometheus rule evaluation duration va missed iteration metriclarini o‘zi chiqaradi. Katta range vector, keng regex va yuqori cardinality aggregationlari profiling qilinadi.
To‘g‘rilik va o‘zgarishlar
Counterdan rate yoki increase olish aggregationdan oldin bajariladi, aks holda turli instance resetlari noto‘g‘ri hisoblanishi mumkin. Histogram bucketlari le labelini saqlagan holda yig‘iladi. Average ko‘pincha alohida sum va count agregatlaridan keyin bo‘lish orqali olinadi; instancelar average qiymatini oddiy o‘rtachalash og‘irlikni yo‘qotadi.
Qoida ifodasi o‘zgarsa eski va yangi ma’nodagi samplelar bir metric nomida davom etishi xavfli. Semantika sezilarli o‘zgarganda yangi nom ishlatiladi yoki tarixiy chegarasi qayd etiladi. Rule fayli syntax check, unit test va staging ma’lumoti bilan tekshiriladi.
Oraliq va staleness
Rule intervali xom scrape intervalidan juda qisqa bo‘lsa yangi sample kelmasdan bir necha marta bir xil holat baholanadi. Juda uzun interval qisqa sakrashlarni yo‘qotadi va dashboard resolutionini pasaytiradi. Range vector oynasi vaqtinchalik scrape yo‘qolishiga yetarli bo‘lishi kerak. Input series stale bo‘lsa natija ham kutilmagan bo‘shliq beradi; uni avtomatik nol bilan to‘ldirish servis yo‘qligini haqiqiy nol trafikdan ajratmaydi.
Rule deploymentida Prometheus configuration reload muvaffaqiyati va group health tekshiriladi. Ikki server bir xil recording rule natijasini remote storagega yozsa external label collision yuz berishi mumkin; replica labeli va deduplication siyosati aniq bo‘ladi.
Bog‘liq tushunchalar
Prometheus, PromQL, Rule group, Time series, Aggregation, Cardinality, Alerting rule