Iminumungkahi kong basahin ang transcript ng ulat ni Roman Khavronenko "ExtendedPromQL"
Maikling tungkol sa akin. Roman ang pangalan ko. Nagtatrabaho ako sa CloudFlare at nakatira sa London. Ngunit isa rin akong tagapangasiwa ng VictoriaMetrics.
At ako ang may akda para sa Grafana at ay isang maliit na proxy para sa ClickHouse.
Magsisimula tayo sa unang bahagi, na tinatawag na "Mga Kahirapan sa Pagsasalin", at dito ay pag-uusapan ko ang katotohanan na ang anumang wika o kahit na isang wika lamang ng komunikasyon ay napakahalaga. Dahil ito ang paraan kung paano mo ipaparating ang iyong mga saloobin sa ibang tao o sistema, kung paano ka bumalangkas ng isang kahilingan. Ang mga tao sa Internet ay nagtatalo tungkol sa kung aling wika ang mas mahusay - java o iba pa. Para sa aking sarili, napagpasyahan ko na kinakailangan na pumili ng isang gawain, dahil ang lahat ng ito ay tiyak.
Magsimula tayo sa simula pa lang. Ano ang PromQL? Ang PromQL ay Prometheus Query Language. Ganito kami bumubuo ng mga query sa Prometheus para makakuha ng data ng time series, time series.
Ano ang data ng serye ng oras? Sa literal, ito ay tatlong mga parameter.
Ang mga ito ay:
- Ano ang tinitingnan namin.
- Pag tingin namin.
- At anong halaga ang ipinapakita nito.
Kung titingnan mo ang chart na ito (ang chart na ito ay mula sa aking telepono, na nagpapakita ng mga istatistika ng aking mga hakbang), pagkatapos dito ay mabilis mong masasagot ang mga tanong na ito.
Tinitingnan namin ang mga hakbang. Nakikita natin ang kahulugan at nakikita natin ang oras kapag tinitingnan natin ito. Iyon ay, sa pagtingin sa diagram na ito, madali mong masasabi na noong Linggo ay lumakad ako ng mga 15 hakbang. Ito ay data ng serye ng oras.
Ngayon ay "i-break" (ibahin) natin ang mga ito sa isa pang modelo ng data sa anyo ng isang talahanayan. Narito din ang aming tinitingnan. Dito ako nagdagdag ng kaunting karagdagang data, na tatawagin nating meta-data, ibig sabihin, hindi ako ang dumaan, kundi dalawang tao, halimbawa, si Jay at Silent Bob. Ito ang aming tinitingnan; kung ano ang ipinapakita nito at kung kailan ito nagpapakita ng halaga.
Ngayon subukan nating iimbak ang lahat ng data na ito sa database. Halimbawa, kinuha ko ang ClickHouse syntax. At narito kami ay lumilikha ng isang talahanayan na tinatawag na "Mga Hakbang", ibig sabihin, kung ano ang aming tinitingnan. May panahon dito kung titingnan natin ito; kung ano ang ipinapakita nito at ilang meta-data kung saan iimbak kung sino ito: Jay at Silent Bob.
At upang subukang mailarawan ang lahat, gagamitin namin ang Grafana, dahil, una, ito ay maganda.
Gagamitin din namin ang plugin na ito. Mayroong dalawang dahilan para dito. Ang una ay dahil sinulat ko ito. At alam kong eksakto kung gaano kahirap bumunot ng data ng time series mula sa ClickHouse para ipakita ito sa Grafana.
Ipapakita namin sa Graph Panel. Ito ang pinakasikat na panel sa Grafana at nagpapakita ng halaga kumpara sa oras, kaya dalawang parameter lang ang kailangan namin.
Isulat natin ang pinakasimpleng query - kung paano ipakita ang mga istatistika ng hakbang sa Grafana, na iniimbak ang data na ito sa ClickHouse, sa talahanayan na aming ginawa. At nagsusulat kami ng isang simpleng query. Pumili kami mula sa mga hakbang. Pumili kami ng value at pipiliin ang oras ng mga value na ito, ibig sabihin, ang parehong tatlong parameter na pinag-usapan namin.
At bilang resulta, nakukuha namin ang graph na ito. Sino ang nakakaalam kung bakit siya kakaiba?
Tama, kailangan mong ayusin ayon sa oras.
At sa huli nakakakuha kami ng mas mahusay, ngunit kakaiba pa rin ang iskedyul. Sino ang nakakaalam kung bakit? Tama, mayroong dalawang kalahok, at namimigay kami ng dalawang serye ng oras sa Grafana, dahil kung haharapin namin muli ang modelo ng data, kung gayon ang bawat serye ng oras ay isang natatanging kumbinasyon ng isang pangalan at lahat ng mga key-values ββng label.
Samakatuwid, kailangan nating pumili ng isang tiyak na tao. Si Jay ang pipiliin namin.
At gumuhit muli. Ngayon ang graph ay mukhang katotohanan. Ngayon ito ay isang normal na iskedyul at lahat ay gumagana nang maayos.
At, malamang, alam mo kung paano gawin ang tungkol sa parehong bagay, ngunit sa Prometheus sa pamamagitan ng PromQL. Halos ganito. Medyo mas madali. At buwagin natin ang lahat. Gumawa kami ng mga Hakbang. At salain ni Jay. Hindi namin tinukoy dito na kailangan naming makakuha ng halaga at hindi kami pumili ng oras.
Ngayon subukan nating kalkulahin ang bilis ng paggalaw ni Jay o Silent Bob. Sa ClickHouse, kakailanganin naming gawin ang runningDifference, ibig sabihin, kalkulahin ang pagkakaiba sa pagitan ng mga pares ng mga puntos at hatiin ang mga ito sa oras upang makuha ang eksaktong bilis. Magiging ganito ang hitsura ng kahilingan.
At ipapakita niya ang humigit-kumulang na mga halagang ito, ibig sabihin, humigit-kumulang 1,8 hakbang bawat segundo ang ginagawa ng Silent Bob o Jay.
At sa Prometheus alam mo rin kung paano gawin ito. Mas madali kaysa dati.
At para maging madali din itong gawin sa Grafana, nagdagdag ako ng ganitong wrapper na halos kamukha ng PromQL. Ito ay tinatawag na Rate Macros, o kahit anong gusto mong tawag dito. Sa Grafana, isusulat mo lang ang "rate", ngunit sa isang lugar sa kaibuturan ito ay nagiging isang malaking kahilingan. At hindi mo na kailangang tingnan ito, naroroon ito sa isang lugar, ngunit nakakatipid ka ng maraming oras, dahil ang pagsusulat ng napakalaking mga query sa SQL ay palaging mahal. Madali kang magkamali at pagkatapos ay hindi mo maintindihan kung ano ang nangyayari sa mahabang panahon.
At ito ay isang query na hindi man lang magkasya sa isang slide, at kinailangan ko pang hatiin ito sa dalawang column. Isa rin itong kahilingan sa ClickHouse, na gumagawa ng parehong rate, ngunit para sa parehong serye ng oras: Silent Bob at Jay, upang magkaroon kami ng dalawang time series sa panel. At ito ay napakahirap, sa aking opinyon.
At ayon kay Prometheus ito ay magiging sum (rate). Para sa ClickHouse gumawa ako ng hiwalay na macro na tinatawag na RateColumns na mukhang isang Prometheus query.
Tiningnan namin at tila napakaganda ng PromQL, ngunit mayroon itong, siyempre, mga limitasyon.
Ang mga ito ay:
- Limitadong PILI.
- Mga SUMALI sa Edge.
- Walang HAVING support.
At kung matagal mo nang pinagtatrabahuhan ito, alam mo na kung minsan napakahirap gumawa ng isang bagay sa PromQL, at sa SQL magagawa mo ang halos lahat, dahil lahat ng mga pagpipiliang ito na napag-usapan lang natin ay maaaring gawin sa SQL . Ngunit magiging maginhawa bang gamitin ito? At ito ang nagpapaisip sa akin na hindi palaging ang pinakamakapangyarihang wika ang pinakamaginhawa.
Samakatuwid, kung minsan kailangan mong pumili ng isang wika para sa mga gawain. Parang labanan ni Batman at Superman. Malinaw na mas malakas si Superman, ngunit nagawang talunin siya ni Batman dahil mas praktikal siya at alam kung ano ang kanyang ginagawa.
At ang susunod na bahagi ay Extending PromQL.
Muli tungkol sa VictoriaMetrics. Ano ang VictoriaMetrics? Ito ay isang database ng serye ng oras, ito ay nasa OpenSource, ipinamahagi namin ang mga bersyon ng solo at cluster nito. Ayon sa aming mga benchmark, ito ang pinakamabilis na nasa merkado ngayon at ito ay katulad sa mga tuntunin ng compression, ibig sabihin, ang mga nabubuhay na tao ay nag-uulat ng compression na humigit-kumulang 0,4 bytes bawat punto, kapag ang Prometheus ay may 1,2-1,4.
Sinusuportahan namin hindi lamang ang Prometheus. Sinusuportahan namin ang InfluxDB, Graphite, OpenTSDB.
Maaari kang "magsulat" sa amin, iyon ay, maaari kang maglipat ng lumang data.
At perpektong gumagana rin kami sa Prometheus at Grafana, ibig sabihin, sinusuportahan namin ang PromQL engine. At sa Grafana, maaari mo lang baguhin ang Prometheus endpoint sa VictoriaMetrics at gagana ang lahat ng iyong dashboard tulad ng ginawa nila.
Ngunit maaari ka ring gumamit ng mga karagdagang chip na ibinigay ng VictoriaMetrics.
Mabilis naming dadaan ang mga tampok na idinagdag namin.
Alisin ang interval param - maaari mong laktawan ang pagitan ng parameter sa Grafana. Kapag ayaw mong makakuha ng kakaibang mga graph kapag nag-zoom-in/out sa panel, inirerekomendang gamitin ang variable $__interval. Ito ay isang panloob na pagbabago ng Grafana at pinipili nito ang mismong hanay ng data. At mauunawaan mismo ng VictoriaMetrics kung ano dapat ang hanay na ito. At hindi mo kailangang i-update ang lahat ng iyong mga query. Ito ay magiging mas madali.
Ang pangalawang function ay ang interval reference. Maaari mong gamitin ang puwang na ito sa iyong mga expression. Maaari mong i-multiply, hatiin, ilipat, sumangguni dito.
Susunod ay ang rollup function na pamilya. Binabago ng rollup function ang alinman sa iyong time series sa tatlong magkakahiwalay na time series. Ang mga ito ay min, max at avg. Sa tingin ko ito ay napaka-maginhawa, dahil kung minsan maaari itong magpakita ng ilang mga outlier (anomalya) at mga kamalian.
At kung irate o rate lang ang ginagawa mo, malamang na makaligtaan mo ang ilang kaso kung saan hindi kumikilos ang time series sa paraang nilayon mo. Ito ay mas madaling makita gamit ang function na ito, sabihin nating ang max ay napaka-off avg.
Susunod ay ang default na variable. Default - nangangahulugan ito kung anong halaga ang kailangan nating iguhit sa Grafana kung wala tayong time series sa ngayon. Kailan ito mangyayari? Sabihin nating nag-export ka ng ilang sukatan ng error. At mayroon kang isang cool na application na kapag nagsimula ka, wala kang mga error at kahit na walang mga error para sa susunod na tatlong oras o kahit isang araw. At mayroon kang mga dashboard na nagpapakita ng mga ugnayan mula sa tagumpay hanggang sa pagkakamali. At wala silang ipapakita sa iyo dahil wala kang sukatan ng error. At sa default maaari mong tukuyin ang anuman.
Keep_last_Value - sine-save ang huling halaga ng sukatan kung nawawala ito. Kung hindi ito nakita ng Prometheus pagkatapos ng susunod na scrape sa loob ng 5 minuto, dito natin tatandaan ang huling halaga nito at hindi na muling masisira ang iyong mga chart.
Scrape_interval - ipinapakita kung gaano kadalas nangongolekta ang Prometheus ng data sa iyong sukatan, kung gaano kadalas. Dito makikita mo ang pass, halimbawa.
Ang pagpapalit ng label ay isang sikat na feature. Ngunit sa tingin namin ito ay medyo kumplikado dahil nangangailangan ito ng mga argumento ng integer. At kailangan mong hindi lamang matandaan ang 5 argumento, ngunit tandaan din ang kanilang pagkakasunud-sunod.
Samakatuwid, bakit hindi gawing mas simple ang mga ito? Iyon ay, hatiin ito sa maliliit na function na may malinaw na syntax.
At ngayon ang pinaka-kawili-wili. Bakit sa tingin namin ito ay pinalawig na PromQL? Dahil sinusuportahan namin ang Common Table Expressions. Maaari mong sundin ang QR code (), tingnan ang mga link na may mga halimbawa, mula sa playground, kung saan maaari kang magpatakbo ng mga query nang direkta sa VictoriaMetrics nang hindi ito ini-install sa browser lamang.
At ano ito? Ang kahilingang ito mula sa itaas ay medyo sikat na kahilingan. Sa tingin ko sa anumang dashboard sa maraming kumpanya ay ginagamit mo ang parehong filter para sa lahat. Kadalasan kaya. Ngunit kapag kailangan mong magdagdag ng ilang bagong filter, kailangan mong i-update ang bawat panel, o i-download ang dashboard, buksan ito sa JSON, gawin ang paghahanap na palitan, na nangangailangan din ng oras. Bakit hindi iimbak ang halagang ito sa isang variable at muling gamitin ito? Mukhang, sa aking opinyon, mas simple at mas malinaw.
Halimbawa, kapag kailangan kong i-update ang mga filter sa Grafana sa lahat ng mga kahilingan, at ang dashboard ay maaaring malaki o maaaring mayroong ilan sa mga ito. At paano ko gustong lutasin ang problemang ito sa Grafana?
Niresolba ko ang problemang ito tulad nito: Gumagawa ako ng commonFilter at tinutukoy ang filter na ito sa loob nito, at pagkatapos ay ginagamit ko itong muli sa mga query. Ngunit kung gayon din ang gagawin mo ngayon, hindi ito gagana dahil hindi ka pinapayagan ng Grafana na gumamit ng mga variable sa loob ng mga variable ng query. At medyo kakaiba.
At kaya gumawa ako ng opsyon na nagpapahintulot sa iyo na gawin ito. At kung interesado ka o gusto mo ng ganoong feature, suportahan o hindi gusto kung hindi mo gusto ang ideyang ito.
Higit pa tungkol sa PromQL extended. Dito namin tinukoy hindi lamang isang variable, ngunit direkta ng isang buong function. At tinatawag namin itong ru (paggamit ng mapagkukunan). At ang function na ito ay tumatanggap ng mga libreng mapagkukunan, isang limitasyon sa mapagkukunan, at isang filter. Ang syntax ay tila simple. At napakadaling gamitin ang function na ito at kalkulahin ang porsyento ng libreng memorya na mayroon kami. Iyon ay, kung gaano karaming memorya ang mayroon tayo, kung anong limitasyon at kung paano mag-filter. Mukhang mas maganda kung isusulat mo itong lahat gamit muli ang parehong mga filter, dahil ito ay magiging isang malaki, malaking query.
At narito ang isang halimbawa ng napakalaking kahilingan. Ito ay mula sa opisyal na NodeExporter dashboard para sa Grafana. Pero hindi ko talaga maintindihan kung ano ang nangyayari dito. Iyon ay, siyempre, naiintindihan ko kung titingnan mong mabuti, ngunit ang bilang ng mga bracket ay maaaring agad na mabawasan ang pagganyak upang maunawaan kung ano ang nangyayari dito. At bakit hindi gawin itong mas simple at mas malinaw?
Halimbawa, tulad nito, pag-highlight ng mga mahahalagang bagay o bahagi sa mga variable. At pagkatapos ay gawin ang iyong pangunahing matematika. Ito ay mas katulad ng programming, ito ang gusto kong makita sa hinaharap sa Grafana.
Narito ang pangalawang halimbawa ng kung paano namin ito mapapadali kung mayroon na kaming ru function na ito, at mayroon na itong direkta sa VictoriaMetrics. At pagkatapos ay ipapasa mo lang ang naka-cache na halaga na iyong idineklara sa CTE.
Napag-usapan ko na kung gaano kahalaga ang paggamit ng tamang programming language. At, malamang, may kakaibang nangyayari sa Grafana sa bawat kumpanya. At, malamang, nagbibigay ka pa rin ng access sa Grafana sa iyong mga developer, at ang mga developer ay gumagawa ng sarili nilang paraan. At lahat sila ay ginagawa ito sa ibang paraan. Ngunit gusto ko ito kahit papaano pareho, iyon ay, nabawasan sa isang karaniwang pamantayan.
Sabihin na nating wala ka lang system engineers, baka may mga expert ka pa, devops or SREs. Marahil mayroon kang mga eksperto na alam kung ano ang pagsubaybay, alam kung ano ang Grafana, ibig sabihin, nagtatrabaho sila dito sa loob ng maraming taon at alam nila kung paano ito gagawin nang tama. At naisulat na nila ito ng 100 beses at ipinaliwanag ito sa lahat, ngunit sa ilang kadahilanan ay walang nakikinig.
Paano kung mailalagay nila ang kaalamang ito nang direkta sa Grafana upang magamit muli ng ibang mga user ang mga function? At kung kinakailangan upang kalkulahin ang porsyento ng libreng memorya, pagkatapos ay ilalapat lamang nila ang function. Ngunit paano kung ang mga tagalikha ng mga exporter, kasama ang kanilang produkto, ay nagbigay din ng isang hanay ng mga function, kung paano gagana sa kanilang mga sukatan, dahil alam nila kung ano ang mga sukatan na ito at kung paano kalkulahin ang mga ito nang tama?
Ang isang ito ay hindi talaga umiiral. Narito ang ginawa ko sa aking sarili. Ito ang suporta sa library sa Grafana. Sabihin nating ginawa ng mga taong gumawa ng NodeExporter ang inilarawan ko. At nagbigay din ng isang hanay ng mga tampok.
Ibig sabihin, parang ganito. Ikinonekta mo ang library na ito sa Grafana, pupunta ka sa pag-edit, at narito, napakasimple sa JSON kung paano gagana sa sukatang ito. Iyon ay, ilang hanay ng mga pag-andar, ang kanilang paglalarawan at kung ano ang kanilang nalalahad.
Sa aking opinyon, ito ay maaaring maging kapaki-pakinabang, dahil pagkatapos ay magsusulat ka sa Grafana nang ganoon. At "sinasabi" sa iyo ni Grafana na mayroong ganoon at ganoong function mula sa ganoon at ganoong library - gamitin natin ito. Sa tingin ko iyon ay magiging napaka-cool.
Kaunti tungkol sa VictoriaMetrics. Gumagawa kami ng maraming kawili-wiling bagay. Basahin ang aming mga artikulo tungkol sa compression, tungkol sa aming kumpetisyon sa iba pang mga application ng data ng time series, ang aming paliwanag kung paano magtrabaho sa PromQL, dahil marami pang nagsisimula dito, pati na rin ang tungkol sa vertical scalability at tungkol sa paghaharap kay Thanos.
Tanong:
Sisimulan ko ang aking tanong sa isang simpleng kwento ng buhay. Noong una kong sinimulan ang paggamit ng Grafana, nagsulat ako ng isang napaka-mapanghikayat na 5 line query. Ang huling resulta ay isang napakakumbinsi na tsart. Ang graph na ito ay halos napunta sa produksyon. Ngunit sa mas malapit na pagsisiyasat, lumabas na ang tsart na ito ay nagpapakita ng ganap na katarantaduhan na walang kinalaman sa katotohanan, kahit na ang mga numero ay nahulog sa hanay na inaasahan naming makita. At ang tanong ko. Mayroon kaming mga aklatan, mayroon kaming mga function, ngunit paano kami magsusulat ng mga pagsubok para sa Grafana? Sumulat ka ng isang kumplikadong query na nakakaapekto sa desisyon ng negosyo - mag-order ng isang tunay na lalagyan ng mga server o hindi mag-order. At tulad ng alam natin, ang function na ito na gumuhit ng isang graph ay katulad ng katotohanan. Salamat.
Salamat sa tanong. Mayroong dalawang bahagi dito. Una, nakukuha ko ang impresyon, batay sa aking karanasan, na karamihan sa mga user, kapag tiningnan nila ang kanilang mga chart, ay hindi naiintindihan kung ano ang ipinapakita nila sa kanila. Kahit papaano, napakahusay ng mga tao sa pag-iisip ng dahilan para sa anumang anomalya na nangyayari sa mga chart, kahit na ito ay isang bug sa loob ng isang function. At ang pangalawang bahagi - tila sa akin na ang paggamit ng gayong mga pag-andar ay magiging mas angkop sa paglutas ng iyong problema, sa halip na ang bawat isa sa iyong mga developer ay gumagawa ng kanilang sariling pagpaplano ng kapasidad at paggawa ng mga pagkakamali na may ilang posibilidad.
Paano mag-check?
Paano suriin? Hindi siguro.
Bilang isang pagsubok sa Grafana.
At paano ang Grafana? Direktang isinasalin ng Grafana ang kahilingang ito sa DataSource.
Sa pamamagitan ng pagdaragdag ng kaunti sa mga parameter.
Hindi, walang idinagdag sa Grafana. Maaaring may mga parameter ng GET, tulad ng hakbang. Hindi ito tahasang tinukoy, ngunit maaari mo itong i-override, hindi mo ito ma-override, ngunit awtomatiko itong idinagdag. Hindi ka nagsusulat ng mga pagsubok dito. Sa palagay ko hindi ka dapat umasa sa Grafana dito bilang isang mapagkukunan ng katotohanan.
Salamat sa ulat! Salamat sa compression! Naalala mo ang tungkol sa pagmamapa ng variable sa isang graph, na sa Grafana hindi ka maaaring gumamit ng variable sa isang variable. Naiintindihan mo ba ang ibig kong sabihin?
Oo.
Ito ay sa una ay sakit ng ulo noong gusto kong gumawa ng alerto sa Grafana. At doon kailangan mong gumawa ng alerto para sa bawat host nang hiwalay. Narito ang bagay na ginawa mo, gumagana ba ito para sa mga alerto sa Grafana?
Kung hindi ma-access ng Grafana ang mga variable sa ibang paraan, oo, gagana ito. Ngunit ang payo ko ay huwag gumamit ng pag-alerto sa Grafana, mas mabuting gumamit ka ng alertmanager.
Oo, ginagamit ko ito, ngunit tila mas madaling i-set up sa Grafana, ngunit salamat sa tip!
Pinagmulan: www.habr.com