Ju lutem shqyrtoni interpretimin e raportit të Roman Khavronenko "ExtendedPromQL"
Përshkrim i shkurtër për 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 â Ă«shtĂ« njĂ« proxy i vogĂ«l pĂ«r ClickHouse.
Do tĂ« fillojmĂ« me pjesĂ«n e parĂ«, e cila quhet "VĂ«shtirĂ«sitĂ« e pĂ«rkthimit" dhe nĂ« tĂ« do tĂ« flas pĂ«r atĂ« se çdo gjuhĂ« ose madje edhe thjesht mĂ«nyra e komunikimit â Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme. Sepse kjo Ă«shtĂ« mĂ«nyra se si ju i pĂ«rcillni njĂ« personi tjetĂ«r ose njĂ« sistemi mendimet tuaja, si e formuloni kĂ«rkesĂ«n. NjerĂ«zit nĂ« internet debatojnĂ« pĂ«r atĂ« se cila gjuhĂ« Ă«shtĂ« mĂ« e mira â java apo ndonjĂ« tjetĂ«r. PĂ«r vete, vendosa tĂ« zgjedh sipas detyrĂ«s, sepse e gjithĂ« kjo Ă«shtĂ« specifike.
Le tĂ« fillojmĂ« nga fillimi. ĂfarĂ« Ă«shtĂ« PromQL? PromQL â Ă«shtĂ« Gjuha e KĂ«rkimeve Prometheus. Kjo Ă«shtĂ« mĂ«nyra se si formojmĂ« kĂ«rkesat nĂ« Prometheus, pĂ«r tĂ« marrĂ« tĂ« dhĂ«na serike temporale.
ĂfarĂ« janĂ« tĂ« dhĂ«nat serike temporale? NĂ«se e shohim literal, ato janĂ« tre parametra.
Ato janë:
- ĂfarĂ« po shohim.
- Kur po e shohim atë.
- Dhe çfarë vlere tregon.
Nëse e shikojmë këtë diagram (këtu janë të dhënat nga telefoni im që tregon statistikat e hapave të mi), mund të përgjigjemi shpejt në këto pyetje.
Po shohim hapa. Shohim vlerën dhe shohim kohën, kur po e shohim. Domethënë, duke e parë këtë diagram, është lehtë të thuash se të dielën kam kaluar rreth 15,000 hapa. Këto janë të dhëna serike temporale.
Tani le tĂ« "çpopullojmĂ«" (transformojmĂ«) ato nĂ« njĂ« model tjetĂ«r tĂ« dhĂ«nash nĂ« formĂ«n e njĂ« tabele. KĂ«tu gjithashtu kemi atĂ« qĂ« po shohim. KĂ«tu kam shtuar pak tĂ« dhĂ«na shtesĂ«, tĂ« cilat do tâi quajmĂ« meta-tĂ« dhĂ«na, dmth. nuk kam kaluar vetĂ«m unĂ«, por dy persona, le tĂ« themi, Jay dhe Silent Bob. Ky Ă«shtĂ« ai qĂ« po shohim; çfarĂ« tregon kjo dhe kur e 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. PĂ«r shembull, mora sintaksĂ«n e ClickHouse. Dhe kĂ«tu krijojmĂ« njĂ« tabelĂ« qĂ« quhet "Steps", dmth. çfarĂ« po shohim. Kemi kohĂ«n, kur po e shohim atĂ«; çfarĂ« tregon dhe disa meta-tĂ« dhĂ«na, ku do tĂ« ruajmĂ«, kush Ă«shtĂ«: Jay dhe Silent Bob.
Dhe për të përpiqur 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 pĂ«r kĂ«tĂ«. E para â sepse unĂ« e shkrova atĂ«. Dhe unĂ« e di mirĂ« se sa e vĂ«shtirĂ« Ă«shtĂ« tĂ« nxjerrĂ«sh tĂ« dhĂ«na time series nga ClickHouse, pĂ«r t'i treguar nĂ« Grafana.
Do ta tregojmë në Graph Panel. Kjo është paneli më popullor në Grafana, i cili tregon varësinë e vlerës nga koha, prandaj na duhen vetëm dy parametra.
Le tĂ« shkruajmĂ« kĂ«rkesĂ«n mĂ« tĂ« thjeshtĂ« â si tĂ« tregojmĂ« statistikat e hapave nĂ« Grafana, duke i ruajtur kĂ«to tĂ« dhĂ«na nĂ« ClickHouse, nĂ« atĂ« tabelĂ« qĂ« e krijuam. Dhe ne shkruajmĂ« njĂ« kĂ«rkesĂ« tĂ« tillĂ« tĂ« thjeshtĂ«. Ne zgjedhim nga hapat. Ne zgjedhim vlerĂ«n dhe zgjedhim kohĂ«n e kĂ«tyre vlerave, dmth ato tri parametra qĂ« kemi pĂ«rmendur.
Dhe rezultati do të jetë një grafik i tillë. Kush e di pse është kaq i çuditshëm?
Saktë, duhet ta rendisim sipas kohës.
Dhe në fund do të kemi një grafik më të mirë, por ende të çuditshëm. Kush e di pse? E saktë, ka dy pjesëmarrës, dhe ne në Grafana i japim dy time series, sepse nëse e shqyrtojmë modelin e të dhënave përsëri, çdo time series është një kombinim unik i emrit dhe të gjitha çelës-vlerave të etiketave.
Prandaj duhet të zgjedhim një person konkret. Ne zgjedhim Jay.
Dhe e vizatojmë përsëri. Tani grafiku duket më i vërtetë. Tani është një grafik normal dhe gjithçka funksionon mirë.
Dhe ndoshta e dini si ta bëni diçka të ngjashme në Prometheus përmes PromQL. Paksa kështu. Më e thjeshtë. Dhe gjithashtu do ta ndajmë këtë të gjitha. Ne merremi me Hapat. Dhe filtrojmë për Jay. Këtu nuk specifikojmë se duam të marrim vlerën dhe nuk zgjedhim kohën.
Tani le të provojmë të llogarisim shpejtësinë e lëvizjes së Jay ose Silent Bob. Në ClickHouse do të duhet të bëjmë runningDifference, dmth të llogarisim diferencën midis çifteve të pikave dhe t'i ndajmë ato me kohën, për të marrë shpejtësinë e saktë. Kërkesa do të duket pak a shumë kështu.
Dhe do të tregojë vlera të tilla, dmth Silent Bob ose Jay bëjnë përafërsisht 1.8 hapa në sekondë.
Dhe në Prometheus e dini si ta bëni këtë gjithashtu. Më e lehtë se sa ishte më parë.
Dhe qĂ« tĂ« mbetet gjithashtu e lehtĂ« pĂ«r t'u bĂ«rĂ« nĂ« Grafana, kam shtuar kĂ«tĂ« mbĂ«shtjellĂ«s, qĂ« duket shumĂ« si PromQL. E quajmĂ« Rate Macros ose si tĂ« doni ta quani. NĂ« Grafana shkruani thjesht «rate», por diku thellĂ« ajo transformohet nĂ« njĂ« pyetje tĂ« madhe. Dhe nuk keni nevojĂ« ta shikoni atĂ«, ajo Ă«shtĂ« diku aty, por ju kurseni shumĂ« kohĂ«, sepse tĂ« shkruani pyetje kaq tĂ« mĂ«dha SQL â Ă«shtĂ« gjithmonĂ« e shtrenjtĂ«. Ju mund tĂ« gaboni lehtĂ«sisht dhe pastaj tĂ« mos kuptoni pĂ«r çfarĂ« po ndodh pĂ«r njĂ« kohĂ« tĂ« gjatĂ«.
Dhe kjo është një pyetje që nuk u vendos as në një slajd dhe më duhej ta ndaj në dy kolona. Kjo është gjithashtu një pyetje në ClickHouse, që bën të njëjtën gjë rate, por për të dyja seritë e kohës: Silent Bob dhe Jay, në mënyrë që në panel të kemi dy seri kohore. Dhe kjo është tashmë shumë e komplikuar, sipas mendimit tim.
Dhe për Prometheus do të jetë sum (rate). Për ClickHouse bëra një makros të veçantë, e cila quhet RateColumns, e cila duket si një pyetje në Prometheus.
Ne e shikuam dhe duket se PromQL është i shkëlqyer, por ai ka, natyrisht, kufizime.
Ato janë:
- SELECT i kufizuar.
- JOIN-i kufitar.
- Nuk ka mbështetje HAVING.
Dhe nëse keni punuar me të për një kohë të gjatë, ju 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 që ne po i diskutojmë tani mund të ishin bërë në SQL. Por do të ishte e përshtatshme për t'u përdorur? Dhe kjo më çon në mendimin se nuk është gjithmonë gjuha më e fuqishme që mund të jetë më e përshtatshme.
Prandaj ndonjĂ«herĂ« duhet tĂ« zgjidhni njĂ« gjuhĂ« pĂ«r detyra. Kjo Ă«shtĂ« si beteja e Batman-it me Superman-in. ĂshtĂ« e qartĂ« se Superman Ă«shtĂ« mĂ« i fortĂ«, por Batman arriti ta mposht atĂ«, sepse ai ishte mĂ« praktik dhe e dinte saktĂ«sisht se çfarĂ« po bĂ«nte.
Dhe pjesa tjetĂ«r â Ă«shtĂ« Extending PromQL.
NjĂ« herĂ« tjetĂ«r pĂ«r VictoriaMetrics. ĂfarĂ« Ă«shtĂ« VictoriaMetrics? Kjo Ă«shtĂ« njĂ« bazĂ« tĂ« dhĂ«nash serish kohore, ajo Ă«shtĂ« OpenSource, ne e shpĂ«rndajmĂ« versionet njĂ«herĂ«sh dhe klaster. Sipas benchmarkeve tona, ajo Ă«shtĂ« mĂ« e shpejtĂ« nga gjithçka qĂ« ka nĂ« treg tani dhe pĂ«r kompresimin po ashtu, pra, njerĂ«z tĂ« vĂ«rtetĂ« raportojnĂ« kompresimin diku nĂ« 0,4 bytes pĂ«r pikĂ«, kur pĂ«r Prometheus Ă«shtĂ« 1,2-1,4.
Ne mbështesim jo vetëm Prometheus. Ne mbështesim InfluxDB, Graphite, OpenTSDB.
Ne mund tĂ« âshkruajmĂ«â, pra mund tĂ« transferojmĂ« tĂ« dhĂ«na tĂ« vjetra.
Dhe po ashtu punojmë në mënyrë perfekte me Prometheus dhe Grafana, pra ne mbështesim motorin PromQL. Dhe në Grafana mund të thjesht ndryshoni endpoint-in e Prometheus-it me VictoriaMetrics dhe të gjitha dashboardet tuaja do të funksionojnë siç kanë funksionuar.
Porosinë e VictoriaMetrics, ju gjithashtu mund të përdorni veçori të tjera.
Ne do të kalojmë shpejt nëpër funksionet që kemi shtuar.
Omit interval param â ju mund tĂ« mos e pĂ«rfshini parametrin e intervalit nĂ« Grafana. Kur nuk dĂ«shironi tĂ« merrni grafika tĂ« çuditshme gjatĂ« zoom-in/ out nĂ« panel, rekomandohet tĂ« pĂ«rdorni variablĂ«n {$__interval}.Kjo Ă«shtĂ« njĂ« variabĂ«l e brendshme e Grafana dhe ajo e zgjidh vetĂ« intervalin e tĂ« dhĂ«nave. Dhe VictoriaMetrics mund tĂ« kuptojĂ« se çfarĂ« duhet tĂ« jetĂ« ky interval. Nuk keni nevojĂ« ta pĂ«rditĂ«soni tĂ« gjithĂ« kĂ«rkesat tuaja. Do tĂ« jetĂ« shumĂ« mĂ« e thjeshtĂ«.
Funksioni i dytë është referimi i intervalit. Ju mund ta përdorni këtë interval në shprehjet tuaja. Mund ta shumëzoni, ta ndani, ta kaloni e ta referoni.
Më pas, kemi familjen e funksioneve të rollup. Funksioni rollup transformon çdo serë kohore tuajën në tri serë të veçanta. Këto janë min, max dhe avg. Mendoj se është shumë e dobishme, sepse ndonjëherë mund të tregojë disa outliers (anomali) dhe pasaktësi.
Nëse thjesht bëni irate ose rate, ka shumë të ngjarë që mund të humbni disa raste kur serë kohore sillet ndryshe nga çfarë keni pritur. Me këtë funksion është shumë më e lehtë të shihni, për shembull, që max është shumë më i lartë se avg.
Më pas kemi variablën default. Default tregon se cili është vlera që duam të vizatojmë në Grafana, nëse në atë moment nuk kemi ndonjë serë të dhënash. Kur ndodh kjo? Për shembull, nëse eksportoni ndonjë metrikë për gabimet. Ndërkohë që aplikacioni juaj është aq i shkëlqyer, saqë kur e keni nisur, nuk ka pasur gabime dhe as nuk ka patur gabime në orët e para ose madje edhe një ditë. Dhe keni dashboard që tregojnë raportin mes suksesit dhe gabimeve. Ato do t'ju tregojnë asgjë, sepse nuk keni metrikë gabimi. Por në default mund të vendosni çfarëdo.
Keep_last_Value â ruan vlerĂ«n e fundit tĂ« metrikĂ«s, nĂ«se ajo humbet. NĂ«se Prometheus pas skanimit tĂ« ardhshĂ«m nuk e gjen atĂ« brenda 5 minutash, ne do tĂ« ruajmĂ« vlerĂ«n e saj tĂ« fundit dhe grafikat tuaja sĂ«rish nuk do tĂ« dĂ«shtojnĂ«.
Scrape_interval â tregon se sa shpesh Prometheus mbledh tĂ« dhĂ«na pĂ«r metrikĂ«n tuaj, me çfarĂ« frekuence. KĂ«tu mund tĂ« shihni ndonjĂ« shkĂ«putje, pĂ«r shembull.
Label replace â funksion popullor. Por ne mendojmĂ« se Ă«shtĂ« paksa i komplikuar, sepse merr gjithsej argumente. Dhe ju duhet jo vetĂ«m tĂ« mbani mend 5 argumente, por gjithashtu renditjen e tyre.
Prandaj, pse të mos i thjeshtojmë ato? Domethënë, t'i ndajmë në funksione të vogla me sintaksë të kuptueshme.
Dhe tani, ajo që është më interesante. Pse e quajmë këtë PromQL të zgjeruar? Sepse mbështesim Shprehjet e Tavolinave të Përgjithshme. Mund të kaloni nëpër QR-kodin (), të shihni lidhjet me shembuj, me playground, ku mund të ekzekutoni kërkesat direkt në VictoriaMetrics pa e instaluar atë, thjesht në shfletues.
Dhe çfarë është kjo? Ky kërkesë lart është një kërkesë mjaft popullore. Mendoj se në çdo dashboard të shumë kompanive, përdorni të njëjtin filtr për gjithçka. Zakonisht, ashtu është. Por kur ju nevojitet të shtoni ndonjë filtër të ri, duhet të përditësoni ç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 ri-përdorni atë? Më duket kjo shumë më e thjeshtë dhe e qartë.
Për shembull, kur më duhet të përditësoj filtrat në Grafana në të gjitha kërkesat, dhe dashboard-i mund të jetë i madh ose mund të ketë edhe disa. Dhe si do doja ta zgjidhja këtë problem në Grafana?
Unë e zgjidh këtë problem kështu: krijoj commonFilter dhe në të përcaktoj këtë filtër, dhe pastaj e ri-përdor në kërkesa. Por nëse e bëni tani ashtu si unë, kjo nuk do të funksionojë, sepse Grafana nuk ju lejon të përdorni variablat brenda variablave të kërkesave. Dhe kjo është pak e çuditshme.
Dhe prandaj bëra një variant të tillë që lejon ta bëni këtë. Dhe nëse jeni të interesuar ose dëshironi një tipar të tillë, atëherë mbështeteni ose jepni një dislike, nëse nuk ju pëlqen kjo ide.
Më pas për PromQL të zgjeruar. Këtu ne përcaktojmë jo vetëm një variabël, por një funksion të tërë. Dhe e quajmë ru (konsumimi i burimeve). Dhe kjo funksion merr burimet e lira, kufizimin e burimit dhe filtrin. Duket se sintaksa është e thjeshtë. Dhe është shumë e lehtë të përdorim këtë funksion dhe të llogarisim përqindjen e memories së lirë që kemi. Domethënë, sa memorie kemi, çfarë kufizimi dhe si të filtrojmë. Kjo duket shumë më e përshtatshme nëse do të shkruanit të gjitha, duke ri-përdorur të njëjtët filtrat, sepse do të shndërrohej në një kërkesë shumë të madhe.
Ja, dhe ky është një shembull i një kërkese të madhe. Ai vjen nga pisha zyrtare e NodeExporter për Grafana. Por unë e kuptoj pak çfarë po ndodh këtu. Domethënë, natyrisht e kuptoj, nëse e shikoj me vëmendje, por numri i hapësirave mund të zvogëlojë menjëherë motivimin për të kuptuar se çfarë po ndodh këtu. E pse të mos e bëjmë më të thjeshtë dhe më të kuptueshëm?
Për shembull, kështu, duke theksuar gjërat ose pjesët e rëndësishme në variabla. Dhe më pas të bëjmë matematikën tonë bazë. Kjo duket më shumë si programim, kjo është ajo që do të doja të shihja në të ardhmen në Grafana.
Ky është një shembull tjetër, se si mund ta bëjmë edhe më të thjeshtë, nëse do të kishim këtë funksion ru, dhe ajo është tashmë e pranishme në VictoriaMetrics. Dhe ju thjesht kaloni vlerën e mbajtur, të cilën e keni shpallur në CTE.
Unë kam folur tashmë rreth rëndësisë së përdorimit të gjuhës së duhur të programimit. Dhe, ndoshta, në çdo kompani në Grafana ndodhin disa gjëra të ndryshme. Ndërsa, ndoshta, ju jepni akses në Grafana për zhvilluesit tuaj, dhe ata bëjnë diçka tjetër. Dhe të gjithë e bëjnë këtë ndryshe. Por do të donim që të ishte pak si një standard, domethënë të reduktonim në një standard të përbashkët.
Le të themi se nuk keni vetëm inxhinierë sistemesh, ndoshta keni edhe ekspertë, devops ose SRE. Mund të keni ekspertë që dinë se çfarë është monitorimi, dinë se çfarë është Grafana, domethënë ata punojnë me këtë për vite dhe e dinë mirë si të bëjnë. Dhe ata e kanë shkruar këtë 100 herë dhe e kanë shpjeguar të gjithëve, por për ndonjë arsye askush nuk po dëgjon.
E çfarë do të ndodhte nëse do të mund të vendosnin këto njohuri direkt në Grafana, në mënyrë që përdoruesit e tjerë të mund të ripërdorin funksionet? Dhe nëse do të duhej të llogarisnim përqindjen e memories së lirë, ata thjesht do të aplikonin funksionin. E çfarë, nëse krijuesit e eksportuesve, së bashku me produktin e tyre, ofronin gjithashtu një grup funksionesh, se si të punonin me metrikat e tyre, sepse ata e dinë saktësisht se çfarë janë metrikat dhe si të llogariten saktë?
Kjo në të vërtetë nuk ekziston. Këtë e kam bërë vetë. Kjo është mbështetje për bibliotekat në Grafana. Të themi, djemtë që bënë NodeExporter, kanë bërë atë që kam folur. Dhe gjithashtu ofruan një grup funksionesh.
Pra, duket se kështu duket. Ju lidhni këtë bibliotekë në Grafana, hyni në redaktim dhe këtu është shumë e thjeshtë në JSON si të punoni me këtë metrikë. Pra, një grup funksionesh, përshkrimi i tyre dhe se si shfaqen ato.
Mendoj se kjo mund tĂ« jetĂ« e dobishme, sepse atĂ«herĂ« nĂ« Grafana do tĂ« shkruani thjesht kĂ«shtu. Dhe Grafana "thonĂ«", qĂ« ka njĂ« funksion tĂ« tillĂ« nga kjo bibliotekĂ« â le tĂ« pĂ«rdorim atĂ«. MĂ« duket se do tĂ« ishte shumĂ« e shkĂ«lqyer.
Pak rreth VictoriaMetrics. Ne bëjmë shumë gjëra interesante. Lexoni artikujt tanë për kompresimin, për garat tona me aplikacionet e tjera të të dhënave të serive të kohës, shpjegimin tonë si të punoni me PromQL, sepse ka akoma shumë fillestarë, si dhe për shkallëzimin vertikal dhe përballjen me Thanos.
Pyetje:
Do ta filloj pyetjen time me njĂ« histori tĂ« thjeshtĂ« personale. Kur fillova pĂ«r herĂ« tĂ« parĂ« tĂ« pĂ«rdor Grafana, shkrova njĂ« kĂ«rkesĂ« shumĂ« bindĂ«se me gjatĂ«si 5 rreshta. NĂ« fund rezultoi njĂ« grafik shumĂ« bindĂ«s. Ky grafik pothuajse shkoi nĂ« prodhim. Por kur e shqyrtova mĂ« nga afĂ«r, doli se ky grafik tregon njĂ« bollĂ«k tĂ« çuditshĂ«m, pa asnjĂ« lidhje me realitetin, ndonĂ«se numrat bien nĂ« intervalin qĂ« prisnim tĂ« shihnim. Dhe pyetja ime. Ne kemi biblioteka, kemi funksione, por si shkruajmĂ« teste pĂ«r Grafana? Ju keni shkruar njĂ« kĂ«rkesĂ« komplekse, nga e cila varet njĂ« vendim biznesi â tĂ« porositni ose jo njĂ« kontejner real serverash. Dhe si e dimĂ« qĂ« ky funksion, i cili çizmon grafikĂ«t, duket si e vĂ«rteta. Faleminderit.
Faleminderit pĂ«r pyetjen. KĂ«tu ka dy pjesĂ«. E para â ndjej bazuar nĂ« praktikĂ«n time, qĂ« shumica e pĂ«rdoruesve, kur shohin grafikĂ«t e tyre, nuk e kuptojnĂ« se çfarĂ« po tregojnĂ« ata. PĂ«r njĂ« arsye, njerĂ«zit janĂ« shumĂ« tĂ« mirĂ« nĂ« tĂ« gjetur justifikim pĂ«r çdo anomalie qĂ« ndodh nĂ« grafikĂ«t, pĂ«rderisa kjo Ă«shtĂ« njĂ« gabim brenda funksionit. Dhe pjesa e dytĂ« â mĂ« duket se pĂ«rdorimi i funksioneve tĂ« tilla do tĂ« ishte shumĂ« mĂ« i pĂ«rshtatshĂ«m pĂ«r zgjidhjen e problemit tuaj, nĂ« vend qĂ« çdo zhvillues i juaj tĂ« bĂ«nte planifikimin e kapacitetit dhe tĂ« gabonte me njĂ« ndonjĂ« probabilitet.
Si të verifikohet?
Si të verifikohet? Ndoshta, asnjëherë.
Në formë testi në Grafana.
ĂfarĂ« ka tĂ« bĂ«jĂ« Grafana me kĂ«tĂ«? Grafana e pĂ«rktheu kĂ«tĂ« kĂ«rkesĂ« drejtpĂ«rdrejt nĂ« DataSource.
Duke shtuar pak në parametrat.
Jo, në Grafana nuk ka asgjë që shtohet. Aty mund të ketë parametra GET, si për shembull, step. Ai nuk specifikohet qartë, por mund ta ripërcaktoni, ose mund ta lini siç është, por ai shtohet automatikisht. Nuk do të shkruani teste këtu. Mendonjëse, nuk ia vlen të mbështeteni këtu në Grafana si burim të vërtetë.
Faleminderit për prezantimin! Faleminderit për kompresimin! Ju përmendët për mapping-in e variablës në grafik, se në Grafana nuk mund të përdorni një variabël brenda një variabele. E kuptoni për çfarë po flas?
Po.
Ishte fillimisht një dhimbje koke, kur doja të bëja alert në Grafana. Dhe aty duhet bërë alert për çdo host veç e veç. Ky gjë që keni bërë, a funksionon për alerts 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 alerting nĂ« Grafana fare, mĂ« mirĂ« ta pĂ«rdorni alertmanager.
Po, e përdor, por thjesht kjo në Grafana duket më e lehtë për konfigurim, por faleminderit për këshillën!
Burimi: habr.com
