"ExtendedPromQL" - препис на доклада на Роман Хавроненко

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

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

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

Да започнем от самото начало. Какво е PromQL? PromQL е Prometheus Query Language. Ето как формираме заявки в Prometheus, за да получим данни от времеви серии, времеви серии.

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

Те са:

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

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

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

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

Сега нека се опитаме да съхраним всички тези данни в базата данни. Например взех синтаксиса на ClickHouse. И тук създаваме една таблица, наречена "Стъпки", т.е. това, което гледаме. Тук има време, когато го разглеждаме; какво показва и някои метаданни, където ще съхраняваме кой е: Джей и Тихият Боб.

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

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

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

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

И в резултат получаваме тази графика. Кой знае защо е толкова странен?

Точно така, трябва да сортирате по време.

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

Следователно трябва да изберем конкретен човек. Ние избираме Джей.

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

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

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

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

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

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

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

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

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

Те са:

• Ограничен ИЗБОР.
• Edge JOINs.
• Няма поддръжка.

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

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

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

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

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

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

И също така работим перфектно с Prometheus и Grafana, т.е. поддържаме PromQL двигателя. А в Grafana можете просто да промените крайната точка на Prometheus на VictoriaMetrics и всичките ви табла за управление ще работят както са работили.

Но можете да използвате и допълнителни чипове, предоставени от VictoriaMetrics.

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

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

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

Следва фамилията функции за събиране. Функцията за обобщаване трансформира всяка от вашите времеви серии в три отделни времеви серии. Това са мин., макс. и ср. Намирам го за много удобно, защото понякога може да покаже някои отклонения (аномалии) и неточности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Според мен това може да е полезно, защото тогава щеше да се пише на Графана просто така. И Графана ви "казва", че има такава и такава функция от такава и такава библиотека - нека да я използваме. Мисля, че би било много готино.

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

въпроси:

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

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

Как да проверя?

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

Като тест в Графана.

А какво да кажем за Графана? Grafana превежда тази заявка директно към DataSource.

Като добавим малко към параметрите.

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

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

Да.

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

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

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

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