Predlažem da pročitate transkript izvještaja Romana Khavronenka “ExtendedPromQL”
Ukratko o meni. Moje ime je Roman. Radim u CloudFlareu i živim u Londonu. Ali ja sam i VictoriaMetrics održavač.
A ja sam autor za Grafana i je mali proxy za ClickHouse.
Počećemo s prvim dijelom, koji se zove “Poteškoće u prevođenju” iu njemu ću govoriti o tome da je svaki jezik, pa čak i samo jezik komunikacije veoma važan. Jer ovako prenosite svoje misli drugoj osobi ili sistemu, kako formulišete zahtjev. Ljudi na internetu se svađaju koji je jezik bolji - java ili neki drugi. Za sebe sam odlučio da biram prema zadatku, jer je sve ovo specifično.
Počnimo od samog početka. Šta je PromQL? PromQL je Prometheusov jezik upita. Ovako formiramo upite u Prometheusu da bismo dobili podatke o vremenskim serijama.
Šta su podaci o vremenskim serijama? Bukvalno, ovo su tri parametra.
To su:
- u šta gledamo?
- Kada ga pogledamo.
- I koju vrijednost pokazuje?
Ako pogledate ovaj grafikon (ovaj grafikon je s mog telefona koji prikazuje moju statistiku koraka), može brzo odgovoriti na ova pitanja.
Gledamo stepenice. Vidimo značenje i vidimo vrijeme kada ga gledamo. Odnosno, gledajući ovaj dijagram, lako možete reći da sam u nedjelju prešao oko 15 koraka. Ovo su podaci vremenske serije.
Sada ih "podijelimo" (konvertujmo) u drugi model podataka u obliku tabele. Ovdje također imamo ono što gledamo. Ovdje sam dodao malo dodatnih podataka, koje ćemo nazvati meta-podaci, odnosno nisam ja prošao kroz ovo, nego dvije osobe, na primjer, Jay i Silent Bob. Ovo je ono što mi gledamo; šta pokazuje i kada pokazuje tu vrijednost.
Pokušajmo sada sve ove podatke pohraniti u bazu podataka. Na primjer, uzeo sam ClickHouse sintaksu. I ovdje kreiramo jednu tabelu pod nazivom “Koraci”, odnosno ono što gledamo. Postoji vrijeme kada to gledamo; šta prikazuje i neke meta podatke u koje ćemo pohraniti ko je to: Jay i Silent Bob.
A da pokušamo sve ovo vizualizirati, koristit ćemo Grafanu jer je prije svega lijepa.
Također ćemo koristiti ovaj dodatak. Dva su razloga za to. Prvi je zato što sam ja to napisao. I znam tačno koliko je teško izvući podatke o vremenskim serijama iz ClickHouse-a kako bi ih prikazali u Grafani.
Prikazat ćemo ga na panelu grafikona. Ovo je najpopularniji panel u Grafani, koji pokazuje ovisnost vrijednosti o vremenu, tako da su nam potrebna samo dva parametra.
Hajde da napišemo najjednostavniji upit - kako prikazati statistiku koraka u Grafani, pohranjujući ove podatke u ClickHouse, u tabeli koju smo kreirali. I pišemo ovaj jednostavan zahtjev. Biramo između stepenica. Odabiremo vrijednost i biramo vrijeme ovih vrijednosti, odnosno ista tri parametra o kojima smo govorili.
I kao rezultat, dobićemo ovakav grafikon. Ko zna zašto je tako čudan?
Tako je, treba da se sortiramo po vremenu.
I na kraju ćemo dobiti bolji, ali ipak čudan raspored. Ko zna zašto? Tako je, dva su učesnika, a mi u Grafani poklanjamo dvije vremenske serije, jer ako ponovo pogledate model podataka, onda je svaka vremenska serija jedinstvena kombinacija imena i svih oznaka ključ/vrijednost.
Stoga moramo izabrati konkretnu osobu. Mi biramo Jaya.
I crtajmo ponovo. Sada graf izgleda kao istina. Sada je ovo normalan raspored i sve dobro funkcioniše.
I vjerovatno znate kako da uradite otprilike istu stvar, ali u Prometheusu preko PromQL-a. Ovako nešto. Malo jednostavnije. I hajde da sve razbijemo. Preduzeli smo korake. I filtriraj po Jayu. Ovdje ne navodimo da trebamo dobiti vrijednost i ne biramo vrijeme.
Pokušajmo sada izračunati brzinu kretanja Jaya ili Silent Boba. U ClickHouse-u ćemo morati da uradimo runDifference, tj. izračunati razliku između parova tačaka i podeliti ih vremenom da dobijemo tačnu brzinu. Zahtjev će izgledati otprilike ovako.
I prikazat će otprilike ove vrijednosti, tj. Silent Bob ili Jay čine otprilike 1,8 koraka u sekundi.
A u Prometeju i vi znate kako se to radi. Mnogo lakše nego prije.
A da bih to olakšao i u Grafani, dodao sam ovaj omot, koji izgleda vrlo sličan PromQL-u. Zove se Rate Macros ili kako god želite. U Grafani jednostavno napišete “stopa”, ali negdje duboko u sebi to se pretvara u ovaj veliki zahtjev. I ne morate ga ni gledati, tu je negdje, ali štedite puno vremena, jer je pisanje ovako ogromnih SQL upita uvijek skupo. Lako možete pogriješiti i onda dugo vremena ne razumjeti šta se dešava.
A ovo je zahtjev koji nije stao ni u jedan slajd i čak sam morao da ga podijelim u dvije kolone. Ovo je takođe zahtev u ClickHouse-u, koji pravi istu stopu, ali za obe vremenske serije: Silent Bob i Jay, tako da imamo dve vremenske serije na panelu. A ovo je već jako teško, po mom mišljenju.
A prema Prometeju to će biti suma (stopa). Za ClickHouse sam napravio zaseban makro pod nazivom RateColumns, koji izgleda kao upit u Prometheusu.
Pogledali smo ga i čini se da je PromQL tako kul, ali ima, naravno, ograničenja.
To su:
- Ograničeni SELECT.
- Borderline JOINs.
- Nema podrške.
A ako ste dugo radili s njim, onda znate da je ponekad jako teško nešto napraviti u PromQL-u, ali u SQL-u možete skoro sve, jer sve ove opcije o kojima smo upravo pričali mogu se uraditi u SQL-u . Ali da li bi ga bilo zgodno koristiti? I to me navodi da mislim da najmoćniji jezik možda nije uvijek najpogodniji.
Stoga, ponekad morate odabrati jezik za zadatak. To je kao da se Batman bori sa Supermenom. Jasno je da je Superman jači, ali Betmen je uspeo da ga pobedi jer je praktičniji i tačno je znao šta radi.
I sljedeći dio je Proširivanje PromQL-a.
Još jednom o VictoriaMetrics. Šta je VictoriaMetrics? Ovo je baza podataka vremenskih serija, nalazi se u OpenSource-u, mi distribuiramo njene pojedinačne i klaster verzije. Prema našim benchmarkovima, brži je od svega što je sada na tržištu i kompresija je slična, odnosno stvarni ljudi navode kompresiju od oko 0,4 bajta po točki, dok je Prometheusova 1,2-1,4.
Podržavamo više od Prometeja. Podržavamo InfluxDB, Graphite, OpenTSDB.
Možete nam „pisati“, odnosno prenijeti stare podatke.
Takođe savršeno radimo sa Prometheusom i Grafanom, odnosno podržavamo PromQL engine. A u Grafani možete jednostavno promijeniti Prometheus krajnju tačku u VictoriaMetrics i sve vaše kontrolne ploče će raditi kao što su radile.
Ali možete koristiti i dodatne funkcije koje VictoriaMetrics pruža.
Brzo ćemo proći kroz funkcije koje smo dodali.
Izostaviti parametar intervala – možete izostaviti parametre intervala u Grafani. Kada ne želite da dobijete čudne grafikone prilikom zumiranja/umanjivanja u panelu, preporučljivo je koristiti varijablu $__interval. Ovo je interna Grafana promjena i sama bira raspon podataka. I sama VictoriaMetrics može razumjeti kakav bi trebao biti ovaj raspon. I ne morate ažurirati sve svoje zahtjeve. Biće mnogo lakše.
Druga funkcija je intervalno referenciranje. Ovaj interval možete koristiti u svojim izrazima. Možete množiti, dijeliti, prenositi, pozivati se na to.
Sljedeća je porodica rollup funkcija. Funkcija Rollup transformira bilo koju vašu vremensku seriju u tri odvojene vremenske serije. To su min, max i prosječni. Smatram da je ovo vrlo zgodno jer ponekad može pokazati neke odstupanja i nepreciznosti.
A ako samo radite bijesni ili ocjenjujte, onda ćete vjerovatno propustiti neke slučajeve u kojima se vremenska serija ne ponaša kako ste očekivali. Sa ovom funkcijom je mnogo lakše vidjeti, recimo da je max mnogo od prosječne vrijednosti.
Sljedeća je zadana varijabla. Default - ovo znači koju vrijednost trebamo ucrtati u Grafani ako trenutno nemamo vremensku seriju. Kada se to dešava? Recimo da izvozite neke metrike grešaka. I imate tako cool aplikaciju da kada pokrenete, nemate nikakvih grešaka, pa čak ni grešaka u naredna tri sata ili čak dan. I imate kontrolne table koje pokazuju odnos od uspjeha do greške. I neće vam ništa pokazati jer nemate metriku greške. A prema zadanim postavkama možete odrediti bilo šta.
Keep_last_Value – čuva posljednju vrijednost metrike ako nedostaje. Ako ga Prometheus ne pronađe u roku od 5 minuta nakon sljedećeg skrapanja, onda ćemo ovdje zapamtiti njegovu posljednju vrijednost i vaše karte se više neće pokvariti.
Scrape_interval – pokazuje koliko često Prometheus prikuplja podatke o vašoj metrici i kojom frekvencijom. Ovdje možete vidjeti propusnicu, na primjer.
Zamjena etikete je popularna funkcija. Ali mislimo da je to malo komplikovano jer su potrebni čitavi argumenti. I morate zapamtiti ne samo 5 argumenata, već i njihov redoslijed.
Stoga, zašto ih ne učiniti jednostavnijim? Odnosno, podijelite ga na male funkcije s razumljivom sintaksom.
A sada zabavni dio. Zašto mislimo da je ovo prošireni PromQL? Zato što podržavamo Common Table Expressions. Možete pratiti QR kod (), pogledajte linkove sa primjerima, sa igrališta, gdje možete pokrenuti upite direktno u VictoriaMetrics-u bez jednostavnog instaliranja u pretraživač.
A šta je ovo? Ovaj zahtjev iznad je prilično popularan zahtjev. Mislim da na bilo kojoj kontrolnoj tabli u mnogim kompanijama koristite isti filter za sve. Obično je tako. Ali kada trebate dodati neki novi filter, morate ažurirati svaki panel, ili preuzeti kontrolnu ploču, otvoriti je u JSON-u, pronaći zamjenu, što također zahtijeva vrijeme. Zašto ne pohraniti ovu vrijednost u varijablu i ponovo je koristiti? Ovo izgleda, po mom mišljenju, mnogo jednostavnije i jasnije.
Na primjer, kada trebam ažurirati filtere u Grafani u svim zahtjevima, a kontrolna ploča može biti ogromna ili ih čak može biti nekoliko. A kako bih ja htio riješiti ovaj problem u Grafani?
Ovaj problem rješavam na ovaj način: napravim commonFilter i definiram ovaj filter u njemu, a zatim ga ponovo koristim u upitima. Ali ako sada uradite isto, to neće raditi jer vam Grafana ne dozvoljava da koristite varijable unutar varijabli upita. I malo je čudno.
I tako sam napravio opciju koja vam omogućava da to uradite. A ako ste zainteresovani ili želite takvu funkciju, onda je podržite ili ne volite ako vam se ova ideja ne sviđa.
Više o proširenom PromQL-u. Ovdje ne definiramo samo varijablu, već i cijelu funkciju. I mi to zovemo ru (upotreba resursa). I ova funkcija prihvaća besplatne resurse, ograničenje resursa i filter. Čini se da je sintaksa jednostavna. I vrlo je lako koristiti ovu funkciju i izračunati postotak slobodne memorije koju imamo. Odnosno, koliko memorije imamo, koja su ograničenja i kako filtrirati. Izgleda mnogo zgodnije ako ste sve napisali, ponovo koristeći iste filtere, jer bi se to pretvorilo u veliki, veliki upit.
A evo primjera tako velikog, velikog zahtjeva. To je sa službene NodeExporter kontrolne ploče za Grafanu. Ali jedva razumem šta se ovde dešava. To je, naravno, razumijem ako dobro pogledate, ali broj zagrada može odmah smanjiti motivaciju da shvatite šta se ovdje događa. A zašto to ne učiniti jednostavnijim i jasnijim?
Na primjer, ovako, razdvajanje značajnih stvari ili dijelova u varijable. A onda uradite svoju osnovnu matematiku. Ovo je već više kao programiranje, to bih volio vidjeti u budućnosti u Grafani.
Evo drugog primjera kako bismo ovo mogli učiniti još lakšim da već imamo ovu ru funkciju, a ona već postoji direktno u VictoriaMetrics. I onda jednostavno proslijedite keširanu vrijednost koju ste deklarirali u CTE-u.
Već sam govorio o tome koliko je važno koristiti pravi programski jezik. I, vjerovatno, svaka firma u Grafani ima nešto drugačije. I vjerovatno daješ pristup Grafani svojim programerima, a programeri rade svoje. I svi to rade nekako drugačije. Ali ja sam želio da to bude nekako isto, odnosno da se svede na zajednički standard.
Recimo da čak nemate samo sistem inženjere, možda čak imate stručnjake, devops ili SRE. Možda imate stručnjake koji znaju šta je monitoring, koji znaju šta je Grafana, odnosno već godinama rade sa njom i tačno znaju kako da to urade kako treba. I to su već 100 puta napisali i svima objasnili, ali iz nekog razloga niko ne sluša.
Što ako bi mogli staviti ovo znanje direktno u Grafanu kako bi drugi korisnici mogli ponovo koristiti funkcije? A ako bi trebali izračunati postotak slobodne memorije, jednostavno bi primijenili funkciju. Šta ako su kreatori izvoznika, uz svoj proizvod, dali i set funkcija kako da rade sa svojim metrikama, jer tačno znaju šta su to metrike i kako ih pravilno izračunati?
Ovo zapravo ne postoji. Ovo sam i sam uradio. Ovo je podrška biblioteke u Grafani. Recimo da su momci koji su napravili NodeExporter uradili ono o čemu sam pričao. Takođe su obezbedili i skup funkcija.
Odnosno, izgleda otprilike ovako. Ovu biblioteku povežete sa Grafanom, uđete u uređivanje i vrlo jednostavno je napisano u JSON-u kako se radi sa ovom metrikom. Odnosno, neki skup funkcija, njihov opis i ono u što se pretvaraju.
Mislim da bi ovo moglo biti od koristi, jer bi onda u Grafani pisali baš tako. A Grafana vam "kaže" da postoji takva i takva funkcija iz te i takve biblioteke - hajde da je iskoristimo. Mislim da bi to bilo super.
Malo o VictoriaMetrics. Radimo mnogo zanimljivih stvari. Pročitajte naše članke o kompresiji, o našim takmičenjima sa drugim aplikacijama podataka vremenskih serija, naše objašnjenje kako raditi sa PromQL-om, jer u tome još uvijek ima puno početnika, kao i o vertikalnoj skalabilnosti i o konfrontaciji sa Thanosom.
Pitanja:
Počeću svoje pitanje jednostavnom životnom pričom. Kada sam prvi put počeo da koristim Grafanu, napisao sam veoma ubedljiv upit koji je imao 5 redova. Krajnji rezultat je vrlo uvjerljiv grafikon. Ovaj raspored je skoro ušao u proizvodnju. No, nakon detaljnijeg pregleda, pokazalo se da ovaj grafikon pokazuje apsolutnu besmislicu koja nema nikakve veze sa stvarnošću, iako brojke spadaju u raspon koji smo očekivali. I moje pitanje. Imamo biblioteke, imamo funkcije, ali kako da napišemo testove za Grafanu? Napisali ste složen zahtjev od kojeg zavisi poslovna odluka - naručiti pravi kontejner servera ili ne naručiti. A kao što znamo, ova funkcija koja crta graf je slična istini. Hvala ti.
Hvala na pitanju. Postoje dva dijela. Prvo, stičem utisak, na osnovu mog iskustva, da većina korisnika, kada pogledaju svoje grafikone, ne razumeju šta im pokazuju. Iz nekog razloga, ljudi su vrlo dobri u pronalaženju izgovora za bilo koju anomaliju koja se pojavi u grafovima, čak i ako je riječ o grešci unutar funkcije. I drugi dio – čini mi se da bi korištenje ovakvih funkcija bilo puno bolji pristup rješavanju vašeg problema, umjesto da svaki od vaših programera radi svoje planiranje kapaciteta i pravi greške sa određenom vjerovatnoćom.
Kako provjeriti?
Kako provjeriti? Vjerovatno ne.
Kao test u Grafani.
Kakve veze ima Grafana s tim? Grafana prevodi ovaj zahtjev direktno u DataSource.
Dodavanje malo parametara.
Ne, Grafani se ništa ne dodaje. Možda postoje GET parametri, kao, recimo, korak. Nije eksplicitno specificirano, ali ga možete nadjačati ili ga ne možete nadjačati, ali se dodaje automatski. Ovdje nećete pisati testove. Mislim da se ovde ne treba oslanjati na Grafanu kao na izvor istine.
Hvala na izvještaju! Hvala na kompresiji! Spomenuli ste mapiranje varijable u graf, da u Grafani ne možete koristiti varijablu unutar varijable. Da li znate šta mislim?
Da.
Ovo je u početku bila glavobolja kada sam htio napraviti upozorenje u Grafani. I tu trebate napraviti upozorenje za svaki host posebno. Ovo što si napravio, radi li za upozorenja u Grafani?
Ako Grafana ne pristupa varijablama drugačije, onda da, radit će. Ali moj savjet je da uopće ne koristite alarmiranje u Grafani, bolje je da koristite alertmanager.
Da, koristim ga, ali mi se činilo da je lakše postaviti u Grafani, ali hvala na savjetu!
izvor: www.habr.com