„ExtendedPromQL“ — Roman Khavronenkole ettekande tõlgendus

Pakun tutvuda Roma Havronenko ettekande "ExtendedPromQL" kokkuvõttega

Lühidalt minust. Minu nimi on Roman. Töödan CloudFlares, elan Londonis. Kuid olen ka VictoriaMetrics'i hooldaja.
Ja olen autori ClickHouse plugina Grafana jaoks ja ClickHouse-proxy - see on väike proxy ClickHouse'ile.

Alustame esimesest osast, mis kannab nime „Tõlkimise keerukused”, kus räägin, et iga keel või isegi lihtsalt suhtluskeel on äärmiselt oluline. See on viis, kuidas edastate oma mõtteid teisele inimesele või süsteemile, kuidas koostate päringu. Internetis vaieldakse selle üle, milline keel on parem – java või mõni muu. Olin otsustanud, et tuleb valida vastavalt ülesandele, sest kõik see on spetsiifiline.

Alustame algusest. Mis on PromQL? PromQL on Prometheuse päringu keel. See on see, kuidas me koostame päringuid Prometheuses, et saada ajaseeria andmeid.

Mis on ajaseeria andmed? Kui rääkida laiemalt, siis need koosnevad kolmest parameetrist.

Need on:

• Millele me vaatame.
• Kui me sellele vaatame.
• Ja millist väärtust see näitab.

Kui vaadata seda diagrammi (see diagramm on minu telefonist, kus on näha minu sammude statistika), siis sellele küsimustele on kiiresti vastata.

Vaadates samme. Me näeme väärtust ja aega, kui me seda vaatame. See tähendab, et seda diagrammi vaadates on lihtne öelda, et pühapäeval läbis sain umbes 15 000 sammu. Need on ajaseriaali andmed.

Nüüd proovime "lahti võtta" (muuta) need teise andmemudeli kujul tabelina. Siin on meil samuti see, mida jälgime. Siia lisasin natuke täiendavaid andmeid, mida kutsume metaandmeteks, see tähendab, et seda ei teinud mina, vaid kaks inimest, ütleme Jay ja Silent Bob. See on see, mida jälgime; mida see näitab ja millal see väärtust näitab.

Nüüd proovime kõik need andmed salvestada andmebaasi. Näiteks kasutasin ClickHouse süntaksit. Siin loome ühe tabeli, mida nimetatakse „Steps”, st see, mida me vaatame. Siin on aeg, mil me seda vaatame; mida see näitab ja mingid metaandmed, kus salvestame, kes see on: Jay ja Silent Bob.

Ja et selleks, et neid kõiki visualiseerida, kasutame Grafanat, sest see on esiteks ilus.

Kasutame ka seda plugina. Sellel on kaks põhjust. Esiteks, kuna ma selle kirjutasin. Ja ma tean täpselt, kui raske on time series andmeid ClickHouse'ist välja tõmmata, et näidata need Grafanas.

Kuvame seda Graph Panelis. See on kõige populaarsem paneel Grafanas, mis näitab väärtuste sõltuvust ajast, seega vajame vaid kahte parameetrit.

Käime läbi kõige lihtsama päringu — kuidas näidata samme Graafikas, hoides neid andmeid ClickHouse'is, tabelis, mille me lõime. Ja kirjutame sellise lihtsa päringu. Valime sammudest. Valime väärtuse ja valime nende väärtuste aja, st nende kolm parameetrit, millest me rääkisime.

Ja tulemuseks saame sellise grafi. Kes teab, miks see nii imelik välja näeb?

Õige, tuleb sortida ajakohaselt.

Ja lõpuks saame me parema, kuid siiski veidra graafiku. Kes teab, miks? Õige, seal on kaks osalejat, ja me anname Grafanas kaks time series, sest kui uurida andmemudelit veel kord, siis iga time series on ainulaadne kombinatsioon nimest ja kõigist võtme-väärtuse labelitest.

