«ExtendedPromQL» — разшифровка на доклада на Роман Хавроненко

Предлагам да се запознаете с разширената интерпретация на доклада на Роман Хавроненко "ExtendedPromQL"

Накратко за мен. Казвам се Роман. Работя в CloudFlare, живея в Лондон. Но също така съм мейтенер на VictoriaMetrics.
И аз съм автор на ClickHouse плъгина за Grafana и ClickHouse-proxy – това е малък прокси за ClickHouse.

Ще започнем с първата част, която се нарича „Сложности при превода“ и в нея ще говоря за това, че всеки език или дори просто език на общуване – това е много важно. Защото това е начинът, по който предавате на друг човек или система своите мисли, как формулирате запитването си. Хората в интернет спорят кой език е по-добър – java или някой друг. За себе си реших, че трябва да избирате в зависимост от задачата, защото всичко това е специфично.

Да започнем от самото начало. Какво е PromQL? PromQL – това е език за запитвания на Prometheus. Това е начинът, по който формираме запитвания в Prometheus, за да получим time series данни, времеви редици.

Какво представляват time series данните? Буквално, това са три параметъра.

Това е:

• На какво гледаме.
• Кога гледаме на това.
• И каква стойност показва.

Ако погледнем тази диаграма (това е диаграмата от моя телефон, която показва статистиката на стъпките ми), можем бързо да отговорим на тези въпроси.

Гледаме на стъпките. Виждаме стойността и виждаме времето, когато гледаме на нея. Т.е. гледайки на тази диаграма, лесно можем да кажем, че в неделя съм изминал около 15 000 стъпки. Това са time series данни.

Сега нека "преобразуваме" (конвертираме) данните в друг модел на данни под формата на таблица. Тук също имаме това, което наблюдаваме. Добавих малко допълнителни данни, които ще наречем мета-данни, т.е. това не съм аз, а двама души, да кажем, Jay и Silent Bob. Ето на какво обръщаме внимание; какво показва и кога показва тази стойност.

Сега нека се опитаме да запазим всичките тези данни в база данни. За пример взех синтаксиса на ClickHouse. И тук създаваме една таблица, която се нарича „Steps“, т.е. на какво гледаме. Тук има време, когато гледаме на това; какво показва и някакви мета-данни, където ще съхраняваме, кой е: Jay и Silent Bob.

И за да се опитаме да визуализираме всичко това, ще използваме Grafana, защото, първо, това е красиво.

Също така ще използваме този плъгин. Има две причини за това. Първата е, че аз го написах. И знам колко е трудно да се извлекат данни за времеви серии от ClickHouse, за да се покажат в Grafana.

Ще показваме в Graph Panel. Това е най-популярната панел в Grafana, която показва зависимостта на стойността от времето, така че ни трябват само два параметъра.

Нека напишем най-простата заявка — как да покажем статистика за стъпките в Grafana, като съхраняваме тези данни в ClickHouse, в таблицата, която създадохме. И написваме такава проста заявка. Избираме от стъпките. Избираме стойността и времето на тези стойности, т.е. същите три параметъра, за които говорихме.

И в резултат получаваме такъв график. Знае ли някой защо изглежда толкова странно?

Правилно, трябва да се сортира по време.

В крайна сметка ще получим вече малко по-добре, но все още странен график. Знае ли някой защо? Правилно, там са двама участници и в Grafana предаваме две времеви серии, защото ако разгледаме отново дата модела, всяка времева серия е уникална комбинация от име и всички ключ-стойности на етикетите.

Затова трябва да изберем конкретен човек. Избираме Jay.

И рисуваме отново. Сега графикът вече изглежда нормално. Сега е нормален график и всичко работи добре.

И вероятно знаете как да направите нещо подобно, но в Prometheus чрез PromQL. Приблизително така. Малко по-лесно. И освен това ще разделим всичко. Взимахме Steps. И филтрираме по Jay. Тук не казваме, че ни трябва да получим стойност и не избираме време.

