Azt javaslom, olvassa el Roman Havronenko „ExtendedPromQL” című jelentésének átiratát.
Röviden rólam. A nevem Roman. A CloudFlare-nél dolgozom, és Londonban élek. De a VictoriaMetrics karbantartója is vagyok.
És én vagyok a szerző Grafana és egy kis proxy a ClickHouse számára.
Kezdjük az első résszel, ami a „Fordítási nehézségek” címet viseli, és ebben arról fogok beszélni, hogy minden nyelv, vagy akár csak a kommunikáció nyelve nagyon fontos. Mert így közvetíti a gondolatait egy másik embernek vagy rendszernek, így fogalmaz meg egy kérést. Az interneten az emberek azon vitatkoznak, hogy melyik nyelv a jobb - a java vagy más. Magamban úgy döntöttem, hogy a feladat szerint kell választanom, mert mindez specifikus.
Kezdjük a legelejéről. Mi az a PromQL? A PromQL a Prometheus lekérdezési nyelv. Így képezünk lekérdezéseket a Prometheusban, hogy idősoros adatokat kapjunk.
Mi az idősoros adat? Szó szerint ez három paraméter.
Ezek a következők:
- Mit nézünk?
- Amikor ránézünk.
- És milyen értéket mutat?
Ha megnézi ezt a diagramot (ez a diagram a telefonomról származik, amely a lépésstatisztikáimat mutatja), gyorsan válaszol ezekre a kérdésekre.
Nézzük a lépéseket. Látjuk a jelentést és látjuk az időt, amikor ránézünk. Vagyis ezt a diagramot nézve könnyen kijelenthető, hogy vasárnap körülbelül 15 000 lépést gyalogoltam. Ezek idősoros adatok.
Most „osztjuk” (konvertáljuk) őket egy másik adatmodellbe táblázat formájában. Itt is megvan, amit nézünk. Ide tettem egy kis kiegészítő adatot, amit meta-adatnak fogunk nevezni, vagyis nem én mentem át ezen, hanem két ember, például Jay és Silent Bob. Ezt nézzük; mit mutat és mikor mutatja azt az értéket.
Most próbáljuk meg ezeket az adatokat egy adatbázisban tárolni. Például a ClickHouse szintaxist vettem. És itt létrehozunk egy táblázatot „Lépések” néven, vagyis amit nézünk. Van, amikor ránézünk; mit mutat, és néhány metaadat, ahol tárolni fogjuk, hogy ki ő: Jay és Silent Bob.
És hogy megpróbáljuk elképzelni mindezt, a Grafanát fogjuk használni, mert először is gyönyörű.
Mi is ezt a plugint fogjuk használni. Ennek két oka van. Az első, mert én írtam. És pontosan tudom, milyen nehéz idősor-adatokat lekérni a ClickHouse-ból, hogy megmutassák a Grafana-ban.
Megjelenítjük a Grafikon panelen. Ez a Grafana legnépszerűbb panelje, amely egy érték időfüggését mutatja, így csak két paraméterre van szükségünk.
Írjuk meg a legegyszerűbb lekérdezést - hogyan jelenítsük meg a lépésstatisztikát a Grafana-ban, tárolva ezeket az adatokat a ClickHouse-ban, az általunk létrehozott táblázatba. És ezt az egyszerű kérést írjuk. Lépések közül választunk. Kiválasztunk egy értéket és kiválasztjuk ezeknek az értékeknek az idejét, vagyis ugyanazt a három paramétert, amiről beszéltünk.
Ennek eredményeként egy ilyen grafikont kapunk. Ki tudja, miért olyan furcsa?
Így van, idő szerint kell válogatnunk.
És a végén jobb, de mégis furcsa menetrendet kapunk. Ki tudja miért? Így van, két résztvevő van, mi pedig a Grafana-nál két idősort adunk ki, mert ha újra megnézzük az adatmodellt, akkor minden idősor a név és az összes kulcsérték címkék egyedi kombinációja.
Ezért egy konkrét személyt kell választanunk. Mi Jayt választjuk.
És rajzoljunk újra. Most a grafikon úgy néz ki, mint az igazság. Most ez a normál ütemterv, és minden jól működik.
És valószínűleg tudja, hogyan kell nagyjából ugyanezt csinálni, de a Prometheusban a PromQL-en keresztül. Valami ilyesmi. Kicsit egyszerűbb. És bontsuk szét az egészet. Lépéseket tettünk. És szűrje meg Jay. Itt nem adjuk meg, hogy értéket kell kapnunk, és nem választunk időpontot.
Most próbáljuk meg kiszámítani Jay vagy Silent Bob mozgási sebességét. A ClickHouse-ban el kell végeznünk a runningDifference-t, azaz ki kell számolnunk a pontpárok közötti különbséget, és el kell osztani őket idővel, hogy megkapjuk a pontos sebességet. A kérés valahogy így fog kinézni.
És körülbelül ezeket az értékeket fogja mutatni, azaz a Silent Bob vagy Jay körülbelül 1,8 lépést tesz meg másodpercenként.
És a Prometheusban is tudod, hogyan kell ezt csinálni. Sokkal könnyebb, mint korábban volt.
És hogy a Grafana-ban is egyszerű legyen, hozzáadtam ezt a borítót, amely nagyon hasonlít a PromQL-hez. Aránymakróknak hívják, vagy ahogy akarod. A Grafana-ban egyszerűen azt írod, hogy „rate”, de valahol mélyen ez átalakul ebbe a nagy kérésbe. És nem is kell ránézni, valahol ott van, de rengeteg időt takarít meg, mert ilyen hatalmas SQL lekérdezések írása mindig drága. Könnyen hibázhat, és utána sokáig nem érti, mi történik.
És ez egy olyan kérés, ami nem is fért bele egy diába, sőt két oszlopra kellett osztanom. Ez is egy kérés a ClickHouse-ban, amely ugyanazt az arányt adja, de mindkét idősorra: Silent Bob és Jay, hogy két idősor legyen a panelen. És ez már nagyon nehéz szerintem.
Prométheusz szerint pedig összeg (ráta) lesz. A ClickHouse-hoz külön makrót készítettem RateColumns néven, ami úgy néz ki, mint egy lekérdezés a Prometheusban.
Megnéztük, és úgy tűnik, hogy a PromQL olyan menő, de természetesen vannak korlátai.
Ezek a következők:
- Korlátozott KIVÁLASZTÁS.
- Borderline JOIN-ok.
- NINCS támogatás.
És ha már régóta dolgozol vele, akkor tudod, hogy néha nagyon nehéz valamit csinálni PromQL-ben, de SQL-ben szinte mindent megtehetsz, mert ezeket a lehetőségeket, amiről az imént beszéltünk, meg lehet tenni SQL-ben . De kényelmes lenne használni? És ez arra késztet engem, hogy a legerősebb nyelv nem mindig a legkényelmesebb.
Ezért néha nyelvet kell választania a feladathoz. Mintha Batman Supermannel harcolna. Egyértelmű, hogy Superman erősebb, de Batman le tudta győzni, mert gyakorlatiasabb és pontosan tudta, mit csinál.
A következő rész pedig a PromQL kiterjesztése.
Még egyszer a VictoriaMetrics-ről. Mi az a VictoriaMetrics? Ez egy idősoros adatbázis, OpenSource-ban van, egyetlen és fürt verzióját is forgalmazzuk. A mi benchmarkjaink szerint gyorsabb, mint bármi, ami jelenleg a piacon van, és a tömörítés is hasonló, vagyis a valós emberek körülbelül 0,4 bájt/pont tömörítésről számolnak be, míg a Prometheusé 1,2-1,4.
Nemcsak Prometheust támogatjuk. Támogatjuk az InfluxDB-t, a Graphite-ot, az OpenTSDB-t.
Nekünk „írhat”, vagyis átvihet régi adatokat.
És a Prometheusszal és a Grafana-val is tökéletesen együttműködünk, vagyis támogatjuk a PromQL motort. A Grafana programban pedig egyszerűen módosíthatja a Prometheus végpontot VictoriaMetrics-re, és az összes irányítópult úgy fog működni, ahogyan korábban.
De használhat további funkciókat is, amelyeket a VictoriaMetrics biztosít.
Gyorsan áttekintjük az általunk hozzáadott funkciókat.
Intervallumparaméter elhagyása – az intervallumparamétereket kihagyhatja a Grafanában. Ha nem szeretne furcsa grafikonokat kapni a panelen való nagyításkor/kicsinyítéskor, javasolt a változó használata $__interval. Ez egy belső Grafana változás, és maga választja ki az adattartományt. És maga a VictoriaMetrics is képes megérteni, mi legyen ez a tartomány. És nem kell minden kérését frissítenie. Sokkal könnyebb lesz.
A második funkció az intervallum hivatkozás. Ezt az intervallumot használhatja kifejezéseiben. Lehet szorozni, osztani, átvinni, hivatkozni rá.
A következő az összesítő függvénycsalád. Az összesítő funkció bármelyik idősorát három különálló idősorrá alakítja át. Ezek a min, max és avg. Ezt nagyon kényelmesnek tartom, mert néha kiugró értékeket és pontatlanságokat mutathat.
És ha csak haragszik vagy értékel, akkor valószínűleg kihagy néhány olyan esetet, amikor az idősorok nem úgy viselkednek, ahogyan azt várta. Ezzel a funkcióval sokkal könnyebben áttekinthető, mondjuk a max nagyon az avg-től van.
A következő az alapértelmezett változó. Alapértelmezett - ez azt jelenti, hogy milyen értéket kell rajzolnunk a Grafana-ban, ha pillanatnyilag nincs idősorunk. Mikor történik ez? Tegyük fel, hogy valamilyen hibamutatót exportál. És van egy olyan klassz alkalmazásod, hogy amikor elindítod, a következő három órában vagy akár egy napban sincsenek hibáid, sőt még semmi hiba. És vannak irányítópultjai, amelyek bemutatják a kapcsolatot a sikertől a hibáig. És semmit sem fognak mutatni, mert nincs hibamérőszáma. És alapértelmezésben bármit megadhat.
Keep_last_Value – elmenti a metrika utolsó értékét, ha az hiányzik. Ha a Prometheus nem találja meg 5 percen belül a következő kaparás után, akkor itt megjegyezzük az utolsó értékét, és a diagramjai nem törnek újra.
Scrape_interval – megmutatja, hogy a Prometheus milyen gyakran és milyen gyakorisággal gyűjt adatokat a metrikáról. Itt láthat például egy bérletet.
A címkecsere népszerű funkció. De úgy gondoljuk, hogy ez egy kicsit bonyolult, mert egész érvek kellenek hozzá. És nem csak 5 érvre kell emlékeznie, hanem a sorrendjükre is.
Ezért miért ne lehetne egyszerűbbé tenni őket? Azaz bontsuk fel apró függvényekre, érthető szintaxissal.
És most a szórakoztató rész. Miért gondoljuk, hogy ez kiterjesztett PromQL? Mert támogatjuk a Common Table Expressions kifejezéseket. Követheti a QR kódot (), tekintse meg a példákat tartalmazó hivatkozásokat a játszótérről, ahol közvetlenül futtathat lekérdezéseket a VictoriaMetricsben anélkül, hogy egyszerűen telepítené a böngészőbe.
És mi ez? Ez a fenti kérés meglehetősen népszerű. Szerintem sok cégnél minden irányítópulton ugyanazt a szűrőt használja mindenre. Általában így. Ha azonban új szűrőt kell hozzáadnia, frissítenie kell az egyes paneleket, vagy le kell töltenie az irányítópultot, meg kell nyitnia JSON-ban, meg kell találnia a cserét, ami szintén időt vesz igénybe. Miért nem tárolja ezt az értéket egy változóban, és használja újra? Ez véleményem szerint sokkal egyszerűbbnek és világosabbnak tűnik.
Például amikor minden kérésnél frissítenem kell a Grafana szűrőit, és a műszerfal hatalmas lehet, vagy akár több is lehet. És hogyan szeretném megoldani ezt a problémát a Grafanában?
Ezt a problémát a következőképpen oldom meg: csinálok egy commonFilter-t és definiálom benne ezt a szűrőt, majd újra felhasználom a lekérdezésekben. De ha most megteszed ugyanezt, az nem fog működni, mert a Grafana nem teszi lehetővé a változók használatát a lekérdezési változókon belül. És ez egy kicsit furcsa.
Ezért készítettem egy lehetőséget, amely lehetővé teszi ezt. És ha érdekli vagy szeretne egy ilyen funkciót, akkor támogassa, vagy nem tetszik, ha nem tetszik ez az ötlet.
További információ a PromQL kiterjesztettről. Itt nem csak egy változót definiálunk, hanem egy teljes függvényt. Mi pedig ru-nak (erőforráshasználat) hívjuk. És ez a funkció ingyenes erőforrásokat, erőforrás-korlátozást és szűrőt fogad el. A szintaxis egyszerűnek tűnik. És nagyon könnyű használni ezt a funkciót, és kiszámítani a szabad memória százalékos arányát. Vagyis mennyi memóriánk van, mi a korlátozás és hogyan szűrjünk. Sokkal kényelmesebbnek tűnik, ha az egészet ugyanazokkal a szűrőkkel írnád, mert abból nagy-nagy lekérdezés lenne.
És itt van egy példa egy ilyen nagy-nagy kérésre. A Grafana hivatalos NodeExporter irányítópultjáról származik. De alig értem, mi történik itt. Ezt persze megértem, ha alaposan megnézzük, de a zárójelek száma azonnal csökkentheti a motivációt, hogy megértsük, mi történik itt. És miért ne lehetne egyszerűbbé és áttekinthetőbbé tenni?
Például így, jelentős dolgokat vagy részeket változókra szétválasztani. És akkor végezze el az alapvető matematikát. Ez már inkább programozás, ezt szeretném látni a jövőben a Grafanában.
Íme egy második példa arra, hogyan tehetjük ezt még egyszerűbbé, ha már rendelkeznénk ezzel a ru funkcióval, és már közvetlenül a VictoriaMetricsben létezik. Ezután egyszerűen átadja a gyorsítótárazott értéket, amelyet a CTE-ben deklarált.
Már beszéltem arról, hogy mennyire fontos a megfelelő programozási nyelv használata. És valószínűleg Grafana minden cégénél más történik. És valószínűleg hozzáférést ad a Grafanához a fejlesztőinek, és a fejlesztők megteszik a maguk dolgát. És mindegyik másképp csinálja. De azt szerettem volna, hogy valahogy egyforma legyen, vagyis lecsökkentsem egy közös szabványra.
Tegyük fel, hogy nem is csak rendszermérnökök vannak, hanem még szakértők, devopok vagy SRE is. Talán vannak olyan szakértői, akik tudják, mi az a monitorozás, akik tudják, mi az a Grafana, vagyis évek óta dolgoznak vele, és pontosan tudják, hogyan kell helyesen csinálni. És ezt már 100-szor megírták és elmagyarázták mindenkinek, de valamiért nem hallgatja meg senki.
Mi lenne, ha ezt a tudást közvetlenül a Grafanába helyeznék, hogy más felhasználók újra felhasználhassák a szolgáltatásokat? És ha ki kell számítani a szabad memória százalékos arányát, egyszerűen alkalmazzák a függvényt. Mi lenne, ha az exportőrök készítői a termékükkel együtt egy sor függvényt is megadnának a mérőszámaikkal való munkavégzéshez, mert pontosan tudják, mik ezek a mérőszámok, és hogyan kell helyesen kiszámítani őket?
Ez nem igazán létezik. Ezt én magam csináltam. Ez a Grafana könyvtári támogatása. Tegyük fel, hogy azok a srácok, akik a NodeExportert csinálták, azt tették, amiről beszéltem. És egy sor funkciót is biztosítottak.
Vagyis valahogy így néz ki. Csatlakoztatja ezt a könyvtárat a Grafanához, elkezdi a szerkesztést, és nagyon egyszerűen meg van írva JSON-ban, hogyan kell dolgozni ezzel a mérőszámmal. Vagyis néhány funkciókészlet, azok leírása és az, hogy mivé alakulnak át.
Szerintem ez hasznos lehet, mert akkor a Grafánában csak úgy írnál. Grafana pedig „megmondja”, hogy van ilyen és ilyen funkció egy ilyen és olyan könyvtárból - használjuk. Szerintem az nagyon klassz lenne.
Egy kicsit a VictoriaMetrics-ről. Sok érdekes dolgot csinálunk. Olvassa el cikkeinket a tömörítésről, a más idősoros adatalkalmazásokkal folytatott versenyeinkről, a PromQL-lel való munkavégzésről szóló magyarázatunkat, mert ebben még nagyon sok a kezdő, valamint a vertikális skálázhatóságról és a Thanos-szal való szembenézésről.
Kérdések:
A kérdésemet egy egyszerű élettörténettel kezdem. Amikor először elkezdtem használni a Grafana-t, egy nagyon lenyűgöző lekérdezést írtam, amely 5 soros volt. A végeredmény egy nagyon meggyőző grafikon. Ez az ütemterv már majdnem beindult. De alaposabban megvizsgálva kiderült, hogy ez a grafikon abszolút ostobaságot mutat, aminek semmi köze a valósághoz, bár a számok a várt tartományba esnek. És a kérdésem. Vannak könyvtáraink, vannak függvényeink, de hogyan írjunk teszteket a Grafana számára? Összetett kérelmet írt, amelytől az üzleti döntés múlik - rendelni valódi szerverkonténert vagy nem. És mint tudjuk, ez a függvény, amely a grafikont rajzolja, hasonló az igazsághoz. Köszönöm.
Köszönöm a kérdést. Két rész van. Először is, tapasztalataim alapján az a benyomásom, hogy a legtöbb felhasználó, amikor ránéz a grafikonjaira, nem érti, mit mutat nekik. Valamilyen oknál fogva az emberek nagyon jól tudnak kifogást találni a grafikonokban előforduló bármilyen rendellenességre, még akkor is, ha az egy függvényen belüli hiba. És a második rész - számomra úgy tűnik, hogy az ilyen funkciók használata sokkal jobb megközelítés lenne a probléma megoldására, ahelyett, hogy minden fejlesztő saját kapacitástervezést végezne, és bizonyos valószínűséggel hibákat követne el.
Hogyan ellenőrizzük?
Hogyan kell ellenőrizni? Valószínűleg nem.
Próbaként a Grafanában.
Mi köze ehhez a Grafanának? A Grafana ezt a kérést közvetlenül a DataSource-ba fordítja le.
Kicsit hozzátéve a paraméterekhez.
Nem, a Grafana nem ad hozzá semmit. Lehetnek GET paraméterek, mint például a lépés. Kifejezetten nincs megadva, de felülírhatod, vagy nem írhatod felül, de automatikusan hozzáadódik. Itt nem fogsz teszteket írni. Nem hiszem, hogy itt a Grafanára kellene hagyatkoznunk, mint az igazság forrására.
Köszönöm a beszámolót! Köszönöm a tömörítést! Említetted egy változó leképezését egy gráfban, hogy a Grafanában nem lehet változót használni egy változón belül. Tudod, mire gondolok?
Igen.
Ez kezdetben fejfájást okozott, amikor riasztást akartam létrehozni a Grafanában. És ott minden egyes gazdagéphez külön-külön kell riasztást küldeni. Ez az általad készített dolog működik a Grafana riasztásainál?
Ha a Grafana nem éri el másképp a változókat, akkor igen, működni fog. De azt tanácsolom, hogy egyáltalán ne használjon riasztást a Grafanában, jobban jár, ha az alertmanagert használja.
Igen, használom, de egyszerűbbnek tűnt beállítani a Grafanában, de köszönöm a tanácsot!
Forrás: will.com