Seega peame valima konkreetse inimese. Valime Jay.

Ja joonistame uuesti. Nüüd näeb graafik välja nagu tõde. Nüüd on see normaalne graafik ja kõik töötab hästi.

Ja tõenäoliselt teate, kuidas umbes sama teha Prometheus'e kaudu PromQL-i abil. Umbes nii. Natuke lihtsam. Ja jagame selle kõik üles. Võtsime Steps. Ja filtreerime Jay järgi. Me siin ei näita, et peame saama väärtuse ja me ei vali aega.

Nüüd proovime arvutada Jay või Silent Bob'i liikumiskiirus. ClickHouse'is peame tegema runningDifference, st arvutama erinevuse punktide paaride vahel ja jagama need ajaga, et saada täpne kiirus. Küsitlus näeb välja umbes nii.

Ja see näitab umbes selliseid väärtusi, st umbes 1,8 sammu sekundis teeb Silent Bob või Jay.

Ja Prometheus'e puhul teate, kuidas seda ka teha. Oluliselt lihtsam, kui see oli varem.

Ja et see jääks samuti lihtsaks teha Grafanas, lisasin ma sellise katte, mis näeb välja väga sarnane PromQL-iga. Seda nimetatakse Rate Macros või kuidas iganes te seda nimetate. Grafanas kirjutate lihtsalt „rate“, kuid kuskil sügaval see transformeeritakse selliseks suureks päringuks. Ja teil ei pea isegi vaatama, see on kuskil seal olemas, kuid säästate hulga aega, kuna selliste suurte SQL-päringute kirjutamine on alati kulukas. Te võite kergesti eksida ja siis kaua mõelda, mis toimub.

Ja see on päring, mis ei mahtunud isegi ühele slaidile ja pidin selle isegi kaheks veeruks jagama. See on samuti päring ClickHouse'is, mis teeb sama rate'i, kuid mõlema ajasarja jaoks: nii Silent Bobi kui ka Jay jaoks, et meil oleks paneelil kaks ajasarja. Ja see on juba väga keeruline, minu arvates.

Ja Prometheuse puhul on see sum(rate). ClickHouse'i jaoks tegin ma eraldi makro, mis nimetatakse RateColumns, mis näeb välja nagu päring Prometheuses.

Me vaatasime ja näiliselt on PromQL nii lahe, kuid tal on muidugi piiranguid.

Need on:

• Piiratud SELECT.
• Piiratud JOIN.
• Puudub HAVING-toe.

Ja kui olete selle süsteemiga kaua töötanud, teate, et mõnikord on PromQL-is millegi tegemine väga keeruline, samas kui SQL-is on võimalused praktiliselt piiritud, kuna kõik need variandid, millest me just rääkisime, oleks saanud SQL-is teostada. Kuid kas selline lähenemine oleks mugav? See viib mind mõttele, et kõige võimsam keel ei pruugi alati olla kõige mugavam.

Seetõttu tuleb vahel valida keel vastavalt ülesannetele. See on nagu Batmani ja Supermani kokkuvõte. Selge, et Superman on tugevam, kuid Batman suutis ta võita, sest ta oli praktilisem ja teadis täpselt, mida teeb.

Järgmine osa on PromQL-i laiendamine.

Veel kord VictoriaMetrics'ist. Mis on VictoriaMetrics? See on ajajoonete põhine andmebaas, mis on avatud allikaga, pakkume selle single ja cluster-versioone. Meie jõudluse testide põhjal on see kiireim, mis turul praegu saadaval on, samuti kompressiooni poolest, see tähendab, et inimesed toovad välja kompressiooni, mis on kuskil 0,4 baiti punkti kohta, samas kui Prometheusel on see 1,2-1,4.

Me toetame mitte ainult Prometheust. Me toetame ka InfluxDB-d, Graphitet ja OpenTSDB-d.

Meie süsteemi saab "kirjutada", mis tähendab, et vanade andmete üleviimine on võimalik.