А сега да опитаме да пресметнем скоростта на движение на Jay или Silent Bob. В ClickHouse ще трябва да направим runningDifference, т.е. да изчислим разликата между двойки точки и да я разделим на времето, за да получим точната скорост. Заявката ще изглежда приблизително така.

И тя ще покаже приблизително такива стойности, т.е. около 1,8 стъпки в секунда прави Silent Bob или Jay.

И в Prometheus знаете как да го направите също. Много по-лесно, отколкото беше преди.

И за да бъде това толкова лесно да се прави в Grafana, добавих такава обвивка, която изглежда много сходно с PromQL. Тя се нарича Rate Macros или както искате я наречете. В Grafana просто пишете "rate", но дълбоко в системата тя се трансформира в такъв голям заявка. И не е нужно дори да я гледате, тя е там, но спестявате много време, защото писането на такива огромни SQL заявки винаги е изтощително. Лесно можете да сгрешите и след това дълго да не разберете какво се случва.

А това е заявка, която не се побра дори на един слайд и ми се наложи да я разделя на две колони. Това също е заявка в ClickHouse, която прави същото rate, но за двете времеви серии: и за Silent Bob, и за Jay, за да имаме две времеви серии на панела. И вече е много сложно, според мен.

И за Prometheus това ще бъде sum(rate). За ClickHouse направих отделен макрос, който се нарича RateColumns, който изглежда като заявка в Prometheus.

Погледнахме и изглежда, че PromQL е страхотен, но разбира се, има своите ограничения.

Това е:

• Ограничен SELECT.
• Гранични JOIN.
• Няма поддръжка за HAVING.

И ако сте работили дълго с него, знаете, че понякога е много трудно да направите нещо в PromQL, докато в SQL можете да правите почти всичко, защото всички тези варианти, които обсъдихме, могат да бъдат направени в SQL. Но дали би било удобно да се ползва? Това ме накара да се замисля, че не винаги най-силният език може да бъде най-удобният.

Затова понякога трябва да избирате език според задачите. Това е като битка между Батман и Супермен. Ясно е, че Супермен е по-силен, но Батман успя да го победи, защото е по-практичен и знаеше точно какво прави.

Следващата част е това - Разширяване на PromQL.

Още веднъж за VictoriaMetrics. Какво е VictoriaMetrics? Това е база данни за времеви серии, тя е с отворен код, дистрибутираме я в единична и клъстерна версия. Според нашите бенчмаркове, тя е най-бързата на пазара в момента и по компресия, т.е. реални хора докладват компресия от около 0,4 байта на точка, докато при Prometheus - 1,2-1,4.

Поддържаме не само Prometheus. Поддържаме InfluxDB, Graphite, OpenTSDB.

В нас може да се "писа", т.е. можем да прехвърляме стари данни.

И освен това работим идеално с Prometheus и Grafana, тоест поддържаме PromQL engine. В Grafana просто можете да смените Prometheus endpoint на VictoriaMetrics и всичките ви дашбордове ще работят, както преди.

Но вие можете да използвате и допълнителни функции, които предоставя VictoriaMetrics.

Бързо ще минем през функциите, които добавихме.

Omit interval param – можете да пропуснете интервалния параметър в Grafana. Когато не искате да получавате странни графики при zoom-in/out в панела, препоръчително е да използвате променливата $__interval. Това е вътрешна променлива на Grafana и тя сама избира диапазона на данните. И VictoriaMetrics може сама да разбира какъв да бъде този диапазон. Няма нужда да обновявате всички ваши запитвания. Ще бъде много по-лесно.

Втората функция е интервално рефериране. Можете да използвате този интервал във вашите изрази. Можете да го умножавате, делите, предавате, реферирате.

Следва семейството на rollup функции. Rollup функцията трансформира всяка ваша времева серия в три отделни времеви серии. Това са min, max и avg. Смятам, че това е много удобно, защото понякога може да покаже някакви аномалии и неточности.

Ако просто правите irate или rate, вероятно можете да пропуснете някои случаи, когато времевата серия се държи по различен начин от предположеното. С тази функция е много по-лесно да се види, например, че max е много далеч от avg.

