«ExtendedPromQL» — Romani Havronenko ettekande kokkuvõte

Tutvustan Romain Khavroenko raporti "ExtendedPromQL" sisukokkuvõtet.

Lühidalt minust. Minu nimi on Romain. Töötoime CloudFlare'is, elan Londonis. Olen ka VictoriaMetrics'i hooldaja.
Ja ma olen autor ClickHouse'i pluginast Grafana jaoks ja ClickHouse-proxy – see on väike proxy ClickHouse'i jaoks.

Kasutame esimest osa, mis kannab nime "Tõlke keerukused", kus räägin, et iga keel või isegi lihtsalt suhtlemiskeel on väga oluline. Sest see on viis, kuidas edastate oma mõtteid teisele inimesele või süsteemile, kuidas te esitate päringu. Internetis vaieldakse selle üle, milline keel on parem – java või mõni muu. Otsustasin, et tuleb valida vastavalt ülesandele, sest kõik see on spetsiifiline.

Alustame algusest. Mis on PromQL? PromQL on Prometheuse päringukeel. See on viis, kuidas me vormistame päringud Prometheuses, et saada ajaseeria andmeid.

Mis on ajaseeria andmed? Kui võtta sõnasõnaliselt, siis need on kolm parameetrit.

Need on:

• Millele me vaatame.
• Millal me sellele vaatame.
• Ja milline väärtus näitab.

Kui vaadata seda diagrammi (see diagramm on minu telefonist, mis näitab minu samblaste statistikat), siis saame kiiresti sellele küsimusele vastata.

Me vaatame samme. Näeme väärtust ja aega, mil me sellele vaatame. Seega, vaadates seda diagrammi, on lihtne öelda, et pühapäeval kõndisin umbes 15 000 sammu. Need on ajaseeria andmed.

Nüüd proovime "jaotada" (muuta) need teise andmemudeli kujul tabelina. Siin on meil samuti see, millele me vaatame. Siia olen lisanud täiendavaid andmeid, mida nimetame metaandmeteks, seega see ei olnud mitte mina, vaid kaks inimest, oletame, Jay ja Silent Bob. See on see, millele me vaatame; mida see näitab ja millal see väärtus näitab.

Nüüd proovime salvestada kõik need andmed andmebaasi. Näiteks võtsin ClickHouse'i süntaksi. Siin loome ühe tabeli, mis kannab nime "Steps", st millele me vaatame. Siin on aeg, mil me sellele vaatame; mida see näitab ja mõned metaandmed, kus me salvestame, kes see on: Jay ja Silent Bob.

Ja et proovida seda kõike visualiseerida, kasutame Grafana't, sest eelkõige on see ilus.

Me kasutame ka seda pistikprogrammi. Selleks on kaks põhjust. Esiteks, sest mina selle kirjutasin. Ja ma tean täpselt, kui keeruline on time series andmete eraldamine ClickHouse'ist, et neid Grafanas näidata.

Kätkeme Graph Panelis. See on kõige populaarsem paneel Grafanas, mis kuvab väärtuse sõltuvust ajast, seega vajame ainult kahte parameetrit.

Kirjutame kõige lihtsama päringu — kuidas näidata samme Grafanas, mille andmed on salvestatud ClickHouse'i, tabelisse, mille me lõime. Ja me kirjutame sellise lihtsa päringu. Valime sammudest. Valime väärtuse ja valime nende väärtuste aja, st samad kolm parameetrit, millest me rääkisime.

Ja tulemuseks saame sellise graafiku. Kas keegi teab, miks see nii kummaline on?

Õige, tuleb sorteerida ajas.

Ja lõpuks saame juba parem, aga ikka kummalise graafiku. Kas keegi teab, miks? Õige, seal on kaks osalejat, ja me saame Grafanas kaks time series, sest kui vaatame tüpoloogiat veel kord, siis iga time series on ainulaadne kombinatsioon nimest ja kõigist võtme-väärtuse labelitest.

Seega peame valima konkreetse isiku. 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 ilmselt teate, kuidas teha umbes sama ka Prometheuses läbi PromQL. Umbes nii. Veidi lihtsam. Ja veel jagame selle kõik. Me võtsime Steps. Ja filtreerime Jay järgi. Me ei näita siin, et me tahame saada väärtust ja me ei vali aega.