Meie toetame Prometheus ja Grafana, st me toetame PromQL mootorit. Grafanas saate lihtsalt vahetada Prometheuse lõpp-punkti VictoriaMetrics'i vastu ja kõik teie armatuurlaudade töötab nagu varem.

Kuid saate kasutada ka täiendavaid funktsioone, mida VictoriaMetrics pakub.

Käime kiiresti üle funktsioonidest, mille me oleme lisanud.

Omit interval param – saate Grafanas vaheparameetrid vahele jätta. Kui te ei soovi saada kummalisi graafikuid zoom-in/zoom-out ajal paneelil, on soovitatav kasutada muutujat {$__interval}. See on Grafana sisemine muutuja ja see valib automaatselt andmete ulatuse. VictoriaMetrics suudab samuti aru saada, milline see vahemik olema peaks. Te ei pea kõiki oma päringuid uuendama. See on palju lihtsam.

Teine funktsioon on vahe viitamine. Saate seda vahemikku oma väljendites kasutada. Saate seda korrutada, jagada, edastada ja viidata sellele.

Edasi tuleme rollup funktsioonide pere juurde. Rollup funktsioon muundab teie ajaseeria kolme eraldi ajaseeriaks: min, max ja avg. Ma arvan, et see on väga mugav, kuna see võib mõnikord näidata mõningaid anomaaliaid ja ebatäpsusi.

Ja kui te lihtsalt teete irate või rate, võite tõenäoliselt mööda hiilida juhtumitest, kus ajasarjad käituvad teistsuguselt, kui te arvasite. Selle funktsiooniga on palju lihtsam näha, et max on keskmisest oluliselt kõrgem.

Edasi liikudes muutuja default. Default tähendab, millist väärtust peame Grafanas kuvama, kui meil ei ole hetkel ajasarja. Millal see juhtub? Oletame, et eksportite mingit mõõdikut vigade kohta. Ja teil on nii äge rakendus, et kui alustasite, ei ole teil vigu ja isegi järgmisel kolm tundi või isegi päeval ei ole vigu. Ja teil on armatuurlaud, mis näitab suhet success ja error vahel. Ja see näitab teile mitte midagi, sest teil ei ole viga mõõdikut. Defaultis saate määrata, mida iganes soovite.

Keep_last_Value – salvestab mõõdiku viimase väärtuse, kui see kaob. Kui Prometheus ei leia järgmisel skreipimisel seda 5 minuti jooksul, siis me salvestame selle viimase väärtuse ja teie graafikud ei purune uuesti.

Scrape_interval – näitab, kui tihti Prometheus kogub andmeid teie mõõdiku kohta, kui suure sagedusega. Siit on võimalik näha vahelejätmisi näiteks.

Label replace – populaarne funktsioon. Kuid me arvame, et see on natuke keeruline, kuna see nõuab mitut argumenti. Ja peate mitte ainult meeles pidama 5 argumenti, vaid ka nende järjekorda.

Seetõttu, miks mitte muuta neid lihtsamaks? St. jagada väiksemateks funktsioonideks, millel on arusaadav süntaks.

Ja nüüd kõige huvitavam. Miks me arvame, et see on extended PromQL? Sest toetame Common Table Expressions. Saate skaneerida QR-koodi (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), vaadata linke näidistega, mänguplatsiga, kus saate päringuid otse VictoriaMetricsis teha ilma selle installimata, lihtsalt brauseris.

Ja mis see siis on? See päring üleval – see on üsna populaarne päring. Ma arvan, et paljudes ettevõtetes igas armatuurlauduses kasutate sama filtrit kõikjal. Niimoodi see tavaliselt on. Kuid kui peate lisama mingi uue filtri, siis peate uuendama iga paneeli või laadima armatuurlaua alla, avama JSON-is, tegema find replace, mis võtab samuti aega. Miks mitte hoida seda väärtust muutuja sees ja uuesti kasutada? See tundub minu arvates palju lihtsam ja arusaadavam.