Следва променливата default. Default означава каква стойност трябва да визуализираме в Grafana, ако в момента нямаме времева серия. Кога се случва това? Например, когато експортирате метрика за грешки. И имате толкова хубаво приложение, че когато стартирахте, нямате грешки и дори през следващите три часа или ден. Имате дашборди, които показват съотношението success към error. И те ще ви показват нищо, защото нямате метрика за грешки. А в default можете да зададете каквото и да е.

Keep_last_Value – запазва последната стойност на метриката, ако тя се е загубила. Ако Prometheus след следващото скрейпване не я е намерил в течение на 5 минути, ние ще запомним последната й стойност и графиките ви отново няма да се повредят.

Scrape_interval – показва колко често Prometheus събира данни за вашата метрика, с каква честота. Тук можете да видите пропуски, например.

Label replace – популярна функция. Но смятаме, че е малко сложна, тъй като приема множество аргументи. И трябва да помните не само 5 аргумента, но и тяхната последователност.

Затова, защо да не ги направим по-прости? Т.е. да ги разбием на по-малки функции с разбираем синтаксис.

И сега най-интересното. Защо считаме, че това е разширен PromQL? Защото поддържаме общи таблици. Можете да сканирате QR кода (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), да видите линкове с примери, с playground, където можете да изпълнявате запитвания директно в VictoriaMetrics без инсталиране, просто в браузъра.

И какво е това? Това запитване отгоре е доста популярно. Мисля, че във всеки дашборд в много компании използвате един и същ филтър за всичко. Обикновено е така. Но когато трябва да добавите някакъв нов филтър, трябва да актуализирате всяка панелка или да изтеглите дашборда, да го отворите в JSON, да направите намери и замени, което също отнема време. Защо да не съхранявате това значение в променлива и да го преизползвате? Според мен, това изглежда много по-просто и разбираемо.

Например, когато трябва да актуализирам филтри в Grafana във всички запитвания, а дашбордът може да е огромен или дори да има няколко. И как бих искал да реша този проблем в Grafana?

Решавам този проблем така: правя commonFilter и в него определям този филтър, а след това го преизползвам в запитванията. Но ако направите същото сега, това няма да работи, защото Grafana не ви позволява да използвате променливи вътре в променливи запитвания. И това е малко странно.

И затова направих такъв вариант, който позволява да се прави това. И ако сте заинтересовани или искате такава функция, то подкрепете или дайте нехаресване, ако не ви харесва идеята. https://github.com/grafana/grafana/pull/16694

По-нататък относно разширенията на PromQL. Тук определяме не само променлива, но и цяла функция. И я наричаме ru (използване на ресурси). Тази функция приема свободни ресурси, ограничения по ресурсите и филтър. Синтаксисът изглежда доста прост. Много е лесно да се използва тази функция и да се изчисли процентът на свободната памет у нас. Т.е. колко памет разполагаме, какво е ограничението и как да филтрираме. Това изглежда много по-удобно, ако пишете всичко, преизползвайки същите филтри, тъй като това би се превърнало в голямо запитване.

Ето пример за такъв голям-групен запит. Той идва от официалния дашборд на NodeExporter за Grafana. Но не разбирам напълно какво става тук. Тоест, разбира се, разбирам, ако се вгледам по-внимателно, но броят на скобите може веднага да намали мотивацията да разбера какво всъщност се случва. И защо не го направим по-просто и разбираемо?

Например, така, като подчертаем важните неща или части в променливи. И после да направим своята основна математика. Това вече е по-близо до програмирането, това е, което бих искал да видя в бъдеще в Grafana.

Ето втори пример как можем да направим това още по-просто, ако вече имахме тази функция ru, която всъщност вече я има в VictoriaMetrics. И просто предавате кешираната стойност, която сте обявили в CTE.

Вече споменах, колко е важно да се използва правилният език за програмиране. Вероятно във всяка компания с Grafana се случва нещо свое. И вероятно давате достъп на разработчиците си до Grafana, и те правят нещо свое. И всички те го правят по различен начин. А бих искал да бъде по един и същи начин, тоест да се сведе до общ стандарт.

