«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 предоставяме два времеви реда, защото ако разгледаме отново моделa на данни, всяка времева линия е уникална комбинация от име и всички ключови стойности на етикетите.

Затова трябва да изберем конкретен човек. Избираме 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. Но удобно ли би било да го ползвате? И това ме кара да мисля, че не винаги най-мощният език може да бъде най-удобният.

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

Следващата част – е Extending PromQL.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И затова направих такъв вариант, който позволява да се прави това. И ако ви интересува или искате такава функция, то подкрепете или дайте dislike, ако не харесвате идеята. 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. Правим много интересни неща. Прочетете нашите статии за компресия, за нашите състезания с други приложения за времеви серии данни, нашето обяснение как да работите с PromQL, защото в това има много новаци, а също така за вертикалната мащабируемост и съпротивлението с Thanos.

Вопроси:

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

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

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

Как да проверим? Вероятно, никак.

Под формата на тест в Grafana.

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

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

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

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

Да.

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

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

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

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