Ehdotan, että luet Roman Khavronenkon raportin "ExtendedPromQL"
Lyhyesti minusta. Nimeni on Roman. Työskentelen CloudFlaressa ja asun Lontoossa. Mutta olen myös VictoriaMetricsin ylläpitäjä.
Ja minä olen kirjoittaja Grafanalle ja on pieni välityspalvelin ClickHouselle.
Aloitamme ensimmäisestä osasta, jonka nimi on "Käännösvaikeudet", ja siinä puhun siitä, että mikä tahansa kieli tai jopa pelkkä viestintäkieli on erittäin tärkeä. Koska tällä tavalla välität ajatuksesi toiselle henkilölle tai järjestelmälle, miten muotoilet pyynnön. Ihmiset Internetissä kiistelevät kumpi kieli on parempi - java vai jokin muu. Itselleni päätin, että on tarpeen valita tehtävä, koska kaikki tämä on erityistä.
Aloitetaan aivan alusta. Mikä on PromQL? PromQL on Prometheus-kyselykieli. Näin muodostamme kyselyitä Prometheukseen saadaksemme aikasarjadataa, aikasarjoja.
Mitä aikasarjatiedot ovat? Kirjaimellisesti nämä ovat kolme parametria.
Ne ovat:
- Mitä me katsomme.
- Kun katsomme sitä.
- Ja mitä arvoa se osoittaa.
Jos katsot tätä kaaviota (tämä kaavio on puhelimestani, joka näyttää askeleideni tilastot), täältä voit nopeasti vastata näihin kysymyksiin.
Tarkastelemme vaiheita. Näemme merkityksen ja näemme ajan, kun katsomme sitä. Eli katsomalla tätä kaaviota voit helposti sanoa, että kävelin sunnuntaina noin 15 000 askelta. Tämä on aikasarjadataa.
Nyt "rikotaan" (muunnetaan) ne toiseksi tietomalliksi taulukon muodossa. Tässä meillä on myös se, mitä katsomme. Lisäsin tähän vähän lisätietoa, jota kutsumme metatiedoksi, eli en minä käynyt läpi, vaan kaksi ihmistä, esimerkiksi Jay ja Silent Bob. Sitä me tarkastelemme; mitä se näyttää ja milloin se näyttää sen arvon.
Yritetään nyt tallentaa kaikki nämä tiedot tietokantaan. Esimerkiksi otin ClickHouse-syntaksin. Ja tässä luomme yhden taulukon nimeltä "Steps", eli mitä tarkastelemme. Tässä on aika, kun katsomme sitä; mitä se näyttää ja joitain metatietoja, joihin tallennamme kuka se on: Jay ja Silent Bob.
Ja yrittääksemme visualisoida kaiken, käytämme Grafanaa, koska ensinnäkin se on kaunis.
Käytämme myös tätä laajennusta. Tähän on kaksi syytä. Ensimmäinen johtuu siitä, että kirjoitin sen. Ja tiedän tarkalleen, kuinka vaikeaa on vetää aikasarjatietoja ClickHousesta näyttääksesi ne Grafanassa.
Näytämme Graafi-paneelissa. Tämä on Grafanan suosituin paneeli ja näyttää arvon suhteessa aikaan, joten tarvitsemme vain kaksi parametria.
Kirjoitetaan yksinkertaisin kysely - kuinka näyttää askeltilastot Grafanassa, tallentamalla nämä tiedot ClickHouseen, luomaan taulukkoon. Ja kirjoitamme niin yksinkertaisen kyselyn. Valitsemme vaiheista. Valitsemme arvon ja valitsemme näiden arvojen ajan, eli samat kolme parametria, joista puhuimme.
Ja tuloksena saamme tämän kaavion. Kuka tietää, miksi hän on niin outo?
Aivan oikein, sinun täytyy lajitella ajan mukaan.
Ja lopulta saamme paremman, mutta silti kummallisen aikataulun. Kuka tietää miksi? Aivan oikein, osallistujia on kaksi, ja annamme Grafanassa kaksi aikasarjaa, koska jos käsittelemme tietomallia uudelleen, jokainen aikasarja on ainutlaatuinen yhdistelmä nimestä ja kaikista nimiöistä avainarvot.
Siksi meidän on valittava tietty henkilö. Valitsemme Jayn.
Ja piirrä uudelleen. Nyt kaavio näyttää todelta. Nyt on normaali aikataulu ja kaikki toimii hyvin.
Ja luultavasti tiedät kuinka tehdä sama asia, mutta Prometheuksessa PromQL:n kautta. Suunnilleen näin. Hieman helpompaa. Ja puretaan se kaikki. Otimme Steps. Ja Jayn suodatin. Emme määrittele tässä, että meidän on saatava arvo, emmekä valitse aikaa.
Yritetään nyt laskea Jayn tai Silent Bobin liikenopeus. ClickHousessa meidän täytyy tehdä runningDifference, eli laskea pisteparien välinen ero ja jakaa ne ajalla saadaksesi tarkan nopeuden. Pyyntö näyttää suunnilleen tältä.
Ja hän näyttää suunnilleen nämä arvot, eli noin 1,8 askelta sekunnissa tekee Silent Bob tai Jay.
Ja Prometheuksessa osaat myös tehdä sen. Paljon helpompaa kuin ennen.
Ja jotta se olisi helppo tehdä myös Grafanassa, lisäsin sellaisen kääreen, joka näyttää hyvin samanlaiselta kuin PromQL. Sitä kutsutaan nopeusmakroiksi tai miksi haluat sitä kutsua. Grafanassa kirjoitat vain "hinta", mutta jossain syvällä se muuttuu niin suureksi pyynnöksi. Ja sinun ei tarvitse edes katsoa sitä, se on siellä jossain, mutta säästät paljon aikaa, koska niin valtavien SQL-kyselyiden kirjoittaminen on aina kallista. Voit helposti tehdä virheen etkä ymmärrä mitä tapahtuu pitkään aikaan.
Ja tämä on kysely, joka ei mahtunut edes yhteen diaan, ja minun piti jopa jakaa se kahteen sarakkeeseen. Tämä on myös ClickHousen pyyntö, joka tekee saman koron, mutta molemmille aikasarjoille: Silent Bob ja Jay, joten meillä on paneelissa kaksi aikasarjaa. Ja tämä on mielestäni jo erittäin vaikeaa.
Ja Prometheuksen mukaan se on summa (kurssi). ClickHouselle tein erillisen makron nimeltä RateColumns, joka näyttää Prometheus-kyselyltä.
Katsoimme ja näyttää siltä, että PromQL on niin siistiä, mutta sillä on tietysti rajoituksia.
Ne ovat:
- Rajoitettu SELECT.
- Edge JOINit.
- EI OLE tukea.
Ja jos olet työskennellyt sen kanssa pitkään, tiedät, että joskus on erittäin vaikeaa tehdä jotain PromQL:ssä, ja SQL:ssä voit tehdä melkein kaiken, koska kaikki nämä vaihtoehdot, joista juuri puhuimme, voidaan tehdä SQL: ssä. . Mutta olisiko sen käyttö kätevää? Ja tämä saa minut ajattelemaan, että aina tehokkain kieli ei voi olla kätevin.
Siksi joskus sinun on valittava tehtävien kieli. Se on kuin Batmanin ja Supermanin välinen taistelu. On selvää, että Superman on vahvempi, mutta Batman pystyi voittamaan hänet, koska hän on käytännöllisempi ja tiesi tarkalleen mitä oli tekemässä.
Ja seuraava osa on PromQL:n laajentaminen.
Vielä kerran VictoriaMetricsistä. Mikä on VictoriaMetrics? Tämä on aikasarjatietokanta, se on OpenSourcessa, jaamme sen yksittäis- ja klusteriversioita. Vertailuarvojemme mukaan se on nopein nyt markkinoilla oleva ja pakkaus on samanlainen, eli elävät ihmiset raportoivat noin 0,4 tavua pistettä kohti, kun Prometheusilla on 1,2-1,4.
Emme tue vain Prometheusta. Tuemme InfluxDB:tä, Graphitea, OpenTSDB:tä.
Voit "kirjoittaa" meihin, eli voit siirtää vanhoja tietoja.
Ja toimimme täydellisesti myös Prometheuksen ja Grafanan kanssa, eli tuemme PromQL-moottoria. Ja Grafanassa voit yksinkertaisesti muuttaa Prometheus-päätepisteen VictoriaMetricsiksi, ja kaikki kojelautasi toimivat kuten ne toimivat.
Mutta voit myös käyttää VictoriaMetricsin tarjoamia lisäsiruja.
Käymme nopeasti läpi lisäämämme ominaisuudet.
Jätä väliparametri pois – voit ohittaa parametrivälin Grafanassa. Kun et halua saada outoja kaavioita paneelia lähennettäessä/loitonnettaessa, on suositeltavaa käyttää muuttujaa $__interval. Tämä on sisäinen Grafana-muutos ja se valitsee itse tietoalueen. Ja VictoriaMetrics voi itse ymmärtää, mikä tämän alueen pitäisi olla. Eikä sinun tarvitse päivittää kaikkia kyselyjäsi. Se on paljon helpompaa.
Toinen toiminto on intervalliviittaus. Voit käyttää tätä välilyöntiä lausekkeissasi. Voit kertoa, jakaa, siirtää, viitata siihen.
Seuraava on rollup-toimintoperhe. Rollup-toiminto muuttaa minkä tahansa aikasarjasi kolmeksi erilliseksi aikasarjaksi. Nämä ovat min, max ja avg. Minusta se on erittäin kätevä, koska joskus se voi näyttää poikkeamia (poikkeavuuksia) ja epätarkkuuksia.
Ja jos teet vain vihaa tai arvostelet, voit luultavasti missata joitakin tapauksia, joissa aikasarjat eivät toimi haluamallasi tavalla. Se on paljon helpompi nähdä tällä toiminnolla, oletetaan, että max on hyvin paljon keskiarvon alapuolella.
Seuraava on oletusmuuttuja. Oletus - tämä tarkoittaa, mitä arvoa meidän on piirrettävä Grafanaan, jos meillä ei ole tällä hetkellä aikasarjaa. Milloin se tapahtuu? Oletetaan, että viet joitakin virhemittareita. Ja sinulla on niin hieno sovellus, että kun käynnistät, sinulla ei ole virheitä eikä edes mitään virheitä seuraavan kolmen tunnin tai jopa päivän aikana. Ja sinulla on kojelautat, jotka näyttävät suhteita menestyksestä virheeseen. Ja he eivät näytä sinulle mitään, koska sinulla ei ole virhemittaria. Ja oletuksena voit määrittää mitä tahansa.
Keep_last_Value – tallentaa mittarin viimeisen arvon, jos se puuttuu. Jos Prometheus ei seuraavan kaavin jälkeen löytänyt sitä 5 minuutin sisällä, niin tässä muistamme sen viimeisen arvon ja kaaviosi eivät katkea uudelleen.
Scrape_interval – näyttää, kuinka usein Prometheus kerää tietoja mittaristasi ja millä tiheydellä. Täältä näet esimerkiksi passin.
Tarran vaihto on suosittu ominaisuus. Mutta mielestämme se on hieman monimutkainen, koska se vaatii kokonaislukuargumentteja. Ja sinun ei tarvitse muistaa vain 5 argumenttia, vaan myös niiden järjestys.
Miksi ei siis tehdä niistä yksinkertaisempia? Eli jaa se pieniksi funktioiksi selkeällä syntaksilla.
Ja nyt mielenkiintoisin. Miksi mielestämme se on laajennettu PromQL? Koska tuemme yleisiä taulukkolausekkeita. Voit seurata QR-koodia (), katso linkkejä esimerkkeineen leikkikentältä, jossa voit suorittaa kyselyitä suoraan VictoriaMetricsissä asentamatta sitä vain selaimeen.
Ja mikä se on? Tämä pyyntö ylhäältä on melko suosittu pyyntö. Luulen, että useiden yritysten kaikissa kojelaudoissa käytät samaa suodatinta kaikkeen. Yleensä niin. Mutta kun sinun on lisättävä uusi suodatin, sinun on päivitettävä jokainen paneeli tai ladattava kojelauta, avattava se JSONissa, suoritettava etsintäkorvaus, mikä myös vie aikaa. Mikset tallenna tätä arvoa muuttujaan ja käytä sitä uudelleen? Se näyttää mielestäni paljon yksinkertaisemmalta ja selkeämmältä.
Esimerkiksi, kun minun on päivitettävä Grafanan suodattimet kaikissa pyynnöissä, ja kojelauta voi olla valtava tai niitä voi olla jopa useita. Ja kuinka haluaisin ratkaista tämän ongelman Grafanassa?
Ratkaisen tämän ongelman seuraavasti: Teen commonFilterin ja määritän siihen tämän suodattimen ja käytän sitä sitten uudelleen kyselyissä. Mutta jos teet saman nyt, se ei toimi, koska Grafana ei salli sinun käyttää muuttujia kyselymuuttujien sisällä. Ja se on vähän outoa.
Ja niin tein vaihtoehdon, jonka avulla voit tehdä tämän. Ja jos olet kiinnostunut tai haluat tällaisen ominaisuuden, tue tai et pidä, jos et pidä tästä ideasta.
Lisätietoja PromQL laajennetusta. Tässä ei määritellä vain muuttuja, vaan suoraan koko funktio. Ja me kutsumme sitä ru (resurssien käyttö). Ja tämä toiminto hyväksyy ilmaisia resursseja, resurssirajan ja suodattimen. Syntaksi näyttää olevan yksinkertainen. Ja on erittäin helppoa käyttää tätä toimintoa ja laskea vapaan muistin prosenttiosuus. Eli kuinka paljon muistia meillä on, mikä raja ja miten suodatetaan. Näyttää paljon paremmalta, jos kirjoitat kaiken käyttämällä samoja suodattimia, koska se muuttuisi suureksi, suureksi kyselyksi.
Ja tässä on esimerkki tällaisesta suuresta, suuresta pyynnöstä. Se on Grafanan virallisesta NodeExporter-hallintapaneelista. Mutta en oikein ymmärrä mitä täällä tapahtuu. Sen tietysti ymmärrän, jos katsot tarkasti, mutta sulujen määrä voi välittömästi vähentää motivaatiota ymmärtää, mitä täällä tapahtuu. Ja miksi ei tehdä siitä yksinkertaisempaa ja selkeämpää?
Esimerkiksi näin korostamalla tärkeitä asioita tai osia muuttujissa. Ja sitten suorita peruslaskentasi. Tämä on enemmän kuin ohjelmointia, tämän haluaisin nähdä tulevaisuudessa Grafanassa.
Tässä on toinen esimerkki siitä, kuinka voimme tehdä siitä entistä helpompaa, jos meillä olisi jo tämä ru-funktio, ja se on jo olemassa suoraan VictoriaMetricsissä. Ja sitten välität vain välimuistissa olevan arvon, jonka olet ilmoittanut CTE:ssä.
Olen jo puhunut siitä, kuinka tärkeää on käyttää oikeaa ohjelmointikieltä. Ja todennäköisesti Grafanassa tapahtuu jotain erilaista jokaisessa yrityksessä. Ja luultavasti annat silti pääsyn Grafanaan kehittäjillesi, ja kehittäjät tekevät jotain omaa. Ja he kaikki tekevät sen eri tavalla. Mutta halusin sen jotenkin samanlaisena, eli pelkistettynä yhteiseen standardiin.
Oletetaan, että sinulla ei ole edes vain järjestelmäinsinöörejä, ehkä sinulla on jopa asiantuntijoita, devoppeja tai SRE:itä. Ehkä sinulla on asiantuntijoita, jotka tietävät mitä seuranta on, tietävät mitä Grafana on, eli he ovat työskennelleet tämän kanssa vuosia ja tietävät tarkalleen, miten se tehdään oikein. Ja he kirjoittivat sen jo 100 kertaa ja selittivät sen kaikille, mutta jostain syystä kukaan ei kuuntele.
Mitä jos he voisivat laittaa tämän tiedon suoraan Grafanaan, jotta muut käyttäjät voisivat käyttää toimintoja uudelleen? Ja jos olisi tarpeen laskea vapaan muistin prosenttiosuus, he yksinkertaisesti käyttävät funktiota. Mutta entä jos viejien luojat antaisivat tuotteensa ohella myös joukon toimintoja, kuinka heidän mittareitaan voidaan käyttää, koska he tietävät tarkalleen, mitä nämä mittarit ovat ja kuinka ne lasketaan oikein?
Tätä ei todellakaan ole olemassa. Tässä on mitä tein itse. Tämä on Grafanan kirjastotuki. Oletetaan, että NodeExporterin tehneet kaverit tekivät sen, mitä kuvailin. Ja tarjosi myös joukon ominaisuuksia.
Eli jotain tältä se näyttää. Yhdistät tämän kirjaston Grafanaan, siirryt muokkaamiseen, ja tässä on hyvin yksinkertaista työskennellä tämän mittarin kanssa JSONissa. Eli jotkin funktiot, niiden kuvaus ja mitä ne kehittyvät.
Mielestäni tästä voisi olla hyötyä, koska silloin kirjoittaisit Grafanalla juuri niin. Ja Grafana "kertoo" sinulle, että sellaisesta ja sellaisesta kirjastosta on olemassa sellainen ja sellainen toiminto - käytetään sitä. Minusta se olisi erittäin siistiä.
Hieman VictoriaMetricsistä. Teemme paljon mielenkiintoisia asioita. Lue artikkelimme pakkaamisesta, kilpailusta muiden aikasarjatietosovellusten kanssa, selostuksemme PromQL:n kanssa työskentelystä, koska tässä on paljon enemmän aloittelijoita, sekä vertikaalisesta skaalautumisesta ja vastakkainasettelusta Thanosin kanssa.
Kysymykset:
Aloitan kysymykseni yksinkertaisella elämäntarinalla. Kun aloitin Grafanan käytön, kirjoitin erittäin vakuuttavan 5 rivin kyselyn. Lopputulos on erittäin vakuuttava kaavio. Tämä kaavio on melkein otettu tuotantoon. Mutta lähemmin tarkasteltuna kävi ilmi, että tämä kaavio näyttää absoluuttista hölynpölyä, jolla ei ole mitään tekemistä todellisuuden kanssa, vaikka luvut kuuluvatkin alueelle, jonka odotimme näkevämme. Ja kysymykseni. Meillä on kirjastoja, meillä on toimintoja, mutta miten kirjoitamme testejä Grafanalle? Olet kirjoittanut monimutkaisen kyselyn, joka vaikuttaa liiketoimintapäätökseen - tilata oikea palvelinkontti vai olla tilaamatta. Ja kuten tiedämme, tämä kaavion piirtävä funktio on samanlainen kuin totuus. Kiitos.
Kiitos kysymyksestä. Tässä on kaksi osaa. Ensinnäkin saan kokemukseni perusteella vaikutelman, että useimmat käyttäjät eivät ymmärrä kaavioitaan katsoessaan, mitä he näyttävät heille. Jotenkin ihmiset ovat erittäin hyviä keksimään tekosyyn kaikille kaavioissa tapahtuville poikkeavuuksille, vaikka se olisi funktion sisällä oleva virhe. Ja toinen osa - minusta vaikuttaa siltä, että tällaisten toimintojen käyttäminen sopisi paljon paremmin ongelmasi ratkaisemiseen sen sijaan, että jokainen kehittäjäsi tekisi oman kapasiteetin suunnittelunsa ja tekisi virheitä jollain todennäköisyydellä.
Kuinka tarkistaa?
Kuinka tarkistaa? Luultavasti ei.
Kokeeksi Grafanassa.
Entä Grafana? Grafana kääntää tämän pyynnön suoraan tietolähteeseen.
Lisäämällä vähän parametreihin.
Ei, Grafanaan ei lisätä mitään. Saattaa olla GET-parametreja, kuten step. Sitä ei ole erikseen määritelty, mutta voit ohittaa sen, et voi ohittaa sitä, mutta se lisätään automaattisesti. Et kirjoita kokeita tänne. En usko, että sinun pitäisi luottaa Grafanaan totuuden lähteenä.
Kiitos raportista! Kiitos pakkauksesta! Muistit muuttujan kartoittamisesta graafiin, että Grafanassa ei voi käyttää muuttujaa muuttujassa. Ymmärrätkö mitä tarkoitan?
Kyllä.
Tämä oli aluksi päänsärkyä, kun halusin hälyttää Grafanassa. Ja siellä sinun on tehtävä hälytys jokaiselle isännälle erikseen. Tässä on tämä asia, jonka teit, toimiiko se Grafanan hälytyksissä?
Jos Grafana ei käytä muuttujia jollain muulla tavalla, niin kyllä, se toimii. Mutta neuvoni on, että älä käytä hälytyksiä Grafanassa ollenkaan, sinun on parempi käyttää hälytyshallintaa.
Kyllä, käytän sitä, mutta se vain näytti helpommalta asentaa Grafanaan, mutta kiitos vinkistä!
Lähde: will.com