Predlagam, da preberete prepis poročila Romana Khavronenka "ExtendedPromQL"
Na kratko o meni. Moje ime je Roman. Delam pri CloudFlare in živim v Londonu. Sem pa tudi vzdrževalec VictoriaMetrics.
In jaz sem avtor za Grafana in je majhen proxy za ClickHouse.
Začeli bomo s prvim delom, ki se imenuje “Težave pri prevajanju” in v njem bom govoril o tem, da je vsak jezik ali celo samo jezik komunikacije zelo pomemben. Ker tako posredujete svoje misli drugi osebi ali sistemu, tako oblikujete zahtevo. Ljudje na internetu se prepirajo, kateri jezik je boljši - java ali kateri drug. Zase sem se odločil, da moram izbrati glede na nalogo, ker je vse to specifično.
Začnimo od samega začetka. Kaj je PromQL? PromQL je Prometheus Query Language. Tako oblikujemo poizvedbe v Prometheusu, da dobimo podatke o časovni vrsti.
Kaj so podatki časovne vrste? Dobesedno so to trije parametri.
So:
- Kaj gledamo?
- Ko ga pogledamo.
- In kakšno vrednost prikazuje?
Če pogledate ta grafikon (ta grafikon je iz mojega telefona, ki prikazuje statistiko mojih korakov), lahko hitro odgovori na ta vprašanja.
Gledamo korake. Vidimo pomen in vidimo čas, ko ga pogledamo. Se pravi, če pogledamo ta diagram, zlahka rečemo, da sem v nedeljo prehodil približno 15 korakov. To so podatki časovne serije.
Zdaj pa jih »razdelimo« (pretvorimo) v drug podatkovni model v obliki tabele. Tukaj imamo tudi to, kar gledamo. Tukaj sem dodal malo dodatnih podatkov, ki jih bomo imenovali metapodatki, torej skozi to nisem šel jaz, ampak dve osebi, na primer Jay in Silent Bob. To je tisto, kar gledamo; kaj kaže in kdaj pokaže to vrednost.
Zdaj pa poskusimo vse te podatke shraniti v bazo podatkov. Za primer sem vzel sintakso ClickHouse. In tukaj ustvarimo eno tabelo z imenom "Koraki", torej tisto, kar gledamo. Obstaja čas, ko ga pogledamo; kaj prikazuje in nekaj meta podatkov, kamor bomo shranili, kdo je: Jay in Silent Bob.
In da bi poskusili vse to vizualizirati, bomo uporabili Grafana, ker je najprej lepa.
Uporabili bomo tudi ta vtičnik. Razloga za to sta dva. Prvi je zato, ker sem ga jaz napisal. In točno vem, kako težko je potegniti podatke o časovni vrsti iz ClickHouse, da jih prikažemo v Grafani.
Prikazali ga bomo na grafični plošči. To je najbolj priljubljena plošča v Grafani, ki prikazuje odvisnost vrednosti od časa, zato potrebujemo samo dva parametra.
Napišimo najpreprostejšo poizvedbo - kako prikazati statistiko korakov v Grafani, te podatke shraniti v ClickHouse, v tabeli, ki smo jo ustvarili. In napišemo to preprosto prošnjo. Izbiramo med koraki. Izberemo vrednost in izberemo čas teh vrednosti, torej iste tri parametre, o katerih smo govorili.
In kot rezultat bomo dobili tak graf. Kdo ve, zakaj je tako čuden?
Tako je, razvrstiti se moramo po času.
In na koncu bomo dobili boljši, a še vedno čuden urnik. Kdo ve zakaj? Tako je, udeleženca sta dva in mi pri Grafani podarjamo dve časovni seriji, ker če ponovno pogledate podatkovni model, potem je vsaka časovna serija edinstvena kombinacija imena in vseh oznak ključ-vrednost.
Zato moramo izbrati točno določeno osebo. Izbrali smo Jaya.
In spet narišimo. Zdaj je graf videti kot resnica. Zdaj je to normalen urnik in vse deluje dobro.
In verjetno veste, kako narediti približno isto stvar, vendar v Prometheusu prek PromQL. Nekaj podobnega. Malo bolj preprosto. In razčlenimo vse skupaj. Naredili smo korake. In filtriraj po Jayu. Tukaj ne navajamo, da moramo pridobiti vrednost, in ne izbiramo časa.
Zdaj pa poskusimo izračunati hitrost gibanja Jaya ali Silent Boba. V ClickHouse bomo morali izvesti RunningDifference, tj. izračunati razliko med pari točk in jih deliti s časom, da dobimo natančno hitrost. Zahteva bo videti nekako takole.
In prikazal bo približno te vrednosti, tj. Silent Bob ali Jay naredi približno 1,8 koraka na sekundo.
In v Prometeju znate tudi to narediti. Veliko lažje, kot je bilo prej.
In da bi bilo to enostavno narediti tudi v Grafani, sem dodal ta ovoj, ki je zelo podoben PromQL. Imenuje se Rate Macros ali kakor koli ga želite imenovati. V Grafani preprosto napišeš »stopnja«, a nekje globoko v sebi se preoblikuje v to veliko zahtevo. In sploh vam ga ni treba pogledati, tam nekje je, vendar prihranite veliko časa, saj je pisanje tako velikih SQL poizvedb vedno drago. Z lahkoto lahko naredite napako in potem dolgo časa ne boste razumeli, kaj se dogaja.
In to je zahteva, ki ni sodila niti v en diapozitiv in sem jo moral celo razdeliti v dva stolpca. To je tudi zahteva v ClickHouse, ki naredi enako stopnjo, vendar za obe časovni seriji: Silent Bob in Jay, tako da imamo na plošči dve časovni seriji. In to je že po moje zelo težko.
In po Prometeju bo to vsota (stopnja). Za ClickHouse sem naredil ločen makro z imenom RateColumns, ki je videti kot poizvedba v Prometheusu.
Pogledali smo ga in zdi se, da je PromQL tako kul, vendar ima seveda omejitve.
So:
- Omejen SELECT.
- Mejni spoji.
- Brez podpore.
In če ste z njim delali dlje časa, potem veste, da je včasih zelo težko nekaj narediti v PromQL, toda v SQL lahko naredite skoraj vse, saj bi vse te možnosti, o katerih smo pravkar govorili, lahko naredili v SQL . Toda ali bi ga bilo priročno uporabljati? In zaradi tega razmišljam, da najmočnejši jezik morda ni vedno najprimernejši.
Zato morate včasih izbrati jezik za nalogo. Kot da bi se Batman boril s Supermanom. Jasno je, da je Superman močnejši, vendar ga je Batman lahko premagal, ker je bolj praktičen in je natančno vedel, kaj počne.
In naslednji del je razširitev PromQL.
Še enkrat o VictoriaMetrics. Kaj je VictoriaMetrics? To je podatkovna zbirka časovnih vrst, je v OpenSource, distribuiramo njene enojne in grozdne različice. Po naših merilih je hitrejši od vsega, kar je zdaj na trgu, in stiskanje je podobno, tj. pravi ljudje poročajo o stiskanju približno 0,4 bajta na točko, medtem ko je Prometheus 1,2-1,4.
Podpiramo več kot samo Prometheus. Podpiramo InfluxDB, Graphite, OpenTSDB.
Lahko nam »pišete«, torej prenesete stare podatke.
Prav tako odlično sodelujemo s Prometheusom in Grafano, torej podpiramo motor PromQL. In v Grafani lahko preprosto spremenite končno točko Prometheus v VictoriaMetrics in vse vaše nadzorne plošče bodo delovale tako, kot so.
Uporabite pa lahko tudi dodatne funkcije, ki jih ponuja VictoriaMetrics.
Na hitro bomo pregledali funkcije, ki smo jih dodali.
Izpusti intervalni parameter – v Grafani lahko izpustite intervalne parametre. Kadar ne želite dobiti nenavadnih grafov pri povečavi/pomanjšanju na plošči, je priporočljivo uporabiti spremenljivko $__interval. To je interna sprememba Grafana in sama izbere obseg podatkov. In VictoriaMetrics sama lahko razume, kakšen bi moral biti ta obseg. In ni vam treba posodobiti vseh svojih zahtev. To bo veliko lažje.
Druga funkcija je intervalno referenciranje. Ta interval lahko uporabite v svojih izrazih. Lahko ga množite, delite, prenašate, se sklicujete nanj.
Naslednja je družina funkcij zbiranja. Funkcija Rollup pretvori katero koli vašo časovno serijo v tri ločene časovne serije. To so min, max in povprečje. To se mi zdi zelo priročno, ker lahko včasih pokaže nekaj odstopanj in netočnosti.
In če ste samo jezni ali ocenjevani, potem boste verjetno zamudili nekaj primerov, ko se časovna vrsta ne obnaša, kot ste pričakovali. S to funkcijo je veliko lažje videti, recimo, da je max zelo veliko od povprečja.
Naslednja je privzeta spremenljivka. Privzeto - to pomeni, kakšno vrednost moramo izrisati v Grafanu, če trenutno nimamo časovne vrste. Kdaj se to zgodi? Recimo, da izvažate nekaj meritev napak. In imaš tako kul aplikacijo, da ko začneš, nimaš nobene napake in celo nobene napake naslednje tri ure ali celo dan. In imate nadzorne plošče, ki prikazujejo razmerje od uspeha do napake. In ne bodo vam pokazali ničesar, ker nimate metrike napak. In privzeto lahko določite karkoli.
Keep_last_Value – shrani zadnjo vrednost metrike, če ta manjka. Če ga Prometheus ne najde v 5 minutah po naslednjem strganju, si bomo tukaj zapomnili njegovo zadnjo vrednost in vaši grafikoni se ne bodo več zlomili.
Scrape_interval – prikazuje, kako pogosto Prometheus zbira podatke o vaši metriki in s kakšno pogostostjo. Tukaj lahko vidite na primer prepustnico.
Zamenjava nalepk je priljubljena funkcija. Vendar menimo, da je malo zapleteno, ker zahteva cele argumente. In zapomniti si morate ne le 5 argumentov, ampak tudi njihovo zaporedje.
Zakaj jih torej ne bi poenostavili? To pomeni, da ga razdelite na majhne funkcije z razumljivo sintakso.
In zdaj zabavni del. Zakaj menimo, da je to razširjen PromQL? Ker podpiramo skupne tabelne izraze. Sledite lahko QR kodi (), si oglejte povezave s primeri iz igrišča, kjer lahko izvajate poizvedbe neposredno v VictoriaMetrics, ne da bi ga preprosto namestili v brskalnik.
In kaj je to? Ta zgornja zahteva je precej priljubljena. Mislim, da na kateri koli nadzorni plošči v mnogih podjetjih uporabljate isti filter za vse. Ponavadi je tako. Ko pa morate dodati kakšen nov filter, morate posodobiti vsako ploščo ali prenesti nadzorno ploščo, jo odpreti v JSON, poiskati zamenjavo, kar prav tako vzame čas. Zakaj ne bi te vrednosti shranili v spremenljivko in jo ponovno uporabili? To je po mojem mnenju veliko bolj preprosto in jasno.
Na primer, ko moram posodobiti filtre v Grafani v vseh zahtevah, nadzorna plošča pa je lahko ogromna ali pa jih je lahko celo več. In kako bi rad rešil ta problem v Grafani?
To težavo rešujem na naslednji način: naredim commonFilter in v njem definiram ta filter, nato pa ga ponovno uporabim v poizvedbah. Toda če storite enako zdaj, ne bo delovalo, ker vam Grafana ne dovoljuje uporabe spremenljivk znotraj poizvedbenih spremenljivk. In to je malo čudno.
In tako sem naredil možnost, ki vam to omogoča. In če vas zanima ali želite takšno funkcijo, jo podprite ali ne marajte, če vam ta ideja ni všeč.
Več o PromQL extended. Tu ne definiramo samo spremenljivke, ampak celotno funkcijo. In temu pravimo ru (uporaba virov). In ta funkcija sprejema brezplačne vire, omejitev virov in filter. Zdi se, da je sintaksa preprosta. In zelo enostavno je uporabljati to funkcijo in izračunati odstotek prostega pomnilnika, ki ga imamo. Se pravi, koliko pomnilnika imamo, kakšna je omejitev in kako filtrirati. Videti je veliko bolj priročno, če bi napisali vse in ponovno uporabili iste filtre, ker bi se spremenilo v veliko, veliko poizvedbo.
In tukaj je primer tako velike, velike zahteve. Je z uradne nadzorne plošče NodeExporter za Grafana. Ampak komaj razumem, kaj se tukaj dogaja. To seveda razumem, če natančno pogledate, vendar lahko število oklepajev takoj zmanjša motivacijo za razumevanje, kaj se tukaj dogaja. In zakaj ne bi bilo preprostejše in jasnejše?
Na primer, takole, ločevanje pomembnih stvari ali delov na spremenljivke. In nato naredite svojo osnovno matematiko. To je že bolj podobno programiranju, to bi rad videl v prihodnosti v Grafanu.
Tukaj je drugi primer, kako bi lahko to naredili še lažje, če že imamo to funkcijo ru in že obstaja neposredno v VictoriaMetrics. Nato preprosto posredujete predpomnjeno vrednost, ki ste jo navedli v CTE.
O tem, kako pomembna je uporaba pravega programskega jezika, sem že govoril. In verjetno se v vsakem podjetju v Grafani dogaja kaj drugega. In verjetno tudi omogočite dostop do Grafane svojim razvijalcem, razvijalci pa naredijo svoje. In vsi to počnejo nekako drugače. Želel pa sem, da bi bilo nekako enako, torej reducirati na skupen standard.
Recimo, da niti nimate samo sistemskih inženirjev, morda imate celo strokovnjake, devops ali SRE. Morda imate strokovnjake, ki vedo, kaj je monitoring, ki vedo, kaj je Grafana, se pravi, da se s tem ukvarjajo že leta in točno vedo, kako se to naredi prav. In to so že 100x napisali in vsem razložili, pa jih iz nekega razloga nihče ne posluša.
Kaj pa, če bi lahko to znanje dali neposredno v Grafano, da bi lahko drugi uporabniki znova uporabili funkcije? In če bi morali izračunati odstotek prostega pomnilnika, bi preprosto uporabili funkcijo. Kaj pa, če bi ustvarjalci izvoznikov skupaj s svojim izdelkom zagotovili tudi nabor funkcij za delo z njihovimi metrikami, saj točno vedo, kaj so te metrike in kako jih pravilno izračunati?
To v resnici ne obstaja. To sem naredil tudi sam. To je podpora knjižnice v Grafani. Recimo, da so fantje, ki so naredili NodeExporter, naredili to, o čemer sem govoril. In zagotovili so tudi nabor funkcij.
Se pravi, izgleda nekako takole. To knjižnico povežeš z Grafano, greš v urejanje in v JSON je zelo preprosto napisano, kako delati s to metriko. To je nek nabor funkcij, njihov opis in v kaj se spremenijo.
Mislim, da bi to lahko koristilo, ker bi potem v Grafanu pisal kar tako. In Grafana vam "pove", da obstaja taka in taka funkcija iz te in te knjižnice - uporabimo jo. Mislim, da bi bilo to zelo kul.
Nekaj o VictoriaMetrics. Počnemo veliko zanimivih stvari. Preberite naše članke o stiskanju, o naših tekmovanjih z drugimi aplikacijami za podatke o časovnih vrstah, našo razlago, kako delati s PromQL, ker je v tem še veliko začetnikov, pa tudi o vertikalni skalabilnosti in o spopadu s Thanosom.
Vprašanja:
Vprašanje bom začel s preprosto življenjsko zgodbo. Ko sem prvič začel uporabljati Grafano, sem napisal zelo privlačno poizvedbo, dolgo 5 vrstic. Končni rezultat je zelo prepričljiv graf. Ta urnik je že skoraj v proizvodnji. Toda ob natančnejšem pregledu se je izkazalo, da ta graf prikazuje popolno neumnost, ki nima nobene zveze z realnostjo, čeprav so številke v območju, ki smo ga pričakovali. In moje vprašanje. Imamo knjižnice, imamo funkcije, ampak kako napisati teste za Grafana? Napisali ste kompleksno zahtevo, od katere je odvisna poslovna odločitev - naročiti pravi kontejner strežnikov ali ne. In kot vemo, je ta funkcija, ki riše graf, podobna resnici. Hvala vam.
Hvala za vprašanje. Obstajata dva dela. Prvič, glede na izkušnje imam vtis, da večina uporabnikov, ko pogleda svoje grafikone, ne razume, kaj jim prikazujejo. Iz nekega razloga so ljudje zelo dobri v iskanju izgovora za vsako anomalijo, ki se pojavi na grafih, tudi če gre za napako v funkciji. In drugi del - zdi se mi, da bi bila uporaba takšnih funkcij veliko boljši pristop k reševanju vašega problema, namesto da bi vsak vaš razvijalec sam načrtoval zmogljivosti in z nekaj verjetnosti delal napake.
Kako preveriti?
Kako preveriti? Verjetno ne.
Kot test v Grafani.
Kaj ima Grafana s tem? Grafana to zahtevo prevede neposredno v DataSource.
Dodajanje malenkosti k parametrom.
Ne, Grafani ni nič dodano. Obstajajo lahko parametri GET, kot je, recimo, korak. Ni izrecno določeno, vendar ga lahko preglasite ali pa ga ne preglasite, vendar se doda samodejno. Tukaj ne boste pisali testov. Mislim, da se tukaj ne bi smeli zanašati na Grafana kot vir resnice.
Hvala za poročilo! Hvala za kompresijo! Omenili ste preslikavo spremenljivke v graf, da v Grafani ne morete uporabiti spremenljivke znotraj spremenljivke. Veš kaj mislim?
Da.
To je bil na začetku glavobol, ko sem želel ustvariti opozorilo v Grafani. In tam morate narediti opozorilo za vsakega gostitelja posebej. Ta stvar, ki si jo naredil, deluje za opozorila v Grafani?
Če Grafana ne dostopa do spremenljivk drugače, potem ja, bo delovalo. Ampak moj nasvet je, da sploh ne uporabljajte opozoril v Grafani, bolje je, da uporabite alertmanager.
Ja, uporabljam ga, vendar se mi je zdelo lažje nastaviti v Grafani, ampak hvala za nasvet!
Vir: www.habr.com