Aga nüüd proovime arvutada Jay või Silent Bob'i liikuvuse kiirus. ClickHouse'is peame tegema runningDifference, st arvutama paaride punktide erinevuse ja jagama nad ajaga, et saada täpne kiirus. Päring 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 Prometheuses teate, kuidas seda teha samuti. Oluliselt lihtsam, kui see oli varem.

Ja et see oleks Grafanas lihtne, lisasin ma sellise mähise, mis sarnaneb PromQL-iga. Seda nimetatakse Rate Macros või kuidas iganes soovite. Grafanas kirjutate lihtsalt „rate”, kuid kuskil sügaval muudetakse see suureks päringuks. Teie ei pea isegi sellele vaatama, see on seal kuskil, kuid säästate rohkesti aega, sest selliste suurte SQL-päringute kirjutamine on alati aeganõudev. Te võite kergesti eksida ja hiljem kaua aru saada, mis toimub.

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

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

Me vaatasime ja tundus, et PromQL on tõeliselt äge, kuid sellel on loomulikult omad piirangud.

Need on:

• Piiratud SELECT.
• Piiratud JOIN.
• Puudub HAVING tugi.

Ja kui olete sellega kaua töötanud, siis teate, et mõnikord on PromQL'is midagi teha väga raske, samas kui SQL-is saab teha praktiliselt kõike, sest kõik need variandid, millest me praegu rääkisime, oleks saanud teostada SQL-is. Kuid kas oleks mugav seda kasutada? Ja see viib mind mõtlema, et mitte alati ei pruugi kõige võimsam keel olla kõige mugavam.

Seetõttu tuleb mõnikord valida keel ülesannete järgi. See on nagu Batmani ja Supermani lahing. Selge, et Superman on tugevam, kuid Batman suutis ta võita, sest ta on praktilisem ja teadis täpselt, mida teeb.

Ja järgmine osa on Extending PromQL.

Veel kord VictoriaMetricsist. Mis on VictoriaMetrics? See on ajalooliste andmete baas, mis on OpenSource, me jagame selle single- ja klastriversioone. Meie benchmarkide kohaselt on see kiireim, mis turul praegu on ja kompressioon on samuti sarnane, st elavad inimesed teatavad kompressioonist umbes 0,4 bait/punkt, kui Prometheuse puhul on see 1,2-1,4.

Me toetame mitte ainult Prometheust. Me toetame InfluxDB-d, Graphite'i, OpenTSDB-d.

Meisse saab "kirjutada", st vanu andmeid saab üle kanda.

Ja me töötame ideaalselt Prometheuse ja Grafanaga, st toetame PromQL mootorit. Ja Grafanas võite lihtsalt vahetada Prometheuse lõpp-punkti VictoriaMetricsi vastu, ja teie kõik armatuurlaud toimib nagu enne.

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

Vaatame kiiresti funktsioone, mille me oleme lisanud.

Omandage interval'i parameeter – saate Grafanas vahe parameetreid vahele jätta. Kui te ei soovi saada kummalisi graafikuid, kui zoomite sisse/välja paneelil, siis on soovitatav kasutada muutujat $__interval. See on Grafana sisemine muutuja ja see valib ise andmete vahemiku. Ja VictoriaMetrics suudab ise mõista, milline see vahemik olema peab. Te ei pea uuendama oma päringuid. See on palju lihtsam.

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

Edasi liikudes rollup funktsioonide kogum. Rollup funktsioon muudab teie ajaseeriad kolmeks eraldi ajaseeriaks. Need on min, max ja avg. Arvan, et see on väga mugav, kuna see võib mõnikord näidata teatud kõrvalekaldeid ja ebatäpsusi.

Ja kui te lihtsalt teete irate või rate, siis on tõenäoline, et võite mõnda juhtumit kõrvale jätta, kui ajaseeria käitub mitte nii, nagu te oletate. Selle funktsiooniga on palju lihtsam näha, et näiteks max on palju kõrgem kui avg.

