Navrhujem oboznámiť sa s prekladom prezentácie Romana Chavronenka "ExtendedPromQL"
Stručne o mne. Volám sa Roman. Pracujem v CloudFlare a žijem v Londýne. Som tiež údržbárom VictoriaMetrics.
A som autor pre Grafanu a – je to malý proxy pre ClickHouse.
Začneme s prvou časťou, ktorá sa volá „Zložitosti prekladu“, a v nej budem rozprávať o tom, že každý jazyk alebo dokonca len jazyk komunikácie – je to veľmi dôležité. Pretože to, ako prenášate svoje myšlienky inej osobe alebo systému, je zásadné, ako formulujete dopyt. Ľudia na internete sa hádajú, ktorý jazyk je lepší – java alebo nejaký iný. Pre seba som sa rozhodol, že treba vybrať podľa úlohy, pretože všetko to je špecifické.
Začneme od samého začiatku. Čo je to PromQL? PromQL – to je jazyk dotazov Prometheus. Takto formulujeme dopyty v Prometheuse, aby sme získali dáta o časových radoch.
Čo sú to dáta o časových radoch? Ak to vezmeme doslovne, sú to tri parametre.
Sú to:
- Na čo sa pozeráme.
- Kedy sa na to pozeráme.
- A akú hodnotu to ukazuje.
Ak sa pozrieme na túto diagramu (táto diagram je z môjho telefónu, ktorý ukazuje štatistiku mojich krokov), môžeme rýchlo odpovedať na tieto otázky.
Sledujeme kroky. Vidíme hodnotu a vidíme čas, keď sa na to pozeráme. T. j. pozrúc na tento diagram, môžeme ľahko povedať, že v nedeľu som prešiel približne 15 000 krokov. To sú dáta o časových radoch.
Teraz sa pokúsme „rozbiť“ (premeniť) ich na iný model dát vo forme tabuľky. Tu máme tiež to, na čo sa pozeráme. Trochu som pridal ďalšie údaje, ktoré budeme nazývať meta-dátami, t. j. to neprešiel som ja, ale dvaja ľudia, povedzme, Jay a Silent Bob. Toto je to, na čo sa pozeráme; čo to ukazuje a kedy ukazuje túto hodnotu.
Teraz sa pokúsme uložiť všetky tieto dáta do databázy. Na príklad som vzal syntaktiku ClickHouse. A tu vytvárame jednu tabuľku, ktorá sa volá „Steps“, t. j. na čo sa pozeráme. Tu je čas, keď sa na to pozeráme; čo to ukazuje a nejaké meta-dáta, kde budeme ukladať, kto to je: Jay a Silent Bob.
A aby sme sa pokúsili vizualizovať toto všetko, budeme používať Grafanu, pretože, po prvé, je to krásne.
Takisto budeme používať tento plugin. Existujú dva dôvody. Prvý je ten, že som ho napísal. A presne viem, ako ťažké je získať časové údaje z ClickHouse, aby sme ich mohli zobraziť v Grafane.
Zobrazíme to v Graf Panel. Je to najpopulárnejšia panel v Grafane, ktorý zobrazuje závislosť hodnoty od času, takže potrebujeme iba dva parametre.
Napíšme najjednoduchší dotaz — ako zobraziť štatistiku krokov v Grafane, pričom tieto údaje sú uložené v ClickHouse, v tej tabuľke, ktorú sme vytvorili. A píšeme takýto jednoduchý dotaz. Vyberáme zo krokov. Vyberáme hodnotu a vyberáme čas týchto hodnôt, teda tie tri parametre, o ktorých sme hovorili.
A výsledkom bude takýto graf. Kto vie, prečo je taký zvláštny?
Správne, treba to zoradiť podľa času.
A nakoniec dostaneme už lepší, ale stále zvláštny graf. Kto vie, prečo? Správne, sú tam dvaja účastníci, a v Grafane posielame dva časové rady, pretože ak sa pozrieme na dátový model ešte raz, každá časová rada je unikátna kombinácia mena a všetkých kľúč-hodnotových labelov.
Preto musíme vybrať konkrétneho človeka. Vyberáme Jaya.
A znova kreslíme. Teraz už graf vyzerá pravdivejšie. Teraz je to normálny graf a všetko funguje dobre.
A pravdepodobne viete, ako to urobiť podobne, ale v Prometheovi cez PromQL. Približne takto. O niečo jednoduchšie. A ešte to všetko rozdelíme. Brali sme Krokov. A filtrujeme podľa Jaya. Tu neuvádzame, čo potrebujeme získať a nevyberáme čas.
A teraz sa pokúsime vypočítať rýchlosť pohybu Jaya alebo Silent Boba. V ClickHouse nám bude treba urobiť runningDifference, teda vypočítať rozdiel medzi pármi bodov a rozdeliť ich časom, aby sme získali presnú rýchlosť. Dotaz bude vyzerať asi takto.
A ukáže približne takéto hodnoty, teda Silent Bob alebo Jay robí asi 1,8 kroku za sekundu.
A v Prometheovi viete, ako to urobiť tiež. Oveľa jednoduchšie, než to bolo predtým.
Aby to bolo v Grafana tak jednoduché, pridal som takýto obal, ktorý sa veľmi podobá na PromQL. Nazýva sa to Rate Macros, alebo ako chcete. V Grafana jednoducho napíšete „rate“, ale niekde v hĺbke sa to transformuje na taký veľký dotaz. A nemusíte sa na to ani pozerať, je tam niekde, ale ušetríte množstvo času, pretože písanie takých obrovských SQL dotazov je vždy nákladné. Ľahko sa môžete pomýliť a potom dlho nechápete, čo sa deje.
A toto je dotaz, ktorý sa ani nezmestil do jedného snímku a musel som ho rozdeliť na dve stĺpce. Toto je tiež dotaz v ClickHouse, ktorý robí to isté rate, ale pre obe časové rady: aj pre Silent Boba, aj pre Jaya, aby sme mali na paneli dve časové rady. A to už je podľa mňa veľmi zložité.
A v Prometheovi to bude sum(rate). Pre ClickHouse som vytvoril samostatný makro, ktorý sa volá RateColumns, ktorý vyzerá ako dotaz v Prometheovi.
Pozreli sme sa na to a zdá sa, že PromQL je všetko také skvelé, ale má samozrejme aj obmedzenia.
Sú to:
- Obmedzený SELECT.
- Obmedzené JOIN.
- Žiadna podpora pre HAVING.
A ak ste s ním pracovali dlho, viete, že niekedy je veľmi ťažké urobiť niečo v PromQL, zatiaľ čo v SQL môžete robiť takmer všetko, pretože všetky tieto varianty, o ktorých sme teraz hovorili, by mohli byť vykonané v SQL. Ale bolo by pohodlné to používať? A to ma privádza k myšlienke, že nie vždy je najvýkonnejší jazyk najpohodlnejší.
Preto niekedy treba vybrať jazyk podľa úloh. Je to ako súboj Batmana so Supermanom. Je jasné, že Superman je silnejší, ale Batman ho dokázal poraziť, pretože bol praktickejší a presne vedel, čo robí.
A nasledujúca časť – to je Rozšírenie PromQL.
Ešte raz o VictoriaMetrics. Čo je to VictoriaMetrics? Je to databáza časových radov, je open source, distribujeme ju v single a cluster verziách. Podľa našich benchmarkov je najrýchlejšia na trhu a v oblasti kompresie podobne, t. j. živí ľudia hlásia kompresiu okolo 0,4 bajtov na bod, zatiaľ čo u Prometheusa je to 1,2-1,4.
Nepodporujeme len Prometheus. Podporujeme aj InfluxDB, Graphite, OpenTSDB.
Môžete do nás "písať", t. j. môžete prenášať staré dáta.
A ešte ideálne fungujeme s Prometheusom a Grafanou, t. j. podporujeme PromQL engine. A v Grafane môžete jednoducho zmeniť Prometheus endpoint na VictoriaMetrics a všetky vaše dashboardy budú fungovať ako predtým.
Môžete však využiť aj ďalšie funkcie, ktoré ponúka VictoriaMetrics.
Rýchlo prejdeme funkciami, ktoré sme pridali.
Omit interval param – môžete preskočiť interval parametrov v Grafane. Keď nechcete dostávať zvláštne grafy pri priblížení alebo oddialení na paneli, je odporúčané použiť premennú $__interval. Je to vnútorná premenná Grafany a sama vyberá rozsah dát. VictoriaMetrics dokáže tiež pochopiť, aký tento rozsah by mal byť. Nemusíte aktualizovať všetky vaše dotazy. Bude to oveľa jednoduchšie.
Druhá funkcia – to je intervalové odkazovanie. Tento interval môžete použiť vo svojich výrazoch. Môžete ho násobiť, deliť, prenášať, odkazovať na neho.
Ďalej je tu rodina funkcií rollup. Funkcia rollup transformuje akýkoľvek váš časový rad na tri samostatné časové rady. To sú min, max a avg. Považujem to za veľmi užitočné, pretože to môže občas ukázať nejaké odľahlé hodnoty (anomálie) a nepresnosti.
A ak jednoducho robíte irate alebo rate, pravdepodobne môžete vynechať niektoré prípady, keď sa časový rad správa inak, než ste predpokladali. S touto funkciou je oveľa jednoduchšie vidieť, že max je veľmi silno od avg.
Ďalej premenná default. Default znamená, akú hodnotu potrebujeme zobraziť v Grafane, ak momentálne nemáme časový rad. Kedy sa to stane? Povedzme, že exportujete nejakú metriku chýb. A máte také skvelé aplikácie, že keď ste začali, nemáte chyby a dokonca žiadne chyby nemáte nasledujúce tri hodiny alebo aj deň. A máte dashboardy, ktoré ukazujú vzťah medzi úspechom a chybou. A budú vám zobrazovať nič, pretože nemáte metriku chýb. A v default môžete uviesť čokoľvek.
Keep_last_Value – uchováva poslednú hodnotu metriky, ak zmizla. Ak Prometheus po nasledujúcom skenovaní nenašiel metriku v priebehu 5 minút, tu zapamätáme jej poslednú hodnotu a vaše grafy sa opäť nerozpadnú.
Scrape_interval – ukazuje, ako často Prometheus zbiera dáta o vašej metrike, s akou frekvenciou. Tu môžete vidieť vynechanie, napríklad.
Label replace – populárna funkcia. Ale považujeme ju za trochu zložitú, pretože vyžaduje množstvo argumentov. A musíte si nielen pamätať 5 argumentov, ale aj ich poradie.
Preto, prečo ich neurobiť jednoduchšie? T. j. rozdeliť na malé funkcie s jasnou syntaxou.
A teraz prichádza to zaujímavé. Prečo považujeme toto za rozšírený PromQL? Pretože podporujeme spoločné tabuľkové výrazy. Môžete prejsť na QR kód (), pozrieť si odkazy s príkladmi, s playgroundom, kde môžete vykonávať dotazy priamo vo VictoriaMetrics bez jej inštalácie, jednoducho v prehliadači.
A čo to vlastne je? Tento dotaz vyššie – to je pomerne populárny dotaz. Myslím, že v akomkoľvek dashboarde v mnohých firmách používate rovnaký filter pre všetko. Zvyčajne je to tak. Ale keď potrebujete pridať nejaký nový filter, musíte aktualizovať každý panel, alebo stiahnuť dashboard, otvoriť ho v JSON, robiť find replace, čo tiež trvá čas. Prečo by sme nemohli uložiť túto hodnotu do premennej a znovu ju použiť? To vyzerá podľa mňa oveľa jednoduchšie a zrozumiteľnejšie.
Napríklad, keď musím aktualizovať filtre v Grafane vo všetkých dotazoch, a dashboard môže byť pri tom obrovský alebo ich môže byť aj niekoľko. A ako by som chcel vyriešiť tento problém v Grafane?
Riešim tento problém takto: vytvorím commonFilter a v ňom definujem tento filter, a potom ho znovu používam v dotazoch. Ale ak to teraz urobíte rovnako, nebude to fungovať, pretože Grafana vám nedovolí používať premenné vo vnútri dotazov premiérnych. A to je trochu zvláštne.
A preto som vytvoril takú variantu, ktorá to umožňuje. A ak vás to zaujíma alebo chcete takú funkciu, podporte ju alebo dajte dislike, ak sa vám táto myšlienka nepáči.
Ďalej o rozšírenom PromQL. Tu definujeme nielen premennú, ale priamo celú funkciu. A nazývame ju ru (resource usage). A táto funkcia prijíma voľné zdroje, obmedzenie zdrojov a filter. Zdá sa, že syntax je celkom jednoduchá. A je veľmi ľahké použiť túto funkciu a vypočítať percento voľnej pamäte u nás. T. j. koľko máme pamäte, aké obmedzenie a ako filtrovať. To vyzerá oveľa pohodlnejšie, ak by ste to všetko písali, znovu používajúc rovnaké filtre, pretože by sa to premenilo na veľký-veľký dotaz.
A tu je príklad takého veľkého dopytu. Pochádza z oficiálneho panelu NodeExporter pre Grafana. Ale príliš dobre nerozumiem, čo sa tu deje. T. j., samozrejme, rozumiem, ak sa na to pozriete pozornejšie, ale množstvo zátvoriek môže okamžite znížiť motiváciu snažiť sa pochopiť, čo sa tu deje. A prečo to neuľahčiť a nezjednodušiť?
Napríklad takto, pričom sa dôležité veci alebo časti zvýraznia v premenných. A potom sa vykoná základná matematika. Toto už viac pripomína programovanie, to je to, čo by som chcel vidieť v budúcnosti v Grafane.
Tu je druhý príklad, ako to môžeme urobiť ešte jednoduchšie, keby sme už mali túto funkciu ru, a ona už existuje priamo vo VictoriaMetrics. A potom jednoducho predáte cacheovanú hodnotu, ktorú ste vyhlásili v CTE.
Už som hovoril o tom, ako je dôležité používať správny programovací jazyk. A asi v každej spoločnosti sa v Grafane deje niečo vlastné. A určite dávate prístup k Grafane svojim vývojárom, ktorí robia niečo vlastné. A všetci to robia nejako inak. Rád by som to videl aspoň nejako jednotne, t. j. zúžiť to na spoločný štandard.
Predpokladajme, že máte nielen systémových inžinierov, možno máte aj expertov, devops alebo SRE. Môže byť, že máte expertov, ktorí vedia, čo je monitoring, vedia, čo je Grafana, t. j. pracujú s tým roky a presne vedia, ako to robiť správne. A už to písali 100-krát a všetkým to vysvetlili, ale prečo si ich nikto nevšíma.
A čo keby mohli tieto znalosti priamo vložiť do Grafany, aby ich mohli iní používatelia znova použiť? A ak by bolo potrebné vypočítať percento voľnej pamäte, jednoducho by použili funkciu. A čo ak by tvorcovia exportérov spolu so svojím produktom poskytli aj súbor funkcií, ako pracovať s ich metrikami, pretože presne vedia, aké sú to metriky a ako ich správne vypočítať?
Toto vlastne neexistuje. To som urobil sám. Je to podpora knižníc v Grafane. Predpokladajme, že chlapci, ktorí vytvorili NodeExporter, urobili to, o čom hovorím. A tiež poskytli súbor funkcií.
T. j. vyzerá to asi takto. Pripojíte túto knižnicu do Grafany, prejdete do editácie a tu je veľmi jednoducho napísané v JSON, ako pracovať s touto metríkou. T. j. nejaký súbor funkcií, ich opísanie a do čoho sa rozvinú.
Myslím, že by to mohlo byť užitočné, pretože potom by ste v Grafane písali jednoducho tak. A Grafana "hovorí", že existuje takáto funkcia z tejto knižnice – poďme ju použiť. Mám pocit, že by to bolo veľmi skvelé.
Trochu o VictoriaMetrics. Robíme veľa zaujímavých vecí. Prečítajte si naše články o kompresii, naše súťaže s inými aplikáciami na časové rady, naše vysvetlenie, ako pracovať s PromQL, pretože v tom je ešte veľa nováčikov, a takisto o vertikálnej škálovateľnosti a o konfrontácii so Thanosom.
Otázky:
Začnem svoju otázku jednoduchým príbehom zo života. Keď som prvýkrát začal používať Grafanu, napísal som veľmi presvedčivý dotaz s dĺžkou 5 riadkov. Nakoniec som dostal veľmi presvedčivý graf. Tento graf takmer šiel do produkcie. Ale pri bližšom skúmaní sa ukázalo, že tento graf ukazuje absolútnu nezmysel, ktorá nemá nič spoločné s realitou, hoci čísla sa nachádzajú v rozsahu, ktorý sme očakávali vidieť. A moja otázka. Máme knižnice, máme funkcie, ale ako píšeme testy pre Grafanu? Napísali ste zložitý dotaz, od ktorého závisí obchodné rozhodnutie – objednať skutočný kontajner serverov alebo nie. A ako vieme, že tá funkcia, ktorá kreslí graf, vyzerá pravdivo. Ďakujem.
Ďakujem za otázku. Tu sú dve časti. Prvá – mám pocit, vychádzajúc z mojej praxe, že väčšina používateľov, keď sa pozerá na svoje grafy, nechápe, čo im ukazujú. Nejakým spôsobom sú ľudia veľmi dobrí v tom, aby si vymysleli ospravedlnenie akejkoľvek anomálie, ktorá sa objavuje na grafoch, aj keď je to chyba vnútri funkcie. A druhá časť – mám pocit, že použitie takýchto funkcií by oveľa lepšie vyhovovalo riešeniu vašej problémy, namiesto toho, aby každý z vašich vývojárov robil svoj capacity planning a robil chyby s nejakou pravdepodobnosťou.
Ako skontrolovať?
Ako skontrolovať? Snáď nijako.
V podobe testu v Grafane.
Čo má Grafana spoločné? Grafana prevádza tento dotaz priamo do DataSource.
Pridaním trochu do parametrov.
Nie, v Grafana sa nič nepridáva. Môžu tam byť GET parametre, ako napríklad step. Nie je to jasne uvedené, ale môžete ho predefinovať, alebo nemusíte, ale pridáva sa automaticky. Tu nemôžete napísať testy. Myslím si, že by ste sa na Grafana nemali spoliehať ako na zdroj pravdy.
Ďakujem za prezentáciu! Ďakujem za kompresiu! Spomínali ste mapovanie premennej v grafe, že v Grafana nemožno použiť premennú v premennej. Rozumiete, o čom hovorím?
Áno.
To bola spočiatku veľká bolest' hlavy, keď som chcel vytvoriť alert v Grafana. A tam treba robiť alert pre každého hostiteľa zvlášť. Funguje tento nástroj, ktorý ste vytvorili, pre alerty v Grafana?
Ak Grafana neoslovuje premenné nejakým iným spôsobom, tak – áno, bude to fungovať. Ale moja rada je, aby ste alertovanie v Grafana nepoužívali vôbec, je lepšie použiť alertmanager.
Áno, používam ho, ale len sa mi to v Grafana zdalo jednoduchšie na nastavenie, ale ďakujem za radu!
Zdroj: habr.com
