Ви предлагам да го прочитате транскриптот од извештајот на Роман Хавроненко „ExtendedPromQL“
Накратко за мене. Моето име е Роман. Работам во CloudFlare и живеам во Лондон. Но, јас сум и одржувач на VictoriaMetrics.
И јас сум авторот за Графана и е мал прокси за ClickHouse.
Ќе започнеме со првиот дел, кој се нарекува „Тешкотии во преводот“ и во него ќе зборувам за фактот дека секој јазик, па дури и само јазик на комуникација е многу важен. Затоа што вака ги пренесувате вашите мисли на друго лице или систем, како формулирате барање. Луѓето на Интернет се расправаат за тоа кој јазик е подобар - Java или некој друг. За себе решив дека треба да изберам според задачата, бидејќи сето ова е специфично.
Да почнеме од самиот почеток. Што е PromQL? PromQL е Prometheus Query Language. Вака формираме барања во Прометеј за да добиеме податоци за временски серии.
Што се податоци за временски серии? Буквално, ова се три параметри.
Ова се:
- Што гледаме?
- Кога ќе го погледнеме.
- И каква вредност покажува?
Ако ја погледнете оваа табела (оваа табела е од мојот телефон што ја покажува мојата статистика за чекори), може брзо да одговори на овие прашања.
Ги гледаме чекорите. Го гледаме значењето и го гледаме времето кога го гледаме. Односно, гледајќи го овој дијаграм, можете лесно да кажете дека во неделата одев околу 15 чекори. Ова се податоци за временски серии.
Сега да ги „поделиме“ (конвертираме) во друг модел на податоци во форма на табела. Овде го имаме и она што го гледаме. Овде додадов малку дополнителни податоци, кои ќе ги наречеме мета-податоци, т.е не бев јас што го поминав ова, туку двајца луѓе, на пример, Џеј и Тивко Боб. Ова е она што го гледаме; што покажува и кога ја покажува таа вредност.
Сега ајде да се обидеме да ги зачуваме сите овие податоци во базата на податоци. На пример, ја зедов синтаксата ClickHouse. И тука создаваме една табела наречена „Чекори“, односно она што го гледаме. Има време кога го гледаме; што покажува и некои мета податоци каде ќе складираме кој е: Џеј и Тивко Боб.
И за да се обидеме да го визуелизираме сето ова, ќе ја користиме Графана бидејќи, пред сè, таа е прекрасна.
Ќе го користиме и овој приклучок. Постојат две причини за ова. Првиот е затоа што јас го напишав. И точно знам колку е тешко да се извлечат податоци за временски серии од ClickHouse за да се прикажат во Графана.
Ќе го прикажеме во Графичкиот панел. Ова е најпопуларниот панел во Графана, кој ја покажува зависноста на вредноста од времето, па ни требаат само два параметри.
Ајде да го напишеме наједноставното барање - како да се прикаже статистиката за чекори во Графана, складирајќи ги овие податоци во ClickHouse, во табелата што ја создадовме. И ние го пишуваме ова едноставно барање. Ние избираме од чекорите. Избираме вредност и го избираме времето на овие вредности, односно истите три параметри за кои зборувавме.
И како резултат на тоа, ќе добиеме ваков график. Кој знае зошто е толку чуден?
Така е, треба да се средиме по време.
И на крајот ќе добиеме подобар, но сепак чуден распоред. Кој знае зошто? Така е, има двајца учесници, а ние во Графана подаруваме две временски серии, бидејќи ако повторно го погледнете моделот на податоци, тогаш секоја временска серија е уникатна комбинација на име и сите ознаки со клучна вредност.
Затоа, треба да избереме одредена личност. Го избираме Џеј.
И пак да цртаме. Сега графикот изгледа како вистина. Сега ова е нормален распоред и се работи добро.
И веројатно знаете како да го направите приближно истото, но во Prometheus преку PromQL. Нешто како ова. Малку поедноставно. И да го срушиме сето тоа. Презедовме чекори. И филтрирајте според Џеј. Овде не прецизираме дека треба да добиеме вредност и не бираме време.
Сега да се обидеме да ја пресметаме брзината на движење на Џеј или Тивко Боб. Во ClickHouse ќе треба да направиме runningDifference, односно да ја пресметаме разликата помеѓу паровите точки и да ги поделиме по време за да ја добиеме точната брзина. Барањето ќе изгледа отприлика вака.
И ќе ги покаже приближно овие вредности, т.е. Тивкото Боб или Џеј прави приближно 1,8 чекори во секунда.
И во Прометеј знаете како да го направите ова. Многу полесно отколку порано.
И за да биде исто така лесно да се направи во Grafana, ја додадов оваа обвивка, која изгледа многу слична на PromQL. Тоа се вика Rate Macros или како што сакате наречете го. Во Графана едноставно пишувате „стапка“, но некаде длабоко таа се трансформира во ова големо барање. И не мора ни да го гледате, таму е некаде, но заштедувате многу време, бидејќи пишувањето такви огромни SQL прашања е секогаш скапо. Можете лесно да направите грешка, а потоа да не разберете што се случува долго време.
И ова е барање кое не се вклопуваше ни во еден слајд и дури морав да го поделам на две колони. Ова е исто така барање во ClickHouse, што ја прави истата стапка, но за двете временски серии: Silent Bob и Jay, така што имаме две временски серии на панелот. И ова е веќе многу тешко, според мене.
А според Прометеј тоа ќе биде збир (стапка). За ClickHouse, направив посебно макро наречено RateColumns, кое изгледа како барање во Prometheus.
Го погледнавме и се чини дека PromQL е толку кул, но има, се разбира, ограничувања.
Ова се:
- Ограничен SELECT.
- Гранични ПРИКЛУЧУВАЊА.
- НЕМА ПОДРШКА.
И ако сте работеле со него долго време, тогаш знаете дека понекогаш е многу тешко да се направи нешто во PromQL, но во SQL можете да направите речиси сè, бидејќи сите овие опции за кои штотуку зборувавме може да се направат во SQL . Но, дали би било погодно да се користи? И ова ме тера да мислам дека најмоќниот јазик можеби не е секогаш најзгодниот.
Затоа, понекогаш треба да изберете јазик за задачата. Тоа е како Бетмен да се бори со Супермен. Јасно е дека Супермен е посилен, но Бетмен успеа да го победи бидејќи е попрактичен и точно знаеше што прави.
И следниот дел е Extnding PromQL.
Уште еднаш за VictoriaMetrics. Што е VictoriaMetrics? Ова е база на податоци за временски серии, таа е во OpenSource, ние ги дистрибуираме нејзините единечни и кластер верзии. Според нашите репери, тој е побрз од се што е сега на пазарот и компресијата е слична, односно вистинските луѓе пријавуваат компресија од околу 0,4 бајти по точка, додека кај Прометеј е 1,2-1,4.
Ние поддржуваме повеќе од само Прометеј. Ние поддржуваме InfluxDB, Graphite, OpenTSDB.
Можете да ни „пишувате“, односно да пренесувате стари податоци.
И, исто така, работиме совршено со Prometheus и Grafana, односно го поддржуваме моторот PromQL. И во Grafana можете едноставно да ја промените крајната точка на Prometheus во VictoriaMetrics и сите ваши контролни табли ќе работат како што работеа.
Но, можете да користите и дополнителни функции што ви ги обезбедува VictoriaMetrics.
Брзо ќе ги разгледаме функциите што ги додадовме.
Изостави параметри на интервал – можете да ги испуштите параметрите на интервалот во Графана. Кога не сакате да добивате чудни графикони кога зумирате/одзумирате во панелот, се препорачува да ја користите променливата $__interval. Ова е внатрешна промена на Grafana и самата го избира опсегот на податоци. И самата VictoriaMetrics може да разбере каков треба да биде овој опсег. И не треба да ги ажурирате сите ваши барања. Ќе биде многу полесно.
Втората функција е референцирање на интервал. Можете да го користите овој интервал во вашите изрази. Можете да множите, делите, пренесувате, упатувате на него.
Следно е семејството на функции за собирање. Функцијата Rollup трансформира која било од вашите временски серии во три посебни временски серии. Тоа се мин, максимум и просек. Сметам дека ова е многу погодно затоа што понекогаш може да покаже некои оддалечени и неточности.
И ако само правите лути или оценувате, тогаш веројатно ќе пропуштите некои случаи кога временските серии не се однесуваат како што очекувавте. Со оваа функција е многу полесно да се види, да речеме дека макс е многу од просечно.
Следна е стандардната променлива. Стандардно - тоа значи која вредност треба да ја нацртаме во Графана ако во моментот немаме временска серија. Кога се случува ова? Да речеме дека извезувате одредени метрики за грешки. И имате толку кул апликација што кога ќе започнете, немате грешки, па дури и грешки во следните три часа, па дури и еден ден. И имате контролни табли кои ја прикажуваат врската од успех до грешка. И тие нема да ви покажат ништо затоа што немате метрика за грешки. И стандардно можете да наведете што било.
Keep_last_Value – ја зачувува последната вредност на метриката ако недостасува. Ако Прометеј не го најде во рок од 5 минути по следното гребење, тогаш овде ќе ја запомниме неговата последна вредност и вашите топ листи нема повторно да се скршат.
Scrape_interval – покажува колку често Prometheus собира податоци за вашата метрика и со која фреквенција. Овде можете да видите пропусница, на пример.
Замената на етикетата е популарна карактеристика. Но, мислиме дека е малку комплицирано затоа што потребни се цели аргументи. И треба не само да запомните 5 аргументи, туку и да ја запомните нивната низа.
Затоа, зошто да не ги направиме поедноставни? Односно, разложете го на мали функции со разбирлива синтакса.
И сега забавниот дел. Зошто мислиме дека ова е продолжен PromQL? Затоа што поддржуваме изрази на заедничка табела. Можете да го следите QR-кодот (), видете ги врските со примери, од игралиштето, каде што можете да извршувате прашања директно во VictoriaMetrics без да го инсталирате едноставно во прелистувачот.
И што е ова? Ова барање погоре е прилично популарно барање. Мислам дека во било која контролна табла во многу компании користите ист филтер за се. Обично така. Но, кога треба да додадете нов филтер, треба да го ажурирате секој панел или да ја преземете контролната табла, да ја отворите во JSON, да пронајдете замена, што исто така бара време. Зошто да не ја зачувате оваа вредност во променлива и повторно да ја искористите? Ова изгледа, според мене, многу поедноставно и појасно.
На пример, кога треба да ажурирам филтри во Графана во сите барања, а контролната табла може да биде огромна или дури може да има неколку од нив. И како би сакал да го решам овој проблем во Графана?
Овој проблем го решавам на овој начин: правам заеднички филтер и го дефинирам овој филтер во него, а потоа повторно го користам во прашања. Но, ако го сторите истото сега, нема да работи бидејќи Grafana не дозволува да користите променливи во променливите за пребарување. И тоа е малку чудно.
И така направив опција што ви овозможува да го направите ова. И ако сте заинтересирани или сакате таква функција, тогаш поддржете ја или не ви се допаѓа ако не ви се допаѓа оваа идеја.
Повеќе за PromQL се прошири. Овде дефинираме не само променлива, туку цела функција. И ние го нарекуваме ru (користење ресурси). И оваа функција прифаќа бесплатни ресурси, ограничување на ресурсите и филтер. Се чини дека синтаксата е едноставна. И многу е лесно да се користи оваа функција и да се пресмета процентот на слободна меморија што ја имаме. Односно, колку меморија имаме, кое е ограничувањето и како да се филтрира. Изгледа многу поудобно ако го напишете сето тоа, повторно користејќи ги истите филтри, бидејќи тоа ќе се претвори во големо, големо барање.
И еве пример за толку големо, големо барање. Тоа е од официјалната табла NodeExporter за Grafana. Но, едвај разбирам што се случува овде. Тоа е, се разбира, разбирам ако погледнете внимателно, но бројот на загради може веднаш да ја намали мотивацијата да разберете што се случува овде. И зошто да не го направиме поедноставно и појасно?
На пример, вака, одвојување значајни работи или делови во променливи. А потоа направете ја вашата основна математика. Ова веќе повеќе личи на програмирање, ова би сакал да го видам во иднина во Графана.
Еве втор пример за тоа како би можеле да го олесниме ова ако веќе ја имавме оваа функција ru, а таа веќе постои директно во VictoriaMetrics. И тогаш едноставно ја пренесувате кешираната вредност што сте ја декларирале во CTE.
Веќе зборував за тоа колку е важно да се користи вистинскиот програмски јазик. И, веројатно, секоја компанија во Графана има нешто различно. Веројатно и вие им давате пристап до Grafana на вашите програмери, а програмерите си го прават своето. И сите го прават тоа некако поинаку. Но, сакав некако да биде исто, односно да се сведе на заеднички стандард.
Да речеме дека немате само системски инженери, можеби имате дури и експерти, devops или SRE. Можеби имате стручњаци кои знаат што е мониторинг, кои знаат што е Графана, односно работат со него со години и точно знаат како да го направат тоа правилно. И ова веќе го напишале 100 пати и им го објасниле на сите, но поради некоја причина никој не слуша.
Што ако би можеле да го стават ова знаење директно во Grafana за да можат другите корисници повторно да ги користат функциите? И кога би требало да го пресметаат процентот на слободна меморија, едноставно би ја примениле функцијата. Што ако креаторите на извозниците, заедно со нивниот производ, обезбедиле и збир на функции за тоа како да работат со нивните метрики, бидејќи тие точно знаат што се овие метрики и како правилно да ги пресметаат?
Ова навистина не постои. Ова е она што јас самиот го направив. Ова е библиотечната поддршка во Графана. Да речеме дека момците кои го направија NodeExporter го направија она за што зборував. И тие исто така обезбедија збир на функции.
Односно, изгледа вака нешто. Ја поврзувате оваа библиотека со Grafana, влегувате во уредување и многу едноставно е напишано во JSON како да се работи со оваа метрика. Односно, одреден сет на функции, нивниот опис и во што се претвораат.
Мислам дека ова би можело да биде корисно, бидејќи тогаш во Графана би пишувале баш така. И Графана „ви кажува“ дека има таква и таква функција од таква и таква библиотека - ајде да ја користиме. Мислам дека тоа би било многу кул.
Малку за VictoriaMetrics. Правиме многу интересни работи. Прочитајте ги нашите написи за компресија, за нашите натпревари со други апликации за податоци за временски серии, нашето објаснување за тоа како да се работи со PromQL, бидејќи сè уште има многу почетници во ова, како и за вертикалната приспособливост и за конфронтацијата со Танос.
Прашања:
Ќе го започнам моето прашање со едноставна животна приказна. Кога првпат почнав да ја користам Grafana, напишав многу привлечно барање кое беше долго 5 линии. Крајниот резултат е многу убедлив график. Овој распоред речиси влезе во производство. Но, по поблиска проверка, се покажа дека овој графикон покажува апсолутна глупост што нема никаква врска со реалноста, иако бројките се во опсегот што очекувавме да го видиме. И моето прашање. Имаме библиотеки, имаме функции, но како да пишуваме тестови за Графана? Напишавте сложено барање од кое зависи деловната одлука - да нарачате вистински контејнер со сервери или да не нарачате. И како што знаеме, оваа функција што го црта графикот е слична на вистината. Ви благодарам.
Фала за прашањето. Има два дела. Прво, добивам впечаток, врз основа на моето искуство, дека повеќето корисници, кога ги гледаат нивните табели, не разбираат што им покажуваат. Поради некоја причина, луѓето се многу добри во изговорот за секоја аномалија што се појавува во графиконите, дури и ако тоа е грешка во функцијата. И вториот дел - ми се чини дека користењето на такви функции би било многу подобар пристап за решавање на вашиот проблем, наместо секој од вашите развивачи да прави сопствено планирање на капацитетот и да прави грешки со одредена веројатност.
Како да се провери?
Како да се провери? Најверојатно не.
Како тест во Графана.
Каква врска има Графана со тоа? Графана го преведува ова барање директно во DataSource.
Додавање малку на параметрите.
Не, ништо не се додава на Графана. Може да има параметри GET, како, да речеме, чекор. Не е експлицитно наведено, но можете да го отфрлите или да не го отфрлите, но се додава автоматски. Овде нема да пишувате тестови. Мислам дека овде не треба да се потпираме на Графана како извор на вистината.
Ви благодариме за извештајот! Ви благодариме за компресијата! Спомнавте мапирање на променлива во граф, дека во Графана не можете да користите променлива во променлива. Дали знаете на што мислам?
Да.
Ова првично беше главоболка кога сакав да создадам предупредување во Графана. И таму треба да направите предупредување за секој домаќин посебно. Ова што го направивте, дали работи за предупредувања во Графана?
Ако Grafana не пристапува поинаку до променливите, тогаш да, ќе работи. Но, мој совет е воопшто да не користиш алармирање во Графана, подобро е да користиш alertmanager.
Да, го користам, но едноставно ми изгледаше полесно да се постави во Графана, но фала за советот!
Извор: www.habr.com
