Прапаную азнаёміцца з расшыфроўкай даклада Рамана Хаўроненкі "ExtendedPromQL"
Коратка пра мяне. Мяне клічуць Раман. Я працую ў CloudFlare, жыву ў Лондане. Але таксама я мэйтэрнэр VictoriaMetrics.
І я аўтар для Grafana і - гэта маленькі проксі для ClickHouse.
Мы пачнем з першай часткі, якая называецца “Складанасці перакладу” і ў ёй я буду расказваць пра тое, што любая мова ці нават проста мова зносін – гэта вельмі важна. Таму што гэта тое, як вы перадаеце іншаму чалавеку ці сістэме свае думкі, як вы фармулюеце запыт. Людзі ў інтэрнэце спрачаюцца пра тое, якая мова лепшая – java ці нейкая іншая. Для сябе я вырашыў, што трэба выбіраць пад задачу, бо ўсё гэта спецыфічна.
Пачнём з самага пачатку. Што такое PromQL? PromQL - гэта Prometheus Query Language. Гэта тое, як мы фармуем запыты ў Prometheus, каб атрымаць time series дадзеныя, часовыя шэрагі.
Што такое time series дадзеныя? Калі літаральна, то гэта тры параметры.
гэта:
- На што мы глядзім.
- Калі мы на гэта глядзім.
- І якое значэнне паказвае.
Калі паглядзець на гэтую дыяграму (гэтая дыяграма з майго тэлефона, якая паказвае статыстыку маіх крокаў), то тут можна хутка адказаць на гэтыя пытанні.
Мы глядзім на крокі. Мы бачым значэнне і бачым час, калі мы глядзім на гэта. Г. зн. гледзячы на гэтую дыяграму лёгка можна сказаць, што ў нядзелю я прайшоў каля 15 000 крокаў. Гэта time series дадзеныя.
Зараз давайце "разаб'ём" (пераўтваральны) іх у іншую мадэль дадзеных у выглядзе табліцы. Тут у нас таксама ёсьць тое, на што мы глядзім. Тут я крыху дадаў дадатковыя дадзеныя, якія мы будзем называць мета-дадзенымі, г. зн. гэта прайшоў не я, а два чалавекі, дапусцім, Jay і Silent Bob. Вось гэта тое, на што мы глядзім; што гэта паказвае і калі яно паказвае гэтае значэнне.
Цяпер давайце паспрабуем захаваць усе гэтыя дадзеныя ў базе дадзеных. Для прыкладу я ўзяў ClickHouse сінтаксіс. І тут мы ствараем адну табліцу, якая завецца "Steps", г. зн. на што мы глядзім. Тут ёсьць час, калі мы на гэта глядзім; што яно паказвае і нейкія мета-дадзеныя, дзе мы будзем захоўваць, хто гэта: Jay і Silent Bob.
І для таго каб паспрабаваць візуалізаваць гэта ўсё, мы будзем выкарыстоўваць Grafana, таму што, па-першае, гэта прыгожа.
Таксама мы будзем выкарыстоўваць гэты плягін. На гэта ёсць дзве прычыны. Першая - таму што я яго напісаў. І я сапраўды ведаю, як цяжка выцягваць time series дадзеныя з ClickHouse, каб паказаць у Grafana.
Адлюстроўваць мы будзем у Graph Panel. Гэта самая папулярная панэль у Grafana, якая паказвае залежнасць значэння ад часу, таму нам трэба ўсяго толькі два параметры.
Давайце напішам самы просты запыт - як паказаць статыстыку крокаў у Grafana, захоўваючы гэтыя дадзеныя ў ClickHouse, у той табліцы, што мы стварылі. І мы пішам вось такі просты запыт. Мы выбіраем з крокаў. Мы выбіраем значэнне і выбіраем час гэтых значэнняў, т. е. тыя ж тры параметры, пра якія мы казалі.
І ў выніку мы атрымаем вось такі графік. Хто ведае, чаму ён такі дзіўны?
Правільна, трэба адсартаваць па часе.
І ў выніку мы атрымаем ужо лепей, але ўсё яшчэ дзіўны графік. Хто ведае, чаму? Правільна, там два ўдзельніка, і мы ў Grafana аддаём два time series, таму што калі разабрацца з дата-мадэллю яшчэ раз, то кожная time series - гэта ўнікальная камбінацыя імя і ўсіх ключ-значэнняў labels.
Таму нам трэба абраць канкрэтнага чалавека. Мы выбіраем 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, але па абедзвюх time series: і Silent Bob, і па Jay, каб у нас на панэлі былі дзве time series. І гэта ўжо вельмі складана, на маю думку.
І па Prometheus гэта будзе sum (rate). Для ClickHouse я зрабіў асобны макрас, які называецца RateColumns, які выглядае, як запыт у Prometheus.
Мы паглядзелі і быццам бы PromQL увесь такі класны, але ў яго ёсць, вядома, абмежаванні.
гэта:
- Limited SELECT.
- Памежныя JOIN.
- Няма падтрымкі HAVING.
І калі вы прапрацавалі з ім доўга, то вы ведаеце, што часам вельмі цяжка зрабіць нешта ў PromQL, а ў SQL можна рабіць практычна ўсё, таму што ўсе гэтыя варыянты, якія мы зараз прагаварылі, можна было зрабіць у SQL. Але ці было б зручна гэтым карыстацца? І гэта напіхвае мяне на думку, што не заўсёды самая магутная мова можа быць самай зручнай.
Таму часам трэба выбіраць мову пад задачы. Гэта як бітва Бэтмэна з Супермэнам. Зразумела, што Супермэн мацнейшы, але Бэтмен змог яго перамагчы, таму што ён больш практычны і дакладна ведаў, што ён робіць.
І наступная частка - гэта Extending PromQL.
Яшчэ раз пра VictoriaMetrics. Што такое VictoriaMetrics? Гэта time series базы дадзеных, яна ў OpenSource, мы дыстрыбуюць яе single і cluster-версіі. Па нашых бенчмарках яна хутчэй за ўсё, што ёсць на рынку цяпер і па кампрэсіі аналагічна, т. е. жывыя людзі рэпартуюць кампрэсію дзесьці ў 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 можа сама разумець, якім гэты дыяпазон даложаны быць. І вам не трэба апдэйціць усе вашыя запыты. Будзе нашмат прасцей.
Другая функцыя - гэта interval referencing. Вы можаце выкарыстоўваць гэты інтэрвал у сваіх выразах. Вы можаце памнажаць, дзяліць, перадаваць, спасылацца на яго.
Далей сямейства rollup function. Rollup function трансфармуе любы ваш time series у тры асобныя time series. Гэта min, max і avg. Я лічу, што гэта вельмі зручна, таму што часам гэта можа паказаць нейкія outliers (анамаліі) і недакладнасці.
І калі вы проста робіце irate ці rate, то верагодна вы можаце прапусціць нейкія выпадкі, калі time series паводзіць сябе не так, як вы меркавалі. З гэтай функцыяй нашмат прасцей убачыць, дапусцім, што max вельмі моцна ад avg.
Далей пераменная default. Default - гэта значыць, якое значэнне нам трэба адмаляваць у Grafana, калі ў нас няма time series у дадзены момант. Калі гэта адбываецца? Дапусцім вы экспартуеце нейкую метрыку па памылках. І ў вас такое класнае прыкладанне, што калі вы стартавалі, то ў вас няма памылак і нават няма памылак у наступныя тры гадзіны ці нават дзень. І ў вас ёсць дашборды, якія паказваюць адносіны з success да error. І яны будуць вам паказваць нічога, таму што ў вас няма метрыкі error. А ў default вы можаце паказаць што заўгодна.
Keep_last_Value - захоўвае апошняе значэнне метрыкі, калі яна знікла. Калі Prometheus пасля наступнага скрэйпа не знайшоў яе на працягу 5 хвілін, то тут мы будзем запамінаць яе апошняе значэнне і вашыя графікі зноў не зламаюцца.
Scrape_interval - паказвае, як часта Prometheus збірае дадзеныя па ваша метрыцы, з якой частатой. Тут можна ўбачыць пропуск, напрыклад.
Label replace - папулярная функцыя. Але мы лічым, што яна крыху складаная, таму што яна прымае цэлых аргументаў. І вам трэба не толькі памятаць 5 аргументаў, але яшчэ і памятаць іх паслядоўнасць.
Таму, чаму б не зрабіць іх прасцей? Т. е. разбіць на дробныя функцыі са зразумелым сінтаксісам.
І зараз самае цікавае. Чаму мы лічым, што гэта extended PromQL? Таму што мы падтрымліваем Common Table Expressions. Вы можаце перайсці па QR-кодзе (), паглядзець спасылкі з прыкладамі, з playground, дзе можаце выканаць запыты непасрэдна ў VictoriaMetrics без яе ўстаноўкі проста ў браўзэры.
І што ж гэта такое? Вось гэты запыт зверху - гэта даволі папулярны запыт. Я думаю, у любым дашбордзе ў многіх кампаній вы карыстаецеся адзін і той жа фільтр для ўсяго. Звычайна так. Але калі вам трэба дадаць нейкі новы фільтр, тое даводзіцца абнаўляць кожную панэль, альбо спампоўваць дашборд, адчыняць у JSON, рабіць find replace, што таксама займае час. Чаму б не захоўваць гэтае значэнне ў зменнай і перавыкарыстоўваць яго? Гэта выглядае, на мой погляд, на шмат прасцей і зразумелей.
Напрыклад, калі мне трэба абнаўляць фільтры ў Grafana ва ўсіх запытах, а дашборд пры гэтым можа быць вялізны ці іх можа быць нават некалькі. І як бы я хацеў вырашаць гэтую праблему ў Grafana?
Я вырашаю гэтую праблему так: я раблю commonFilter і ў ім вызначаю гэты фільтр, а потым яго перавыкарыстоўваю ў запытах. Але калі вы зробіце зараз гэтак жа, гэта не будзе працаваць, таму што Grafana не дазваляе вам выкарыстоўваць зменныя ўнутры зменных запытаў. І гэта крыху дзіўна.
І таму я зрабіў такі варыянт, які дазваляе гэта рабіць. І калі вам цікава ці вы хочаце такую фічу, то падтрымайце ці дызлайкніце, калі вам не падабаецца такая ідэя.
Далей пра PromQL extended. Тут мы вызначаем не толькі зменную, але цэлую функцыю. І завем яе ru (resource usage). І прымае гэтая функцыя вольныя рэсурсы, абмежаванне па рэсурсе і фільтр. Накшталт бы сінтаксіс увесь просты. І вельмі лёгка выкарыстоўваць гэтую функцыю і палічыць працэнт вольнай памяці ў нас. Т. е. колькі ў нас ёсць памяці, якое абмежаванне і як фільтраваць. Гэта выглядае нашмат зручней, калі б вы пісалі гэта ўсё, перавыкарыстоўваючы адны і тыя ж фільтры, таму што гэта б ператварылася ў вялікі-вялікі запыт.
І вось прыклад такога вялікага-вялікага запыту. Ён з афіцыйнага дашборда NodeExporter для Grafana. Але я слаба разумею, што тут адбываецца. Т. е., вядома, разумею, калі прыгледзецца, але колькасць дужак можа адразу панізіць матывацыю разбірацца ў тым, што тут адбываецца. І чаму б не зрабіць яго прасцей і зразумелей?
Напрыклад, вось так, вылучыўшы значныя рэчы ці часткі ў зменныя. І потым зрабіць сваю базавую матэматыку. Гэта ўжо больш падобна на праграмаванне, гэта тое, што я б і хацеў бачыць у будучыні ў Grafana.
Вось другі прыклад, як мы можам зрабіць гэта яшчэ прасцей, калі б у нас ужо была гэтая функцыя be, а яна ўжо ёсць непасрэдна ў VictoriaMetrics. І вы тады проста перадаеце закэшаванае значэнне, якое вы абвясцілі ў CTE.
Я ўжо казаў, пра тое, як важна выкарыстоўваць патрэбную мову праграмавання. І, мусіць, у кожнай кампаніі ў Grafana дзеецца што-небудзь сваё. І, напэўна, вы яшчэ даяце доступ да Grafana сваім распрацоўшчыкам, і распрацоўшчыкі робяць нешта сваё. І ўсе яны робяць гэта неяк па-рознаму. А хацелася, каб неяк аднолькава, г.зн. звесці да агульнага стандарту.
Дапусцім, у вас ёсць нават не проста сістэмныя інжынеры, можа быць у вас нават ёсць эксперты, дэвопс або SRE. Можа ў вас есць эксперты, якія ведаюць, што такое маніторынг, ведаюць, што такое Grafana, г. зн. яны працуюць з гэтым гадамі і яны дакладна ведаюць, як рабіць правільна. І яны ўжо пісалі гэта 100 разоў і ўсім тлумачылі, але чамусьці ніхто не слухае.
А што, калі б яны змаглі гэтыя веды непасрэдна пакласці ў Grafana, каб іншыя карыстачы маглі перавыкарыстоўваць функцыі? І калі б трэба было б палічыць працэнт свабоднай памяці, то яны б проста прымянілі функцыю. А што, калі стваральнікі экспарцёраў, разам са сваім прадуктам давалі таксама і набор функцый, як працаваць з іх метрыкамі, бо яны дакладна ведаюць, што гэта за метрыкі і як іх правільна лічыць?
Вось гэтага насамрэч не існуе. Вось гэта я зрабіў сам. Гэта падтрымка бібліятэк у Grafana. Дапушчальны, рабяты, якія зрабілі NodeExporter, зрабілі тое, пра што я распавёў. І падалі таксама набор функцый.
Т. е. выглядае гэта прыкладна так. Вы падключаеце гэтую бібліятэку ў Grafana, вы заходзіце ў рэдагаванне і тут вельмі проста ў JSON напісана, як працаваць з гэтай метрыкай. Т. е. нейкі набор функцый, іх апісанне і ў што яны разгортваюцца.
На маю думку, гэта магло б быць карысным, таму што тады ў Grafana вы б пісалі проста так. І вам Grafana "кажа", што ёсць вось вось такая функцыя з вось такой бібліятэкі – давайце яе выкарыстоўваць. Мне здаецца, што гэта было б вельмі здорава.
Трохі пра VictoriaMetrics. Мы робім вельмі шмат цікавых рэчаў. Пачытайце нашы артыкулы пра compression, пра нашы спаборніцтвы з іншымі time series дадаткамі дадзеных, наша тлумачэнне як працаваць з PromQL, таму што ў гэтым шмат яшчэ пачаткоўцаў, а таксама пра vertical scalability і пра супрацьстаянне з Thanos.
пытанні:
Я пачну сваё пытанне з простай жыццёвай гісторыі. Калі я ўпершыню пачаў выкарыстоўваць Grafana, я напісаў вельмі пераканаўчы запыт даўжынёй у 5 радкоў. У выніку атрымаўся вельмі пераканаўчы графік. Гэты графік амаль з'ехаў у production. Але пры бліжэйшым разглядзе аказалася, што гэты графік паказвае абсалютную ахінею, якая не мае ніякага дачынення да рэальнасці, хоць лічбы трапляюць у дыяпазон, які мы чакалі ўбачыць. І маё пытанне. У нас есць бібліятэкі, у нас ёсць функцыі, а як мы пішам тэсты для Grafana? Вы напісалі складаны запыт, ад якога залежыць бізнэс-рашэнне - замовіць сапраўдны кантэйнер сервераў ці не заказваць. І як мы ведаем, гэтая функцыя, якая малюе графік падобная да праўды. Дзякуй.
Дзякуй за пытанне. Тут дзве часткі. Першая - у мяне складаецца ўражанне, зыходзячы з маёй практыкі, што большасць карыстачоў, калі глядзяць на свае графікі, не разумеюць, што яны ім паказваюць. Чамусьці людзі вельмі добрыя ў тым, каб прыдумаць апраўданне любой анамаліі, якая адбываецца на графіках, нават калі гэта памылка ўнутры функцыі. І другая частка - мне здаецца, што выкарыстанне вось такіх функцый нашмат лепш падышло б да рашэння вашай праблемы, замест таго, каб кожны з вашых распрацоўшчыкаў рабіў свой capacity planning і памыляўся з нейкай верагоднасцю.
Як праверыць?
Як праверыць? Мусіць, ніяк.
У выглядзе тэсту ў Grafana.
Прычым тут Grafana? Grafana транслюе гэты запыт непасрэдна ў DataSource.
Дадаючы ледзь-ледзь у параметры.
Не, у Grafana нічога не дадаюць. Там могуць быць GET-параметры, як, дапусцім, step. Ён відавочна не паказваецца, але вы яго можаце перавызначыць, можаце не перавызначаць, але ён дадаецца аўтаматычна. Вы тут не напішыце тэсты. Я думаю, што ня варта спадзявацца тут на Grafana, як на крыніцу праўды.
Дзякуй за даклад! Дзякуй за кампрэсію! Вы ўспаміналі пра mapping зменнай у графіцы, што ў Grafana нельга выкарыстоўваць зменную ў зменнай. Разумееце, пра што я?
Да.
Гэта было першапачаткова галаўным болем, калі я хацеў зрабіць alert у Grafana. І там трэба alert рабіць для кожнага хаста асобна. Вось гэтая штука, якую вы зрабілі, яна працуе для alerts у Grafana?
Калі Grafana не звяртаецца да зменных неяк па-іншаму, то так, яна будзе працаваць. Але мая парада не выкарыстоўваць алертынг у Grafana наогул, вам лепш выкарыстоўваць alertmanager.
Так, я яго выкарыстоўваю, але проста гэта ў Grafana здалося лягчэй у наладзе, але дзякуй за параду!
Крыніца: habr.com