Soovitan lugeda Roman Khavronenko ettekande “ExtendedPromQL” ärakirja
Lühidalt minust. Minu nimi on Roman. Töötan CloudFlare'is ja elan Londonis. Kuid ma olen ka VictoriaMetricsi hooldaja.
Ja mina olen autor Grafana ja on ClickHouse'i väike puhverserver.
Alustame esimese osaga, mille nimi on “Tõlkeraskused” ja selles räägin sellest, et iga keel või isegi lihtsalt suhtluskeel on väga oluline. Sest nii edastad sa oma mõtteid teisele inimesele või süsteemile, sõnastad palve. Internetis vaidlevad inimesed, kumb keel on parem – java või mõni muu. Enda jaoks otsustasin, et pean valima ülesande järgi, sest see kõik on spetsiifiline.
Alustame päris algusest. Mis on PromQL? PromQL on Prometheuse päringukeel. Nii moodustame Prometheuses päringuid aegridade andmete saamiseks.
Mis on aegridade andmed? Sõna otseses mõttes on need kolm parameetrit.
Need on:
- Mida me vaatame?
- Kui me seda vaatame.
- Ja mis väärtust see näitab?
Kui vaatate seda diagrammi (see diagramm on minu telefonist, mis näitab minu sammude statistikat), saab see neile küsimustele kiiresti vastata.
Vaatame samme. Me näeme tähendust ja me näeme aega, kui me seda vaatame. See tähendab, et seda diagrammi vaadates võite kergesti öelda, et pühapäeval kõndisin umbes 15 000 sammu. Need on aegridade andmed.
Nüüd "jagame" (teisendame) need tabeli kujul teiseks andmemudeliks. Siin on ka see, mida me vaatame. Siia lisasin veidi lisaandmeid, mida hakkame nimetama metaandmeteks ehk seda ei teinud mina, vaid kaks inimest, näiteks Jay ja Silent Bob. See on see, mida me vaatame; mida see näitab ja millal seda väärtust näitab.
Nüüd proovime salvestada kõik need andmed andmebaasi. Näiteks võtsin ClickHouse'i süntaksi. Ja siin loome ühe tabeli nimega “Sammud”, st mida me vaatame. On aeg, mil me seda vaatame; mida see näitab ja mõned metaandmed, kuhu me salvestame, kes see on: Jay ja Silent Bob.
Ja selle kõige visualiseerimiseks kasutame Grafanat, sest esiteks on see ilus.
Kasutame ka seda pistikprogrammi. Sellel on kaks põhjust. Esimene on see, et ma kirjutasin selle. Ja ma tean täpselt, kui raske on ClickHouse'ist aegridade andmeid hankida, et neid Grafanas näidata.
Kuvame selle graafiku paneelil. See on Grafana populaarseim paneel, mis näitab väärtuse sõltuvust ajast, seega vajame ainult kahte parameetrit.
Kirjutame meie loodud tabelisse kõige lihtsama päringu - kuidas Grafanas sammude statistikat näidata, salvestades need andmed ClickHouse'i. Ja me kirjutame selle lihtsa taotluse. Valime sammude hulgast. Valime väärtuse ja valime nende väärtuste aja, st samad kolm parameetrit, millest me rääkisime.
Ja selle tulemusena saame sellise graafiku. Kes teab, miks ta nii imelik on?
See on õige, peame aja järgi sorteerima.
Ja lõpuks saame parema, kuid siiski kummalise graafiku. Kes teab miks? Täpselt nii, osalejaid on kaks ja meie Grafanas anname ära kaks aegrida, sest kui andmemudelit uuesti vaadata, siis on iga aegrida unikaalne kombinatsioon nimest ja kõigist võtme-väärtuse siltidest.
Seetõttu peame valima konkreetse inimese. Valime Jay.
Ja joonistame uuesti. Nüüd näib graafik tõene. Nüüd on see tavaline graafik ja kõik toimib hästi.
Ja ilmselt teate, kuidas teha umbes sama asja, kuid Prometheuses PromQL-i kaudu. Midagi sellist. Natuke lihtsam. Ja murrame selle kõik lahti. Võtsime sammud. Ja filtreerige Jay järgi. Me ei täpsusta siin, et meil on vaja väärtust saada ja me ei vali aega.
Nüüd proovime välja arvutada Jay või Silent Bobi liikumiskiiruse. ClickHouse'is peame tegema runDifference'i, st arvutama punktipaaride erinevuse ja jagama need ajaga, et saada täpne kiirus. Taotlus näeb välja umbes selline.
Ja see näitab ligikaudu neid väärtusi, st Vaikne Bob või Jay teeb umbes 1,8 sammu sekundis.
Ja Prometheuses teate, kuidas seda ka teha. Palju lihtsam kui varem.
Ja et seda oleks ka Grafanas lihtne teha, lisasin selle ümbrise, mis näeb välja väga sarnane PromQL-iga. Seda nimetatakse määramakrodeks või kuidas iganes soovite seda nimetada. Grafanas kirjutate lihtsalt "määr", kuid kusagil sügaval muutub see selleks suureks taotluseks. Ja te ei pea seda isegi vaatama, see on kuskil olemas, kuid säästate palju aega, sest selliste tohutute SQL-päringute kirjutamine on alati kallis. Võid kergesti eksida ja siis pikka aega mitte aru saada, mis toimub.
Ja see on taotlus, mis ei mahtunud isegi ühte slaidi ja ma pidin selle isegi kaheks veeruks jagama. See on ka ClickHouse'i taotlus, mis teeb sama määra, kuid mõlema aegrea jaoks: Silent Bob ja Jay, nii et meil on paneelil kaks aegrida. Ja see on minu meelest juba väga raske.
Ja Prometheuse järgi on see summa (määr). ClickHouse'i jaoks tegin eraldi makro nimega RateColumns, mis näeb välja nagu Prometheuse päring.
Vaatasime seda ja tundub, et PromQL on nii lahe, kuid sellel on loomulikult piirangud.
Need on:
- Piiratud VALIK.
- Piirjoonelised JOIN-id.
- EI OLE tuge.
Ja kui olete sellega pikka aega töötanud, siis teate, et mõnikord on PromQL-is midagi väga raske teha, kuid SQL-is saate teha peaaegu kõike, sest kõiki neid võimalusi, millest just rääkisime, saab teha SQL-is . Aga kas seda oleks mugav kasutada? Ja see paneb mind mõtlema, et kõige võimsam keel ei pruugi alati kõige mugavam olla.
Seetõttu peate mõnikord valima ülesande jaoks keele. See on nagu Batman võitleks Supermaniga. On selge, et Superman on tugevam, kuid Batman suutis temast jagu saada, sest ta on asjalikum ja teadis täpselt, mida teeb.
Ja järgmine osa on PromQL-i pikendamine.
Veelkord VictoriaMetricsist. Mis on VictoriaMetrics? See on aegridade andmebaas, see on avatud lähtekoodiga, levitame selle üksik- ja klastriversioone. Meie võrdlusnäitajate kohaselt on see kiirem kui mis tahes praegu turul olev ja tihendus on sarnane, st tegelikud inimesed teatavad tihendusest umbes 0,4 baiti punkti kohta, Prometheuse oma aga 1,2–1,4.
Toetame enamat kui lihtsalt Prometheust. Toetame InfluxDB, Graphite, OpenTSDB.
Meile saab “kirjutada” ehk vanu andmeid üle kanda.
Ja me töötame suurepäraselt ka Prometheuse ja Grafanaga, st toetame PromQL mootorit. Ja Grafanas saate lihtsalt muuta Prometheuse lõpp-punktiks VictoriaMetrics ja kõik teie armatuurlauad töötavad nii, nagu nad töötasid.
Kuid saate kasutada ka VictoriaMetricsi pakutavaid lisafunktsioone.
Vaatame kiiresti läbi lisatud funktsioonid.
Jäta intervalliparameeter välja – saate Grafanas intervalli parameetrid välja jätta. Kui te ei soovi paneelil sisse/välja suumimisel kummalisi graafikuid saada, on soovitatav kasutada muutujat $__interval. See on Grafana sisemine muudatus ja see valib ise andmevahemiku. Ja VictoriaMetrics ise saab aru, milline see vahemik peaks olema. Ja te ei pea kõiki oma taotlusi värskendama. See saab olema palju lihtsam.
Teine funktsioon on intervallide viitamine. Saate seda intervalli oma avaldistes kasutada. Saate seda korrutada, jagada, üle kanda, viidata.
Järgmine on koondfunktsioonide perekond. Koondfunktsioon muudab mis tahes teie aegread kolmeks eraldi aegreaks. Need on min, max ja avg. Minu arvates on see väga mugav, sest mõnikord võib see näidata kõrvalekaldeid ja ebatäpsusi.
Ja kui sa lihtsalt vihastad või hindad, siis jätad tõenäoliselt kahe silma vahele mõned juhtumid, kus aegread ei käitu nii, nagu ootasid. Selle funktsiooniga on seda palju lihtsam näha, oletame, et max on väga palju avg-st.
Järgmine on vaikemuutuja. Vaikimisi – see tähendab, millist väärtust peame Grafanas joonistama, kui meil hetkel aegrida pole. Millal see juhtub? Oletame, et ekspordite veamõõdikuid. Ja teil on nii lahe rakendus, et käivitamisel pole järgmise kolme tunni või isegi päeva jooksul ühtegi viga ja isegi mitte ühtegi viga. Ja teil on armatuurlauad, mis näitavad suhet edust veani. Ja nad ei näita teile midagi, kuna teil pole veamõõdikut. Ja vaikimisi saate määrata kõike.
Keep_last_Value – salvestab mõõdiku viimase väärtuse, kui see puudub. Kui Prometheus ei leia seda 5 minuti jooksul pärast järgmist kraapimist, siis siin jätame selle viimase väärtuse meelde ja teie graafikud enam ei purune.
Scrape_interval – näitab, kui sageli ja millise sagedusega Prometheus teie mõõdiku kohta andmeid kogub. Siin näete näiteks passi.
Sildi asendamine on populaarne funktsioon. Kuid me arvame, et see on veidi keeruline, sest see nõuab terveid argumente. Ja peate mitte ainult 5 argumenti meeles pidama, vaid ka nende järjestust meeles pidama.
Seega, miks mitte muuta need lihtsamaks? See tähendab, et jagage see arusaadava süntaksiga väikesteks funktsioonideks.
Ja nüüd lõbus osa. Miks me arvame, et see on laiendatud PromQL? Kuna me toetame tavalisi tabeliväljendeid. Saate jälgida QR-koodi (), vaadake mänguväljaku linke koos näidetega, kus saate otse VictoriaMetricsis päringuid käivitada, ilma seda lihtsalt brauserisse installimata.
Ja mis see on? See ülaltoodud taotlus on üsna populaarne. Arvan, et paljude ettevõtete armatuurlaual kasutatakse kõige jaoks sama filtrit. Tavaliselt nii. Kuid kui teil on vaja lisada mõni uus filter, peate iga paneeli värskendama või laadima armatuurlaua alla, avama selle JSON-is, leidma asendamise, mis võtab samuti aega. Miks mitte salvestada see väärtus muutujas ja seda uuesti kasutada? See tundub minu arvates palju lihtsam ja selgem.
Näiteks kui pean Grafana filtreid värskendama kõigis taotlustes ja armatuurlaud võib olla tohutu või neid võib olla isegi mitu. Ja kuidas ma tahaksin selle probleemi Grafanas lahendada?
Ma lahendan selle probleemi järgmiselt: teen commonFilteri ja defineerin selles selle filtri ning kasutan seda siis päringutes uuesti. Aga kui teete sama praegu, siis see ei tööta, sest Grafana ei luba teil päringumuutujate sees muutujaid kasutada. Ja see on natuke imelik.
Ja nii ma tegin valiku, mis võimaldab teil seda teha. Ja kui olete huvitatud või soovite sellist funktsiooni, siis toetage seda või ei meeldi see, kui see idee teile ei meeldi.
Lisateavet PromQL laiendatud kohta. Siin defineerime mitte ainult muutuja, vaid terve funktsiooni. Ja me kutsume seda ru (ressursikasutus). Ja see funktsioon aktsepteerib tasuta ressursse, ressursipiiranguid ja filtrit. Süntaks näib olevat lihtne. Ja seda funktsiooni on väga lihtne kasutada ja vaba mälu protsenti arvutada. See tähendab, kui palju mälu meil on, mis on piirang ja kuidas filtreerida. Tundub palju mugavam, kui kirjutaksite selle kõik uuesti samu filtreid kasutades, sest see muutuks suureks ja suureks päringuks.
Ja siin on näide sellisest suurest suurest taotlusest. See pärineb Grafana ametlikult NodeExporteri armatuurlaualt. Aga ma ei saa vaevu aru, mis siin toimub. Seda ma muidugi mõistan, kui tähelepanelikult vaadata, aga sulgude arv võib kohe kahandada motivatsiooni mõista, mis siin toimub. Ja miks mitte muuta see lihtsamaks ja selgemaks?
Näiteks niimoodi oluliste asjade või osade eraldamine muutujateks. Ja siis tehke oma elementaarne matemaatika. See on juba rohkem nagu programmeerimine, seda tahaks tulevikus Grafanas näha.
Siin on teine näide selle kohta, kuidas saaksime seda veelgi lihtsamaks muuta, kui meil oleks see ru-funktsioon juba olemas ja see on VictoriaMetricsis juba olemas. Seejärel edastate lihtsalt vahemällu salvestatud väärtuse, mille deklareerisite CTE-s.
Olen juba rääkinud, kui oluline on kasutada õiget programmeerimiskeelt. Ja ilmselt on igas Grafana ettevõttes midagi erinevat. Ja tõenäoliselt annate ka oma arendajatele juurdepääsu Grafanale ja arendajad ajavad oma asju. Ja nad kõik teevad seda kuidagi erinevalt. Aga ma tahtsin, et see oleks kuidagi sama, st et taandada see ühisele standardile.
Oletame, et teil pole isegi mitte ainult süsteemiinsenerid, vaid võib-olla isegi eksperdid, devopid või SRE. Võib-olla on teil eksperte, kes teavad, mis on monitooring, kes teavad, mis on Grafana, st nad on sellega aastaid töötanud ja teavad täpselt, kuidas seda õigesti teha. Ja nad on seda juba 100 korda kirjutanud ja kõigile selgitanud, aga millegipärast keegi ei kuula.
Mis siis, kui nad saaksid need teadmised otse Grafanasse panna, et teised kasutajad saaksid funktsioone uuesti kasutada? Ja kui neil oli vaja arvutada vaba mälu protsent, rakendaksid nad lihtsalt funktsiooni. Mis oleks, kui eksportijate loojad pakuksid koos oma tootega ka funktsioonide komplekti, kuidas oma mõõdikutega töötada, sest nad teavad täpselt, mis need mõõdikud on ja kuidas neid õigesti arvutada?
Seda pole tegelikult olemas. Seda ma ise tegin. See on Grafana raamatukogu tugi. Oletame, et mehed, kes tegid NodeExporteri, tegid seda, millest ma rääkisin. Ja nad pakkusid ka funktsioonide komplekti.
See tähendab, et see näeb välja umbes selline. Ühendate selle teegi Grafanaga, asute redigeerima ja JSON-is on väga lihtsalt kirjutatud, kuidas selle mõõdikuga töötada. See tähendab, et mõned funktsioonid, nende kirjeldus ja see, milleks need muutuvad.
Ma arvan, et see võib olla kasulik, sest siis Grafanas kirjutaksite just nii. Ja Grafana “ütleb”, et sellisest ja sellisest raamatukogust on olemas selline ja selline funktsioon - kasutame seda. Ma arvan, et see oleks väga lahe.
Natuke VictoriaMetricsist. Teeme palju huvitavaid asju. Lugege meie artikleid tihendamise kohta, meie võistlustest teiste aegridade andmerakendustega, meie selgitusi selle kohta, kuidas PromQL-iga töötada, sest selles on veel palju algajaid, samuti vertikaalse skaleeritavuse ja vastasseisu kohta Thanosega.
Küsimused:
Alustan oma küsimust lihtsa elulooga. Kui ma esimest korda Grafanat kasutama hakkasin, kirjutasin väga mõjuva päringu, mis oli 5 rida pikk. Lõpptulemus on väga veenev graafik. See ajakava on peaaegu tootmisse läinud. Kuid lähemal uurimisel selgus, et see graafik näitab absoluutset jama, millel pole tegelikkusega mingit pistmist, kuigi numbrid jäävad vahemikku, mida me eeldasime. Ja minu küsimus. Meil on raamatukogud, meil on funktsioonid, aga kuidas me Grafana jaoks teste kirjutame? Olete kirjutanud keerulise taotluse, millest sõltub äriotsus – kas tellida päris serverite konteiner või mitte tellida. Ja nagu me teame, sarnaneb see graafikut koostav funktsioon tõega. Aitäh.
Täname küsimuse eest. Seal on kaks osa. Esiteks jääb mulle oma kogemuse põhjal mulje, et enamik kasutajaid ei saa graafikuid vaadates aru, mida nad neile näitavad. Millegipärast oskavad inimesed väga hästi välja mõelda vabanduse igale graafikutes esinevale anomaaliale, isegi kui tegu on funktsioonisisese veaga. Ja teine osa - mulle tundub, et selliste funktsioonide kasutamine oleks palju parem lähenemine teie probleemi lahendamisele, selle asemel, et iga teie arendaja ise planeeriks oma võimekust ja teeks teatud tõenäosusega vigu.
Kuidas kontrollida?
Kuidas kontrollida? Ilmselt mitte.
Testiks Grafanas.
Mis on Grafanal sellega pistmist? Grafana tõlgib selle päringu otse andmeallikasse.
Parameetritele natukene juurde.
Ei, Grafanale ei lisata midagi. Võib olla GET-i parameetreid, nagu näiteks samm. See ei ole otseselt määratud, kuid saate selle tühistada või te ei saa seda tühistada, kuid see lisatakse automaatselt. Sa ei kirjuta siia teste. Ma arvan, et me ei peaks siinkohal toetuma Grafanale kui tõeallikale.
Täname raporti eest! Aitäh tihendamise eest! Mainisite muutuja kaardistamist graafikus, et Grafanas ei saa muutujat muutuja sees kasutada. Kas tead mida mõtlen?
Jah.
Algselt valmistas see peavalu, kui tahtsin Grafanasse hoiatuse luua. Ja seal peate iga hosti jaoks eraldi hoiatuse tegema. Kas see teie tehtud asi töötab Grafana hoiatuste puhul?
Kui Grafana ei pääse muutujatele erinevalt juurde, siis jah, see töötab. Kuid minu nõuanne on, et ärge Grafanas hoiatusi üldse kasutage, parem on kasutada alertmanagerit.
Jah, ma kasutan seda, aga tundus, et seda on Grafanas lihtsam seadistada, aga tänan nõu eest!
Allikas: www.habr.com