Edasi muutuja default. Default tähendab, millist väärtust peame Grafanas joonistama, kui meil ei ole ajaseeriat hetkel. Millal see juhtub? Oletame, et ekspordite mõnda veateavet. Ja teil on nii suur rakendus, et kui te alustate, siis ei ole teil vigu ja isegi kolme tunni jooksul või isegi päeva jooksul ei ole vigu. Ja teil on armatuurlaud, mis näitab suhete suhet edus ja vigades. Ja nad näitavad teile mitte midagi, kuna teil ei ole veateavet. Default's saate määrata ükskõik mida.

Keep_last_Value – salvestab viimase mõõtme väärtuse, kui see kaob. Kui Prometheus ei leia järgmisel häälestamisel seda viie minuti jooksul, siis 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 sageli. Siit on näiteks võimalik näha lünki.

Label replace – populaarne funktsioon. Kuid meie arvates on see pisut keeruline, kuna see võtab terveid argumente. Ja peate mitte ainult meeles pidama 5 argumenti, vaid ka nende järjekorda.

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

Ja nüüd tuleb huvitav osa. Miks me arvame, et see on extended PromQL? Sest toetame Ühislauda. Sa saad skaneerida QR-koodi (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), vaadata näidiste linke, mänguväljakku, kus saad teostada päringuid otse VictoriaMetrics'is ilma selle installimata lihtsalt brauseris.

Ja mis see siis on? See ülalpool olev päring – see on üsna populaarne päring. Ma arvan, et igas andmevisualiseerimises paljudes ettevõtetes kasutad sama filtrit kõigi jaoks. Tavaliselt nii. Aga kui pead lisama mingi uue filtri, tuleb iga paneel uuendada või laadida andmevisualiseerimine alla, avada JSON-is, teha find replace, mis ka võtab aega. Miks mitte hoida seda väärtust muutujas ja taaskasutada seda? See tundub minu arvates palju lihtsam ja arusaadavam.

Näiteks, kui mul on vaja uuendada filtreid Grafanas kõigis päringutes, ja andmevisualiseerimine võib olla tohutu või neid võib olla isegi mitu. Ja kuidas ma sooviksin seda probleemi Grafanas lahendada?

Lahendan selle probleemi nii: teen commonFilteri ja määratlen selles filtris, ning seejärel taaskasutada seda päringutes. Kuid kui sa teed nüüd samamoodi, ei toimi see, sest Grafana ei luba sul kasutada muutujaid sisemistes päringumuutujates. Ja see on veidi kummaline.

Ja seetõttu tegin sellise variandi, mis lubab seda teha. Ja kui see huvitab sind või soovid sellist funktsiooni, siis toeta või hinda negatiivselt, kui sulle ei meeldi selline idee. https://github.com/grafana/grafana/pull/16694

Edasi extended PromQL'i kohta. Siin määratleme mitte ainult muutuja, vaid lausa terve funktsiooni. Ja nimetame selle ru (resource usage). See funktsioon võtab vastu vabad ressursid, ressursi piirangu ja filtri. Süntaks tundub olema lihtne. Ja on väga lihtne kasutada seda funktsiooni ning arvutada meie vabade mälu protsent. St. kui palju meil on mälu, mis on piirang ja kuidas filtreerida. See tundub oluliselt mugavam, sest kirjutades kõik kasutada sama filtrit, see muutuks suureks-pädevaks päringuks.

Ja, ja näide sellisest suurest päringust. See on ametlikust NodeExporter'i juhtpaneelist Grafanas. Aga ma ei saa aru, mis siin toimub. T. e., muidugi, ma saan aru, kui tähelepanelikult vaadata, aga sulgede arv võib kohe motivatsiooni alandada mõista, mis siin toimub. Ja miks mitte teha seda lihtsamaks ja selgemaks?

Näiteks nii, tuues esile olulised asjad või osad muutujatesse. Ja siis tehes oma baasmatemaatika. See on juba rohkem nagu programmeerimine, see on see, mida ma tahaksin tulevikus Grafanas näha.

See on teine näide, kuidas saame seda veelgi lihtsamaks teha, kui meil oleks see funktsioon ru, ja see on juba olemas VictoriaMetrics'is. Ja siis edastate lihtsalt vahemälus oleva väärtuse, mille olete CTE's kuulutanud.

