Navrhujem, aby ste si prečítali prepis správy Romana Khavronenka „ExtendedPromQL“
Stručne o mne. Volám sa Roman. Pracujem v CloudFlare a žijem v Londýne. Ale som tiež správcom VictoriaMetrics.
A autorom som ja pre Grafana a je malý proxy server pre ClickHouse.
Začneme prvou časťou, ktorá sa volá “Ťažkosti prekladu” a v nej budem hovoriť o tom, že veľmi dôležitý je akýkoľvek jazyk alebo aj len jazyk komunikácie. Pretože takto prenášate svoje myšlienky na inú osobu alebo systém, ako formulujete požiadavku. Ľudia na internete sa hádajú, ktorý jazyk je lepší - java alebo nejaký iný. Pre seba som sa rozhodol, že si musím vybrať podľa úlohy, pretože toto všetko je špecifické.
Začnime od úplného začiatku. Čo je PromQL? PromQL je dopytovací jazyk Prometheus. Takto vytvárame dopyty v Prometheus, aby sme získali údaje o časových radoch.
Čo sú údaje časových radov? Doslova ide o tri parametre.
Sú to:
- Na čo sa pozeráme?
- Keď sa na to pozrieme.
- A akú hodnotu to ukazuje?
Ak sa pozriete na tento graf (tento graf je z môjho telefónu, ktorý zobrazuje moje štatistiky krokov), môže rýchlo odpovedať na tieto otázky.
Pozeráme sa na kroky. Vidíme zmysel a vidíme čas, keď sa na to pozeráme. To znamená, že pri pohľade na tento diagram môžete ľahko povedať, že v nedeľu som prešiel asi 15 000 krokov. Ide o údaje z časových radov.
Teraz ich „rozdeľme“ (prekonvertujme) do iného dátového modelu vo forme tabuľky. Aj tu máme to, na čo sa pozeráme. Tu som pridal malé dodatočné údaje, ktoré budeme nazývať metadáta, t. j. neprešiel som tým ja, ale dvaja ľudia, napríklad Jay a Tichý Bob. Toto je to, na čo sa pozeráme; čo ukazuje a kedy ukazuje tú hodnotu.
Teraz sa pokúsime uložiť všetky tieto údaje do databázy. Napríklad som vzal syntax ClickHouse. A tu vytvoríme jednu tabuľku s názvom „Kroky“, teda to, na čo sa pozeráme. Je čas, keď sa na to pozeráme; čo zobrazuje a niektoré metaúdaje, kde budeme ukladať, kto to je: Jay a Tichý Bob.
A aby sme sa pokúsili toto všetko vizualizovať, použijeme Grafana, pretože je v prvom rade krásna.
Tento plugin použijeme aj my. Sú na to dva dôvody. Prvý je preto, že som to napísal. A presne viem, aké ťažké je získať údaje časových radov z ClickHouse, aby ste ich mohli zobraziť v Grafane.
Zobrazíme ho na paneli grafov. Toto je najobľúbenejší panel v Grafane, ktorý zobrazuje závislosť hodnoty od času, takže potrebujeme iba dva parametre.
Napíšeme najjednoduchší dotaz – ako zobraziť štatistiku krokov v Grafane, pričom tieto údaje sú uložené v ClickHouse, v tabuľke, ktorú sme vytvorili. A my píšeme túto jednoduchú požiadavku. Vyberáme z krokov. Vyberieme hodnotu a vyberieme čas týchto hodnôt, teda tie isté tri parametre, o ktorých sme hovorili.
A ako výsledok dostaneme takýto graf. Ktovie, prečo je taký zvláštny?
Presne tak, musíme triediť podľa času.
A nakoniec dostaneme lepší, no stále zvláštny rozvrh. ktovie prečo? Je to tak, sú dvaja účastníci a my v Grafane rozdávame dva časové rady, pretože ak sa znova pozriete na dátový model, potom každý časový rad je jedinečnou kombináciou názvu a všetkých označení kľúč-hodnota.
Preto si musíme vybrať konkrétneho človeka. Vyberáme Jaya.
A poďme znova kresliť. Teraz graf vyzerá ako pravda. Teraz je to normálny rozvrh a všetko funguje dobre.
A asi viete, ako urobiť zhruba to isté, ale v Prometheus cez PromQL. Niečo také. Trochu jednoduchšie. A poďme si to celé rozobrať. Urobili sme Kroky. A filtrovať podľa Jaya. Nešpecifikujeme tu, že potrebujeme získať hodnotu a nevyberáme si čas.
Teraz skúsme vypočítať rýchlosť pohybu Jaya alebo Tichého Boba. V ClickHouse budeme musieť urobiť runningDifference, t.j. vypočítať rozdiel medzi pármi bodov a vydeliť ich časom, aby sme získali presnú rýchlosť. Žiadosť bude vyzerať asi takto.
A ukáže približne tieto hodnoty, t.j. Tichý Bob alebo Jay trvá približne 1,8 kroku za sekundu.
A v Prometheus to tiež viete. Oveľa jednoduchšie ako predtým.
A aby to bolo jednoduché aj v Grafane, pridal som tento obal, ktorý vyzerá veľmi podobne ako PromQL. Volá sa to makrá na hodnotenie alebo ako to nazvať. V Grafane jednoducho napíšete „sadzba“, ale niekde hlboko sa to pretaví do tejto veľkej požiadavky. A nemusíte sa na to ani pozerať, niekde to je, ale ušetríte veľa času, pretože písanie takýchto obrovských SQL dopytov je vždy drahé. Ľahko sa môžete pomýliť a potom dlho nebudete rozumieť tomu, čo sa deje.
A to je požiadavka, ktorá sa nezmestila ani do jednej snímky a dokonca som ju musel rozdeliť do dvoch stĺpcov. Toto je požiadavka aj v ClickHouse, ktorý robí rovnakú sadzbu, ale pre oba časové rady: Silent Bob a Jay, takže na paneli máme dva časové rady. A to je už podľa mňa veľmi ťažké.
A podľa Promethea to bude súčet (sadzba). Pre ClickHouse som vytvoril samostatné makro s názvom RateColumns, ktoré vyzerá ako dotaz v Prometheus.
Pozreli sme sa na to a zdá sa, že PromQL je taký skvelý, ale má, samozrejme, obmedzenia.
Sú to:
- Obmedzený SELECT.
- Hraničné JOINY.
- Bez podpory.
A ak s tým pracujete dlho, viete, že niekedy je veľmi ťažké niečo urobiť v PromQL, ale v SQL sa dá robiť takmer všetko, pretože všetky tieto možnosti, o ktorých sme práve hovorili, sa dajú urobiť v SQL . Ale bolo by vhodné ho použiť? A to ma núti myslieť si, že najsilnejší jazyk nemusí byť vždy ten najpohodlnejší.
Preto si niekedy musíte zvoliť jazyk úlohy. Je to ako keď Batman bojuje so Supermanom. Je jasné, že Superman je silnejší, no Batman ho dokázal poraziť, pretože je praktickejší a presne vedel, čo robí.
A ďalšia časť je Extending PromQL.
Ešte raz o VictoriaMetrics. Čo je VictoriaMetrics? Ide o databázu časových radov, je v OpenSource, distribuujeme jej single a cluster verzie. Podľa našich benchmarkov je rýchlejší ako čokoľvek, čo je teraz na trhu, a kompresia je podobná, t.j. skutoční ľudia uvádzajú kompresiu približne 0,4 bajtu na bod, zatiaľ čo Prometheus je 1,2-1,4.
Podporujeme viac ako len Prometheus. Podporujeme InfluxDB, Graphite, OpenTSDB.
Môžete nám „napísať“, to znamená, že môžete preniesť staré dáta.
A perfektne spolupracujeme aj s Prometheus a Grafana, t.j. podporujeme PromQL engine. A v Grafane môžete jednoducho zmeniť koncový bod Prometheus na VictoriaMetrics a všetky vaše ovládacie panely budú fungovať tak, ako fungovali.
Môžete však použiť aj ďalšie funkcie, ktoré poskytuje VictoriaMetrics.
Rýchlo si prejdeme funkcie, ktoré sme pridali.
Vynechať parametre intervalu – v Grafane môžete vynechať parametre intervalu. Ak nechcete, aby sa pri približovaní/odďaľovaní v paneli zobrazovali divné grafy, odporúča sa použiť premennú $__interval. Ide o internú zmenu Grafany a rozsah údajov si vyberá sám. A samotná VictoriaMetrics dokáže pochopiť, aký by mal byť tento rozsah. A nemusíte aktualizovať všetky svoje požiadavky. Bude to oveľa jednoduchšie.
Druhou funkciou je intervalové odkazovanie. Tento interval môžete použiť vo svojich výrazoch. Môžete ho násobiť, deliť, prenášať, odkazovať.
Ďalej je to rodina funkcií súhrnu. Funkcia Rollup transformuje ktorýkoľvek z vašich časových radov na tri samostatné časové rady. Toto sú min, max a priem. Považujem to za veľmi výhodné, pretože niekedy to môže ukázať nejaké odľahlé hodnoty a nepresnosti.
A ak sa len rozčuľujete alebo hodnotíte, potom vám pravdepodobne ujdú prípady, keď sa časové rady nesprávajú tak, ako ste očakávali. S touto funkciou je to oveľa lepšie vidieť, povedzme, že max je veľmi veľa z avg.
Ďalej je predvolená premenná. Predvolené – to znamená, akú hodnotu musíme v Grafane vykresliť, ak práve nemáme časový rad. Kedy sa to stane? Povedzme, že exportujete nejaké chybové metriky. A máte takú skvelú aplikáciu, že keď spustíte, nemáte žiadne chyby a dokonca žiadne chyby ďalšie tri hodiny alebo dokonca deň. A máte informačné panely, ktoré zobrazujú vzťah od úspechu k chybe. A neukážu vám nič, pretože nemáte metriku chýb. A v predvolenom nastavení môžete zadať čokoľvek.
Keep_last_Value – uloží poslednú hodnotu metriky, ak chýba. Ak ho Prometheus nenájde do 5 minút po ďalšom zoškrabaní, tak si tu zapamätáme jeho poslednú hodnotu a vaše grafy sa už nezlomia.
Scrape_interval – ukazuje, ako často Prometheus zhromažďuje údaje o vašej metrike a s akou frekvenciou. Tu môžete vidieť priesmyk napr.
Nahradenie štítkov je obľúbená funkcia. Ale myslíme si, že je to trochu komplikované, pretože si to vyžaduje celé argumenty. A musíte si pamätať nielen 5 argumentov, ale aj ich postupnosť.
Prečo ich teda nezjednodušiť? To znamená, rozložiť ho na malé funkcie so zrozumiteľnou syntaxou.
A teraz tá zábavná časť. Prečo si myslíme, že ide o rozšírený PromQL? Pretože podporujeme bežné tabuľkové výrazy. Môžete sledovať QR kód (), pozrite si odkazy s príkladmi z ihriska, kde môžete spúšťať dopyty priamo vo VictoriaMetrics bez toho, aby ste ho jednoducho nainštalovali do prehliadača.
a čo je toto? Táto vyššie uvedená požiadavka je pomerne populárna. Myslím, že na akomkoľvek dashboarde v mnohých spoločnostiach používate rovnaký filter na všetko. Zvyčajne áno. Ale keď potrebujete pridať nejaký nový filter, musíte aktualizovať každý panel alebo stiahnuť dashboard, otvoriť ho v JSON, nájsť náhradu, čo si tiež vyžaduje čas. Prečo neuložiť túto hodnotu do premennej a znova ju použiť? Toto vyzerá podľa mňa oveľa jednoduchšie a prehľadnejšie.
Napríklad, keď potrebujem aktualizovať filtre v Grafane vo všetkých požiadavkách a dashboard môže byť obrovský alebo ich môže byť dokonca niekoľko. A ako by som chcel tento problém vyriešiť v Grafane?
Tento problém riešim takto: vytvorím spoločný filter a definujem v ňom tento filter a potom ho znova použijem v dotazoch. Ale ak to isté urobíte teraz, nebude to fungovať, pretože Grafana vám neumožňuje používať premenné vo vnútri premenných dotazu. A je to trochu zvláštne.
A tak som vytvoril možnosť, ktorá vám to umožňuje. A ak máte záujem alebo chcete takúto funkciu, podporte ju alebo sa jej nepáči, ak sa vám táto myšlienka nepáči.
Viac o PromQL rozšírené. Tu definujeme nielen premennú, ale celú funkciu. A nazývame to ru (využitie zdrojov). A táto funkcia akceptuje voľné zdroje, obmedzenie zdrojov a filter. Syntax sa zdá byť jednoduchá. A je veľmi jednoduché použiť túto funkciu a vypočítať percento voľnej pamäte, ktorú máme. Teda koľko máme pamäte, aké je obmedzenie a ako filtrovať. Vyzerá to oveľa pohodlnejšie, ak by ste to všetko napísali a znova použili rovnaké filtre, pretože by sa to zmenilo na veľký, veľký dopyt.
A tu je príklad takejto veľkej, veľkej požiadavky. Je to z oficiálneho hlavného panela NodeExporter pre Grafana. Ale sotva rozumiem tomu, čo sa tu deje. To je, samozrejme, chápem, ak sa pozriete pozorne, ale počet zátvoriek môže okamžite znížiť motiváciu pochopiť, čo sa tu deje. A prečo to neurobiť jednoduchšie a prehľadnejšie?
Napríklad, ako je toto, oddelenie významných vecí alebo častí do premenných. A potom urobte základnú matematiku. Toto je už skôr programovanie, toto by som chcel v budúcnosti vidieť v Grafane.
Tu je druhý príklad toho, ako by sme to mohli ešte zjednodušiť, keby sme túto funkciu ru už mali a už existuje priamo vo VictoriaMetrics. A potom jednoducho odošlete hodnotu uloženú vo vyrovnávacej pamäti, ktorú ste deklarovali v CTE.
Už som hovoril o tom, aké dôležité je používať správny programovací jazyk. A pravdepodobne každá spoločnosť v Grafane má niečo iné. A pravdepodobne tiež poskytujete prístup ku Grafane svojim vývojárom a vývojári si robia svoje. A každý to robí nejako inak. Ale chcel som, aby to bolo nejako rovnaké, teda zredukovať to na bežný štandard.
Povedzme, že nemáte iba systémových inžinierov, možno máte dokonca odborníkov, devops alebo SRE. Možno máte odborníkov, ktorí vedia, čo je monitoring, ktorí vedia, čo je Grafana, teda pracujú s ňou roky a presne vedia, ako na to. A už to písali 100x a každému to vysvetlili, ale z nejakého dôvodu to nikto nepočúva.
Čo keby mohli vložiť tieto znalosti priamo do Grafany, aby ostatní používatelia mohli znova použiť funkcie? A ak by potrebovali vypočítať percento voľnej pamäte, jednoducho by použili funkciu. Čo keby tvorcovia exportérov spolu s ich produktom poskytli aj sadu funkcií, ako s ich metrikami pracovať, pretože presne vedia, čo tieto metriky sú a ako ich správne vypočítať?
Toto naozaj neexistuje. Toto som robil ja sám. Toto je podpora knižnice v Grafane. Povedzme, že chlapci, ktorí vytvorili NodeExporter, urobili to, o čom som hovoril. A poskytovali aj súbor funkcií.
To znamená, že to vyzerá asi takto. Túto knižnicu pripojíte k Grafane, pustíte sa do úprav a v JSON je veľmi jednoducho napísané, ako s touto metrikou pracovať. Teda nejaký súbor funkcií, ich popis a na čo sa premenia.
Myslím, že by sa to mohlo hodiť, lebo potom v Grafane by ste písali len tak. A Grafana vám „hovorí“, že existuje taká a taká funkcia z takej a takej knižnice - poďme ju použiť. Myslím, že by to bolo veľmi cool.
Trochu o VictoriaMetrics. Robíme veľa zaujímavých vecí. Prečítajte si naše články o kompresii, o našich súťažiach s inými aplikáciami časových radov, naše vysvetlenie ako pracovať s PromQL, pretože v tomto je ešte veľa začiatočníkov, ako aj o vertikálnej škálovateľnosti a o konfrontácii s Thanosom.
Otázky:
Svoju otázku začnem jednoduchým životným príbehom. Keď som prvýkrát začal používať Grafana, napísal som veľmi pútavý dotaz, ktorý mal 5 riadkov. Konečným výsledkom je veľmi presvedčivý graf. Tento plán sa takmer dostal do výroby. Ale pri bližšom skúmaní sa ukázalo, že tento graf ukazuje absolútny nezmysel, ktorý nemá nič spoločné s realitou, hoci čísla spadajú do rozsahu, ktorý sme očakávali. A moja otázka. Máme knižnice, máme funkcie, ale ako napíšeme testy pre Grafana? Napísali ste komplexnú požiadavku, od ktorej závisí obchodné rozhodnutie - objednať skutočný kontajner serverov alebo neobjednať. A ako vieme, táto funkcia, ktorá kreslí graf, je podobná pravde. Ďakujem.
dakujem za otazku. Sú dve časti. Po prvé, na základe svojich skúseností mám dojem, že väčšina používateľov, keď sa pozrie na svoje grafy, nerozumie tomu, čo im ukazuje. Z nejakého dôvodu sú ľudia veľmi dobrí vo vymýšľaní ospravedlnenia pre akúkoľvek anomáliu, ktorá sa vyskytuje v grafoch, aj keď ide o chybu v rámci funkcie. A druhá časť – zdá sa mi, že používanie takýchto funkcií by bolo oveľa lepším prístupom k riešeniu vášho problému, namiesto toho, aby si každý z vašich vývojárov robil vlastné kapacitné plánovanie a s určitou pravdepodobnosťou robil chyby.
Ako skontrolovať?
Ako skontrolovať? Pravdepodobne nie.
Ako test v Grafane.
Čo s tým má spoločné Grafana? Grafana preloží túto požiadavku priamo do DataSource.
Trochu pridávame k parametrom.
Nie, do Grafany sa nič nepridáva. Môžu existovať parametre GET, ako napríklad krok. Nie je explicitne špecifikovaný, ale môžete ho prepísať, alebo ho nemôžete prepísať, ale pridá sa automaticky. Tu nebudeš písať testy. Nemyslím si, že by sme sa tu mali spoliehať na Grafanu ako na zdroj pravdy.
Ďakujeme za správu! Ďakujem za kompresiu! Spomínali ste mapovanie premennej v grafe, že v Grafane nemôžete použiť premennú v premennej. Viete, čo mám na mysli?
Áno.
Keď som chcel vytvoriť upozornenie v Grafane, spočiatku to bolelo hlavu. A tam treba spraviť upozornenie pre každého hostiteľa zvlášť. Táto vec, ktorú ste vytvorili, funguje pre upozornenia v Grafane?
Ak Grafana nepristupuje k premenným inak, tak áno, bude to fungovať. Ale moja rada je, aby ste upozornenia v Grafane vôbec nepoužívali, radšej použite alertmanager.
Áno, používam to, ale zdalo sa mi to jednoduchšie nastaviť v Grafane, ale ďakujem za radu!
Zdroj: hab.com