Да предположим, че имате не просто системни инженери, а може дори експерти, девопси или SRE. Може да имате експерти, които знаят какво е мониторинг, знаят какво е Grafana, тоест те работят с това от години и наистина знаят как да го направят правилно. Те вече са го написали 100 пъти и са го обяснявали на всички, но по някаква причина никой не слуша.

А какво, ако тези знания можеха да бъдат интегрирани директно в Grafana, за да могат другите потребители да преизползват функциите? И ако трябваше да изчислим процента свободна памет, просто щяха да приложат функция. А какво, ако създателите на експортери, заедно с продукта си, предоставяха и набор от функции, как да работят с метриките им, защото те точно знаят какви са тези метрики и как да ги изчисляват правилно?

Това наистина не съществува. Това го направих сам. Това е поддръжка на библиотеки в Grafana. Да предположим, че хората, които направиха NodeExporter, направиха това, за което говорих. И също така предоставиха набор от функции.

Т.е. изглежда това приблизително така. Вие свързвате тази библиотека в Grafana, влизате в редактиране и тук много просто в JSON е написано как да работите с тази метрика. Т.е. някакъв набор от функции, тяхното описание и в какво се трансформират.

Според мен това би било полезно, защото тогава в Grafana просто бихте писали така. И Grafana ви "казва", че е налична такава функция от определена библиотека – нека я използваме. Смятам, че това би било наистина страхотно.

Няколко думи за VictoriaMetrics. Ние правим много интересни неща. Прочетете нашите статии за компресия, за нашите състезания с други приложения за time series данни, нашето обяснение как да работите с PromQL, защото много хора все още са новаци в това, а също така за вертикалната скалируемост и сблъсъка с Thanos.

Въпроси:

Започвам въпроса си с една проста житейска история. Когато за първи път започнах да използвам Grafana, написах много убедителен запитване с дължина 5 реда. В резултат на това получих много убедителен график. Този график почти беше готов за продукция. Но при по-подробен преглед се оказа, че този график показва абсолютна глупост, която няма нищо общо с реалността, въпреки че цифрите попадат в диапазона, който очаквахме да видим. И моята стъпка е. Имаме библиотеки, имаме функции, а как пишем тестове за Grafana? Написали сте сложен запит, от който зависи бизнес решение - да поръчате истински контейнер от сървъри или не. И как знаем, че тази функция, която рисува график, изглежда като истинска. Благодаря.

Благодаря за въпроса. Тук има две части. Първата – имам впечатление, основаващо се на моя опит, че повечето потребители, когато гледат на графиците си, не разбират какво им показват. По някаква причина хората са много добри в измислянето на оправдания за всяка аномалия, която се случва на графиците, дори ако това е грешка в самата функция. А втората част – смятам, че използването на такива функции би било много по-добро решение на вашия проблем, вместо всеки от вашите разработчици да прави собствено планиране на капацитета и да греши с някаква вероятност.

Как да проверим?

Как да проверим? Може би, по никакъв начин.

Във вид на тест в Grafana.

Какво общо има тук с Grafana? Grafana предава този запит директно към DataSource.

Добавяйки малко в параметрите.

Не, в Grafana не добавят нищо. Там могат да бъдат GET параметри, като например step. Той не се указва явно, но може да бъде преназначен, или да не се преназначава, но се добавя автоматично. Тук не можете да напишете тестове. Мисля, че не бива да разчитате на Grafana като на източник на истина.

Благодаря за доклада! Благодаря за компресията! Вие споменахте за мапинга на променлива в графиката, че в Grafana не може да се използва променлива в променлива. Разбирате ли за какво говоря?

Да.

Първоначално това беше главоболие, когато исках да направя аларма в Grafana. И там трябва да се прави аларма за всеки хост поотделно. Тази функция, която направихте, работи ли за алармите в Grafana?

Ако Grafana не се отнася към променливите по различен начин, то да, тя ще работи. Но моят съвет е да не използвате аларми в Grafana изобщо, по-добре е да използвате alertmanager.

Да, използвам го, но просто в Grafana изглеждаше по-лесно за настройка, но благодаря за съвета!

Източник: habr.com