Vă propun să citiți transcrierea prezentării lui Roman Khavronenko "ExtendedPromQL"
Pe scurt despre mine. Mă numesc Roman. Lucrez la CloudFlare și locuiesc în Londra. Dar de asemenea, sunt întreținător pentru VictoriaMetrics.
Și sunt autorul pentru Grafana și – este un mic proxy pentru ClickHouse.
Vom începe cu prima parte, care se numește „Dificultăți de traducere” și în care voi vorbi despre faptul că orice limbă sau chiar simpla comunicare este foarte importantă. Pentru că aceasta este modalitatea prin care transmiți cuiva sau unui sistem gândurile tale, cum formulezi o întrebare. Oamenii pe internet dezbat despre care limbă este mai bună – Java sau alta. Eu am decis că trebuie să alegi în funcție de sarcină, pentru că totul este specific.
Să începem de la început. Ce este PromQL? PromQL este Limbajul de Interogare Prometheus. Asta este cum formăm interogări în Prometheus pentru a obține date time series.
Ce sunt datele time series? Dacă ar fi să le explicăm literal, acestea sunt trei parametrii.
Acestea sunt:
- La ce ne uităm.
- Când ne uităm la asta.
- Și ce valoare arată.
Dacă ne uităm la acest grafic (acest grafic de pe telefonul meu, care arată statisticile pașilor mei), atunci aici putem răspunde rapid la aceste întrebări.
Ne uităm la pași. Vedem valoarea și vedem timpul când ne uităm la asta. Adică, privind acest grafic, este ușor de spus că duminica am făcut aproximativ 15.000 de pași. Acestea sunt date time series.
Acum haideți să "transformăm" (sau să convertim) aceste date într-un alt model de date sub formă de tabel. Aici avem, de asemenea, ceea ce observăm. Am adăugat câteva date suplimentare, pe care le vom numi metadate, adică, nu am fost eu, ci două persoane, să zicem, Jay și Silent Bob. Asta este ceea ce ne uităm; ce arată și când arată această valoare.
Acum să încercăm să păstrăm toate aceste date într-o bază de date. Ca exemplu, am luat sintaxa ClickHouse. Și aici creăm un tabel, care se numește „Steps”, adică, la ce ne uităm. Aici este timpul când ne uităm la asta; ce arată și unele metadate, unde vom păstra cine sunt: Jay și Silent Bob.
Și pentru a încerca să vizualizăm totul, vom folosi Grafana, pentru că, în primul rând, este frumos.
De asemenea, vom folosi acest plugin. Există două motive pentru aceasta. Primul – pentru că eu l-am scris. Și știu exact cât de greu este să extragi datele de tip time series din ClickHouse pentru a le afișa în Grafana.
Vom afișa în Graph Panel. Aceasta este cea mai populară panou în Grafana, care arată dependența valorii de timp, așa că avem nevoie doar de două parametre.
Haideți să scriem cea mai simplă interogare – cum să arătăm statisticile pașilor în Grafana, stocând aceste date în ClickHouse, în acea tabelă pe care am creat-o. Și scriem această interogare simplă. Selectăm din pași. Selectăm valoarea și selectăm timpul acestor valori, adică aceleași trei parametre despre care am vorbit.
Și în rezultat vom obține un astfel de grafic. Cine știe de ce arată atât de ciudat?
Corect, trebuie să sortăm după timp.
Și în cele din urmă vom obține un grafic mai bun, dar tot ciudat. Cine știe de ce? Corect, sunt doi participanți și în Grafana oferim două time series, pentru că dacă ne uităm la modelul de date încă o dată, fiecare time series este o combinație unică a numelui și a tuturor cheilor valorilor etichetelor.
De aceea, trebuie să alegem o persoană anume. O alegem pe Jay.
Și desenăm din nou. Acum graficul arată adevărul. Acum este un grafic normal și totul funcționează bine.
Și, probabil, știți cum să faceți cam același lucru, dar în Prometheus prin PromQL. Aproape așa. Un pic mai ușor. Și să descompunem totul. Am analizat pașii. Și filtrăm după Jay. Aici nu specificăm ce valoare trebuie să obținem și nu selectăm timpul.
Acum să încercăm să calculăm viteza de deplasare a lui Jay sau Silent Bob. În ClickHouse va trebui să facem runningDifference, adică să calculăm diferența dintre perechi de puncte și să le împărțim la timp pentru a obține viteza exactă. Interogarea va arăta aproximativ așa.
Și va arăta aprox. aceste valori, adică Silent Bob sau Jay fac aproximativ 1,8 pași pe secundă.
Și în Prometheus știți cum se face și asta. Mult mai simplu decât a fost anterior.
Și pentru a rămâne la fel de ușor de utilizat în Grafana, am adăugat un wrapper care arată foarte asemănător cu PromQL. Aceasta se numește Rate Macros sau cum doriți să o numiți. În Grafana, pur și simplu scrieți „rate”, însă undeva în adâncime, aceasta se transformă într-o interogare mare. Și nu trebuie să vă uitați niciodată la ea, este acolo, dar economisiți o mulțime de timp, deoarece scrierea unor interogări SQL atât de mari este întotdeauna costisitoare. Puteți greși cu ușurință și apoi să nu înțelegeți timp îndelungat ce se întâmplă.
Iată o interogare care nu a încăput nici pe un singur diapozitiv, și a trebuit să o împart în două coloane. Aceasta este, de asemenea, o interogare în ClickHouse, care face același lucru de rate, dar pentru ambele time series: atât pentru Silent Bob, cât și pentru Jay, astfel încât să avem două time series pe panou. Și acesta este deja foarte complicat, în opinia mea.
În Prometheus va fi sum (rate). Pentru ClickHouse, am făcut un macro separat, numit RateColumns, care arată ca o interogare în Prometheus.
Ne-am uitat și, după cum pare, PromQL este foarte fain, dar are, desigur, anumite limitări.
Acestea sunt:
- SELECT limitat.
- JOIN-uri limitate.
- Fără suport pentru HAVING.
Și dacă ați lucrat mult cu el, știți că uneori este foarte greu să faceți ceva în PromQL, în timp ce în SQL puteți face practic totul, pentru că toate aceste opțiuni despre care am discutat acum ar fi putut fi realizate în SQL. Dar ar fi fost convenabil să folosiți acest lucru? Și aceasta mă duce la gândul că nu întotdeauna cel mai puternic limbaj poate fi cel mai convenabil.
Prin urmare, uneori trebuie să alegi limbajul în funcție de sarcină. Este ca o bătălie între Batman și Superman. Este clar că Superman este mai puternic, dar Batman a reușit să-l înfrunte pentru că este mai practic și știa exact ce face.
Și partea următoare este – Extinderea PromQL.
Încă o dată despre VictoriaMetrics. Ce este VictoriaMetrics? Este o bază de date time series, este în OpenSource, distribuită în versiunile single și cluster. Conform benchmark-urilor noastre, este cea mai rapidă de pe piață în prezent, iar în ceea ce privește compresia, de asemenea, adică, persoanele reale raportează o compresie de aproximativ 0,4 byte pe punct, când la Prometheus este între 1,2-1,4.
Susținem nu doar Prometheus. Susținem InfluxDB, Graphite, OpenTSDB.
Putem "scrie", adică putem transfera date vechi.
Și, de asemenea, funcționăm perfect cu Prometheus și Grafana, adică, susținem motorul PromQL. Și în Grafana, puteți pur și simplu să schimbați endpoint-ul Prometheus cu VictoriaMetrics și toate dashboard-urile voastre vor funcționa la fel ca înainte.
Dar puteți utiliza și caracteristici suplimentare oferite de VictoriaMetrics.
Vom trece rapid prin funcțiile pe care le-am adăugat.
Omiterea parametrului interval – puteți omite parametrii interval în Grafana. Când nu doriți să obțineți grafice ciudate la zoom in/out în panou, se recomandă utilizarea variabilei {$__interval}. Aceasta este o variabilă internă Grafana și ea alege singură intervalul de date. Iar VictoriaMetrics poate înțelege singură ce ar trebui să fie acest interval. Și nu este nevoie să actualizați toate interogările. Va fi mult mai simplu.
A doua funcție – este referința intervalului. Puteți folosi acest interval în expresiile dumneavoastră. Puteți înmulți, împărți, transmite, face referire la el.
În continuare, familia funcțiilor rollup. Funcția rollup transformă orice serie temporală a dumneavoastră în trei serii temporale distincte. Acestea sunt min, max și avg. Consider că este foarte convenabil, deoarece uneori poate arăta anumite outliers (anomalii) și imprecizii.
Și dacă pur și simplu faceți irate sau rate, probabil că ați putea să omiteți unele cazuri când seria temporală se comportă diferit față de așteptările dumneavoastră. Cu această funcție, este mult mai simplu să observați, de exemplu, că max este mult mai mare decât avg.
Apoi, variabila default. Default – înseamnă ce valoare trebuie să desenăm în Grafana, dacă nu avem serie temporală în acel moment. Când se întâmplă asta? De exemplu, dacă exportați o metrică de erori. Și aveți o aplicație atât de grozavă încât când ați pornit atunci nu ați avut erori și nici nu ați avut erori în următoarele trei ore sau chiar zi. Și aveți dashboard-uri care arată raportul de succes față de erori. Ele vă vor arăta nimic, pentru că nu aveți metrica de erori. Iar în default puteți specifica orice.
Keep_last_Value – păstrează ultima valoare a metricii, dacă aceasta a dispărut. Dacă Prometheus, după următoarea extragere, nu a găsit-o timp de 5 minute, atunci aici vom reține ultima ei valoare și graficele dumneavoastră nu se vor strica din nou.
Scrape_interval – arată cât de des Prometheus adună date despre metrica dumneavoastră, cu ce frecvență. Aici puteți observa o omisiune, de exemplu.
Label replace – o funcție populară. Dar noi considerăm că este puțin complicată, deoarece ea acceptă un număr întreg de argumente. Și trebuie nu doar să țineți minte 5 argumente, ci și ordinea lor.
Așadar, de ce să nu le facem mai simple? Adică, să le împărțim în funcții mici cu o sintaxă clară.
Și acum vine partea interesantă. De ce considerăm că aceasta este extensia PromQL? Pentru că susținem expresiile de tip Common Table. Puteți să accesați QR-code-ul (), să vizualizați linkurile cu exemple, cu playground-ul, unde puteți executa interogări direct în VictoriaMetrics fără a fi necesară instalarea acesteia, doar în browser.
Și ce reprezintă aceasta? Această interogare de mai sus este o interogare destul de populară. Cred că, în orice dashboard în multe companii, folosiți același filtru pentru toate. De obicei, așa se întâmplă. Dar când trebuie să adăugați un filtru nou, trebuie fie să actualizați fiecare panou, fie să descărcați dashboard-ul, să-l deschideți în JSON, să faceți căutare și înlocuire, ceea ce durează, de asemenea, timp. De ce să nu păstrați această valoare într-o variabilă și să o reutilizați? Este, în opinia mea, mult mai simplu și mai clar.
De exemplu, când trebuie să actualizez filtrele în Grafana în toate interogările, iar dashboard-ul poate fi foarte mare sau chiar pot exista mai multe. Și cum aș dori să rezolv această problemă în Grafana?
Rezolv această problemă astfel: creez commonFilter și în el definesc acest filtru, apoi îl reutilizez în interogări. Dar dacă acum faceți la fel, nu va funcționa, pentru că Grafana nu vă permite să utilizați variabile în variabilele interogărilor. Și este puțin ciudat.
De aceea am creat o variantă care permite acest lucru. Și dacă sunteți interesați sau doriți această funcție, susțineți sau dați dislike, dacă nu vă place această idee.
Mai departe despre PromQL extins. Aici definim nu doar o variabilă, ci chiar o funcție întreagă. Și o numim ru (consumul de resurse). Această funcție primește resursele libere, limita pe resursă și filtrul. Se pare că sintaxa este destul de simplă. Și este foarte ușor să folosiți această funcție și să calculați procentul de memorie liberă pe care o avem. Adică, câtă memorie avem, care este limita și cum filtrăm. Arată mult mai convenabil, dacă ați scrie totul reutilizând aceleași filtre, pentru că s-ar transforma într-o interogare foarte mare.
Iată un exemplu al unei cereri foarte mari. Este din tabloul de bord oficial NodeExporter pentru Grafana. Dar eu înțeleg cam puțin despre ce se întâmplă aici. Adică, desigur, înțeleg dacă mă concentrez, dar numărul de paranteze poate imediat să reducă motivația de a înțelege ceea ce se întâmplă aici. Și de ce să nu-l facem mai simplu și mai clar?
De exemplu, așa, evidențiind lucrurile sau părțile semnificative în variabile. Și apoi efectuând matematica de bază. Asta deja seamănă mai mult cu programarea, este ceea ce mi-ar plăcea să văd în viitor în Grafana.
Iată un al doilea exemplu, cum putem face acest lucru și mai simplu, dacă am avea deja această funcție ru, iar aceasta există deja direct în VictoriaMetrics. Atunci, pur și simplu, transmiți valoarea cached pe care ai declarat-o în CTE.
Am mai spus cât de important este să folosești limbajul de programare potrivit. Și, probabil, în fiecare companie în Grafana se întâmplă ceva propriu. Și, probabil, oferiți acces la Grafana dezvoltatorilor voștri, iar dezvoltatorii fac ceva de-al lor. Și fiecare dintre ei o face diferit. Ar fi bine să arate oarecum uniform, adică să ajungem la un standard comun.
Să spunem că aveți chiar nu doar ingineri de sistem, poate aveți chiar experți, devops sau SRE. Poate aveți experți care știu ce este monitorizarea, știu ce este Grafana, adică au lucrat cu asta de ani de zile și știu exact cum să facă corect. Și au scris asta de 100 de ori și le-au explicat tuturor, dar dintr-un motiv anume nimeni nu îi ascultă.
Dar ce ar fi dacă ar putea să pună aceste cunoștințe direct în Grafana, astfel încât alți utilizatori să poată reutiliza funcțiile? Și dacă ar fi necesar să se calculeze procentul de memorie disponibilă, atunci pur și simplu ar aplica funcția. Dar ce-ar fi dacă creatorii exportatorilor, împreună cu produsul lor, ar oferi de asemenea un set de funcții despre cum să lucrezi cu metricile lor, pentru că știu exact ce metrici sunt și cum să le calculeze corect?
Acest lucru, de fapt, nu există. Asta am făcut eu. Aceasta este suportul pentru biblioteci în Grafana. Să spunem că băieții care au creat NodeExporter au realizat ceea ce am menționat. Și au oferit, de asemenea, un set de funcții.
Adică, arată cam așa. Conectați această bibliotecă în Grafana, intrați în modul de editare și aici este foarte simplu explicat în JSON cum să lucrați cu această metrică. Adică, o anumită set de funcții, descrierea lor și cum se desfășoară acestea.
Cred că ar fi foarte util, deoarece atunci în Grafana ați scrie pur și simplu așa. Și Grafana vă "spune" că există o anumită funcție din această bibliotecă – să o folosim. Mi se pare că ar fi grozav.
Câteva cuvinte despre VictoriaMetrics. Facem foarte multe lucruri interesante. Citește articolele noastre despre compresie, despre competițiile noastre cu alte aplicații de date din serii temporale, explicațiile noastre despre cum să lucrați cu PromQL, pentru că sunt încă mulți începători, dar și despre scalabilitate verticală și despre confruntarea cu Thanos.
Întrebări:
Voi începe întrebarea mea cu o poveste simplă din viață. Când am început prima dată să folosesc Grafana, am scris o interogare foarte convingătoare de 5 rânduri. În final, a rezultat un grafic foarte convingător. Acest grafic aproape că a fost lansat în producție. Dar, la o examinare mai atentă, s-a dovedit că acest grafic arată o aberație absolută, fără legătură cu realitatea, chiar dacă cifrele se încadrează în intervalul pe care ne așteptam să-l vedem. Și întrebarea mea este: avem biblioteci, avem funcții, dar cum scriem testele pentru Grafana? Ați scris o interogare complexă, de care depinde o decizie de afaceri – să comandăm un container real de servere sau nu. Și cum știm că funcția care desenează graficul seamănă cu adevărul. Mulțumesc.
Mulțumesc pentru întrebare. Aici sunt două părți. Prima – mi se pare, din experiența mea, că majoritatea utilizatorilor, atunci când se uită la graficele lor, nu înțeleg ce le arată acestea. Dintr-un motiv anume, oamenii sunt foarte buni la a găsi scuze pentru orice anomalii care apar pe grafice, chiar dacă este o eroare în cadrul funcției. Și a doua parte – cred că utilizarea unor astfel de funcții ar fi mult mai potrivită pentru rezolvarea problemei tale, în loc ca fiecare dintre dezvoltatorii tăi să facă planificarea capacității și să greșească cu o anumită probabilitate.
Cum verific?
Cum verific? Probabil, deloc.
Sub formă de test în Grafana.
Ce legătură are Grafana cu asta? Grafana transmite această interogare direct la DataSource.
Adăugând puțin în parametrii.
Nu, în Grafana nu se adaugă nimic. Acolo pot exista parametri GET, cum ar fi, de exemplu, step. Acesta nu este specificat explicit, dar îl puteți suprascrie sau nu, însă se adaugă automat. Aici nu puteți scrie teste. Cred că nu ar trebui să te bazezi pe Grafana ca sursă de adevăr.
Mulțumesc pentru prezentare! Mulțumesc pentru compresie! Ați menționat despre maparea variabilelor în grafic, că nu se poate folosi o variabilă într-o variabilă în Grafana. Înțelegeți despre ce vorbesc?
Da.
A fost la început o durere de cap când am vrut să fac un alert în Grafana. Acolo trebuie să setez alertă pentru fiecare gazdă în parte. Funcționează acel lucru pe care l-ați creat pentru alertele din Grafana?
Dacă Grafana nu accesează variabilele într-un mod diferit, atunci - da, va funcționa. Dar sfatul meu este să nu folosiți alerting în Grafana deloc, ar fi mai bine să folosiți alertmanager.
Da, îl folosesc, dar pur și simplu mi s-a părut mai ușor de configurat în Grafana, dar mulțumesc pentru sugestie!
Sursa: habr.com