Näiteks, kui mul on vaja Grafanas kõigis päringutes filtreid uuendada, samas kui juhtpaneel võib olla tohutu või neid võib olla mitu. Kuidas ma sooviksin seda probleem Grafanas lahendada?

Lahendan selle probleemi nii: teen commonFilter'i, kus määratlen selle filtri, ja kasutan seda siis päringutes. Kuid kui teete nüüd nii, ei tööta see, sest Grafana ei luba teil kasutada muutujaid päringu sees. See on veidi kummaline.

Seetõttu tegin variandi, mis lubab seda teha. Ja kui see teid huvitab või soovite sellist funktsiooni, siis toetage või andke negatiivne hääletus, kui see idee teile ei meeldi. https://github.com/grafana/grafana/pull/16694

Edasi PromQL laiendatud kohta. Siin me määratleme mitte ainult muutuja, vaid lausa terve funktsiooni. Me nimetame selle ru (ressursside kasutus). See funktsioon võtab vastu vabad ressursid, ressursi piirangu ja filtri. Süntaks näib olema üsna lihtne. Ja selle funktsiooni kasutamine, et arvutada meie vaba mälu protsent, on väga lihtne. St, kui palju meil on mälu, milline on piirang ja kuidas filtreerida. See näeb välja palju mugavam, kui kirjutaksite kõik need samad filtrid ümber, sest see muutuks suureks-puureks päringuks.

Ja siin on näide sellisest suurest-puurest päringust. See pärineb ametlikust NodeExporter'i armatuurlaudast Grafanas. Kuid ma saan vaid kehvasti aru, mis siin toimub. St, loomulikult saan aru, kui tähelepanelikult vaadata, aga sulgude arv võib koheselt vähendada motivatsiooni mõista, mis siin toimub. Ja miks mitte teha seda lihtsamaks ja selgemaks?

Näiteks nii, eristades olulised asjad või osad muutujates. Ja siis teha oma põhistatistika. See juba sarnaneb programmeerimisele, see on see, mida ma tahaksin tulevikus Grafanas näha.

Siin on teine näide, kuidas me saaksime seda veelgi lihtsamaks teha, kui meil juba oleks see funktsioon ru, ja see on juba olemas VictoriaMetricsis. Siis edastate lihtsalt vahemälu väärtuse, mille olete CTE-s deklareerinud.

Olen juba rääkinud, kui tähtis on kasutada õiget programmeerimiskeelt. Ja tõenäoliselt toimub igaühes Grafanas midagi erilist. Ja tõenäoliselt annate ka oma arendajatele juurdepääsu Grafanale, ja arendajad teevad midagi oma moodi. Kõik nad teevad seda kuidagi erinevalt. Oleks tore, kui asja saaks ühtlustada, st viia see ühise standardini.

Oletame, et teil on isegi mitte ainult süsteemiinsenerid, võib-olla on teil isegi eksperdid, devopsid või SRE-d. Võib-olla on teil eksperdid, kes teavad, mis on jälgimine, teavad, mis on Grafana, st nad on sellega aastaid töötanud ja nad teavad täpselt, kuidas õigesti teha. Ja nad on juba seda 100 korda kirjutanud ja kõigile selgitanud, kuid mingil põhjusel ei kuula keegi.

Aga mis siis, kui nad saaksid need teadmised otse Grafanasse panna, et teised kasutajad saaksid funktsioone taaskasutada? Ja kui oleks vaja arvutada vaba mälu protsenti, siis nad lihtsalt kasutaksid funktsiooni. Aga mis siis, kui eksportijate loojad, koos oma tootega, pakkusid samuti funktsioonide komplekti, kuidas töötada nende mõõdikutega, sest nad teavad täpselt, mis need mõõdikud on ja kuidas neid õigesti arvutada?

Seda tõepoolest ei ole. Selle tegin mina ise. See on olemasolev toetus raamatukogudele Grafanas. Oletame, et inimesed, kes tegid NodeExporter'i, tegid seda, mida ma rääkisin. Ja pakkusid samuti funktsioonide komplekti.

