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
