Roman Xavronenkonun "ExtendedPromQL" hesabatının stenoqramını oxumağı təklif edirəm.
Qısaca mənim haqqımda. Mənim adım Romandır. Mən CloudFlare üçün işləyirəm və Londonda yaşayıram. Amma mən həm də VictoriaMetrics xidmətçisiyəm.
Və müəllif mənəm Grafana üçün və ClickHouse üçün kiçik bir proxydir.
Biz “Tərcümə Çətinlikləri” adlanan birinci hissədən başlayacağıq və orada hər hansı bir dilin və hətta sadəcə ünsiyyət dilinin çox vacib olmasından danışacağam. Çünki fikirlərinizi başqa bir şəxsə və ya sistemə belə çatdırırsınız, sorğunu necə formalaşdırırsınız. İnternetdə insanlar hansı dilin daha yaxşı olması barədə mübahisə edirlər - java və ya başqa. Özüm üçün bir vəzifə seçmək lazım olduğuna qərar verdim, çünki bütün bunlar konkretdir.
Ən başdan başlayaq. PromQL nədir? PromQL Prometheus Sorğu Dilidir. Zaman seriyası məlumatlarını, zaman seriyalarını əldə etmək üçün Prometeydə sorğuları belə formalaşdırırıq.
Zaman seriyası məlumatları nədir? Sözün əsl mənasında bunlar üç parametrdir.
Bunlar:
- Nəyə baxırıq.
- Biz baxanda.
- Və hansı dəyəri göstərir.
Əgər siz bu cədvələ baxsanız (bu diaqram mənim telefonumdandır, addımlarımın statistikasını göstərir), onda siz burada bu suallara tez cavab verə bilərsiniz.
Biz addımlara baxırıq. Mənasını görürük və ona baxanda vaxtı görürük. Yəni bu diaqrama baxanda rahatlıqla deyə bilərsiniz ki, bazar günü təxminən 15 min addım getmişəm. Bu zaman seriyası məlumatlarıdır.
İndi onları cədvəl şəklində başqa bir məlumat modelinə "sındıraq" (çevirək). Baxdığımız şey burada da var. Burada meta-data adlandıracağımız bir az əlavə məlumat əlavə etdim, yəni keçən mən yox, iki nəfər, məsələn, Cey və Silent Bob. Baxdığımız budur; nəyi göstərir və bu dəyəri nə vaxt göstərir.
İndi gəlin bütün bu məlumatları verilənlər bazasında saxlamağa çalışaq. Məsələn, mən ClickHouse sintaksisini götürdüm. Və burada biz "Addımlar" adlı bir cədvəl yaradırıq, yəni nəyə baxırıq. Burada bir zaman var ki, ona baxırıq; onun kim olduğunu harada saxlayacağımız və bəzi meta-məlumatlar: Jay və Silent Bob.
Bütün bunları vizuallaşdırmağa çalışmaq üçün Grafana-dan istifadə edəcəyik, çünki birincisi, o, gözəldir.
Biz də bu plaqindən istifadə edəcəyik. Bunun iki səbəbi var. Birincisi, mən yazdığım üçün. Mən Grafana-da göstərmək üçün ClickHouse-dan zaman seriyası məlumatlarını çıxarmağın nə qədər çətin olduğunu dəqiq bilirəm.
Qrafik Paneldə göstərəcəyik. Bu, Grafana-da ən populyar paneldir və zamana qarşı dəyəri göstərir, ona görə də bizə yalnız iki parametr lazımdır.
Ən sadə sorğunu yazaq - Grafana-da addım statistikasını necə göstərmək, bu məlumatları ClickHouse-da, yaratdığımız cədvəldə saxlamaq. Və belə bir sadə sorğu yazırıq. Biz addımlardan seçirik. Biz bir dəyər seçirik və bu dəyərlərin vaxtını, yəni danışdığımız eyni üç parametri seçirik.
Və nəticədə bu qrafiki alırıq. Kim bilir niyə belə qəribədir?
Düzdü, zamana görə sıralamaq lazımdır.
Və sonda daha yaxşı, lakin yenə də qəribə bir cədvəl əldə edirik. Kim bilir niyə? Düzdür, iki iştirakçı var və biz Grafana-da iki zaman seriyasını təqdim edirik, çünki biz yenidən məlumat modeli ilə məşğul olsaq, onda hər bir zaman seriyası adın və bütün etiketlərin açar-dəyərlərinin unikal birləşməsidir.
Buna görə də biz konkret bir insan seçməliyik. Biz Jay seçirik.
Və yenidən çəkin. İndi qrafik həqiqət kimi görünür. İndi normal qrafikdir və hər şey qaydasındadır.
Və yəqin ki, eyni şeyi necə edəcəyinizi bilirsiniz, lakin PromQL vasitəsilə Prometeydə. Təxminən belə. Bir az daha asan. Və gəlin hamısını parçalayaq. Biz addımlar atdıq. Və Jay tərəfindən filtr. Biz burada qiymət almağımız lazım olduğunu qeyd etmirik və vaxt seçmirik.
İndi gəlin Jay və ya Silent Bob-un hərəkət sürətini hesablamağa çalışaq. ClickHouse-da biz runDifference etməli olacağıq, yəni dəqiq sürəti əldə etmək üçün xal cütləri arasındakı fərqi hesablamaq və onları vaxta bölmək lazımdır. Sorğu bu kimi görünəcək.
Və o, təxminən bu dəyərləri göstərəcək, yəni saniyədə təxminən 1,8 addım Silent Bob və ya Jay edir.
Prometeydə də bunu necə edəcəyinizi bilirsiniz. Əvvəlkindən daha asan.
Və Grafana-da bunu asanlaşdırmaq üçün PromQL-ə çox bənzəyən belə bir sarğı əlavə etdim. Bu, Rate Makrosları adlanır və ya onu nə adlandırmaq istəsəniz. Grafana-da siz sadəcə olaraq “dərəcə” yazırsınız, amma dərin bir yerdə o, belə böyük bir istəyə çevrilir. Həm də ona baxmağa belə ehtiyac yoxdur, hardasa var, amma çox vaxta qənaət edirsiniz, çünki belə nəhəng SQL sorğularının yazılması həmişə baha başa gəlir. Siz asanlıqla səhv edə bilərsiniz və sonra uzun müddət nə baş verdiyini başa düşə bilməzsiniz.
Və bu bir slayda belə sığmayan sorğudur və hətta onu iki sütuna bölməli oldum. Bu həm də ClickHouse-da tələbdir, hansı ki, eyni dərəcəsi verir, lakin hər iki vaxt seriyası üçün: Silent Bob və Jay, beləliklə paneldə iki zaman seriyası var. Və bu, mənim fikrimcə, artıq çox çətindir.
Prometeyə görə isə cəmi (dərəcə) olacaqdır. ClickHouse üçün Prometheus sorğusuna bənzəyən RateColumns adlı ayrıca bir makro hazırladım.
Biz baxdıq və görünür ki, PromQL çox gözəldir, lakin əlbəttə ki, məhdudiyyətləri var.
Bunlar:
- Məhdud SEÇİM.
- Edge JOINs.
- DƏSTƏK YOX.
Əgər onunla uzun müddət işləmisinizsə, o zaman bilirsiniz ki, bəzən PromQL-də nəsə etmək çox çətindir və SQL-də demək olar ki, hər şeyi edə bilərsiniz, çünki bayaq haqqında danışdığımız bütün bu variantları SQL-də etmək olar. . Bəs ondan istifadə etmək rahat olardımı? Və bu məni düşündürür ki, heç də həmişə ən güclü dil ən rahat ola bilməz.
Buna görə bəzən tapşırıqlar üçün bir dil seçmək lazımdır. Bu, Betmen və Supermen arasında döyüş kimidir. Supermenin daha güclü olduğu aydındır, lakin Batman onu məğlub edə bildi, çünki o, daha praktikdir və nə etdiyini dəqiq bilirdi.
Və növbəti hissə PromQL-in genişləndirilməsidir.
Bir daha VictoriaMetrics haqqında. VictoriaMetrics nədir? Bu, vaxt seriyası verilənlər bazasıdır, OpenSource-dadır, biz onun tək və klaster versiyalarını yayırıq. Testlərimizə görə, bu, hazırda bazarda olan ən sürətlidir və sıxılma baxımından oxşardır, yəni canlı insanlar Prometeydə 0,4-1,2 olan bir nöqtədə təxminən 1,4 bayt sıxılma haqqında məlumat verirlər.
Biz təkcə Prometeyi dəstəkləmirik. Biz InfluxDB, Graphite, OpenTSDB-ni dəstəkləyirik.
Bizdə "yazmaq" olar, yəni köhnə məlumatları ötürə bilərsiniz.
Həm də biz Prometheus və Grafana ilə mükəmməl işləyirik, yəni PromQL mühərrikini dəstəkləyirik. Və Grafana-da siz sadəcə olaraq Prometheus son nöqtəsini VictoriaMetrics-ə dəyişə bilərsiniz və bütün idarə panelləriniz olduğu kimi işləyəcək.
Lakin siz VictoriaMetrics tərəfindən təmin edilən əlavə çiplərdən də istifadə edə bilərsiniz.
Tezliklə əlavə etdiyimiz funksiyaları nəzərdən keçirəcəyik.
Interval parametrini buraxın - Grafana-da parametr intervalını atlaya bilərsiniz. Paneldə böyüdərkən/kiçildərkən qəribə qrafiklər əldə etmək istəmədikdə, dəyişəndən istifadə etmək tövsiyə olunur. $__interval. Bu daxili Grafana dəyişikliyidir və məlumat diapazonunu özü seçir. VictoriaMetrics özü bu diapazonun nə olduğunu başa düşə bilər. Və bütün sorğularınızı yeniləməli deyilsiniz. Bu, çox asan olacaq.
İkinci funksiya interval istinad edir. Bu boşluqdan ifadələrinizdə istifadə edə bilərsiniz. Çoxalda, bölmək, köçürmək, istinad etmək olar.
Sonrakı toplama funksiyası ailəsidir. Toplama funksiyası hər hansı bir zaman seriyanızı üç ayrı zaman seriyasına çevirir. Bunlar min, maksimum və ortadır. Mən bunu çox rahat hesab edirəm, çünki bəzən bəzi kənar göstəricilər (anomaliyalar) və qeyri-dəqiqliklər göstərə bilir.
Əgər siz sadəcə olaraq hirslənirsinizsə və ya qiymətləndirirsinizsə, o zaman zaman seriyasının nəzərdə tutduğunuz kimi davranmadığı bəzi halları qaçıra bilərsiniz. Bu funksiya ilə bunu görmək daha asandır, deyək ki, max orta hesabla çox aşağıdır.
Sonrakı standart dəyişəndir. Defolt - bu o deməkdir ki, hazırda zaman seriyamız yoxdursa, Grafana-da hansı dəyəri çəkməliyik. Nə vaxt olur? Tutaq ki, siz bəzi xəta göstəricilərini ixrac edirsiniz. Və o qədər gözəl bir tətbiqiniz var ki, işə başlayanda növbəti üç saat və ya hətta bir gün ərzində heç bir səhviniz və hətta səhviniz yoxdur. Uğurdan səhvə qədər əlaqələri göstərən tablolarınız var. Səhv göstəriciniz olmadığı üçün sizə heç nə göstərməyəcəklər. Və standart olaraq hər hansı bir şeyi təyin edə bilərsiniz.
Keep_last_Value - metrikanın son dəyəri yoxdursa, onu saxlayır. Növbəti kazımadan sonra Prometey onu 5 dəqiqə ərzində tapmasa, burada onun son dəyərini xatırlayacağıq və qrafikləriniz bir daha pozulmayacaq.
Scrape_interval - Prometheus'un sizin metrikanız haqqında məlumatı nə qədər tez-tez, hansı tezlikdə topladığını göstərir. Burada, məsələn, keçidi görə bilərsiniz.
Etiketin dəyişdirilməsi məşhur xüsusiyyətdir. Amma biz bunun bir qədər mürəkkəb olduğunu düşünürük, çünki bu, tam arqumentlər tələb edir. Və yalnız 5 arqumenti xatırlamaq deyil, həm də onların ardıcıllığını xatırlamaq lazımdır.
Buna görə niyə onları sadələşdirməyək? Yəni, onu aydın sintaksislə kiçik funksiyalara bölün.
Və indi ən maraqlısı. Niyə biz bunun genişləndirilmiş PromQL olduğunu düşünürük? Çünki biz Ümumi Cədvəl İfadələrini dəstəkləyirik. QR kodu izləyə bilərsiniz (), sadəcə brauzerdə quraşdırmadan sorğuları birbaşa VictoriaMetrics-də icra edə biləcəyiniz oyun meydançasından nümunələrlə bağlantılara baxın.
Və bu nədir? Yuxarıdan gələn bu sorğu kifayət qədər populyar sorğudur. Düşünürəm ki, bir çox şirkətdə hər hansı bir tablosunda hər şey üçün eyni filtrdən istifadə edirsiniz. Adətən belə. Ancaq bəzi yeni filtr əlavə etmək lazım olduqda, hər paneli yeniləməli və ya idarə panelini yükləməli, onu JSON-da açmalı, əvəzləmə tapmalısınız, bu da vaxt aparır. Niyə bu dəyəri dəyişəndə saxlayıb onu təkrar istifadə etməyək? Məncə, daha sadə və aydın görünür.
Məsələn, bütün sorğularda Grafana-da filtrləri yeniləməliyəm və tablosuna nəhəng ola bilər və ya hətta onlardan bir neçəsi ola bilər. Və mən Grafana-da bu problemi necə həll etmək istərdim?
Mən bu problemi belə həll edirəm: Mən ümumiFilter düzəldirəm və orada bu filtri müəyyənləşdirirəm və sonra onu sorğularda təkrar istifadə edirəm. Amma indi eyni şeyi etsəniz, bu işləməyəcək, çünki Grafana sizə sorğu dəyişənləri daxilində dəyişənlərdən istifadə etməyə icazə vermir. Və bir az qəribədir.
Və buna görə də bunu etməyə imkan verən bir seçim etdim. Və belə bir xüsusiyyətlə maraqlanırsınızsa və ya istəyirsinizsə, o zaman bu fikri bəyənmirsinizsə, dəstəkləyin və ya bəyənmədiniz.
Genişləndirilmiş PromQL haqqında ətraflı. Burada biz təkcə dəyişəni deyil, birbaşa bütöv bir funksiyanı təyin edirik. Biz isə buna ru (resurs istifadəsi) deyirik. Və bu funksiya pulsuz resursları, resurs limitini və filtri qəbul edir. Sintaksis sadə görünür. Və bu funksiyadan istifadə etmək və əlimizdə olan boş yaddaşın faizini hesablamaq çox asandır. Yəni nə qədər yaddaşımız var, hansı limit və necə süzülür. Hamısını eyni filtrlərdən təkrar istifadə edərək yazsanız, daha yaxşı görünür, çünki bu, böyük, böyük sorğuya çevriləcək.
Və belə bir böyük, böyük xahişin bir nümunəsidir. Bu Grafana üçün rəsmi NodeExporter idarə panelindəndir. Ancaq burada nə baş verdiyini həqiqətən başa düşə bilmirəm. Bu, əlbəttə ki, diqqətlə baxsanız başa düşürəm, amma mötərizənin sayı burada baş verənləri anlamaq üçün motivasiyanı dərhal azalda bilər. Və niyə bunu daha sadə və aydın etməyək?
Məsələn, dəyişənlərdə əhəmiyyətli şeyləri və ya hissələri vurğulamaq kimi. Və sonra əsas riyaziyyatınızı edin. Bu, artıq proqramlaşdırmaya daha çox bənzəyir, mənim gələcəkdə Grafana-da görmək istədiyim budur.
Əgər bizdə bu ru funksiyası varsa və o, birbaşa VictoriaMetrics-də mövcuddursa, bunu necə daha da asanlaşdıra biləcəyimizə dair ikinci bir nümunə. Və sonra siz sadəcə CTE-də elan etdiyiniz keşlənmiş dəyəri keçirsiniz.
Düzgün proqramlaşdırma dilindən istifadə etməyin nə qədər vacib olduğundan artıq danışdım. Və yəqin ki, hər şirkətdə Grafana-da fərqli bir şey baş verir. Və yəqin ki, siz hələ də tərtibatçılarınıza Grafana-ya giriş verirsiniz və tərtibatçılar özlərinə məxsus bir şey edirlər. Və hamısı bunu fərqli şəkildə edirlər. Amma birtəhər eyni olmasını, yəni ümumi standarta endirilməsini istədim.
Tutaq ki, sizdə təkcə sistem mühəndisləri yoxdur, bəlkə də ekspertlər, devoplar və ya SRE-lər var. Ola bilsin ki, monitorinqin nə olduğunu bilən, Grafana-nın nə olduğunu bilən mütəxəssisləriniz var, yəni onlar illərdir bununla işləyirlər və bunu necə düzgün edəcəyini dəqiq bilirlər. Və artıq 100 dəfə yazıb hamıya başa salıblar, amma nədənsə heç kim qulaq asmır.
Bəs onlar bu biliyi birbaşa Grafana-ya yerləşdirə bilsələr ki, digər istifadəçilər funksiyaları təkrar istifadə edə bilsinlər? Əgər boş yaddaşın faizini hesablamaq lazım gəlsəydi, o zaman sadəcə funksiyanı tətbiq edərdilər. Bəs ixracatçıların yaradıcıları öz məhsulu ilə yanaşı, həm də bir sıra funksiyalar təqdim etsələr, onların ölçüləri ilə necə işləmək lazımdır, çünki onlar bu göstəricilərin nə olduğunu və onları necə düzgün hesablamağı dəqiq bilirlərsə?
Bu həqiqətən mövcud deyil. Budur, mən özüm etdim. Bu Grafanadakı kitabxana dəstəyidir. Tutaq ki, NodeExporter-i yaradan uşaqlar mənim təsvir etdiyim şeyi etdilər. Həm də bir sıra xüsusiyyətlər təqdim etdi.
Yəni belə bir şey görünür. Siz bu kitabxananı Grafana ilə əlaqələndirirsiniz, redaktəyə gedirsiniz və burada JSON-da bu metrik ilə necə işləmək çox sadədir. Yəni bəzi funksiyalar toplusu, onların təsviri və nəyə çevrildikləri.
Fikrimcə, bu faydalı ola bilər, çünki o zaman Grafana-da belə yazardınız. Qrafana isə sizə “deyir” ki, filan kitabxanadan filan funksiya var – gəlin ondan istifadə edək. Məncə, bu, çox gözəl olardı.
VictoriaMetrics haqqında bir az. Çox maraqlı işlər görürük. Sıxılma haqqında, digər zaman seriyası məlumat tətbiqləri ilə rəqabətimiz haqqında, PromQL ilə necə işləmək barədə izahatımız haqqında məqalələrimizi oxuyun, çünki burada daha çox yeni başlayanlar var, həmçinin şaquli miqyaslanma və Thanos ilə qarşıdurma haqqında.
Suallar:
Sualıma sadə bir həyat hekayəsi ilə başlayacağam. Grafana-dan ilk dəfə istifadə etməyə başlayanda çox inandırıcı 5 sətirlik sorğu yazdım. Son nəticə çox inandırıcı bir qrafikdir. Bu qrafik demək olar ki, istehsala keçib. Ancaq daha yaxından yoxlandıqdan sonra məlum oldu ki, bu diaqram reallıqla heç bir əlaqəsi olmayan tamamilə cəfəngiyat göstərir, baxmayaraq ki, rəqəmlər gözlədiyimiz diapazona düşür. Və mənim sualım. Kitabxanalarımız var, funksiyalarımız var, bəs biz Grafana üçün testləri necə yazırıq? Siz biznes qərarına təsir edən mürəkkəb sorğu yazdınız - real server konteynerini sifariş etmək və ya sifariş etməmək. Və bildiyimiz kimi, qrafiki çəkən bu funksiya həqiqətə bənzəyir. Çox sağ ol.
Sual üçün təşəkkür edirik. Burada iki hissə var. Birincisi, mən öz təcrübəmə əsaslanaraq belə bir təəssürat alıram ki, əksər istifadəçilər öz qrafiklərinə baxanda onlara nə göstərdiklərini başa düşmürlər. İnsanlar qrafiklərdə baş verən hər hansı bir anomaliya üçün bir bəhanə tapmağı çox yaxşı bacarırlar, hətta bu, funksiya daxilində səhv olsa belə. İkinci hissə - mənə elə gəlir ki, sizin hər bir tərtibatçınız öz imkanlarını planlaşdırmaq və müəyyən ehtimalla səhv etmək əvəzinə, bu cür funksiyalardan istifadə edərək probleminizi həll etmək daha uyğun olardı.
Nasıl kontrol etməliyəm?
Necə yoxlamaq olar? Yəqin ki, yox.
Grafana'da bir sınaq olaraq.
Bəs Grafana? Grafana bu sorğunu birbaşa DataSource-a tərcümə edir.
Parametrlərə bir az əlavə etməklə.
Xeyr, Grafanaya heç nə əlavə olunmur. GET parametrləri ola bilər, məsələn, addım. Bu, açıq şəkildə göstərilməyib, ancaq onu ləğv edə bilərsiniz, onu ləğv edə bilməzsiniz, lakin avtomatik olaraq əlavə olunur. Siz burada test yazmırsınız. Düşünürəm ki, burada həqiqət mənbəyi kimi Qrafanaya etibar etməməlisiniz.
Hesabat üçün təşəkkür edirik! Sıxılma üçün təşəkkür edirik! Siz qrafikdə dəyişənin xəritələşdirilməsini xatırladınız ki, Grafana-da dəyişəndə dəyişəndən istifadə edə bilməzsiniz. Nə demək istədiyimi başa düşürsən?
Bəli.
Grafana'da xəbərdarlıq etmək istəyəndə bu, əvvəlcə baş ağrısı idi. Və orada hər bir ev sahibi üçün ayrıca xəbərdarlıq etməlisiniz. Budur, etdiyiniz şey, Grafana'da xəbərdarlıqlar üçün işləyirmi?
Əgər Grafana dəyişənlərə başqa yolla daxil deyilsə, bəli, işləyəcək. Amma mənim məsləhətim odur ki, Grafana-da heç bir xəbərdarlıqdan istifadə etməyin, alertmanager-dən istifadə etsəniz daha yaxşı olar.
Bəli, mən istifadə edirəm, amma Grafana-da qurmaq daha asan görünürdü, amma məsləhət üçün təşəkkürlər!
Mənbə: www.habr.com