Ma olen juba rääkinud, kui oluline on kasutada õiget programmeerimiskeelt. Ja ilmselt igas ettevõttes toimub Grafanas midagi oma. Ja ilmselt annate ka oma arendajatele juurdepääsu Grafanale, ja arendajad teevad midagi oma. Ja kõik nad teevad seda kuidagi erinevalt. Ja oleks hea, kui saaks kuidagi ühtsemalt, t. e. viia see ühise standardini.

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

Ja mis siis, kui nad saaksid need teadmised otse Grafanasse panna, et teised kasutajad saaksid funktsioone taaskasutada? Ja kui peaks arvutama vaba mälu protsendi, siis nad lihtsalt rakendaksid funktsiooni. Aga mis siis, kui eksportijate tegijad kaasneksid oma tootega ka funktsioonide kogumitega, kuidas töötada nende mõõtmetega, sest nad teavad täpselt, mis need mõõtmed on ja kuidas neid õigesti arvutada?

Seda tegelikult ei eksisteeri. Selle tegin mina ise. See on toetuse raamatukogude jaoks Grafanas. Eeldame, et poisid, kes tegid NodeExporter'i, tegid seda, millest ma rääkisin. Ja pakkusid ka funktsioonide kogumit.

See, it looks something like this. You connect this library in Grafana, you go into editing, and here it’s very simply written in JSON how to work with this metric. That is, it’s some set of functions, their descriptions, and how they unfold.

I think this could be useful, because then in Grafana you would just write like this. And Grafana 'tells' you that there is such a function from a certain library – let’s use it. I think that would be really great.

A bit about VictoriaMetrics. We are doing a lot of interesting things. Read our articles about compression, about our competitions with other time series data applications, our explanations on how to work with PromQL, because there are still many newcomers, as well as about vertical scalability and our confrontation with Thanos.

Küsimused:

I will start my question with a simple life story. When I first started using Grafana, I wrote a very convincing query that was five lines long. In the end, I got a very convincing graph. This graph almost went into production. But upon closer inspection, it turned out that this graph shows absolute nonsense, having nothing to do with reality, although the numbers fall within the range we expected to see. And my question is. We have libraries, we have functions, but how do we write tests for Grafana? You wrote a complex query that depends on a business decision – whether to order a real container of servers or not. And how do we know that this function, which draws the graph, resembles the truth? Thank you.

Thanks for the question. There are two parts. First – I have the impression, based on my practice, that most users, when looking at their graphs, do not understand what they are showing. For some reason, people are very good at coming up with justifications for any anomalies that occur on the graphs, even if it’s an error inside the function. And the second part – it seems to me that using such functions would suit your problem much better, instead of each of your developers doing their own capacity planning and being wrong with some probability.

How to check?

How to check? Probably, no way.

In the form of a test in Grafana.

What does Grafana have to do with it? Grafana translates this query directly into the DataSource.

Adding a little bit to the parameters.

Ei, Grafanas ei lisata midagi. Seal võivad olla GET-parameetrid, nagu näiteks step. Seda ei öelda selgelt, kuid saate selle ületada, võite mitte ületada, kuid see lisatakse automaatselt. Te ei kirjuta siia teste. Ma arvan, et ei tasu Grafanat tõe allikana usaldada.

Aitäh ettekande eest! Aitäh kompresseerimise eest! Te mainisite, et grafikus ei saa kasutada muutujaid muutuja sees, kas saate aru, millest ma räägin?

Jah.

See oli algselt peavalu, kui ma tahtsin Grafanas hoiatust teha. Ja seal tuleb hoiatust teha iga hosti jaoks eraldi. Kas see, mille te tegite, töötab hoiatuste jaoks Grafanas?

Kui Grafana ei käsitle muutujaid kuidagi teisiti, siis jah, see töötab. Kuid minu soovitus on mitte kasutada Grafanas hoiatamist üldse, teil on parem kasutada alertmanagerit.

Jah, ma kasutan seda, aga lihtsalt tundus Grafanas seadistamine kergem, aga aitäh näpunäite eest!

Allikas: habr.com