Predlažem da pročitate transkript izvješća Romana Khavronenka “ExtendedPromQL”
Ukratko o meni. Moje ime je Roman. Radim u CloudFlareu i živim u Londonu. Ali također sam i održavatelj VictoriaMetrics-a.
A ja sam autor za Grafana i je mali proxy za ClickHouse.
Počet ćemo s prvim dijelom koji se zove “Teškoće prijevoda” iu njemu ću govoriti o tome da je svaki jezik ili čak samo jezik komunikacije vrlo važan. Jer tako prenosite svoje misli drugoj osobi ili sustavu, tako formulirate zahtjev. Ljudi na internetu raspravljaju koji je jezik bolji - java ili neki drugi. Za sebe sam odlučio da trebam birati prema zadatku, jer je sve to specifično.
Krenimo od samog početka. Što je PromQL? PromQL je Prometheus Query Language. Ovako oblikujemo upite u Prometheusu da bismo dobili podatke o vremenskoj seriji.
Što su podaci vremenske serije? Doslovno, to su tri parametra.
To su:
- Što gledamo?
- Kad to pogledamo.
- I koju vrijednost pokazuje?
Ako pogledate ovaj grafikon (ovaj grafikon je s mog telefona koji prikazuje moje statistike koraka), može brzo odgovoriti na ova pitanja.
Gledamo korake. Vidimo smisao i vidimo vrijeme kada ga gledamo. Odnosno, gledajući ovaj dijagram, lako možete reći da sam u nedjelju prošao oko 15 000 koraka. Ovo su podaci vremenske serije.
Sada ih "razdvojimo" (pretvorimo) u drugi podatkovni model u obliku tablice. Ovdje također imamo ono što gledamo. Ovdje sam dodao malo dodatnih podataka, koje ćemo zvati meta-podaci, tj. kroz ovo nisam prošao ja, već dvoje ljudi, na primjer, Jay i Silent Bob. Ovo je ono što gledamo; što pokazuje i kada pokazuje tu vrijednost.
Pokušajmo sada sve te podatke pohraniti u bazu podataka. Na primjer, uzeo sam ClickHouse sintaksu. I ovdje kreiramo jednu tablicu koja se zove "Koraci", tj. ono što gledamo. Postoji vrijeme kada gledamo na to; što prikazuje i neke meta podatke gdje ćemo pohraniti tko je to: Jay i Silent Bob.
A da sve to pokušamo vizualizirati, poslužit ćemo se Grafanom jer je prije svega lijepa.
Također ćemo koristiti ovaj dodatak. Dva su razloga za to. Prvi je zato što sam ga ja napisao. I točno znam koliko je teško iz ClickHousea izvući podatke o vremenskoj seriji da ih prikažemo u Grafani.
Prikazat ćemo ga na Graph Panel-u. Ovo je najpopularniji panel u Grafani, koji pokazuje ovisnost vrijednosti o vremenu, tako da su nam potrebna samo dva parametra.
Napišimo najjednostavniji upit - kako prikazati statistiku koraka u Grafani, pohranjujući te podatke u ClickHouse, u tablici koju smo napravili. I mi pišemo ovaj jednostavan zahtjev. Biramo između koraka. Odaberemo vrijednost i odaberemo vrijeme tih vrijednosti, tj. ista tri parametra o kojima smo govorili.
I kao rezultat, dobit ćemo graf poput ovog. Tko zna zašto je tako čudan?
Tako je, moramo sortirati po vremenu.
I na kraju ćemo dobiti bolji, ali ipak čudan raspored. Tko zna zašto? Tako je, postoje dva sudionika, a mi u Grafani poklanjamo dvije vremenske serije, jer ako ponovno pogledate model podataka, onda je svaka vremenska serija jedinstvena kombinacija imena i svih oznaka ključ-vrijednost.
Stoga trebamo izabrati konkretnu osobu. Biramo Jaya.
I crtajmo opet. Sada grafikon izgleda kao istina. Sada je ovo normalan raspored i sve dobro funkcionira.
I vjerojatno znate kako napraviti otprilike istu stvar, ali u Prometheusu preko PromQL-a. Nešto kao ovo. Malo jednostavnije. I ajmo sve rastaviti. Poduzeli smo korake. I filtriraj prema Jayu. Ovdje ne navodimo da trebamo dobiti vrijednost i ne biramo vrijeme.
Pokušajmo sada izračunati brzinu kretanja Jaya ili Silent Boba. U ClickHouseu ćemo trebati raditi runningDifference, tj. izračunati razliku između parova točaka i podijeliti ih s vremenom kako bismo dobili točnu brzinu. Zahtjev će izgledati otprilike ovako.
I pokazat će otprilike ove vrijednosti, tj. Silent Bob ili Jay napravi otprilike 1,8 koraka u sekundi.
A u Prometeju znate kako se i to radi. Puno lakše nego što je bilo prije.
A kako bih to također učinio jednostavnim za rad u Grafani, dodao sam ovaj omot koji izgleda vrlo slično PromQL-u. Zove se Rate Macros ili kako god to želite nazvati. U Grafani jednostavno napišete “rate”, ali negdje duboko u sebi to se transformira u ovaj veliki zahtjev. I ne morate ga čak ni gledati, tu je negdje, ali štedite puno vremena, jer je pisanje tako velikih SQL upita uvijek skupo. Lako možete pogriješiti i dugo ne razumjeti što se događa.
A ovo je zahtjev koji nije stao ni u jedan slajd i čak sam ga morao podijeliti u dva stupca. To je također zahtjev u ClickHouseu, koji daje istu stopu, ali za obje vremenske serije: Silent Bob i Jay, tako da imamo dvije vremenske serije na panelu. A ovo je već vrlo teško, po mom mišljenju.
A prema Prometeju to će biti suma (stopa). Za ClickHouse napravio sam zasebnu makronaredbu pod nazivom RateColumns, koja izgleda kao upit u Prometheusu.
Pogledali smo ga i čini se da je PromQL tako cool, ali ima, naravno, ograničenja.
To su:
- Ograničeni SELECT.
- Borderline JOIN-ovi.
- Nema podrške.
I ako ste dugo radili s njim, onda znate da je ponekad vrlo teško napraviti nešto u PromQL-u, ali u SQL-u možete učiniti gotovo sve, jer sve ove opcije o kojima smo upravo govorili mogu se napraviti u SQL-u . Ali bi li bilo zgodno koristiti ga? I zbog toga mislim da najmoćniji jezik ne mora uvijek biti i najprikladniji.
Stoga ponekad trebate odabrati jezik za zadatak. Kao da se Batman bori protiv Supermana. Jasno je da je Superman jači, ali Batman ga je uspio pobijediti jer je praktičniji i točno je znao što radi.
I sljedeći dio je proširenje PromQL-a.
Još jednom o VictoriaMetrics. Što je VictoriaMetrics? Ovo je baza podataka vremenskih serija, u OpenSourceu je, distribuiramo njezine pojedinačne i klasterske verzije. Prema našim mjerilima, brži je od svega što je sada na tržištu, a kompresija je slična, tj. stvarni ljudi navode kompresiju od oko 0,4 bajta po točki, dok je kod Prometheusa 1,2-1,4.
Podržavamo više od samog Prometheusa. Podržavamo InfluxDB, Graphite, OpenTSDB.
Možete nam “pisati”, odnosno prenijeti stare podatke.
I također savršeno radimo s Prometheusom i Grafanom, tj. podržavamo PromQL engine. A u Grafani možete jednostavno promijeniti krajnju točku Prometheusa u VictoriaMetrics i sve će vaše nadzorne ploče raditi kao što su radile.
Ali također možete koristiti dodatne značajke koje pruža VictoriaMetrics.
Brzo ćemo proći kroz značajke koje smo dodali.
Izostavi parametar intervala – u Grafani možete izostaviti parametre intervala. Kada ne želite dobivati čudne grafikone prilikom povećavanja/smanjivanja na ploči, preporučuje se korištenje varijable $__interval. Ovo je interna promjena Grafane i sama odabire raspon podataka. I sama VictoriaMetrics može razumjeti kakav bi trebao biti ovaj raspon. I ne morate ažurirati sve svoje zahtjeve. Bit će puno lakše.
Druga funkcija je intervalno referenciranje. Ovaj interval možete koristiti u svojim izrazima. Možete ga množiti, dijeliti, prenositi, pozivati se na njega.
Sljedeća je obitelj funkcija skupljanja. Funkcija Rollup transformira bilo koju vašu vremensku seriju u tri zasebne vremenske serije. To su min, max i avg. Smatram da je ovo vrlo zgodno jer ponekad može pokazati neke odstupanja i netočnosti.
A ako se samo ljutite ili ocjenjujete, tada ćete vjerojatno propustiti neke slučajeve u kojima se vremenski niz ne ponaša kako ste očekivali. S ovom funkcijom puno je lakše vidjeti, recimo da je maks.
Sljedeća je zadana varijabla. Zadano - to znači koju vrijednost trebamo nacrtati u Grafanu ako trenutno nemamo vremensku seriju. Kada se to događa? Recimo da izvozite neke metrike pogreške. I imaš tako cool aplikaciju da kad kreneš, nemaš grešaka, pa čak ni grešaka sljedeća tri sata ili čak dan. I imate nadzorne ploče koje pokazuju odnos od uspjeha do pogreške. I neće vam pokazati ništa jer nemate metriku pogreške. A prema zadanim postavkama možete odrediti bilo što.
Keep_last_Value – sprema posljednju vrijednost metrike ako nedostaje. Ako ga Prometheus ne pronađe u roku od 5 minuta nakon sljedećeg struganja, ovdje ćemo zapamtiti njegovu posljednju vrijednost i vaši grafikoni se više neće pokvariti.
Scrape_interval – pokazuje koliko često Prometheus prikuplja podatke o vašoj metrici i kojom učestalošću. Ovdje možete vidjeti propusnicu, na primjer.
Zamjena naljepnica je popularna značajka. Ali mislimo da je to malo komplicirano jer su potrebni cijeli argumenti. I ne morate samo zapamtiti 5 argumenata, već i zapamtiti njihov redoslijed.
Stoga, zašto ih ne učiniti jednostavnijima? To jest, rastavite ga na male funkcije s razumljivom sintaksom.
A sada zabavni dio. Zašto mislimo da je ovo prošireni PromQL? Zato što podržavamo zajedničke tablične izraze. Možete pratiti QR kod (), pogledajte veze s primjerima iz igrališta, gdje možete pokretati upite izravno u VictoriaMetrics bez jednostavnog instaliranja u pregledniku.
A što je ovo? Ovaj zahtjev iznad je prilično popularan zahtjev. Mislim da na bilo kojoj nadzornoj ploči u mnogim tvrtkama koristite isti filtar za sve. Obično je tako. Ali kada trebate dodati neki novi filter, morate ažurirati svaku ploču ili preuzeti nadzornu ploču, otvoriti je u JSON-u, pronaći zamjenu, što također oduzima vrijeme. Zašto ne pohraniti ovu vrijednost u varijablu i ponovno je upotrijebiti? Ovo izgleda, po mom mišljenju, mnogo jednostavnije i jasnije.
Na primjer, kada trebam ažurirati filtere u Grafani u svim zahtjevima, a nadzorna ploča može biti ogromna ili čak može biti nekoliko njih. A kako bih htio riješiti ovaj problem u Grafani?
Ovaj problem rješavam na sljedeći način: napravim commonFilter i u njemu definiram ovaj filtar, a zatim ga ponovno koristim u upitima. Ali ako sada učinite isto, neće raditi jer vam Grafana ne dopušta korištenje varijabli unutar varijabli upita. I malo je čudno.
I tako sam napravio opciju koja vam to omogućuje. A ako ste zainteresirani ili želite takvu značajku, podržite je ili je ne volite ako vam se ova ideja ne sviđa.
Više o proširenom PromQL-u. Ovdje definiramo ne samo varijablu, već cijelu funkciju. I mi to zovemo ru (korištenje resursa). I ova funkcija prihvaća besplatne resurse, ograničenje resursa i filter. Čini se da je sintaksa jednostavna. I vrlo je jednostavno 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 da ste sve napisali, ponovno koristeći iste filtere, jer bi se pretvorilo u veliki, veliki upit.
I evo primjera tako velikog, velikog zahtjeva. To je sa službene nadzorne ploče NodeExporter za Grafanu. Ali jedva razumijem što se ovdje događa. To je, naravno, razumijem ako pažljivo pogledate, ali broj zagrada može odmah smanjiti motivaciju da shvatite što se ovdje događa. A zašto ga ne učiniti jednostavnijim i jasnijim?
Na primjer, ovako, razdvajanje značajnih stvari ili dijelova u varijable. A onda napravite svoju osnovnu matematiku. Ovo je već više kao programiranje, to bih volio vidjeti u budućnosti u Grafani.
Evo drugog primjera kako ovo možemo učiniti još lakšim ako već imamo ovu ru funkciju i ona već postoji izravno u VictoriaMetrics. Zatim jednostavno proslijedite predmemoriranu vrijednost koju ste deklarirali u CTE-u.
Već sam govorio o tome koliko je važno koristiti pravi programski jezik. I vjerojatno se u svakoj tvrtki u Grafani događa nešto drugo. I vjerojatno također dajete pristup Grafani svojim programerima, a programeri rade svoje. I svi to rade nekako drugačije. Ali htio sam da 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 što je monitoring, koji znaju što je Grafana, odnosno godinama rade s njom i točno znaju kako se to radi kako treba. I to su već 100 puta napisali i svima objasnili, ali iz nekog razloga nitko ne sluša.
Što ako bi to znanje mogli staviti izravno u Grafanu kako bi drugi korisnici mogli ponovno koristiti značajke? A kad bi trebali izračunati postotak slobodne memorije, jednostavno bi primijenili tu funkciju. Što ako su tvorci izvoznika uz svoj proizvod dali i skup funkcija za rad s njihovim metrikama, jer oni točno znaju što su te metrike i kako ih ispravno izračunati?
Ovo zapravo ne postoji. Ovo sam i sama napravila. Ovo je podrška knjižnice u Grafani. Recimo da su dečki koji su napravili NodeExporter napravili ono o čemu sam govorio. Također su pružili niz funkcija.
Odnosno, izgleda otprilike ovako. Tu biblioteku povežete s Grafanom, uđete u editiranje i vrlo jednostavno u JSON-u piše kako raditi s 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 Grafanu pisali upravo tako. A Grafana vam “kaže” da postoji ta i ta funkcija iz te i te biblioteke - hajdemo je koristiti. Mislim da bi to bilo jako cool.
Malo o VictoriaMetrics. Radimo puno zanimljivih stvari. Pročitajte naše članke o kompresiji, o našim natjecanjima s drugim aplikacijama za podatke vremenskih serija, naše objašnjenje kako raditi s PromQL-om, jer još uvijek ima puno početnika u tome, kao i o vertikalnoj skalabilnosti i o sukobu s Thanosom.
Pitanja:
Započet ću svoje pitanje jednostavnom životnom pričom. Kad sam prvi put počeo koristiti Grafanu, napisao sam vrlo uvjerljiv upit koji je bio dug 5 redaka. Konačni rezultat je vrlo uvjerljiv grafikon. Ovaj raspored je skoro ušao u proizvodnju. No, pomnijim promatranjem pokazalo se da ovaj graf prikazuje apsolutnu besmislicu koja nema veze sa stvarnošću, iako su brojke unutar raspona koji smo očekivali vidjeti. I moje pitanje. Imamo knjižnice, imamo funkcije, ali kako napisati testove za Grafanu? Napisali ste kompleksan zahtjev o kojem ovisi poslovna odluka - naručiti pravi kontejner poslužitelja ili ne naručiti. I kao što znamo, ova funkcija koja crta graf je slična istini. Hvala vam.
Hvala na pitanju. Postoje dva dijela. Prvo, imam dojam, na temelju svog iskustva, da većina korisnika, kada pogleda svoje karte, ne razumije što im one pokazuju. Iz nekog razloga, ljudi su vrlo dobri u pronalaženju izgovora za bilo koju anomaliju koja se pojavljuje u grafikonima, čak i ako je to greška unutar funkcije. I drugi dio - čini mi se da bi korištenje takvih funkcija bio puno bolji pristup rješavanju vašeg problema, umjesto da svaki od vaših programera radi vlastito planiranje kapaciteta i s nekom vjerojatnošću griješi.
Kako provjeriti?
Kako provjeriti? Vjerojatno ne.
Probno u Grafani.
Kakve veze Grafana ima s tim? Grafana prevodi ovaj zahtjev izravno u DataSource.
Dodavanje malo parametrima.
Ne, Grafanu se ništa ne dodaje. Mogu postojati GET parametri, poput, recimo, koraka. Nije izričito navedeno, ali ga možete nadjačati ili ga ne možete poništiti, ali se dodaje automatski. Ovdje nećete pisati testove. Mislim da se ovdje ne treba oslanjati na Grafanu kao izvor istine.
Hvala na izvješću! Hvala na kompresiji! Spomenuli ste mapiranje varijable u grafu, da u Grafani ne možete koristiti varijablu unutar varijable. Znaš li što mislim?
Da.
To mi je u početku predstavljalo glavobolju kada sam htio napraviti upozorenje u Grafani. I tu treba napraviti alert za svaki host posebno. Ovo što si napravio, radi li za dojave u Grafani?
Ako Grafana ne pristupa varijablama drugačije, onda da, radit će. Ali moj savjet je da uopće ne koristite alerting u Grafani, bolje vam je alertmanager.
Da, koristim ga, ali samo mi se činilo jednostavnije postaviti u Grafani, ali hvala na savjetu!
Izvor: www.habr.com