Ik stel foar om it transkripsje te lêzen fan it rapport fan Roman Khavronenko "ExtendedPromQL"
Koart oer my. Myn namme is Roman. Ik wurkje foar CloudFlare en wenje yn Londen. Mar ik bin ek in VictoriaMetrics-ûnderhâlder.
En ik bin de skriuwer foar Grafana en is in lytse proxy foar ClickHouse.
Wy sille begjinne mei it earste diel, dat hjit "oersettingsproblemen", en dêryn sil ik prate oer it feit dat elke taal of sels gewoan in kommunikaasjetaal tige wichtich is. Want dit is hoe't jo jo gedachten oerbringe oan in oare persoan of systeem, hoe't jo in fersyk formulearje. Minsken op it ynternet twivelje oer hokker taal better is - java of wat oars. Foar mysels besleat ik dat it nedich is om in taak te kiezen, om't dit alles spesifyk is.
Litte wy fan it begjin ôf begjinne. Wat is PromQL? PromQL is Prometheus Query Language. Dit is hoe't wy fragen foarmje yn Prometheus om tiidreeksgegevens, tiidsearjes te krijen.
Wat is tiidreeksgegevens? Letterlik binne dit trije parameters.
Dit binne:
- Wat sjogge wy nei.
- As wy der nei sjogge.
- En hokker wearde docht it sjen.
As jo nei dizze kaart sjogge (dizze kaart is fan myn tillefoan, dy't de statistiken fan myn stappen toant), dan kinne jo dizze fragen fluch beäntwurdzje.
Wy sjogge nei stappen. Wy sjogge de betsjutting en wy sjogge de tiid as wy der nei sjogge. Dat is, as jo nei dit diagram sjogge, kinne jo maklik sizze dat ik snein sa'n 15 stappen rûn. Dit is tiidrige gegevens.
Litte wy se no "brekke" (transformearje) yn in oar gegevensmodel yn 'e foarm fan in tabel. Hjir hawwe wy ek wat wy sjogge. Hjir haw ik in bytsje ekstra gegevens tafoege, dy't wy meta-data sille neame, dat is, it wie net ik dy't trochgie, mar twa minsken, bygelyks Jay en Silent Bob. Dêr sjogge wy nei; wat it toant en wannear it toant dy wearde.
Litte wy no besykje al dizze gegevens yn 'e databank op te slaan. Bygelyks, ik naam de ClickHouse-syntaksis. En hjir meitsje wy ien tabel mei de namme "Stappen", dat wol sizze wat wy sjogge. Der is in tiid dat wy der nei sjogge; wat it toant en wat meta-data wêr't wy sille opslaan wa't it is: Jay en Silent Bob.
En om te besykjen it allegear te visualisearjen, sille wy Grafana brûke, om't it earst prachtich is.
Ek sille wy dizze plugin brûke. D'r binne twa redenen foar dit. De earste is om't ik it skreau. En ik wit krekt hoe lestich it is om tiidreeksgegevens út ClickHouse te lûken om it yn Grafana te sjen.
Wy sille werjaan yn it Graph Panel. Dit is it populêrste paniel yn Grafana en toant wearde tsjin tiid, dus wy hawwe mar twa parameters nedich.
Litte wy de ienfâldichste fraach skriuwe - hoe't jo stapstatistiken sjen litte yn Grafana, dizze gegevens opslaan yn ClickHouse, yn 'e tabel dy't wy makke hawwe. En wy skriuwe sa'n ienfâldige fraach. Wy kieze út stappen. Wy selektearje in wearde en selektearje de tiid fan dizze wearden, dat wol sizze deselde trije parameters dêr't wy praat oer.
En as gefolch krije wy dizze grafyk. Wa wit wêrom't er sa nuver is?
Dat is krekt, jo moatte sortearje op tiid.
En op it lêst krije wy in better, mar dochs nuver skema. Wa wit wêrom? Dat is krekt, d'r binne twa dielnimmers, en wy jouwe twa tiidsearjes yn Grafana fuort, want as wy wer mei it gegevensmodel omgeane, dan is elke tiidreeks in unike kombinaasje fan in namme en alle labels kaai-wearden.
Dêrom moatte wy in spesifike persoan kieze. Wy kieze Jay.
En wer tekenje. No liket de grafyk op 'e wierheid. No is it in gewoan skema en alles wurket goed.
En, wierskynlik, wite jo hoe't jo itselde ding moatte dwaan, mar yn Prometheus fia PromQL. Likernôch sa. In bytsje makliker. En lit ús it allegear ôfbrekke. We namen Steps. En filterje troch Jay. Wy spesifisearje hjir net dat wy in wearde moatte krije en wy kieze gjin tiid.
Litte wy no besykje de bewegingssnelheid fan Jay of Silent Bob te berekkenjen. Yn ClickHouse moatte wy runningDifference dwaan, d.w.s. it ferskil tusken pearen punten berekkenje en se diele troch tiid om de krekte snelheid te krijen. It fersyk sil der sa útsjen.
En hy sil sjen likernôch dizze wearden, ie likernôch 1,8 stappen per sekonde docht Silent Bob of Jay.
En yn Prometheus witte jo it ek te dwaan. Folle makliker as earder.
En om it ek maklik te dwaan yn Grafana, haw ik sa'n wrapper tafoege dy't heul gelyk liket op PromQL. It hjit Rate Macros, of wat jo it ek neame wolle. Yn Grafana skriuwe jo gewoan "rate", mar earne djip feroaret it yn sa'n grut fersyk. En jo hoege der net iens nei te sjen, it is der earne, mar jo besparje in protte tiid, want it skriuwen fan sokke grutte SQL-fragen is altyd djoer. Jo kinne maklik in flater meitsje en dan lang net begripe wat der bart.
En dit is in fraach dy't net iens paste op ien slide, en ik moast it sels yn twa kolommen splitse. Dit is ek in fersyk yn ClickHouse, dat makket itselde taryf, mar foar beide tiid rige: Silent Bob en Jay, sadat wy hawwe twa tiid rige op it paniel. En dit is neffens my al hiel dreech.
En neffens Prometheus sil it som (taryf) wêze. Foar ClickHouse makke ik in aparte makro neamd RateColumns dy't liket op in Prometheus-query.
Wy seagen en it liket derop dat PromQL allegear sa cool is, mar it hat fansels beheiningen.
Dit binne:
- Limited SELECT.
- Edge JOINs.
- Gjin HAVING stipe.
En as jo der in lange tiid mei wurke hawwe, dan wite jo dat it soms heul lestich is om wat te dwaan yn PromQL, en yn SQL kinne jo hast alles dwaan, om't al dizze opsjes wêr't wy krekt oer praat koenen wurde dien yn SQL . Mar soe it handich wêze om it te brûken? En dit lit my tinke dat net altyd de machtichste taal it handichste wêze kin.
Dêrom moatte jo soms in taal kieze foar taken. It is as in slach tusken Batman en Superman. It is dúdlik dat Superman sterker is, mar Batman koe him ferslaan om't hy praktysker is en krekt wist wat hy die.
En it folgjende diel is PromQL útwreidzje.
Noch ien kear oer VictoriaMetrics. Wat is VictoriaMetrics? Dit is in databank foar tiidsearjes, it is yn OpenSource, wy ferspriede syn single- en klusterferzjes. Neffens ús benchmarks is it de rapste dy't no op 'e merke is en it is ferlykber yn termen fan kompresje, d.w.s. libbene minsken rapportearje kompresje fan sawat 0,4 bytes per punt, as Prometheus 1,2-1,4 hat.
Wy stypje net allinich Prometheus. Wy stypje InfluxDB, Graphite, OpenTSDB.
Jo kinne "skriuwe" yn ús, dat is, kinne jo oerdrage âlde gegevens.
En wy wurkje ek perfekt mei Prometheus en Grafana, d.w.s. wy stypje de PromQL-motor. En yn Grafana kinne jo it Prometheus-einpunt gewoan feroarje yn VictoriaMetrics en al jo dashboards sille wurkje lykas se diene.
Mar jo kinne ek brûke ekstra chips fersoarge troch VictoriaMetrics.
Wy sille fluch gean troch de funksjes dy't wy hawwe tafoege.
Oerslaan yntervalparam - jo kinne parameter ynterval oerslaan yn Grafana. As jo gjin frjemde grafiken krije wolle by it yn-/útzoomen yn it paniel, is it oan te rieden om de fariabele te brûken $__interval. Dit is in ynterne Grafana-feroaring en it kiest it gegevensberik sels. En VictoriaMetrics kin sels begripe wat dit berik moat wêze. En jo moatte net al jo oanfragen bywurkje. It sil folle makliker wêze.
De twadde funksje is yntervalferwizing. Jo kinne dizze ôfstân brûke yn jo útdrukkingen. Jo kinne fermannichfâldigje, diele, oerdrage, ferwize nei it.
Folgjende is de famylje fan rollupfunksje. De rollup-funksje transformeart ien fan jo tiidsearjes yn trije aparte tiidsearjes. Dit binne min, max en gem. Ik fyn it heul handich, om't it soms wat útfallers (anomalies) en ûnkrektens sjen kin.
En as jo gewoan argewaasje dogge of beoardielje, dan kinne jo wierskynlik guon gefallen misse wêr't de tiidsearje net gedraacht lykas jo bedoeld hawwe. It is folle makliker om te sjen mei dizze funksje, lit ús sizze max is hiel folle off avg.
Folgjende is de standert fariabele. Standert - dit betsjut hokker wearde wy moatte tekenje yn Grafana as wy hawwe gjin tiid rige op it stuit. Wannear bart it? Litte wy sizze dat jo wat flatermetriken eksportearje. En jo hawwe sa'n koele applikaasje dat as jo begjinne, jo hawwe gjin flaters en sels gjin flaters foar de folgjende trije oeren of sels in dei. En jo hawwe dashboards dy't relaasjes sjen litte fan sukses oant flater. En se sille jo neat sjen litte, om't jo gjin flatermetrik hawwe. En standert kinne jo alles opjaan.
Keep_last_Value - bewarret de lêste wearde fan 'e metrik as it ûntbrekt. As Prometheus nei de folgjende scrape it net fûn binnen 5 minuten, dan sille wy hjir de lêste wearde ûnthâlde en jo charts sille net wer brekke.
Scrape_interval - lit sjen hoe faak Prometheus gegevens sammelt oer jo metrysk, mei hokker frekwinsje. Hjir kinne jo bygelyks de pas sjen.
Label ferfangen is in populêre funksje. Mar wy tinke dat it in bytsje yngewikkeld is, om't it heule tal arguminten nimt. En jo moatte net allinnich ûnthâlde de 5 arguminten, mar ek ûnthâlde harren folchoarder.
Dêrom, wêrom meitsje se net ienfâldiger? Dat is, brekke it yn lytse funksjes mei dúdlike syntaksis.
En no de meast nijsgjirrige. Wêrom tinke wy dat it PromQL útwreide is? Omdat wy stypje Common Table Expressions. Jo kinne de QR-koade folgje (), sjoch keppelings mei foarbylden, fan 'e boarterstún, wêr't jo fragen direkt yn VictoriaMetrics kinne útfiere sûnder it allinich yn' e browser te ynstallearjen.
En wat is it? Dit fersyk fan boppen is in frij populêr fersyk. Ik tink dat jo yn elk dashboard yn in protte bedriuwen itselde filter brûke foar alles. Gewoanlik sa. Mar as jo in nije filter tafoegje moatte, moatte jo elk paniel bywurkje, of it dashboard downloade, iepenje it yn JSON, doch in fynst ferfange, wat ek tiid nimt. Wêrom net bewarje dizze wearde yn in fariabele en opnij brûke? It liket, neffens my, folle ienfâldiger en dúdliker.
Bygelyks, as ik filters yn Grafana moat bywurkje yn alle oanfragen, en it dashboard kin enoarm wêze of d'r kinne sels ferskate fan har wêze. En hoe soe ik dit probleem yn Grafana oplosse wolle?
Ik losse dit probleem as dit: Ik meitsje in commonFilter en definiearje dit filter yn it, en dan ik werbrûke it yn queries. Mar as jo no itselde dogge, sil it net wurkje, om't Grafana jo net tastean fariabelen te brûken binnen queryfariabelen. En it is in bytsje nuver.
En sa haw ik in opsje makke wêrmei jo dit kinne dwaan. En as jo ynteressearre binne of sa'n funksje wolle, stypje dan of net leuk as jo dit idee net leuk fine.
Mear oer PromQL útwreide. Hjir definiearje wy net allinnich in fariabele, mar direkt in hiele funksje. En wy neame it ru (boarnegebrûk). En dizze funksje akseptearret fergese boarnen, in boarnelimyt en in filter. De syntaksis liket ienfâldich te wêzen. En it is heul maklik om dizze funksje te brûken en it persintaazje fergees ûnthâld te berekkenjen dat wy hawwe. Dat is, hoefolle ûnthâld wy hawwe, hokker limyt en hoe te filterjen. It sjocht der folle better út as jo it allegear skriuwe mei deselde filters opnij brûke, om't it soe feroarje yn in grutte, grutte fraach.
En hjir is in foarbyld fan sa'n grut, grut fersyk. It is fan it offisjele NodeExporter-dashboard foar Grafana. Mar ik begryp net echt wat hjir bart. Dat is fansels, ik begryp it as jo goed sjogge, mar it oantal heakjes kin de motivaasje om te begripen wat hjir bart fuortendaliks ferminderje. En wêrom net ienfâldiger en dúdliker meitsje?
Bygelyks, lykas dit, markearje wichtige dingen as dielen yn fariabelen. En dan do dyn basis wiskunde. Dit is mear as programmearring, dit is wat ik graach sjen soe yn 'e takomst yn Grafana.
Hjir is in twadde foarbyld fan hoe't wy kinne meitsje it noch makliker as wy al hie dizze ru funksje, en it bestiet al direkt yn VictoriaMetrics. En dan passe jo gewoan de cached wearde troch dy't jo hawwe ferklearre yn 'e CTE.
Ik haw it al oer hoe wichtich it is om de juste programmeartaal te brûken. En, wierskynlik, bart der wat oars yn Grafana yn elk bedriuw. En, wierskynlik, jouwe jo jo ûntwikkelders noch tagong ta Grafana, en de ûntwikkelders dogge wat fan har eigen. En se dogge it allegear op in oare manier. Mar ik woe it ien of oare manier itselde, dat is, redusearre ta in mienskiplike standert.
Litte wy sizze dat jo net iens gewoan systeemingenieurs hawwe, miskien hawwe jo sels saakkundigen, devops of SRE's. Miskien hawwe jo saakkundigen dy't witte wat tafersjoch is, witte wat Grafana is, d.w.s. se wurkje hjir al jierren mei en se witte krekt hoe't se it goed dwaan moatte. En se hawwe it al 100 kear skreaun en elkenien útlein, mar om ien of oare reden harket nimmen.
Wat as se dizze kennis direkt yn Grafana kinne pleatse, sadat oare brûkers de funksjes opnij kinne brûke? En as it nedich is om it persintaazje frije ûnthâld te berekkenjen, dan soene se de funksje gewoan tapasse. Mar wat as de makkers fan eksporteurs, tegearre mei har produkt, ek in set fan funksjes levere, hoe't se mei har metriken wurkje, om't se krekt witte wat dizze metriken binne en hoe't se se korrekt kinne berekkenje?
Dizze bestiet net echt. Hjir is wat ik sels dien. Dit is de biblioteek stipe yn Grafana. Litte wy sizze dat de jonges dy't NodeExporter makken diene wat ik beskreau. En ek levere in set fan funksjes.
Dat is, it sjocht der sa út. Jo ferbine dizze bibleteek mei Grafana, jo geane yn it bewurkjen, en hjir is it heul ienfâldich yn JSON hoe't jo mei dizze metrik wurkje. Dat is, guon set fan funksjes, harren beskriuwing en wat se ûntjaan yn.
Neffens my soe dat wol nuttich wêze kinne, want dan skriuwe je sa yn Grafana. En Grafana "fertelt" jo dat der sa'n en sa'n funksje is fan sa en sa'n bibleteek - lit ús it brûke. Ik tink dat soe wêze hiel cool.
In bytsje oer VictoriaMetrics. Wy dogge in protte nijsgjirrige dingen. Lês ús artikels oer kompresje, oer ús konkurrinsje mei oare dataapplikaasjes foar tiidsearjes, ús útlis oer hoe't jo kinne wurkje mei PromQL, om't d'r folle mear begjinners yn dit binne, lykas oer fertikale skaalberens en oer konfrontaasje mei Thanos.
Fragen:
Ik sil myn fraach begjinne mei in ienfâldich libbensferhaal. Doe't ik earst begûn te brûken Grafana, Ik skreau in hiel oertsjûgjende 5 line query. It einresultaat is in heul oertsjûgjende grafyk. Dizze grafyk is hast yn produksje gien. Mar by neier ynspeksje die bliken dat dizze kaart absolute ûnsin toant dy't neat mei de realiteit te krijen hat, hoewol de nûmers falle yn it berik dat wy ferwachte te sjen. En myn fraach. Wy hawwe bibleteken, wy hawwe funksjes, mar hoe skriuwe wy tests foar Grafana? Jo hawwe in komplekse fraach skreaun dy't ynfloed hat op it saaklike beslút - om in echte kontener fan servers te bestellen of net te bestellen. En sa't wy witte, is dizze funksje dy't in grafyk tekenet gelyk oan 'e wierheid. Dankewol.
Tank foar de fraach. Der binne twa dielen hjir. Earst krij ik de yndruk, basearre op myn ûnderfining, dat de measte brûkers, as se nei har charts sjogge, net begripe wat se har sjen litte. Op ien of oare manier binne minsken heul goed om in ekskús te betinken foar elke anomaly dy't bart op 'e charts, sels as it in brek is yn in funksje. En it twadde diel - it liket my dat it brûken fan sokke funksjes folle better geskikt wêze soe om jo probleem op te lossen, ynstee fan elk fan jo ûntwikkelders dy't har eigen kapasiteitsplanning dogge en flaters meitsje mei wat kâns.
Hoe kinne jo kontrolearje?
Hoe kontrolearje? Wierskynlik net.
As test yn Grafana.
En hoe sit it mei Grafana? Grafana fertaalt dit fersyk direkt nei de DataSource.
Troch it tafoegjen fan in bytsje oan de parameters.
Nee, der wurdt neat oan Grafana tafoege. D'r kinne GET-parameters wêze, lykas stap. It is net eksplisyt oantsjutte, mar jo kinne oerskriuwe it, do kinst net oerskriuwe it, mar it wurdt tafoege automatysk. Jo skriuwe hjir gjin toetsen. Ik tink net dat jo hjir op Grafana fertrouwe moatte as in boarne fan wierheid.
Tank foar it ferslach! Tank foar de kompresje! Jo herinnerje jo oer it yn kaart bringen fan in fariabele yn in grafyk, dat jo yn Grafana gjin fariabele kinne brûke yn in fariabele. Snapst wat ik bedoel?
Ja.
Dit wie yn 't earstoan in hoofdpijn doe't ik in warskôging woe yn Grafana. En dêr moatte jo warskôging dwaan foar elke host apart. Hjir is dit ding dat jo dien hawwe, wurket it foar warskôgings yn Grafana?
As Grafana gjin tagong hat ta fariabelen op in oare manier, dan ja, it sil wurkje. Mar myn advys is hielendal gjin warskôging te brûken yn Grafana, jo kinne better alertmanager brûke.
Ja, ik brûk it, mar it like gewoan makliker te setten yn Grafana, mar tank foar de tip!
Boarne: www.habr.com