Ju rekomandoj që të njihem me interpretimin e referatit të Roman Havronenkos "ExtendedPromQL"
Përshkrim i shkurtër mbi mua. Më quajnë Roman. Punoj në CloudFlare, jetoj në Londër. Por gjithashtu jam mbajtës i VictoriaMetrics.
Dhe unë jam autori për Grafana dhe – ky është një proxy i vogël për ClickHouse.
Do të fillojmë me pjesën e parë, e cila quhet "Sfidat e përkthimit" dhe në të do të flas për faktin se çdo gjuhë, ose madje edhe thjesht një gjuhë komunikimi, është shumë e rëndësishme. Sepse kjo është mënyra se si i transmetoni një personi tjetër ose një sistemi mendimet tuaja, si formulohet kërkesa. Njerëzit në internet debatojnë se cila gjuhë është më e mirë – java apo ndonjë tjetër. Për veten time, vendosa të zgjedh sipas qëllimit, sepse të gjitha këto janë të specifikuara.
Të fillojmë nga fillimi. Çfarë është PromQL? PromQL – është Gjuha e Kërkimeve të Prometheus. Kjo është mënyra se si formulojmë kërkesat në Prometheus për të marrë të dhënat e serive temporale.
Çfarë janë të dhënat e serive temporale? Në përkthim të saktë, ato janë tri parametra.
Këto janë:
- Në çfarë po shohim.
- Kur po shohim këtë.
- Dhe çfarë vlerë tregon.
Nëse shikojmë këtë grafik (ky grafik është nga telefoni im, që tregon statistikën e hapave të mi), atëherë këtu mund të përgjigjemi shpejt për këto pyetje.
Ne shohim hapet. Ne shohim vlerën dhe shohim kohën kur e shohim këtë. Pra, duke parë këtë grafik është lehtë të thuash se në të dielë bëra rreth 15,000 hapa. Këto janë të dhënat e serive temporale.
Tani le të "ndarim" (transformojmë) ato në një model të dhënash tjetër si një tabelë. Këtu po ashtu kemi atë që shohim. Këtu kam shtuar disa të dhëna shtesë, të cilat do t’i quajmë meta-të dhëna, pra këtu nuk jam unë, por dy persona, le të themi, Jay dhe Silent Bob. Këto janë ato që shohim; çfarë tregon dhe kur tregon këtë vlerë.
Tani le të përpiqemi t'i ruajmë të gjitha këto të dhëna në një bazë të dhënash. Si shembull, kam marrë sintaksën e ClickHouse. Dhe këtu krijojmë një tabelë, e cila quhet "Steps", pra çfarë po shohim. Këtu ka kohën kur shohim këtë; çfarë tregon dhe disa meta-të dhëna, ku do të ruajmë, kush janë: Jay dhe Silent Bob.
Dhe për të përpiquar të vizualizojmë gjithçka, do të përdorim Grafana, sepse, së pari, është e bukur.
Gjithashtu do të përdorim këtë plugin. Ka dy arsye. E para – sepse e kam shkruar unë. Dhe e di saktësisht sa e vështirë është të nxjerrësh të dhënat e serive temporale nga ClickHouse për t'i treguar në Grafana.
Ne do ta shfaqim në Graph Panel. Kjo është paneli më i njohur në Grafana, i cili tregon varësinë e vlerës nga koha, kështu që na nevojiten vetëm dy parametra.
Le të shkruajmë kërkesën më të thjeshtë — si të tregojmë statistikat e hapave në Grafana, duke ruajtur këto të dhëna në ClickHouse, në tabelën që krijuam. Dhe shkruajmë këtë kërkesë të thjeshtë. Ne seçim nga hapat. Ne selektojmë vlerën dhe kohën e këtyre vlerave, pra ato tri parametra që thaëm.
Dhe si rezultat do të marrim këtë grafik. Kush e di pse është kaq i çuditshëm?
Saktë, duhet ta rendisim sipas kohës.
Dhe në fund do të marrim një grafik më të mirë, por ende të çuditshëm. Kush e di pse? Saktë, ka dy pjesëmarrës, dhe ne në Grafana japim dy seritë temporale, sepse nëse merremi me modelin e të dhënave sërish, secila seri temporale është një kombinim unik i emrit dhe të gjitha çelësve-vlerave etiketat.
Pra, duhet të zgjidhim një person të veçantë. Ne zgjedhim Jay.
Dhe e vizatojmë përsëri. Tani grafiku tashmë duket si e vërteta. Tani është një grafik normal dhe gjithçka punon mirë.
Dhe ndoshta e dini si të bëni më ose pak më ndryshe, por në Prometheus përmes PromQL. Pjesërisht kështu. Pak më e thjeshtë. Dhe gjithashtu do ta ndajmë këtë. Ne morëm Hapat. Dhe e filtrojmë sipas Jay. Këtu nuk po tregojmë se duam të marrim vlerën dhe nuk po zgjedhim kohën.
Tani le ta përpiqemi të llogarisim shpejtësinë e lëvizjes së Jay ose Silent Bob. Në ClickHouse do të na nevojitet të bëjmë runningDifference, pra të llogarisim ndryshimin midis çiftit të pikave dhe ta ndajmë me kohën, për të marrë shpejtësinë e saktë. Kërkesa do të duket disi kështu.
Dhe do të tregojë ndoshta këto vlera, pra rreth 1.8 hapa në sekondë bën Silent Bob ose Jay.
Dhe në Prometheus e dini si ta bëni këtë gjithashtu. Shumë më e lehtë se sa ishte më parë.
Dhe që të vazhdojë të jetë po aq e lehtë për t’u bërë në Grafana, unë shtova një mbështjellës të tillë, i cili duket shumë si PromQL. Quhet Rate Macros ose si dëshiron ta quash. Në Grafana ju shkruani thjesht "rate", por diku në thellësi ajo transformohet në një kërkesë të tillë të madhe. Dhe nuk keni nevojë as ta shikoni, ajo është diku atje, por kurseni shumë kohë, sepse të shkruash kërkesa të tilla të mëdha SQL është gjithmonë ndyshëm e shtrenjta. Ju mund të gaboni lehtësisht dhe më pas të mos kuptoni për një kohë të gjatë se çfarë po ndodh.
Dhe kjo është një kërkesë që nuk arriti as të vendoset në një slide dhe më duhej ta ndaj në dy kolona. Kjo gjithashtu është një kërkesë në ClickHouse, e cila bën të njëjtën gjë rate, por për të dyja time series: Silent Bob dhe Jay, në mënyrë që në panelin tonë të kemi dy time series. Dhe kjo është tashmë shumë e komplikuar, sipas mendimit tim.
Dhe për Prometheus kjo do të jetë sum (rate). Për ClickHouse kam bërë një makros të veçantë, i quajtur RateColumns, e cila duket si një kërkesë në Prometheus.
Ne shikuam dhe dukej se PromQL ishte shumë i bukur, por ka, sigurisht, kufizime.
Këto janë:
- SELECT i kufizuar.
- JOIN-et e kufizuara.
- Nuk ka mbështetje për HAVING.
Dhe nëse keni punuar me të për një kohë të gjatë, e dini se ndonjëherë është shumë e vështirë të bëni diçka në PromQL, ndërsa në SQL mund të bëni praktikisht gjithçka, sepse të gjitha këto variante, për të cilat po flasim tani, mund të ishin bërë në SQL. Por a do të ishte e rehatshme ta përdorni këtë? Dhe kjo më shtyn të mendoj se nuk është gjithmonë gjuha më e fuqishme ajo që mund të jetë më e rehatshme.
Prandaj, ndonjëherë duhet të zgjidhni gjuhën sipas detyrave. Kjo është si një betejë midis Batman dhe Superman. E qartë se Superman është më i fortë, por Batman arriti ta mundë atë, sepse ishte më praktik dhe e dinte saktësisht se çfarë po bënte.
Dhe pjesa tjetër është – Zgjerimi i PromQL.
Përsëri për VictoriaMetrics. Çfarë është VictoriaMetrics? Është një bazë të dhënash time series, është OpenSource, ne e distribuitohemi në versione single dhe cluster. Sipas banchmark-eve tona, ajo është më e shpejtë se çdo gjë tjetër në treg tani dhe po ashtu për kompresimin, pra, njerëzit e gjallë raportojnë kompresionin diku në 0,4 byte për pikë, kur Prometheus është 1,2-1,4.
Ne mbështesim jo vetëm Prometheus. Ne mbështesim InfluxDB, Graphite, OpenTSDB.
Mund të "shkruani" në ne, pra, mund të transferoni të dhënat e vjetra.
Dhe gjithashtu ne funksionojmë perfekt me Prometheus dhe Grafana, pra, ne mbështesim motorin PromQL. Dhe në Grafana, ju thjesht mund të ndërroni endpoint-in e Prometheus me VictoriaMetrics dhe të gjithë dashboard-et tuaj do të funksionojnë ashtu siç kanë funksionuar.
Por mund të përdorni edhe funksione shtesë që i jep VictoriaMetrics.
Do të kalojmë shpejt nëpër funksionet që ne kemi shtuar.
Omit interval param – mund të kaloni parametrin e intervalit në Grafana. Kur nuk doni të merrni grafikë të çuditshme kur bëni zoom-in/out në panel, është e rekomanduar të përdorni variablën $__interval. Kjo është një variablë e brendshme në Grafana dhe ajo vetë zgjedh intervalin e të dhënave. Dhe VictoriaMetrics mund ta kuptojë vetë se si duhet të jetë ky interval. Dhe nuk keni nevojë ta ribashkoni të gjitha kërkesat tuaja. Do të jetë shumë më e lehtë.
Funksioni i dytë është referenca e intervalit. Mund të përdorni këtë interval në shprehjet tuaja. Mund të shumëzoni, ndaheni, e referoni atë.
Më pas, familja e funksioneve rollup. Funksioni rollup transformon çdo time series tuaj në tre time series të veçanta. Kjo është min, max dhe avg. Unë mendoj se është shumë e rehatshme, sepse ndonjëherë kjo mund të tregojë ndonjë anomalitë dhe imprecisions.
Dhe nëse thjesht bëni irate ose rate, ndoshta mund të humbni ndonjë rast kur time series e ka sjelljen ndryshe nga ajo që keni supozuar. Me këtë funksion është shumë më e lehtë të shihni, për shembull, se max është shumë larg avg.
Më pas variabla default. Default – do të thotë, cila është vlera që duhet të vizatojmë në Grafana, nëse nuk kemi time series në këtë moment. Kur ndodh kjo? Supozoni se ju eksportoni një metrikë për gabimet. Dhe keni një aplikacion kaq të shkëlqyer, sa që kur e filloni, nuk keni gabime dhe as që nuk ka gabime në tre orët e ardhshme ose madje një ditë. Dhe keni dashboard-e që tregojnë marrëdhënien mes suksesit dhe gabimit. Dhe ata do t'ju tregojnë asgjë, sepse nuk keni metrikë për gabimet. Por në default mund të tregoni çfarëdo.
Keep_last_Value – ruan vlerën e fundit të metrikës, nëse ajo ka humbur. Nëse Prometheus nuk e gjen atë në 5 minuta pas skrapit të ardhshëm, këtu do të mbajmë vlerën e saj të fundit dhe grafikët tuaj përsëri nuk do të prishen.
Scrape_interval – tregon sa shpesh Prometheus mbledh të dhënat për metrikën tuaj, me çfarë frekuence. Këtu mund të shihni ndonjë humbje, për shembull.
Label replace – funksion popullor. Por ne mendojmë se është paksa e komplikuar, sepse ai merr shumë argumente. Dhe ju duhet jo vetëm të mbani mend 5 argumente, por gjithashtu të mbani mend radhën e tyre.
Prandaj, pse të mos i bëjmë ato më të thjeshta? Pra, t’i ndajmë në funksione të vogla me sintaksë të qartë.
Dhe tani vjen pjesa më interesante. Pse ne mendojmë që kjo është PromQL e zgjeruar? Sepse mbështesim Shprehjet e Tabelave të Zakonshme. Mund të kaloni përmes QR-kodit (), shikoni lidhjet me shembuj, me një playground, ku mund të bëni kërkesa drejtpërdrejt në VictoriaMetrics pa e instaluar atë, thjesht në shfletuesin tuaj.
Dhe çfarë është kjo? Ky kërkesë lart – është një kërkesë mjaft e njohur. Mendoj se në çdo panel të shumë kompanive përdorni të njëjtin filtrin për gjithçka. Zakonisht bëhet kështu. Por kur ju nevojitet të shtoni ndonjë filtrin të ri, ju duhet të azhurnoni çdo panel, ose të shkarkoni dashboard-in, ta hapni në JSON, të bëni find replace, që gjithashtu merr kohë. Pse të mos e ruani këtë vlerë në një variabël dhe ta rishfrytëzoni atë? Më duket se kjo është shumë më e thjeshtë dhe e qartë.
Për shembull, kur duhet të azhurnoj filtrat në Grafana për të gjitha kërkesat, dhe dashboard-i mund të jetë i madh ose mund të ketë edhe disa. Si do të doja ta zgjidhja këtë problem në Grafana?
E zgjidh këtë problem kështu: krijoj commonFilter dhe në të përcaktoj këtë filtrin, e pastaj e rishfrytëzoj në kërkesa. Por nëse tani e bëni njësoj, kjo nuk do të funksionojë, sepse Grafana nuk lejon që të përdorni variablat brenda kërkesave të variablave. Dhe kjo është pak e çuditshme.
Prandaj krijova një variant që lejon këtë. Nëse jeni të interesuar ose doni një veçori të tillë, mbështetni ose jepni një dislike nëse kjo ide nuk ju pëlqen.
Më tutje në lidhje me PromQL të zgjeruar. Këtu ne përcaktojmë jo vetëm një variabël, por një funksion të tërë. E quajmë atë ru (resource usage). Ky funksion pranon burimet e lira, kufizimin e burimit dhe filtrin. Duket se sintaksa është mjaft e thjeshtë. Edhe shumë e lehtë për të përdorur këtë funksion dhe për të llogaritur përqindjen e memories së lirë. Pra, sa kemi memories, çfarë kufizimi kemi dhe si ta filtrojmë. Kjo duket shumë më e përshtatshme, nëse do t'ju duhej të shkruanit të gjitha këto, duke rishfrytëzuar të njëjtat filtra, sepse do të shndërrohej në një kërkesë shumë të madhe.
Dhe ja një shembull i një kërkese shumë të madhe. Ai vjen nga dashboard-i zyrtar NodeExporter për Grafana. Por unë nuk e kuptoj shumë se çfarë po ndodh këtu. Sigurisht, e kuptoj nëse e shoh me kujdes, por numri i kllapave mund të zvogëlojë menjëherë motivimin për të kuptuar se çfarë po ndodh këtu. Pse të mos e bëjmë atë më të thjeshtë dhe më të qartë?
Për shembull, kështu, duke e ndarë atë në gjëra ose pjesë thelbësore në variabla. Dhe pastaj të bëj matematikën time bazike. Kjo është më e ngjashme me programimin, kjo është ajo që unë do të doja të shihja në të ardhmen në Grafana.
Ja një shembull tjetër, se si mund ta bëjmë edhe më të lehtë, nëse do të kishim këtë funksion ru, dhe ai tashmë është në VictoriaMetrics. Dhe ju atëherë thjesht kaloni vlerën e ruajtur që keni shpallur në CTE.
Kam folur tashmë se sa e rëndësishme është të përdorësh gjuhën e duhur të programimit. Dhe ndoshta në çdo kompani në Grafana ndodhin gjëra të ndryshme. Dhe ndoshta ju gjithashtu u jepni qasje zhvilluesve tuaj në Grafana, dhe zhvilluesit bëjnë diçka të tyre. Dhe të gjithë e bëjnë atë ndryshe. Do të ishte mirë që ta zbresim këtë në një standard të përbashkët.
Supozoni se keni jo vetëm inxhinierë sistemesh, ndoshta keni edhe ekspertë, devops ose SRE. Mund të keni ekspertë që e dinë se çfarë është monitorimi, e dinë se çfarë është Grafana, pra, ata punojnë me këtë për vite me radhë dhe ata me siguri e dinë si ta bëjnë siç duhet. Dhe ata e kanë shkruar këtë 100 herë dhe e kanë shpjeguar të gjithëve, por për ndonjë arsye, askush nuk dëgjon.
Por çfarë do të ndodhte, nëse ata do të mund ta vendosin këtë njohuri direkt në Grafana, që përdoruesit e tjerë të mund të rishfrytëzojnë funksionet? Dhe nëse do të duhej të llogarisnin përqindjen e memories së lirë, ata do të thoshin thjesht ta aplikonin funksionin. Çfarë, nëse krijuesit e eksportuesve, së bashku me produktin e tyre, ofronin gjithashtu një grup funksionesh, si të punoni me metrikat e tyre, sepse ata e dinë me siguri se çfarë janë ato metrika dhe si të llogariten siç duhet?
Në fakt, kjo nuk ekziston. Këtë e kam bërë vetë. Kjo është mbështetja e librarive në Grafana. Supozoni, djemtë që krijuan NodeExporter, bënë atë që kam treguar. Dhe ofruan gjithashtu një grup funksionesh.
Pra, duket kështu. Ju lidheni me këtë bibliotekë në Grafana, hyni në redaktim dhe këtu është shumë e thjeshtë shkruar në JSON, se si të punoni me këtë metrikë. Pra, një grup funksionesh, përshkrimi i tyre dhe si ato zgjidhen.
Më duket se kjo do të ishte e dobishme, sepse atëherë në Grafana do të shkruanit thjesht kështu. Dhe Grafana do t'ju "thonte" se ka një funksion të tillë nga kjo bibliotekë – le të përdorim atë. Më duket se do të ishte shumë e shkëlqyer.
Pak pak për VictoriaMetrics. Ne bëjmë shumë gjëra interesante. Lexoni artikujt tanë mbi compression, konkurrencat tona me aplikacionet e tjera të dhënash time series, shpjegimin tonë se si të punoni me PromQL, sepse ka shumë fillestarë akoma, si dhe mbi vertical scalability dhe përballjen me Thanos.
Pyetje:
Do ta filloj pyetjen time me një histori të thjeshtë nga jeta. Kur fillova për herë të parë të përdorja Grafana, shkrova një kërkesë shumë të besueshme me gjatësi 5 rreshta. Në fund doli një grafik shumë i pranueshëm. Ky grafik pothuajse shkoi në production. Por, duke e parë nga afër, u zbulua se ky grafik tregonte një patate njëmijë, që nuk kishte asnjë lidhje me realitetin, megjithëse numrat bien brenda kufijve që ne prisnim të shihnim. Dhe pyetja ime është: ne kemi biblioteka, kemi funksione, por si shkruajmë teste për Grafana? Keni shkruar një kërkesë të komplikuar, e cila varet nga një vendim biznesi – të porositni një enë reale serverash ose jo. Dhe si e dimë se ajo funksion që vizaton grafikun duket si e vërtetë. Faleminderit.
Faleminderit për pyetjen. Këtu ka dy pjesë. E para – më duket, nga përvoja ime, se shumica e përdoruesve, kur shohin grafikët e tyre, nuk kuptojnë se çfarë u tregojnë ata. Për ndonjë arsye, njerëzit janë shumë të mirë për të gjetur justifikime për çdo anomalie që ndodh në grafikë, madje edhe nëse është një gabim brenda funksionit. Dhe pjesa e dytë – mendoj se përdorimi i këtyre funksioneve do të ishte shumë më i përshtatshëm për zgjidhjen e problemit tuaj, në vend që çdo zhvillues të bënte planifikimin e kapacitetit dhe të gabonte me ndonjë probabilitet.
Si ta kontrollojmë?
Si ta kontrollojmë? Ndoshta, ashtu.
Në formën e një testi në Grafana.
Çfarë lidhet me Grafana? Grafana transmeton këtë kërkesë menjëherë në DataSource.
Duke shtuar pak në parametrat.
Jo, në Grafana nuk shtojnë asgjë. Mund të ketë parametra GET, si për shembull, step. Ai nuk tregohet qartë, por ju mund ta tejkaloni, mund edhe të mos e tejkaloni, por ai shtohet automatikisht. Këtu nuk do të shkruani teste. Mendoj se nuk ia vlen të besoni Grafana si burimi i të vërtetës.
Faleminderit për raportin! Faleminderit për compression! Ju përmendët lidhjen e variableve në grafik, se në Grafana nuk mund të përdoren variabla brenda variablave. A e kuptoni çfarë kam parasysh?
Po.
Kjo ishte fillimisht një dhimbje koke, kur doja të bëja një alert në Grafana. Dhe atje duhet të bësh një alert për çdo host veç e veç. A funksionon kjo gjë që bëtë për alertet në Grafana?
Nëse Grafana nuk i qaset variablave ndryshe, atëherë po, ajo do të funksionojë. Por këshilla ime është të mos përdorni alarmin në Grafana fare, më mirë të përdorni alertmanager.
Po, unë e përdor, por thjesht dukej më e lehtë për t'u konfiguruar në Grafana, por faleminderit për këshillën!
Burimi: habr.com
