Javaslom, hogy ismerkedjen meg Roman Khavronenko "ExtendedPromQL" című előadásának a feldolgozásával.
Röviden rólam. A nevem Roman. A CloudFlare-nél dolgozom, Londonban élek. De a VictoriaMetrics karbantartója is vagyok.
Én vagyok a szerző. a Grafana számára és Ez egy kis proxy a ClickHouse számára.
Kezdünk az első résszel, amelynek címe "A fordítás nehézségei", és ebben el fogom mondani, hogy bármely nyelv, vagy akár az egyszerű kommunikációs nyelv rendkívül fontos. Mert ez az, ahogyan átadja a gondolatait egy másik embernek vagy rendszernek, ahogyan megfogalmazza a kérését. Az emberek az interneten vitatkoznak arról, hogy melyik nyelv jobb – a Java vagy valami más. Én úgy döntöttem, hogy a feladat alapján kell választani, mert minden speciális.
Kezdjük az elején. Mi az a PromQL? A PromQL a Prometheus lekérdező nyelve. Ez az, ahogyan lekérdezéseket alkotunk a Prometheusban, hogy időbeli sorozat adatokat kapjunk.
Mi az időbeli sorozat adat? Ha szó szerint nézzük, akkor három paramétert jelent.
Ez pedig:
- Ami a figyelmünket felkelti.
- Mikor figyeljük ezt.
- És milyen értéket mutat.
Ha megnézzük ezt a diagramot (ez a diagram az én telefonomról készült, ami a lépéseim statisztikáját mutatja), akkor itt gyorsan válaszolhatunk ezekre a kérdésekre.
A lépéseket figyeljük. Látjuk az értéket, és látjuk az időt, amikor ezt figyeljük. Tehát, nézve ezt a diagramot, könnyen megmondhatjuk, hogy vasárnap körülbelül 15 000 lépést tettem meg. Ez időbeli sorozat adat.
Most próbáljuk "felbontani" (átalakítani) őket egy másik adatmódellé egy táblázat formájában. Itt is van az, amire figyelünk. Kicsit több adatot adtam hozzá, amelyeket metaadatoknak hívunk, azaz ezt nem én tettem, hanem két ember, mondjuk, Jay és Silent Bob. Ez az, amire figyelünk; mit mutat ez, és mikor mutatja ezt az értéket.
Most próbáljuk meg tárolni ezeket az adatokat egy adatbázisban. Példának okáért a ClickHouse szintaxisát választottam. Itt létrehozunk egy "Steps" nevű táblázatot, amely az, amire figyelünk. Itt van az idő, amikor figyeljük; mit mutat, és néhány metaadat, ahol tárolni fogjuk, hogy ki ez: Jay és Silent Bob.
És azért, hogy mindezt vizualizálni próbáljuk, a Grafanát fogjuk használni, mert egyrészt gyönyörű.
Használni fogjuk ezt a bővítményt. Két okból. Az első, mert én írtam. És pontosan tudom, milyen nehéz kinyerni az időbeli adatokat a ClickHouse-ból, hogy megjelenítsük a Grafana-ban.
A Graph Panelban fogjuk megjeleníteni. Ez a legnépszerűbb panel a Grafana-ban, amely az értékek időbeli alakulását mutatja, így mindössze két paraméterre van szükségünk.
Írjunk egy nagyon egyszerű lekérdezést – hogyan mutassuk meg a lépésstatisztikát a Grafana-ban, úgy, hogy ezeket az adatokat a ClickHouse-ban tároljuk, abban a táblázatban, amit létrehoztunk. A következő egyszerű lekérdezést írjuk. Lépéseket választunk. Választjuk az értéket és az időt, tehát ugyanazt a három paramétert, amiről már beszéltünk.
Így az alábbi grafikont fogjuk kapni. Tudja valaki, miért annyira furcsa?
Igen, időben kell rendezni.
A végeredmény már jobb, de még mindig furcsa grafikon. Valaki tudja, miért? Igen, két résztvevő van, és mi a Grafana-ban két időbeli sorozatot adunk meg, mert ha újra megnézzük az adattípust, minden időbeli sorozat egyedi kombinációja a névnek és az összes kulcs-érték címkének.
Ezért ki kell választanunk egy konkrét embert. Jay-t választjuk.
Most újra megrajzoljuk. Most a grafikon már hasonlít az igazságra. Most ez egy normális grafikon, és minden jól működik.
Valószínűleg tudja, hogyan csinálja ugyanazt a Prometheusban a PromQL segítségével. Körülbelül így. Egy kicsit egyszerűbb. És szét is bontjuk mindezt. A Lépéseket használtuk. És Jay-re szűrünk. Itt nem jelezzük, hogy az értéket szeretnénk, és nem választjuk ki az időt.
Most próbáljuk meg kiszámítani Jay vagy Silent Bob mozgási sebességét. A ClickHouse-ban futó különbséget kell tennünk, azaz a pontpárok közötti különbséget kell kiszámítanunk, és azokat el kell osztanunk az idővel, hogy pontos sebességet kapjunk. A lekérdezés körülbelül így fog kinézni.
Így körülbelül ilyen értékeket mutat majd, azaz Silent Bob vagy Jay körülbelül 1,8 lépést tesz meg másodpercenként.
A Prometheusban is tudja, hogyan kell ezt megtenni. Sokkal egyszerűbb, mint eddig volt.
És hogy ez a Grafanában is ilyen egyszerűen végezhető legyen, hozzáadtam egy ilyen burkolatot, amely nagyon hasonló a PromQL-hez. Ezt Rate Macros-nak hívják, vagy ahogy csak szeretné. Grafanában csak annyit ír, hogy „rate”, de a mélyben ez átalakul egy ilyen nagy lekérdezéssé. És nem is kell ránéznie, mert valahol ott van, de rengeteg időt spórol meg, mert ilyen hatalmas SQL lekérdezéseket írni mindig költséges. Könnyen hibázhat és aztán hosszú ideig nem értheti, mi történik.
Ez egy lekérdezés, ami még egy diára sem fért el, és ezért kénytelen voltam két oszlopra bontani. Ez is egy ClickHouse lekérdezés, amely ugyanazt a rate-t végzi, de mindkét time series-re: Silent Bob-ra és Jay-re, hogy legyen két time series a panelen. Ez már nagyon bonyolult, véleményem szerint.
És a Prometheus esetében ez sum (rate) lenne. A ClickHouse-hoz készítettem egy külön makrót, amely RateColumns néven ismert, és úgy néz ki, mint egy lekérdezés a Prometheusban.
Néztük, és úgy tűnik, hogy a PromQL nagyon klassz, de természetesen vannak korlátai.
Ez pedig:
- Korlátozott SELECT.
- Határozott JOIN.
- Nincs HAVING támogatás.
Ha sokáig dolgozott vele, akkor tudja, hogy néha nagyon nehéz valamit megvalósítani a PromQL-ben, míg az SQL-ben szinte mindent meg lehet csinálni, mert mindezeket a lehetőségeket, amiket most megbeszéltünk, meg lehetett valósítani SQL-ben. De lenne kényelmes ezt használni? Ez arra a gondolatra juttat, hogy nem mindig a legnagyobb hatalmú nyelv a legkényelmesebb.
Ezért néha a feladatokhoz kell választani a nyelvet. Ez olyan, mint Batman harca Superman ellen. Nyilvánvaló, hogy Superman erősebb, de Batman legyőzte őt, mert praktikusabb volt, és pontosan tudta, mit csinál.
A következő rész pedig a PromQL kiterjesztése.
Ismét a VictoriaMetrics-ról. Mi is az a VictoriaMetrics? Ez egy time series adatbázis, nyílt forráskódú, single és cluster verziókat terjesztünk. A mi benchmarkjaink alapján ez a leggyorsabb, ami jelenleg a piacon van, és a tömörítési arány is hasonló, azaz élő emberek körülbelül 0,4 byte-ot jelentettek pontonként, míg a Prometheus esetében ez 1,2-1,4.
Nemcsak a Prometheus-t támogatjuk. Támogatjuk az InfluxDB-t, Graphite-ot, OpenTSDB-t.
Lehet „írni” ránk, azaz lehet régi adatokat áthelyezni.
És tökéletesen működünk a Prometheus-szal és a Grafanával, azaz támogatjuk a PromQL motort. És a Grafanában egyszerűen megváltoztathatja a Prometheus végpontot VictoriaMetrics-ra, és minden irányítópultja működni fog, ahogyan eddig.
De használhatja a VictoriaMetrics által nyújtott további funkciókat is.
Gyorsan áttekintjük azokat a funkciókat, amelyeket hozzáadtunk.
Omit interval param – megkerülheti az intervallum paramétereket a Grafanában. Amikor nem szeretne furcsa grafikonokat kapni a zoomolás során, ajánlott használni a $__interval változót. Ez a Grafana belső változója, és automatikusan választja ki az adatokat. A VictoriaMetrics pedig megérti, hogy milyen tartományra van szükség. Így nem kell frissíteni az összes lekérdezését. Sokkal egyszerűbb lesz.A második funkció az intervallum hivatkozás. Ezt az intervallumot használhatja a kifejezéseiben. Kihasználhatja, oszthatja, átadhatja, hivatkozhat rá.
Ezután következik a rollup funkciók családja. A rollup funkciók bármely időszakos adatot három különálló időszakos adattá alakítanak: min, max és avg. Úgy gondolom, hogy ez nagyon hasznos, mert néha ez felfedheti a kiugró értékeket és a pontatlanságokat.
Ha csak irate-t vagy rate-t használ, valószínű, hogy kihagyhat néhány esetet, amikor az időszaki adatok nem úgy viselkednek, ahogy azt előre elgondolta. Ezzel a funkcióval sokkal egyszerűbb észrevenni, hogy például a max nagyon eltér az avg-től.
Továbbá a default változó. A default azt jelenti, hogy milyen értéket szeretnénk megjeleníteni a Grafanában, ha éppen nincs időszaki adatunk. Mikor fordul ez elő? Például, ha hibametrikát exportál. És van egy olyan nagyszerű alkalmazása, amelynek indításakor nincsenek hibái, és a következő három órában vagy akár napban sincsenek hibák. Van egy olyan műszerfala, amely a siker és a hiba arányát mutatja. Ez nem fog megjeleníteni semmit, mert nincs hiba metrikája. A defaultban bármit megadhat.
Keep_last_Value – megőrzi a legutolsó metrikát, ha az eltűnik. Ha a Prometheus a következő scrape után 5 percen belül nem találja meg, akkor itt megőrizzük a legutolsó értékét, és a grafikonjai újra nem fognak megszakadni.
Scrape_interval – azt mutatja, hogy a Prometheus milyen gyakran gyűjti az adatokat a metrikájáról, milyen frekvenciával. Itt látható lehet a kihagyás is.
A label replace – népszerű funkció. De azt gondoljuk, hogy ez egy kicsit bonyolult, mert sok argumentumot fogad el. Nemcsak 5 argumentumot kell emlékezni, hanem még a sorrendjüket is.
Ezért kell gondosan figyelni.
Ezért miért ne tennénk őket egyszerűbbé? Vagyis, lebontani kisebb funkciókra, érthető szintaxissal.
És most jön a legérdekesebb. Miért tartjuk ezt extended PromQL-nak? Mert támogatjuk a Common Table Expressions-t. QR-kód segítségével át tud menni (), megtekintheti a példákkal ellátott linkeket, valamint a playgroundot, ahol közvetlenül a VictoriaMetrics-ben hajthat végre lekérdezéseket anélkül, hogy telepítené, csak a böngészőben.
De mi is ez pontosan? Az a lekérdezés fent – ez egy meglehetősen népszerű lekérdezés. Azt hiszem, sok cégnél bármelyik irányítópulton ugyanazt a szűrőt használják mindenhol. Általában így van. De amikor új szűrőt kell hozzáadnia, frissítenie kell minden panelt, vagy le kell töltenie az irányítópultot, megnyitnia JSON-ban, find replace-et csinálnia, ami szintén időt igényel. Miért ne tárolnánk ezt az értéket változóban és ne használnánk újra? Szerintem ez sokkal egyszerűbb és világosabb.
Például amikor szűrőket kell frissítenem a Grafana-ban minden lekérdezésben, és az irányítópult hatalmas lehet, vagy akár több is lehet. Hogyan szeretném ezt megoldani a Grafana-ban?
Én így oldom meg a problémát: készítek egy commonFilter-t, amiben definiálom ezt a szűrőt, majd újra használom a lekérdezésekben. De ha most ezt csinálja, nem fog működni, mert a Grafana nem engedi, hogy változókat használjon belső lekérdezésváltozókban. Ez kicsit furcsa.
Ezért készítettem egy olyan megoldást, amely lehetővé teszi ezt. Ha érdekli, vagy szeretne egy ilyen funkciót, kérjük támogassa, vagy diszlájkolja, ha nem tetszik az ötlet.
Tovább a PromQL extended-ről. Itt nem csak egy változót határozunk meg, hanem egy egész függvényt. Ezt ru-nak (resource usage) nevezzük. Ez a függvény a szabad erőforrásokat, erőforráskorlátot és szűrőt fogad. Úgy tűnik, a szintaxis nagyon egyszerű. Nagyon könnyű használni ezt a függvényt, és kiszámítani a szabad memória százalékát. Vagyis, mennyi memóriánk van, milyen korlátozás van és hogyan kell szűrni. Ez sokkal kényelmesebben néz ki, ha mindezt úgy írná, hogy újrahasználja ugyanazokat a szűrőket, mert ez egy nagy-nagy lekérdezésé válna.
Íme egy példa egy hatalmas-hatalmas lekérdezésre. Ez a Grafana hivatalos NodeExporter műszerfaláról származik. De alig értem, mi történik itt. Tehát persze, értem, ha jobban megnézem, de a zárójelek száma azonnal csökkentheti a motivációt, hogy megértsük, mi folyik itt. Miért ne lehetne egyszerűbbé és érthetőbbé tenni?
Például így, kiemelve a lényeges dolgokat vagy részeket változókba. Aztán elvégezhetem az alapvető matematikát. Ez már inkább hasonlít a programozásra, ez az, amit a jövőben is szeretnék látni a Grafanában.
Itt a második példa, hogyan tehetnénk ezt még egyszerűbbé, ha már létezne ez a ru funkció, amely már közvetlenül elérhető a VictoriaMetrics-ben. Akkor egyszerűen átadnád a cache-elt értéket, amit a CTE-ben deklaráltál.
Már beszéltem arról, mennyire fontos a megfelelő programozási nyelv használata. Valószínűleg minden Grafana vállalatnál sajátos dolog folyik. Valószínűleg hozzáférést adsz a Grafanához a fejlesztőidnek, és a fejlesztők valami sajátot csinálnak. Ők mindannyian valahogy eltérően csinálják. Pedig szeretném, ha valahogy egységes lenne, azaz közös szabványra redukálnánk.
Tegyük fel, hogy nemcsak rendszermérnökök vannak, talán még vannak szakértők, DevOps-ok vagy SRE-k is. Talán vannak olyan szakértők, akik tudják, mi az a monitoring, tudnak a Grafanáról, azaz évek óta dolgoznak vele, és pontosan tudják, hogyan kell csinálni helyesen. Már írták ezt 100-szor, és mindenkinek elmagyarázták, de valamiért senki sem hallgat rájuk.
Mi lenne, ha ezek a tudásokat közvetlenül a Grafanába tudnák elhelyezni, így más felhasználók újra felhasználhatnák a funkciókat? És ha ki kellene számolni a szabad memória százalékát, akkor egyszerűen alkalmaznák a funkciót. Mi lenne, ha az exportálók készítői a termékükkel együtt funkciók készletét is biztosítanák a metrikáik kezelésére, mert pontosan tudják, mik azok a metrikák és hogyan kell helyesen számolni őket?
Ez valójában nem létezik. Ezt én csináltam. Ez a könyvtárak támogatása a Grafanában. Tegyük fel, hogy azok a srácok, akik a NodeExportert készítették, megcsinálták azt, amiről beszéltem. És funkciók készletét is biztosították.
Tehát, így néz ki: csatlakoztatod ezt a könyvtárat a Grafanához, belépsz a szerkesztésbe, és itt nagyon egyszerűen le van írva JSON formátumban, hogyan kell dolgozni ezzel a metrikával. Vagyis van valamilyen funkciókészlet, a leírásuk, és hogy mivé alakulnak.
Szerintem ez hasznos lenne, mert akkor a Grafanában egyszerűen csak így írnál. És a Grafana 'mondja', hogy van egy ilyen-olyan funkció ebben a könyvtárban – használjuk. Úgy érzem, ez nagyon jó lenne.
Kicsit a VictoriaMetricsről. Nagyon sok érdekes dolgot csinálunk. Olvasd el a cikkjeinket a tömörítésről, a többi időbeli sorozat adatfeldolgozó alkalmazásokkal folytatott versenyeinkről, a PromQL-lel való munkáról, mert ebben még sokan újak, és a vertikális skálázhatóságról, valamint a Thanos elleni küzdelemről.
Kérdések:
Kérdésemet egy egyszerű élettörténettel kezdem. Amikor először kezdtem használni a Grafanát, írtam egy nagyon meggyőző lekérdezést, ami öt sor hosszú volt. Ennek eredményeként egy nagyon meggyőző grafikon született. Ez a grafikon majdnem átment a gyártásba. De a közelebbi vizsgálat során kiderült, hogy ez a grafikon abszolút butaságot mutat, ami semmilyen kapcsolatban nincs a valósággal, bár a számok beleestek abba a tartományba, amit vártunk. És a kérdésem: Van könyvtárunk, vannak funkcióink, de hogyan írunk teszteket a Grafanához? Írtál egy bonyolult lekérdezést, ami egy üzleti döntéstől függ - rendelni egy valódi szerverkonténert vagy sem. És hogyan tudjuk, hogy az a funkció, ami a grafikont rajzolja, valósághű? Köszönöm.
Köszönöm a kérdést. Ennek két része van. Az első – az a benyomásom, hogy a gyakorlatomból kifolyólag a legtöbb felhasználó, amikor ránéz a grafikáira, nem érti, mit mutatnak. Valamiért az emberek nagyon jól kitalálnak mindenféle magyarázatot bármilyen anomáliára, ami a grafikákon történik, még akkor is, ha az a funkció hibája. A második rész – úgy érzem, hogy ezek a funkciók sokkal jobban megfelelnének a problémád megoldásához, ahelyett, hogy minden fejlesztőd a saját kapacitástervezését végezné, és véletlenül hibázna.
Hogyan ellenőrizzük?
Hogyan ellenőrizzük? Valószínűleg sehogy.
Grafana teszt formájában.
Mi köze van ehhez a Grafanához? A Grafana közvetlenül ezt a lekérdezést továbbítja az Adatforráshoz.
További paraméterek hozzáadásával.
Nem, a Grafanába semmit sem adnak hozzá. Ott lehetnek GET-paraméterek, mint például a step. Ez nem kerül egyértelműen megadásra, de felülbírálhatod, vagy sem, de automatikusan hozzáadódik. Itt teszteket nem írsz. Azt hiszem, nem érdemes a Grafanára, mint az igazság forrására támaszkodni.
Köszönöm az előadást! Köszönöm a tömörítést! Megemlítetted a változó leképezését a grafikonban, hogy a Grafanában nem lehet változót változóban használni. Értesz, miről beszélek?
Igen.
Ez kezdetben fejfájást okozott, amikor alertet akartam csinálni a Grafanában. Ott alertet minden hosztra külön kell csinálni. Az a dolog, amit csináltál, működik az alertok számára a Grafanában?
Ha a Grafana nem kezeli a változókat másképp, akkor – igen, működni fog. De az én tanácsom az, hogy ne használd az alertinget a Grafanában, jobban jársz, ha az alertmanagert használod.
Igen, használom, de egyszerűen ez a Grafanában könnyebbnek tűnt a beállítás során, de köszönöm a tanácsot!
Forrás: habr.com
