Мен Роман Хавроненконун "ExtendedPromQL" баяндамасынын стенограммасын окууну сунуштайм
Мен жөнүндө кыскача. Менин атым Роман. Мен CloudFlare үчүн иштейм жана Лондондо жашайм. Бирок мен VictoriaMetricsтин тейлөөчүсү болом.
А мен автормун Grafana үчүн жана ClickHouse үчүн кичинекей прокси болуп саналат.
Биз биринчи бөлүктөн баштайбыз, ал "Котормодогу кыйынчылыктар" деп аталат жана анда мен ар кандай тил же жөн эле баарлашуу тили абдан маанилүү экендиги жөнүндө сөз кылам. Анткени сиз өз оюңузду башка адамга же системага ушинтип жеткиресиз, өтүнүчтү кантип түзөсүз. Интернеттеги адамдар кайсы тил жакшыраак экенин талашып жатышат - java же башка. Мен өзүм үчүн тапшырманы тандоо керек деп чечтим, анткени мунун баары конкреттүү.
Эң башынан баштайлы. PromQL деген эмне? PromQL бул Prometheus суроо тили. Ушинтип биз Прометейде убакыт серияларынын маалыматтарын, убакыт серияларын алуу үчүн сурамдарды түзөбүз.
Убакыт сериясынын маалыматтары деген эмне? Сөзмө-сөз, бул үч параметр болуп саналат.
Алар төмөнкүлөр:
- Эмнени карап жатабыз.
- Биз аны караганыбызда.
- Анан кандай баалуулуктарды көрсөтөт.
Эгер сиз бул диаграмманы карасаңыз (бул диаграмма менин телефонумдан алынган, анда менин кадамдарымдын статистикасы көрсөтүлгөн), анда бул жерде сиз бул суроолорго тез жооп бере аласыз.
Биз кадамдарды карап жатабыз. Биз маанини көрүп, аны караганыбызда убакытты көрөбүз. Башкача айтканда, бул диаграмманы карап, жекшемби күнү мен 15 000 кадам бастым деп оңой эле айта аласыз. Бул убакыт сериясынын маалыматтары.
Эми аларды таблица түрүндө башка маалымат моделине «сындыралы» (трансформациялайлы). Бул жерде биз карап жаткан нерсебиз да бар. Бул жерде мен бир аз кошумча маалыматтарды коштум, аларды биз мета-маалыматтар деп атайбыз, башкача айтканда, мен эмес, эки адам, мисалы, Джей жана Silent Bob өттү. Бул биз карап жаткан нерсе; ал эмнени көрсөтөт жана ал баалуулукту качан көрсөтөт.
Эми бул маалыматтардын баарын маалымат базасына сактоого аракет кылалы. Мисалы, мен ClickHouse синтаксисин алдым. Бул жерде биз "Кадамдар" деп аталган бир таблицаны түзүп жатабыз, башкача айтканда, биз карап жаткан нерсе. Бул жерде биз карап турган убак бар; ал эмнени көрсөтөт жана анын ким экенин кайда сактай турган кээ бир мета-берилиштер: Джей жана Тынч Боб.
Жана мунун баарын элестетүү үчүн, биз Grafana колдонобуз, анткени, биринчиден, ал сулуу.
Ошондой эле биз бул плагинди колдонобуз. Мунун эки себеби бар. Биринчиси, анткени мен жазганмын. Анан мен Grafanaда көрсөтүү үчүн ClickHouseдан убакыт серияларынын маалыматтарын чыгарып алуу канчалык кыйын экенин билем.
Биз График панелинде көрсөтөбүз. Бул Grafanaдагы эң популярдуу панель жана убакытка карата маанини көрсөтөт, ошондуктан бизге эки гана параметр керек.
Келгиле, эң жөнөкөй суроону жазалы - Grafanaдагы кадам статистикасын кантип көрсөтүү керек, бул маалыматтарды ClickHouse-да сактап, биз түзгөн таблицада. Жана биз ушундай жөнөкөй суроо жазабыз. Биз кадамдардан тандайбыз. Биз маанини тандайбыз жана бул маанилердин убактысын тандайбыз, б.а. биз айткан үч параметр.
Натыйжада, биз бул графикти алабыз. Анын эмне үчүн мынчалык кызык экенин ким билет?
Туура, убакыт боюнча иреттөө керек.
Акыр-аягы, биз жакшыраак, бирок дагы эле кызыктай графикке ээ болобуз. Эмне үчүн ким билет? Туура, эки катышуучу бар жана биз Графанада эки убакыт сериясын беребиз, анткени биз дагы бир жолу маалымат модели менен алектенсек, анда ар бир убакыт сериясы аталыштын жана бардык энбелгилердин ачкыч-маанилердин уникалдуу айкалышы болуп саналат.
Ошондуктан биз конкреттүү адамды тандап алышыбыз керек. Биз Джейди тандайбыз.
Жана дагы тарт. Азыр график чындыкка окшош. Азыр кадимки график жана баары жакшы иштеп жатат.
Жана, балким, сиз ошол эле нерсени кантип жасоону билесиз, бирок Prometheus'та PromQL аркылуу. Болжол менен ушундай. Бир аз жеңилирээк. Анан мунун баарын талкалап көрөлү. Биз кадамдарды жасадык. Жана Джей менен чыпкалоо. Биз бул жерде баалуулук алышыбыз керек экенин тактабайбыз жана убакытты тандабайбыз.
Эми Jay же Silent Bob кыймылынын ылдамдыгын эсептеп көрөлү. ClickHouseда биз runDifference жасашыбыз керек, б.а., так ылдамдыкты алуу үчүн жуп чекиттердин ортосундагы айырманы эсептеп, аларды убакытка бөлүү керек. Сурам ушундай көрүнөт.
Жана ал болжол менен ушул маанилерди көрсөтөт, башкача айтканда, секундасына болжол менен 1,8 кадам Silent Bob же Jay кылат.
Ал эми Прометейде сиз муну кантип жасоону билесиз. Мурдагыга караганда алда канча жеңил.
Ошондой эле Grafanaда жасоону оңой кылуу үчүн, мен PromQLге абдан окшош болгон орогучту коштум. Ал Rate макростору деп аталат, же сиз аны кандай атасаңыз. Графанада сиз жөн эле "ставка" деп жазасыз, бирок кандайдыр бир тереңдикте ал ушунчалык чоң өтүнүчкө айланат. Жана аны карап отуруунун да кереги жок, ал бир жерде бар, бирок сиз көп убакытты үнөмдөйсүз, анткени мындай чоң SQL сурамдарын жазуу дайыма кымбатка турат. Сиз оңой эле ката кетирип, анан көпкө чейин эмне болуп жатканын түшүнбөй каласыз.
Бул бир слайдга да туура келбеген суроо, мен аны эки тилкеге бөлүүгө туура келди. Бул дагы ClickHouseдагы өтүнүч, ал бирдей ченди түзөт, бирок эки убакыт сериясы үчүн: Silent Bob жана Jay, ошондуктан панелде эки убакыт сериясы бар. Ал эми бул менин оюмча, буга чейин абдан кыйын.
Ал эми Прометей боюнча бул сумма (ставка) болот. ClickHouse үчүн мен Prometheus сурамына окшош болгон RateColumns деп аталган өзүнчө макрос жасадым.
Биз карап көрдүк жана PromQL абдан сонун окшойт, бирок анын, албетте, чектөөлөрү бар.
Алар төмөнкүлөр:
- Чектелген ТАНДОО.
- Edge JOINs.
- Колдоо жок.
Эгер сиз аны менен көптөн бери иштесеңиз, анда PromQLде бир нерсе кылуу кээде өтө кыйын экенин билесиз, ал эми SQLде дээрлик бардыгын жасай аласыз, анткени биз айтып өткөн бул опциялардын бардыгын SQLде жасаса болот. . Бирок аны колдонуу ыңгайлуу болобу? Бул мени дайыма эле эң күчтүү тил эң ыңгайлуу тил боло албайт деген ойго түртөт.
Ошондуктан, кээде тапшырмалар үчүн тил тандоо керек. Бул Батмен менен Супермендин ортосундагы согуш сыяктуу. Супермен күчтүү экени анык, бирок Бэтмен аны жеңе алды, анткени ал практикалык жана эмне кылып жатканын так билген.
Ал эми кийинки бөлүгү - PromQL кеңейтүү.
Дагы бир жолу VictoriaMetrics жөнүндө. VictoriaMetrics деген эмне? Бул убакыт сериясынын маалымат базасы, ал OpenSourceде, биз анын бирдиктүү жана кластердик версияларын таратабыз. Биздин эталондор боюнча, ал азыр рынокто эң ылдам жана кысуу жагынан окшош, башкача айтканда, тирүү адамдар Прометейде 0,4-1,2 болгон учурда бир пунктка болжол менен 1,4 байт кысылганын айтышат.
Биз Прометейди гана эмес, колдойбуз. Биз InfluxDB, Graphite, OpenTSDB колдойбуз.
Сиз бизге "жазууга" болот, башкача айтканда, эски маалыматтарды өткөрө аласыз.
Ошондой эле биз Prometheus жана Grafana менен мыкты иштейбиз, башкача айтканда, PromQL кыймылдаткычын колдойбуз. Ал эми Grafana'да сиз Prometheus акыркы чекитин VictoriaMetrics деп жөн эле өзгөртсөңүз болот жана сиздин бардык башкаруу такталарыңыз алардай иштейт.
Бирок сиз VictoriaMetrics тарабынан берилген кошумча чиптерди да колдоно аласыз.
Биз кошкон функцияларды тез карап чыгабыз.
Интервал параметрин өткөрүп жибериңиз - сиз Grafanaдагы параметр аралыгын өткөрүп жиберсеңиз болот. Панелди чоңойтуу/кичирейтүү учурунда кызыктай графиктерди алууну каалабасаңыз, өзгөрмө колдонуу сунушталат. $__interval. Бул ички Grafana өзгөрүшү жана ал маалымат диапазонун өзү тандайт. Ал эми VictoriaMetrics өзү бул диапазон кандай болушу керектигин түшүнө алат. Жана бардык сурамдарыңызды жаңыртуунун кереги жок. Бул алда канча жеңил болот.
Экинчи функция - интервалдык шилтеме. Бул интервалды туюнтмаларыңызда колдонсоңуз болот. Сиз көбөйтсөңүз, бөлсөңүз, өткөрүп бересиз, ага кайрылсаңыз болот.
Кийинки топтоо функциясынын үй-бүлөсү. Топтоо функциясы каалаган убакыт серияңызды үч өзүнчө убакыт сериясына айлантат. Бул минимум, максимум жана орточо. Мен аны абдан ыңгайлуу деп эсептейм, анткени кээде кээ бир четтөөлөрдү (аномалияларды) жана так эместиктерди көрсөтөт.
Эгер сиз жөн эле ачууланып же баа берип жатсаңыз, анда убакыт сериясы сиз ойлогондой болбой калган учурларды өткөрүп жиберсеңиз болот. Бул функция менен көрүү бир топ жеңил, макс орто эсеп менен өтө төмөн деп коёлу.
Кийинки демейки өзгөрмө болуп саналат. Демейки - бул учурда бизде убакыт сериясы жок болсо, Графанада кандай мааниге ээ болушубуз керектигин билдирет. Качан болот? Кээ бир ката көрсөткүчтөрүн экспорттуңуз дейли. Жана сизде ушунчалык сонун тиркеме бар, сиз баштаганда, кийинки үч саатта, атүгүл бир суткада эч кандай катасыз, жада калса катасыз. Жана сизде ийгиликтен катага чейинки мамилелерди көрсөткөн башкаруу такталары бар. Жана алар сизге эч нерсе көрсөтүшпөйт, анткени сизде ката көрсөткүчү жок. Жана демейкиде сиз каалаган нерсени белгилей аласыз.
Keep_last_Value - метрика жок болсо, анын акыркы маанисин сактайт. Эгерде Прометей кийинки кырып салгандан кийин аны 5 мүнөттүн ичинде таппаса, анда биз анын акыркы маанисин эстейбиз жана диаграммаларыңыз кайра бузулбайт.
Scrape_interval - Prometheus сиздин метрикаңыз боюнча маалыматтарды канча жолу, кандай жыштык менен чогултарын көрсөтөт. Бул жерден, мисалы, өтүүнү көрө аласыз.
Этикетканы алмаштыруу популярдуу функция. Бирок биз муну бир аз татаал деп ойлойбуз, анткени ал бүтүн аргументтерди талап кылат. Жана 5 аргументтерди эстеп гана койбостон, алардын ырааттуулугун да эстеп калуу керек.
Ошондуктан, эмне үчүн аларды жөнөкөйлөтүүгө болбойт? Башкача айтканда, аны так синтаксис менен майда функцияларга бөлүңүз.
Эми эң кызыктуусу. Эмне үчүн биз бул кеңейтилген PromQL деп ойлойбуз? Анткени биз Common Table Expressions колдойбуз. Сиз QR кодун ээрчий аласыз (), оюн аянтчасынан мисалдар менен шилтемелерди караңыз, ал жерде сиз суроолорду түздөн-түз VictoriaMetricsте аны браузерде орнотпостон иштете аласыз.
Жана ал эмне? Жогорудагы бул суроо абдан популярдуу суроо. Менин оюмча, көптөгөн компаниялардын кайсы болбосун панелинде сиз бардыгы үчүн бир эле чыпканы колдоносуз. Адатта ошондой. Бирок жаңы чыпка кошуу керек болгондо, ар бир панелди жаңыртышыңыз керек, же тактасын жүктөп алып, аны JSONде ачып, алмаштырууну табышыңыз керек, бул да убакытты талап кылат. Эмне үчүн бул маанини өзгөрмөдө сактап, кайра колдонууга болбойт? Бул, менин оюмча, алда канча жөнөкөй жана түшүнүктүү көрүнөт.
Мисалы, мен бардык суроо-талаптарда Grafana чыпкаларын жаңыртышым керек болгондо жана башкаруу панели чоң болушу мүмкүн же алардын бир нечеси болушу мүмкүн. Анан мен бул маселени Графанада кантип чечгим келет?
Мен бул маселени мындай чечем: Мен жалпы Фильтр жасайм жана анда бул чыпканы аныктайм, анан аны сурамдарда кайра колдоном. Бирок азыр да ошондой кылсаңыз, ал иштебейт, анткени Grafana суроо өзгөрмөлөрүнүн ичинде өзгөрмөлөрдү колдонууга уруксат бербейт. Жана бул бир аз кызыктай.
Ошентип, мен сизге муну кылууга мүмкүнчүлүк берген вариант жасадым. Жана эгер сизди кызыктырсаңыз же ушундай функцияны кааласаңыз, анда бул идея сизге жакпаса, колдоңуз же жакпаңыз.
PromQL жөнүндө көбүрөөк маалымат. Бул жерде биз бир гана өзгөрмө эмес, түз бүтүндөй функцияны аныктайбыз. Ал эми биз аны ru (ресурсту колдонуу) деп атайбыз. Жана бул функция бекер ресурстарды, ресурстун чегин жана чыпкасын кабыл алат. Синтаксис жөнөкөй көрүнөт. Жана бул функцияны колдонуу жана бизде бош эстутумдун пайызын эсептөө абдан оңой. Башкача айтканда, бизде канча эс бар, кандай чек жана кантип чыпкалоо керек. Эгер сиз мунун баарын бир эле чыпкаларды кайра колдонуу менен жазсаңыз, бир топ жакшы көрүнөт, анткени ал чоң, чоң суроого айланат.
Мына ушундай чоң, чоң өтүнүчтүн бир мисалы. Бул Grafana үчүн расмий NodeExporter тактасынан алынган. Бирок мен бул жерде эмне болуп жатканын такыр түшүнбөйм. Бул, албетте, жакшылап карасаңыз, түшүнөм, бирок кашаалардын саны бул жерде эмне болуп жатканын түшүнүү үчүн мотивацияны дароо азайтышы мүмкүн. Анан эмне үчүн аны жөнөкөй жана түшүнүктүү кылбайт?
Мисалы, бул сыяктуу, өзгөрмөлөрдөгү маанилүү нерселерди же бөлүктөрдү бөлүп көрсөтүү. Анан негизги математиканы кылгыла. Бул программалоого көбүрөөк окшош, мен келечекте Графанада көргүм келет.
Бул жерде бизде бул ru функциясы болгон болсо жана ал түздөн-түз VictoriaMetricsте бар болсо, аны кантип жеңилдете аларыбыздын экинчи мисалы. Андан кийин сиз CTEде жарыялаган кэштелген маанини өткөрүп бересиз.
Мен буга чейин туура программалоо тилин колдонуу канчалык маанилүү экенин айттым. Жана, балким, ар бир компанияда Графанада ар кандай нерсе болуп жатат. Жана, балким, сиз дагы деле иштеп чыгуучуларыңызга Grafana мүмкүнчүлүгүн бересиз жана иштеп чыгуучулар өз алдынча бир нерсе жасашат. Жана алардын баары муну ар кандай жол менен жасашат. Бирок мен аны кандайдыр бир деңгээлде, башкача айтканда, жалпы стандартка түшүрүүнү кааладым.
Сизде жөн эле системалык инженерлер жок дейли, балким, сизде эксперттер, devops же SREлер бар. Мүмкүн, сизде мониторинг деген эмне экенин билген, Grafana эмне экенин билген адистер бардыр, б.а. алар муну менен көп жылдардан бери иштеп келишет жана аны кантип туура жасоону жакшы билишет. Анан буга чейин 100 жолу жазып, баарына түшүндүрүп коюшкан, бирок эмнегедир эч ким укпайт.
Башка колдонуучулар функцияларды кайра колдонушу үчүн алар бул билимди түздөн-түз Grafanaга киргизсечи? Ал эми бош эстутумдун пайызын эсептөө керек болсо, анда алар жөн гана функцияны колдонушмак. Бирок экспортерлордун жаратуучулары өз продукциясы менен бирге функциялардын комплексин, алардын көрсөткүчтөрү менен кантип иштөөнү камсыз кылышсачы, анткени алар бул көрсөткүчтөр эмне экенин жана аларды кантип туура эсептөө керектигин жакшы билишет?
Бул чынында жок. Мына мен өзүм эмне кылдым. Бул Grafana китепкана колдоо болуп саналат. Айталы, NodeExporterди чыгарган балдар мен сүрөттөгөн нерсени жасашты. Ошондой эле бир катар функцияларды камсыз кылат.
Башкача айтканда, бул ушундай көрүнөт. Сиз бул китепкананы Grafanaга туташтырасыз, сиз түзөтүүгө киресиз жана бул жерде JSONде бул метрика менен кантип иштөө өтө жөнөкөй. Башкача айтканда, кээ бир функциялардын жыйындысы, алардын сүрөттөлүшү жана алар эмнеге ачылат.
Менин оюмча, бул пайдалуу болушу мүмкүн, анткени анда сиз Графанада ушинтип жазмаксыз. Ал эми Графана баланча китепканадан тигил же бул функция бар экенин «айтат» - келгиле, аны колдонолу. Мен бул абдан сонун болот деп ойлойм.
VictoriaMetrics жөнүндө бир аз. Биз көп кызыктуу нерселерди жасайбыз. Компрессия жөнүндө, башка убакыт серияларынын берилиштеринин тиркемелери менен болгон атаандаштыгыбыз жөнүндө, PromQL менен кантип иштөө керектиги тууралуу түшүндүрмөлөрүбүздү окуңуз, анткени бул жерде дагы көптөгөн башталгычтар бар, ошондой эле вертикалдык масштабдуулук жана Thanos менен тирешүү жөнүндө.
суроолор:
Мен суроомду жөнөкөй жашоо окуясынан баштайм. Мен биринчи Grafana колдоно баштаганда, мен абдан ынандырарлык 5 сап суроо жаздым. Жыйынтык абдан ынанымдуу диаграмма болуп саналат. Бул график дээрлик өндүрүшкө кирди. Бирок жакшыраак текшерүүдөн кийин, бул диаграммада чындыкка эч кандай тиешеси жок абсолюттук нонсенс экени белгилүү болду, бирок сандар биз күткөн диапазонго туура келет. Жана менин суроом. Бизде китепканалар бар, функциялар бар, бирок Grafana үчүн тесттерди кантип жазабыз? Сиз бизнес-чечимге таасир этүүчү татаал суроо жаздыңыз - серверлердин чыныгы контейнерине заказ кылуу же заказ кылбоо. Жана биз билгендей, графикти тарткан бул функция чындыкка окшош. Рахмат.
Сурооңуз үчүн рахмат. Бул жерде эки бөлүк бар. Биринчиден, мен өзүмдүн тажрыйбама таянып, көпчүлүк колдонуучулар диаграммаларын карап жатканда, аларга эмне көрсөтүп жатканын түшүнбөй тургандай таасир алдым. Кандайдыр бир жол менен, адамдар диаграммаларда болуп жаткан ар кандай аномалияны, ал тургай, функциянын ичиндеги мүчүлүштүк болсо да, шылтоо табууга абдан жакшы. Ал эми экинчи бөлүк - менин оюмча, ар бир иштеп чыгуучуңуз өзүнүн потенциалын пландап, кандайдыр бир ыктымалдуулук менен ката кетиргендин ордуна, мындай функцияларды колдонуу сиздин көйгөйүңүздү чечүүгө ылайыктуураак болот.
текшерүү үчүн эмне керек?
Кантип текшерүү керек? Балким, андай эмес.
Графанада сыноо катары.
Ал эми Grafana жөнүндө эмне айтууга болот? Grafana бул суроону түздөн-түз DataSourceке которот.
Параметрлерге бир аз кошуу менен.
Жок, Grafana эч нерсе кошулбайт. кадам сыяктуу GET параметрлери болушу мүмкүн. Бул ачык көрсөтүлгөн эмес, бирок сиз аны жокко чыгара аласыз, аны жокко чыгара албайсыз, бирок ал автоматтык түрдө кошулат. Сиз бул жерге тест жазбайсыз. Бул жерде чындыктын булагы катары Графанага таянбашыңыз керек деп ойлойм.
Баяндама үчүн рахмат! Компресс үчүн рахмат! Графикте өзгөрмөнүн картасын түзүү жөнүндө эсиңизде калдыңыз, Grafanaда өзгөрмөдө өзгөрмө колдоно албайсыз. Эмнени айткым келгенин түшүндүңүзбү?
Ооба.
Графанада эскертүү бергим келгенде, бул башында башым ооручу. Ал жерде сиз ар бир хост үчүн өзүнчө эскертүү беришиңиз керек. Бул сиз жасаган нерсе, ал Графанада эскертүүлөр үчүн иштейби?
Эгерде Grafana өзгөрмөлөргө башка жол менен кирбесе, анда ооба, ал иштейт. Бирок менин кеңешим - Grafanaда эскертүүнү такыр колдонбоңуз, alertmanagerди колдонсоңуз жакшы болот.
Ооба, мен аны колдоном, бирок аны Grafanaда орнотуу оңой көрүндү, бирок кеңешиңиз үчүн рахмат!
Source: www.habr.com