St see näeb välja umbes nii. Te ühendate selle raamatukogu Grafanas, lähete redigeerimisele ja siin on väga lihtsalt JSONis kirjas, kuidas selle mõõdikuga töötada. St mingi funktsioonide komplekt, nende kirjeldus ja see, millesse nad lahti arenduvad.

Minu arvates võiks see olla kasulik, sest siis kirjutaksite Grafanas lihtsalt nii. Ja Grafana "ütleb" teile, et on olemas selline funktsioon sellisest raamatukogust – laseme selle kasutusele võtta. Mulle tundub, et see oleks väga lahe.

Veidi VictoriaMetricsist. Me teeme palju huvitavaid asju. Tutvuge meie artiklitega kompressioonist, meie võistlustest teiste ajaseeria andmeprogrammide vastu, meie seletus, kuidas töötada PromQL-iga, kuna seal on palju algajaid, samuti vertikaalsest skaleeritavusest ja meie võitlust Thanos'e vastu.

Küsimused:

Alustan oma küsimust lihtsa eluloo näitega. Kui ma esmakordselt Grafanat kasutasin, kirjutasin ma väga veenva viie rea päringu. Tulemusena sai väga veenev diagramm. See diagramm oleks peaaegu läinud tootmisse. Kuid lähemal vaatlusel selgus, et see diagramm näitab absoluutset jama, mis pole kuidagi seotud reaalsusega, kuigi numbrid olid oodatud vahemikus. Ja minu küsimus. Meil on raamatukogud, meil on funktsioonid, aga kuidas kirjutame me teste Grafana jaoks? Te olete kirjutanud keerulise päringu, millest sõltub äriline otsus – tellida tõeline serverite konteiner või mitte. Ja kuidas me teame, et see funktsioon, mis joonistab diagrammi, sarnaneb tõele. Aitäh.

Aitäh küsimuse eest. Siin on kaks osa. Esiteks, mulle tundub, et enamik kasutajaid ei saa oma graafikutest aru. Mille põhjuseks on see, et inimesed suudavad alati leida õigustusi kõigile anomalidele, mis graafikutes esinevad, isegi kui see on funktsiooni sisene viga. Teiseks, mulle tundub, et selliste funktsioonide kasutamine sobiks teie probleemi lahendamiseks paremini, kui et iga teie arendaja teeks oma võimsusplaanimist ja eksiks mingi tõenäosusega.

Kuidas kontrollida?

Kuidas kontrollida? Tõenäoliselt mitte kuidagi.

Grafanas testi vormis.

Mis on Grafana seos? Grafana edastab selle päringu otse DataSource'i.

Lisades veidi parameetreid.

Ei, Grafanas ei lisata midagi. Seal võivad olla GET-parameetrid, nagu näiteks step. Seda ei määrata selgelt, kuid saate selle üle kirjutada või mitte, kuid see lisatakse automaatselt. Te ei kirjutage siia teste. Ma arvan, et ei tohiks Grafanale kui tõe allikale toetuda.

Aitäh ettekande eest! Aitäh kompressiooni eest! Te mainisite, et muutujate täitmine graafikus ei toimi Grafanas, kas mõistate, millest ma räägin?

Jah.

See oli algselt peavalu, kui ma tahtsin Grafanas häireid seadistada. Seal tuleb häired seadistada iga hosti jaoks eraldi. Kas see asi, mida te tegite, töötab Grafanas häirete jaoks?

Kui Grafana ei käsitle muutujaid kuidagi teisiti, siis – jah, see töötab. Aga minu soovitus on mitte kasutada Grafanas häirete seadistamist, teile oleks parem kasutada alertmanagerit.

Jah, ma kasutan seda, aga lihtsalt tundus, et Grafanas oli seadistamine lihtsam, aga aitäh nõuande eest!

Allikas: habr.com