Propun să citesc transcrierea raportului lui Roman Khavronenko „ExtendedPromQL”
Pe scurt despre mine. Numele meu este Roman. Lucrez pentru CloudFlare și locuiesc la Londra. Dar sunt și menținător VictoriaMetrics.
Și eu 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 ea voi vorbi despre faptul că orice limbă sau chiar doar o limbă de comunicare este foarte importantă. Pentru că așa îți transmiți gândurile unei alte persoane sau unui sistem, cum formulezi o cerere. Oamenii de pe Internet se ceartă despre ce limbă este mai bună - java sau alta. Pentru mine, am decis că este necesar să aleg o sarcină, deoarece toate acestea sunt specifice.
Să începem de la bun început. Ce este PromQL? PromQL este limbajul de interogare Prometheus. Acesta este modul în care formăm interogări în Prometheus pentru a obține date de serie de timp, serii de timp.
Ce sunt datele din seria temporală? Literal, aceștia sunt trei parametri.
Acestea sunt:
- La ce ne uităm.
- Când ne uităm la el.
- Și ce valoare arată.
Dacă te uiți la această diagramă (aceasta diagramă este de pe telefonul meu, care arată statisticile pașilor mei), atunci aici poți răspunde rapid la aceste întrebări.
Ne uităm la pași. Vedem sensul și vedem timpul când îl privim. Adică, privind această diagramă, poți spune cu ușurință că duminică am făcut vreo 15 de pași. Acestea sunt date din seria temporală.
Acum să le „rupem” (transformăm) într-un alt model de date sub forma unui tabel. Aici avem și ceea ce ne uităm. Aici am adăugat câteva date suplimentare, pe care le vom numi meta-date, adică nu eu am trecut, ci doi oameni, de exemplu, Jay și Silent Bob. La asta ne uităm; ce arată și când arată acea valoare.
Acum să încercăm să stocăm toate aceste date în baza de date. De exemplu, am luat sintaxa ClickHouse. Și aici creăm un tabel numit „Pași”, adică ceea ce ne uităm. Există un timp când ne uităm la el; ce arată și câteva metadate unde vom stoca cine este: 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. Prima este pentru că am scris-o. Și știu exact cât de greu este să scoți date din seria temporală din ClickHouse pentru a le afișa în Grafana.
Vom afișa în panoul grafic. Acesta este cel mai popular panou din Grafana și arată valoarea în funcție de timp, așa că avem nevoie doar de doi parametri.
Să scriem cea mai simplă interogare - cum să afișați statisticile pașilor în Grafana, stocând aceste date în ClickHouse, în tabelul pe care l-am creat. Și scriem o interogare atât de simplă. Alegem dintre pași. Selectăm o valoare și selectăm timpul acestor valori, adică aceiași trei parametri despre care am vorbit.
Și, ca rezultat, obținem acest grafic. Cine știe de ce este atât de ciudat?
Așa este, trebuie să sortați după timp.
Și până la urmă obținem un program mai bun, dar totuși ciudat. Cine știe de ce? Așa este, există doi participanți și oferim două serii cronologice în Grafana, pentru că dacă ne ocupăm din nou de modelul de date, atunci fiecare serie temporală este o combinație unică a unui nume și a tuturor etichetelor cheie-valoare.
Prin urmare, trebuie să alegem o anumită persoană. Îl alegem pe Jay.
Și desenați din nou. Acum graficul arată ca adevărul. Acum este un program normal și totul merge bine.
Și, probabil, știți cum să faceți același lucru, dar în Prometheus prin PromQL. Cam așa. Puțin mai ușor. Și haideți să descompunem totul. Am făcut Pași. Și filtrează după Jay. Nu precizăm aici că trebuie să obținem o valoare și nu alegem un moment.
Acum să încercăm să calculăm viteza de mișcare a lui Jay sau Silent Bob. În ClickHouse, va trebui să facem runningDifference, adică să calculăm diferența dintre perechile de puncte și să le împărțim în timp pentru a obține viteza exactă. Cererea va arăta cam așa.
Și el va afișa aproximativ aceste valori, adică aproximativ 1,8 pași pe secundă face Silent Bob sau Jay.
Și în Prometheus știi să faci și tu. Mult mai ușor decât înainte.
Și pentru a face și ușor de făcut în Grafana, am adăugat un astfel de înveliș care arată foarte asemănător cu PromQL. Se numește Rate Macros, sau cum vrei să-i spui. În Grafana, scrii doar „rata”, dar undeva în adâncime se transformă într-o cerere atât de mare. Și nici nu trebuie să te uiți la el, este acolo undeva, dar economisești mult timp, pentru că scrierea unor astfel de interogări SQL uriașe este întotdeauna costisitoare. Poți face cu ușurință o greșeală și apoi să nu înțelegi ce se întâmplă mult timp.
Și aceasta este o interogare care nici măcar nu se potrivea pe un diapozitiv și chiar a trebuit să o împart în două coloane. Aceasta este și o solicitare în ClickHouse, care face același tarif, dar pentru ambele serii cronologice: Silent Bob și Jay, astfel încât să avem două serii cronologice pe panou. Și acest lucru este deja foarte dificil, după părerea mea.
Și conform lui Prometeu va fi sumă (rata). Pentru ClickHouse am creat o macrocomandă separată numită RateColumns, care arată ca o interogare Prometheus.
Ne-am uitat și se pare că PromQL este atât de cool, dar are, desigur, limitări.
Acestea sunt:
- SELECTARE limitată.
- Edge JOINs.
- FĂRĂ suport.
Și dacă ai lucrat cu el de mult timp, atunci știi că uneori este foarte greu să faci ceva în PromQL, iar în SQL poți face aproape orice, pentru că toate aceste opțiuni despre care tocmai am vorbit ar putea fi făcute în SQL . Dar ar fi convenabil să-l folosești? Și asta mă face să cred că nu întotdeauna limba cea mai puternică poate fi cea mai convenabilă.
Prin urmare, uneori trebuie să alegeți o limbă pentru sarcini. Este ca o bătălie între Batman și Superman. Este clar că Superman este mai puternic, dar Batman a reușit să-l învingă pentru că este mai practic și știa exact ce face.
Și următoarea parte este Extinderea PromQL.
Încă o dată despre VictoriaMetrics. Ce este VictoriaMetrics? Aceasta este o bază de date în serie de timp, este în OpenSource, distribuim versiunile sale single și cluster. Conform benchmark-urilor noastre, este cel mai rapid care se află acum pe piață și este similar în ceea ce privește compresia, adică oamenii vii raportează o compresie de aproximativ 0,4 octeți pe punct, când Prometheus are 1,2-1,4.
Îl sprijinim nu numai pe Prometeu. Suportăm InfluxDB, Graphite, OpenTSDB.
Puteți „scrie” în noi, adică puteți transfera date vechi.
Și, de asemenea, lucrăm perfect cu Prometheus și Grafana, adică acceptăm motorul PromQL. Și în Grafana, puteți schimba pur și simplu punctul final Prometheus în VictoriaMetrics și toate tablourile de bord vor funcționa așa cum au făcut.
Dar puteți folosi și cipuri suplimentare furnizate de VictoriaMetrics.
Vom parcurge rapid funcțiile pe care le-am adăugat.
Omiteți parametrul de interval - puteți sări peste intervalul de parametru în Grafana. Când nu doriți să obțineți grafice ciudate când măriți / micșorați în panou, este recomandat să utilizați variabila $__interval. Aceasta este o modificare internă a Grafana și alege intervalul de date în sine. Și VictoriaMetrics poate înțelege ea însăși care ar trebui să fie această gamă. Și nu trebuie să vă actualizați toate interogările. Va fi mult mai ușor.
A doua funcție este referirea la intervale. Puteți folosi această spațiere în expresiile dvs. Puteți înmulți, împărți, transferați, faceți referire la el.
Urmează familia de funcții de acumulare. Funcția de acumulare transformă oricare dintre serii temporale în trei serii temporale separate. Acestea sunt min, max și mediu. Mi se pare foarte convenabil, pentru că uneori poate arăta unele anomalii (anomalii) și inexactități.
Și dacă sunteți doar înfuriați sau evaluați, atunci probabil că puteți rata unele cazuri în care seria temporală nu se comportă așa cum ați vrut. Este mult mai ușor de văzut cu această funcție, să presupunem că max este foarte mult depășit de media.
Urmează variabila implicită. Implicit - aceasta înseamnă ce valoare trebuie să desenăm în Grafana dacă nu avem o serie temporală în acest moment. Când se întâmplă? Să presupunem că exportați unele valori de eroare. Și ai o aplicație atât de cool, încât atunci când pornești, nu ai nicio eroare și chiar nicio eroare pentru următoarele trei ore sau chiar o zi. Și aveți tablouri de bord care arată relațiile de la succes la eroare. Și nu vă vor arăta nimic pentru că nu aveți o valoare de eroare. Și în mod implicit puteți specifica orice.
Keep_last_Value - salvează ultima valoare a valorii dacă lipsește. Dacă Prometheus după următoarea răzuire nu l-a găsit în 5 minute, atunci aici ne vom aminti ultima sa valoare și graficele nu se vor rupe din nou.
Scrape_interval - arată cât de des colectează Prometheus date despre valoarea dvs., cu ce frecvență. Aici puteți vedea permisul, de exemplu.
Înlocuirea etichetei este o caracteristică populară. Dar credem că este puțin complicat pentru că necesită argumente întregi. Și nu trebuie doar să vă amintiți cele 5 argumente, ci și să vă amintiți secvența lor.
Prin urmare, de ce să nu le simplificăm? Adică, descompuneți-l în funcții mici cu sintaxă clară.
Și acum cel mai interesant. De ce credem că este PromQL extins? Pentru că acceptăm Common Table Expressions. Puteți urma codul QR (), vezi link-uri cu exemple, din terenul de joaca, unde poti rula interogari direct in VictoriaMetrics fara a-l instala doar in browser.
Și ce e? Această cerere de sus este o cerere destul de populară. Cred că în orice tablou de bord din multe companii folosești același filtru pentru orice. De obicei asa. Dar când trebuie să adăugați un filtru nou, trebuie să actualizați fiecare panou sau să descărcați tabloul de bord, să îl deschideți în JSON, să faceți o înlocuire de căutare, ceea ce necesită și timp. De ce să nu stocați această valoare într-o variabilă și să o reutilizați? Pare, după părerea mea, mult mai simplu și mai clar.
De exemplu, când trebuie să actualizez filtrele în Grafana în toate solicitările, iar tabloul de bord poate fi uriaș sau chiar pot fi mai multe dintre ele. Și cum aș dori să rezolv această problemă în Grafana?
Rezolv această problemă astfel: fac un commonFilter și definesc acest filtru în el, apoi îl reutilizam în interogări. Dar dacă faceți același lucru acum, nu va funcționa, deoarece Grafana nu vă permite să utilizați variabile în interiorul variabilelor de interogare. Și e puțin ciudat.
Și așa am făcut o opțiune care îți permite să faci asta. Și dacă sunteți interesat sau doriți o astfel de caracteristică, atunci susțineți sau nu vă place dacă nu vă place această idee.
Mai multe despre PromQL extins. Aici definim nu numai o variabilă, ci direct o întreagă funcție. Și o numim ru (utilizarea resurselor). Și această funcție acceptă resurse gratuite, o limită de resurse și un filtru. Sintaxa pare a fi 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, ce limită și cum se filtrează. Arată mult mai bine dacă ar fi să le scrii pe toate refolosind aceleași filtre, pentru că s-ar transforma într-o interogare mare, mare.
Și iată un exemplu de cerere atât de mare, mare. Este din tabloul de bord oficial NodeExporter pentru Grafana. Dar nu prea înțeleg ce se întâmplă aici. Adică, desigur, înțeleg dacă te uiți cu atenție, dar numărul de paranteze poate reduce imediat motivația de a înțelege ce se întâmplă aici. Și de ce să nu o facem mai simplă și mai clară?
De exemplu, astfel, evidențierea lucrurilor sau părților semnificative în variabile. Și apoi fă-ți matematica de bază. Deja seamănă mai degrabă cu programarea, asta mi-aș dori să văd în viitor la Grafana.
Iată un al doilea exemplu despre cum putem face și mai ușor dacă avem deja această funcție ru și există deja direct în VictoriaMetrics. Și apoi treceți doar valoarea stocată în cache pe care ați declarat-o în CTE.
Am vorbit deja despre cât de important este să folosești limbajul de programare potrivit. Și, probabil, ceva diferit se întâmplă în Grafana în fiecare companie. Și, probabil, încă dai acces la Grafana dezvoltatorilor tăi, iar dezvoltatorii fac ceva de la sine. Și toți o fac într-un mod diferit. Dar eu am vrut cumva la fel, adică redus la un standard comun.
Să presupunem că nu aveți doar ingineri de sistem, poate că aveți chiar experți, devopți sau SRE. Poate aveți experți care știu ce este monitorizarea, știu ce este Grafana, adică lucrează cu asta de ani de zile și știu exact cum să o facă corect. Și l-au scris deja de 100 de ori și l-au explicat tuturor, dar din anumite motive nimeni nu ascultă.
Ce se întâmplă dacă ar putea pune 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 liberă, atunci ar aplica pur și simplu funcția. Dar dacă creatorii exportatorilor, împreună cu produsul lor, ar furniza și un set de funcții, cum să lucreze cu valorile lor, pentru că știu exact care sunt aceste valori și cum să le calculeze corect?
Acesta chiar nu există. Iată ce am făcut eu însumi. Acesta este suportul bibliotecii din Grafana. Să presupunem că băieții care au făcut NodeExporter au făcut ceea ce am descris. Și a oferit, de asemenea, un set de caracteristici.
Adică arată cam așa. Conectați această bibliotecă la Grafana, intrați în editare și aici este foarte simplu în JSON cum să lucrați cu această metrică. Adică un set de funcții, descrierea lor și în ce se desfășoară.
După părerea mea, asta ar putea fi util, pentru că atunci ai scrie în Grafana exact așa. Și Grafana vă „spune” că există cutare sau cutare funcție dintr-o cutare bibliotecă – să o folosim. Cred că ar fi foarte tare.
Câteva despre VictoriaMetrics. Facem o mulțime de lucruri interesante. Citiți articolele noastre despre compresie, despre concurența noastră cu alte aplicații de date din serii de timp, explicația noastră despre cum să lucrați cu PromQL, pentru că sunt mult mai mulți începători în asta, precum și despre scalabilitatea verticală și despre confruntarea cu Thanos.
Întrebări:
Îmi voi începe întrebarea cu o poveste simplă de viață. Când am început să folosesc Grafana, am scris o interogare de 5 rânduri foarte convingătoare. Rezultatul final este o diagramă foarte convingătoare. Acest grafic aproape a intrat în producție. Dar, la o examinare mai atentă, s-a dovedit că această diagramă arată o prostie absolută care nu are nimic de-a face cu realitatea, deși cifrele se încadrează în intervalul pe care ne așteptam să îl vedem. Și întrebarea mea. Avem biblioteci, avem funcții, dar cum scriem teste pentru Grafana? Ai scris o interogare complexă care afectează decizia de afaceri - de a comanda un adevărat container de servere sau de a nu comanda. Și după cum știm, această funcție care desenează un grafic este similară cu adevărul. Mulțumesc.
Multumesc pentru intrebare. Sunt două părți aici. În primul rând, am impresia, pe baza experienței mele, că majoritatea utilizatorilor, atunci când se uită la graficele lor, nu înțeleg ce le arată. Cumva, oamenii sunt foarte buni să găsească o scuză pentru orice anomalie care se întâmplă pe diagrame, chiar dacă este un bug în interiorul unei funcții. Și a doua parte - mi se pare că utilizarea unor astfel de funcții ar fi mult mai potrivită pentru a vă rezolva problema, în loc ca fiecare dintre dezvoltatorii dvs. să-și facă propria planificare a capacității și să facă greșeli cu o oarecare probabilitate.
Cum să verificați?
Cum se verifică? Probabil ca nu.
Ca test la Grafana.
Și cum rămâne cu Grafana? Grafana traduce această solicitare direct în DataSource.
Adăugând puțin la parametri.
Nu, nu se adaugă nimic la Grafana. Pot exista parametri GET, cum ar fi step. Nu este specificat în mod explicit, dar îl puteți suprascrie, nu îl puteți suprascrie, dar este adăugat automat. Nu scrii teste aici. Nu cred că ar trebui să te bazezi pe Grafana aici ca o sursă de adevăr.
Multumesc pentru raport! Multumesc pentru compresie! V-ați amintit despre maparea unei variabile într-un grafic, că în Grafana nu puteți utiliza o variabilă într-o variabilă. Intelegi ce spun?
Da.
Asta a fost inițial o bătaie de cap când am vrut să fac o alertă în Grafana. Și acolo trebuie să faceți alerte pentru fiecare gazdă separat. Iată acest lucru pe care l-ați făcut, funcționează pentru alerte în Grafana?
Dacă Grafana nu accesează variabile într-un alt mod, atunci da, va funcționa. Dar sfatul meu este să nu folosești deloc alerting în Grafana, mai bine ai folosi alertmanager.
Da, îl folosesc, dar pur și simplu părea mai ușor de configurat în Grafana, dar mulțumesc pentru pont!
Sursa: www.habr.com