Mi proponas legi la transskribon de la raporto de Roman Khavronenko "ExtendedPromQL"
Mallonge pri mi. Mia nomo estas Roman. Mi laboras por CloudFlare kaj loĝas en Londono. Sed mi ankaŭ estas prizorganto de VictoriaMetrics.
Kaj mi estas la aŭtoro por Grafana kaj estas malgranda prokurilo por ClickHouse.
Ni komencos per la unua parto, kiu nomiĝas “Tradukaj malfacilaĵoj”, kaj en ĝi mi parolos pri tio, ke iu ajn lingvo aŭ eĉ nur lingvo de komunikado estas tre grava. Ĉar jen kiel vi transdonas viajn pensojn al alia persono aŭ sistemo, kiel vi formulas peton. Homoj en la Interreto kverelas pri kiu lingvo estas pli bona - java aŭ iu alia. Por mi mem, mi decidis, ke necesas elekti taskon, ĉar ĉio ĉi estas specifa.
Ni komencu de la komenco mem. Kio estas PromQL? PromQL estas Prometheus Query Language. Jen kiel ni formas demandojn en Prometeo por akiri datumojn de temposerio, temposerio.
Kio estas temposerio-datumoj? Laŭvorte, ĉi tiuj estas tri parametroj.
Ĉi tiuj estas:
- Kion ni rigardas.
- Kiam ni rigardas ĝin.
- Kaj kian valoron ĝi montras.
Se vi rigardas ĉi tiun diagramon (ĉi tiu diagramo estas de mia telefono, kiu montras la statistikon de miaj paŝoj), tiam ĉi tie vi povas rapide respondi ĉi tiujn demandojn.
Ni rigardas paŝojn. Ni vidas la signifon kaj ni vidas la tempon kiam ni rigardas ĝin. Tio estas, rigardante ĉi tiun diagramon, oni povas facile diri, ke dimanĉe mi iris ĉirkaŭ 15 000 paŝojn. Ĉi tio estas temposerio-datumoj.
Nun ni "rompu" (transformu) ilin en alian datummodelon en formo de tabelo. Ĉi tie ni ankaŭ havas tion, kion ni rigardas. Ĉi tie mi aldonis iom pliajn datumojn, kiujn ni nomos meta-datumoj, tio estas, ne mi trapasis, sed du homoj, ekzemple, Jay kaj Silent Bob. Jen kion ni rigardas; kion ĝi montras kaj kiam ĝi montras tiun valoron.
Nun ni provu konservi ĉiujn ĉi tiujn datumojn en la datumbazo. Ekzemple, mi prenis la sintakson ClickHouse. Kaj ĉi tie ni kreas unu tablon nomitan "Paŝoj", t.e. kion ni rigardas. Estas tempo ĉi tie, kiam ni rigardas ĝin; kion ĝi montras kaj kelkajn metadatumojn kie ni stokos kiu ĝi estas: Jay kaj Silent Bob.
Kaj por provi ĉion vidigi, ni uzos Grafana, ĉar, unue, ĝi estas bela.
Ankaŭ ni uzos ĉi tiun kromaĵon. Estas du kialoj por ĉi tio. La unua estas ĉar mi skribis ĝin. Kaj mi scias precize kiom malfacile estas eltiri tempajn datumojn de ClickHouse por montri ĝin en Grafana.
Ni montros en la Grafika Panelo. Ĉi tiu estas la plej populara panelo en Grafana kaj montras valoron kontraŭ tempo, do ni bezonas nur du parametrojn.
Ni skribu la plej simplan demandon - kiel montri paŝostatistikojn en Grafana, konservante ĉi tiujn datumojn en ClickHouse, en la tabelo, kiun ni kreis. Kaj ni skribas tian simplan demandon. Ni elektas el paŝoj. Ni elektas valoron kaj elektas la tempon de ĉi tiuj valoroj, t.e. la samajn tri parametrojn pri kiuj ni parolis.
Kaj kiel rezulto, ni ricevas ĉi tiun grafikaĵon. Kiu scias kial li estas tiel stranga?
Ĝuste, vi devas ordigi laŭ tempo.
Kaj finfine ni ricevas pli bonan, sed ankoraŭ strangan horaron. Kiu scias kial? Ĝuste, estas du partoprenantoj, kaj ni fordonas du temposerion en Grafana, ĉar se ni denove traktas la datummodelon, tiam ĉiu temposerio estas unika kombinaĵo de nomo kaj ĉiuj etikedoj ŝlosilvaloroj.
Tial ni devas elekti specifan personon. Ni elektas Jay.
Kaj desegni denove. Nun la grafikaĵo aspektas kiel la vero. Nun ĝi estas normala horaro kaj ĉio funkcias bone.
Kaj, verŝajne, vi scias kiel fari pri la sama afero, sed en Prometheus per PromQL. Proksimume tiel. Iom pli facila. Kaj ni rompu ĉion. Ni faris Paŝojn. Kaj filtrilo per Jay. Ni ne specifas ĉi tie, ke ni devas akiri valoron kaj ni ne elektas tempon.
Nun ni provu kalkuli la movrapidecon de Jay aŭ Silent Bob. En ClickHouse, ni devos fari RunDifference, t.e., kalkuli la diferencon inter paroj de punktoj kaj dividi ilin per tempo por akiri la ĝustan rapidecon. La peto aspektos kiel ĉi tio.
Kaj li montros proksimume ĉi tiujn valorojn, t.e. proksimume 1,8 paŝojn por sekundo faras Silent Bob aŭ Jay.
Kaj en Prometeo vi ankaŭ scias kiel fari ĝin. Multe pli facila ol antaŭe.
Kaj por faciligi ĝin ankaŭ en Grafana, mi aldonis tian envolvaĵon, kiu aspektas tre simila al PromQL. Ĝi nomiĝas Rate Makrooj, aŭ kiel ajn vi volas nomi ĝin. En Grafana, vi nur skribas "tarifo", sed ie profunde ĝi transformiĝas en tiel grandan peton. Kaj oni eĉ ne devas rigardi ĝin, ĝi estas tie ie, sed oni ŝparas multe da tempo, ĉar skribi tiajn grandajn SQL-demandojn ĉiam estas multekosta. Vi povas facile erari kaj poste ne kompreni kio okazas dum longa tempo.
Kaj ĉi tio estas demando, kiu eĉ ne konvenis al unu diapozitivo, kaj mi eĉ devis dividi ĝin en du kolumnojn. Ĉi tio ankaŭ estas peto en ClickHouse, kiu faras la saman tarifon, sed por ambaŭ temposerio: Silent Bob kaj Jay, tiel ke ni havas du temposerio sur la panelo. Kaj ĉi tio estas jam tre malfacila, laŭ mi.
Kaj laŭ Prometeo ĝi estos sumo (tarifo). Por ClickHouse mi faris apartan makroon nomatan RateColumns, kiu aspektas kiel Prometheus-demando.
Ni rigardis kaj ŝajnas, ke PromQL estas tute bonega, sed ĝi havas, kompreneble, limigojn.
Ĉi tiuj estas:
- Limigita SELECT.
- Edge JOINs.
- Ne HAVAS subtenon.
Kaj se vi laboris kun ĝi dum longa tempo, tiam vi scias, ke foje estas tre malfacile fari ion en PromQL, kaj en SQL vi povas fari preskaŭ ĉion, ĉar ĉiuj ĉi tiuj opcioj, pri kiuj ni ĵus parolis, povus esti faritaj en SQL. . Sed ĉu estus oportune uzi ĝin? Kaj tio pensigas min, ke ne ĉiam la plej potenca lingvo povas esti la plej oportuna.
Tial, foje vi devas elekti lingvon por taskoj. Ĝi estas kiel batalo inter Batman kaj Superman. Estas klare ke Superman estas pli forta, sed Batman povis venki lin ĉar li estas pli praktika kaj sciis precize kion li faris.
Kaj la sekva parto estas Etendi PromQL.
Denove pri VictoriaMetrics. Kio estas VictoriaMetrics? Ĉi tio estas datumbazo de temposerio, ĝi estas en OpenSource, ni distribuas ĝiajn unuopajn kaj grapolajn versiojn. Laŭ niaj komparnormoj, ĝi estas la plej rapida kiu nun estas sur la merkato kaj ĝi similas laŭ kunpremado, t.e. vivantaj homoj raportas kunpremadon de ĉirkaŭ 0,4 bajtoj po punkto, kiam Prometheus havas 1,2-1,4.
Ni subtenas ne nur Prometeon. Ni subtenas InfluxDB, Graphite, OpenTSDB.
Vi povas "skribi" en ni, tio estas, vi povas transdoni malnovajn datumojn.
Kaj ni ankaŭ funkcias perfekte kun Prometheus kaj Grafana, t.e. ni subtenas la PromQL-motoron. Kaj en Grafana, vi povas simple ŝanĝi la finpunkton de Prometheus al VictoriaMetrics kaj ĉiuj viaj paneloj funkcios kiel ili.
Sed vi ankaŭ povas uzi pliajn blatojn provizitajn de VictoriaMetrics.
Ni rapide trarigardos la funkciojn, kiujn ni aldonis.
Forlasu intervalan parametron - vi povas preterlasi parametran intervalon en Grafana. Kiam vi ne volas ricevi strangajn grafikaĵojn kiam vi zomi/malproksimigas en la panelo, oni rekomendas uzi la variablon $__interval. Ĉi tio estas interna Grafana ŝanĝo kaj ĝi elektas la datuman gamon mem. Kaj VictoriaMetrics mem povas kompreni, kio devus esti ĉi tiu gamo. Kaj vi ne devas ĝisdatigi ĉiujn viajn demandojn. Estos multe pli facile.
La dua funkcio estas intervalreferencado. Vi povas uzi ĉi tiun interspacon en viaj esprimoj. Vi povas multobligi, dividi, translokigi, raporti al ĝi.
Sekva estas la rollup-funkcia familio. La resuma funkcio transformas iun ajn el viaj temposerio en tri apartajn temposerion. Ĉi tiuj estas min, max kaj mez. Mi trovas ĝin tre oportuna, ĉar foje ĝi povas montri kelkajn eksteraĵojn (anomaliojn) kaj malprecizecojn.
Kaj se vi nur koleras aŭ taksas, tiam vi verŝajne povas maltrafi iujn kazojn, kie la temposerio ne kondutas kiel vi intencis. Estas multe pli facile vidi kun ĉi tiu funkcio, ni diru, ke max estas tre malproksime de mezumo.
Poste estas la defaŭlta variablo. Defaŭlte - ĉi tio signifas kian valoron ni bezonas desegni en Grafana se ni ne havas tempan serion nuntempe. Kiam ĝi okazas? Ni diru, ke vi eksportas iujn erarajn metrikojn. Kaj vi havas tiel bonegan aplikaĵon, ke kiam vi komencas, vi ne havas erarojn kaj eĉ neniujn erarojn dum la sekvaj tri horoj aŭ eĉ tage. Kaj vi havas panelojn, kiuj montras rilatojn de sukceso ĝis eraro. Kaj ili montros al vi nenion ĉar vi ne havas erarmetrikon. Kaj defaŭlte vi povas specifi ion ajn.
Keep_last_Value - konservas la lastan valoron de la metriko se ĝi mankas. Se Prometeo post la sekva skrapado ne trovis ĝin ene de 5 minutoj, tiam ĉi tie ni memoros ĝian lastan valoron kaj viaj leteroj ne rompiĝos denove.
Scrape_interval - montras kiom ofte Prometheus kolektas datumojn pri via metriko, kun kia ofteco. Ĉi tie vi povas vidi la enirpermesilon, ekzemple.
Etiked-anstataŭigo estas populara trajto. Sed ni opinias, ke ĝi estas iom komplika ĉar ĝi prenas entjerajn argumentojn. Kaj vi devas ne nur memori la 5 argumentojn, sed ankaŭ memori ilian sinsekvon.
Tial, kial ne simpligi ilin? Tio estas, malkonstruu ĝin en malgrandajn funkciojn kun klara sintakso.
Kaj nun la plej interesa. Kial ni pensas, ke ĝi estas etendita PromQL? Ĉar ni subtenas Oftajn Tabelesprimojn. Vi povas sekvi la QR-kodon (), vidu ligilojn kun ekzemploj, el la ludejo, kie vi povas ruli demandojn rekte en VictoriaMetrics sen instali ĝin nur en la retumilo.
Kaj kio ĝi estas? Tiu ĉi peto de supre estas sufiĉe populara peto. Mi pensas, ke en iu panelo en multaj kompanioj vi uzas la saman filtrilon por ĉio. Kutime tiel. Sed kiam vi bezonas aldoni novan filtrilon, vi devas ĝisdatigi ĉiun panelon, aŭ elŝuti la panelon, malfermi ĝin en JSON, fari serĉan anstataŭigon, kio ankaŭ bezonas tempon. Kial ne konservi ĉi tiun valoron en variablo kaj reuzi ĝin? Ĝi aspektas, laŭ mi, multe pli simpla kaj klara.
Ekzemple, kiam mi bezonas ĝisdatigi filtrilojn en Grafana en ĉiuj petoj, kaj la panelo povas esti grandega aŭ eĉ povas esti pluraj da ili. Kaj kiel mi ŝatus solvi ĉi tiun problemon en Grafana?
Mi solvas ĉi tiun problemon tiel: mi faras komunan Filtrilon kaj difinas ĉi tiun filtrilon en ĝi, kaj poste mi reuzas ĝin en demandoj. Sed se vi faras la samon nun, ĝi ne funkcios ĉar Grafana ne permesas al vi uzi variablojn en demandaj variabloj. Kaj ĝi estas iom stranga.
Kaj do mi faris eblon, kiu ebligas al vi fari ĉi tion. Kaj se vi interesiĝas aŭ volas tian funkcion, tiam subtenu aŭ malŝatas se vi ne ŝatas ĉi tiun ideon.
Pli pri PromQL etendita. Ĉi tie ni difinas ne nur variablon, sed rekte tutan funkcion. Kaj ni nomas ĝin ru (rimeda uzado). Kaj ĉi tiu funkcio akceptas senpagajn rimedojn, limon de rimedoj kaj filtrilon. La sintakso ŝajnas esti simpla. Kaj estas tre facile uzi ĉi tiun funkcion kaj kalkuli la procenton de libera memoro, kiun ni havas. Tio estas, kiom da memoro ni havas, kian limon kaj kiel filtri. Ĝi aspektas multe pli bone, se vi skribus ĉion reuzante la samajn filtrilojn, ĉar ĝi fariĝus granda, granda demando.
Kaj jen ekzemplo de tia granda, granda peto. Ĝi estas de la oficiala panelo de NodeExporter por Grafana. Sed mi ne vere komprenas kio okazas ĉi tie. Tio estas, kompreneble, mi komprenas, se vi rigardas atente, sed la nombro da krampoj povas tuj redukti la instigon kompreni kio okazas ĉi tie. Kaj kial ne fari ĝin pli simpla kaj klara?
Ekzemple, tiel, reliefigante signifajn aferojn aŭ partojn en variabloj. Kaj tiam faru vian bazan matematikon. Ĉi tio pli similas al programado, jen kion mi ŝatus vidi estonte en Grafana.
Jen dua ekzemplo de kiel ni povas fari ĝin eĉ pli facila se ni jam havis ĉi tiun ru-funkcion, kaj ĝi jam ekzistas rekte en VictoriaMetrics. Kaj tiam vi simple pasas la kaŝmemoritan valoron, kiun vi deklaris en la CTE.
Mi jam parolis pri kiom gravas uzi la ĝustan programlingvon. Kaj, verŝajne, io malsama okazas en Grafana en ĉiu kompanio. Kaj, verŝajne, vi ankoraŭ donas aliron al Grafana al viaj programistoj, kaj la programistoj faras ion propran. Kaj ili ĉiuj faras ĝin alimaniere. Sed mi volis ĝin iel same, tio estas reduktita al komuna normo.
Ni diru, ke vi eĉ ne nur havas sistemajn inĝenierojn, eble vi eĉ havas spertulojn, devopojn aŭ SRE-ojn. Eble vi havas spertulojn kiuj scias kio estas monitorado, scias kio estas Grafana, t.e. ili laboras kun ĉi tio dum jaroj kaj ili scias ĝuste kiel fari ĝin ĝuste. Kaj ili jam skribis ĝin 100 fojojn kaj klarigis ĝin al ĉiuj, sed ial neniu aŭskultas.
Kio se ili povus meti ĉi tiun scion rekte en Grafana por ke aliaj uzantoj povu reuzi la funkciojn? Kaj se necesus kalkuli la procenton de libera memoro, tiam ili simple aplikas la funkcion. Sed kio se la kreintoj de eksportantoj, kune kun sia produkto, ankaŭ provizis aron da funkcioj, kiel labori kun siaj metrikoj, ĉar ili scias precize kio estas ĉi tiuj metrikoj kaj kiel kalkuli ilin ĝuste?
Ĉi tiu vere ne ekzistas. Jen kion mi mem faris. Ĉi tio estas la biblioteka subteno en Grafana. Ni diru, ke la uloj kiuj faris NodeExporter faris tion, kion mi priskribis. Kaj ankaŭ provizis aron da funkcioj.
Tio estas, ĝi aspektas kiel ĉi tio. Vi konektas ĉi tiun bibliotekon al Grafana, vi eniras redaktadon, kaj ĉi tie estas tre simple en JSON kiel labori kun ĉi tiu metriko. Tio estas, iu aro de funkcioj, ilia priskribo kaj en kio ili disvolviĝas.
Miaopinie tio povus esti utila, ĉar tiam vi skribus en Grafana ĝuste tiel. Kaj Grafana "diras" al vi, ke ekzistas tia kaj tia funkcio el tia kaj tia biblioteko - ni uzu ĝin. Mi pensas, ke tio estus tre mojosa.
Iom pri VictoriaMetrics. Ni faras multajn interesajn aferojn. Legu niajn artikolojn pri kunpremado, pri nia konkurenco kun aliaj tempaj datum-aplikoj, nian klarigon pri kiel labori kun PromQL, ĉar estas multaj pli da komencantoj pri tio, same kiel pri vertikala skaleblo kaj pri konfrontiĝo kun Thanos.
Demandoj:
Mi komencos mian demandon per simpla vivrakonto. Kiam mi unue komencis uzi Grafana, mi skribis tre konvinkan 5-linian demandon. La fina rezulto estas tre konvinka diagramo. Ĉi tiu grafikaĵo preskaŭ eniris en produktadon. Sed post pli proksima inspektado, montriĝis, ke ĉi tiu diagramo montras absolutan sensencaĵon, kiu havas nenion komunan kun la realo, kvankam la nombroj falas en la gamon, kiun ni atendis vidi. Kaj mia demando. Ni havas bibliotekojn, ni havas funkciojn, sed kiel ni skribas testojn por Grafana? Vi skribis kompleksan demandon, kiu influas la komercan decidon - mendi veran ujon da serviloj aŭ ne mendi. Kaj kiel ni scias, ĉi tiu funkcio, kiu desegnas grafeon, similas al la vero. Dankon.
Dankon pro la demando. Estas du partoj ĉi tie. Unue, mi havas la impreson, surbaze de mia sperto, ke la plej multaj uzantoj, kiam ili rigardas siajn leterojn, ne komprenas kion ili montras al ili. Iel, homoj tre kapablas elpensi pretekston por iu ajn anomalio, kiu okazas sur la furorlisto, eĉ se ĝi estas cimo ene de funkcio. Kaj la dua parto - ŝajnas al mi, ke uzi tiajn funkciojn multe pli taŭgas por solvi vian problemon, anstataŭ ke ĉiu el viaj programistoj faru sian propran kapacitan planadon kaj faru erarojn kun iom da probableco.
Kiel kontroli?
Kiel kontroli? Verŝajne ne.
Kiel testo en Grafana.
Kaj kio pri Grafana? Grafana tradukas ĉi tiun peton rekte al la Datumfonto.
Aldonante iom al la parametroj.
Ne, nenio estas aldonita al Grafana. Povas ekzisti GET-parametroj, kiel paŝo. Ĝi ne estas eksplicite specifita, sed vi povas anstataŭi ĝin, vi ne povas anstataŭi ĝin, sed ĝi estas aldonita aŭtomate. Vi ne skribas testojn ĉi tie. Mi ne pensas, ke vi devus fidi sur Grafana ĉi tie kiel fonto de vero.
Dankon pro la raporto! Dankon pro la kunpremo! Vi rememoris pri mapado de variablo en grafikaĵo, ke en Grafana vi ne povas uzi variablon en variablo. Ĉu vi komprenas, kion mi volas diri?
Jes.
Ĉi tio estis komence kapdoloro kiam mi volis fari atentigon en Grafana. Kaj tie vi devas fari atentigon por ĉiu gastiganto aparte. Jen ĉi tiu afero, kiun vi faris, ĉu ĝi funkcias por atentigoj en Grafana?
Se Grafana ne aliras variablojn alimaniere, tiam jes, ĝi funkcios. Sed mia konsilo estas tute ne uzi atentigon en Grafana, prefere vi uzu alertmanager.
Jes, mi uzas ĝin, sed ĝi simple ŝajnis pli facile agordi en Grafana, sed dankon pro la konsilo!
fonto: www.habr.com