Jeg foreslår å lese utskriften av rapporten av Roman Khavronenko "ExtendedPromQL"
Kort om meg. Mitt navn er Roman. Jeg jobber for CloudFlare og bor i London. Men jeg er også en VictoriaMetrics vedlikeholder.
Og jeg er forfatteren for Grafana og er en liten proxy for ClickHouse.
Vi starter med den første delen, som kalles "Oversettelsesvansker", og i den vil jeg snakke om det faktum at ethvert språk eller bare et kommunikasjonsspråk er veldig viktig. For det er slik du formidler tankene dine til en annen person eller system, hvordan du formulerer en forespørsel. Folk på Internett krangler om hvilket språk som er bedre - java eller noe annet. For meg selv bestemte jeg meg for at det er nødvendig å velge en oppgave, fordi alt dette er spesifikt.
La oss starte helt fra begynnelsen. Hva er PromQL? PromQL er Prometheus Query Language. Dette er hvordan vi danner spørringer i Prometheus for å få tidsseriedata, tidsserier.
Hva er tidsseriedata? Bokstavelig talt er dette tre parametere.
De er:
- Hva ser vi på.
- Når vi ser på det.
- Og hvilken verdi viser det.
Hvis du ser på dette diagrammet (dette diagrammet er fra telefonen min, som viser statistikken over trinnene mine), så her kan du raskt svare på disse spørsmålene.
Vi ser på trinn. Vi ser meningen og vi ser tiden når vi ser på den. Det vil si at når man ser på dette diagrammet, kan man enkelt si at jeg på søndag gikk rundt 15 000 skritt. Dette er tidsseriedata.
La oss nå "bryte" (transformere) dem til en annen datamodell i form av en tabell. Her har vi også det vi ser på. Her la jeg til litt ekstra data, som vi vil kalle meta-data, det vil si at det ikke var jeg som gikk gjennom, men to personer, for eksempel Jay og Silent Bob. Det er det vi ser på; hva den viser og når den viser den verdien.
La oss nå prøve å lagre alle disse dataene i databasen. For eksempel tok jeg ClickHouse-syntaksen. Og her lager vi en tabell som heter "Steps", det vil si det vi ser på. Det er en tid her når vi ser på det; hva det viser og noen metadata der vi vil lagre hvem det er: Jay og Silent Bob.
Og for å prøve å visualisere alt, vil vi bruke Grafana, fordi det for det første er vakkert.
Vi vil også bruke denne plugin. Det er to grunner til dette. Den første er fordi jeg skrev den. Og jeg vet nøyaktig hvor vanskelig det er å trekke ut tidsseriedata fra ClickHouse for å vise det i Grafana.
Vi vil vise i grafpanelet. Dette er det mest populære panelet i Grafana og viser verdi kontra tid, så vi trenger bare to parametere.
La oss skrive den enkleste spørringen - hvordan du viser trinnstatistikk i Grafana, lagrer disse dataene i ClickHouse, i tabellen vi opprettet. Og vi skriver et så enkelt spørsmål. Vi velger fra trinn. Vi velger en verdi og velger tiden for disse verdiene, det vil si de samme tre parameterne som vi snakket om.
Og som et resultat får vi denne grafen. Hvem vet hvorfor han er så rar?
Det stemmer, du må sortere etter tid.
Og til slutt får vi en bedre, men likevel merkelig timeplan. Hvem vet hvorfor? Det stemmer, det er to deltakere, og vi gir bort to tidsserier i Grafana, for hvis vi tar for oss datamodellen igjen, så er hver tidsserie en unik kombinasjon av et navn og alle etiketter nøkkelverdier.
Derfor må vi velge en bestemt person. Vi velger Jay.
Og tegne igjen. Nå ser grafen ut som sannheten. Nå er det en normal timeplan og alt fungerer bra.
Og sannsynligvis vet du hvordan du gjør omtrent det samme, men i Prometheus via PromQL. Omtrent slik. Litt lettere. Og la oss bryte ned det hele. Vi tok skritt. Og filtrer etter Jay. Vi spesifiserer ikke her at vi trenger å få en verdi og vi velger ikke tidspunkt.
La oss nå prøve å beregne bevegelseshastigheten til Jay eller Silent Bob. I ClickHouse må vi gjøre runningDifference, dvs. beregne forskjellen mellom poengpar og dele dem på tid for å få den nøyaktige hastigheten. Forespørselen vil se omtrent slik ut.
Og han vil vise omtrent disse verdiene, dvs. omtrent 1,8 skritt per sekund gjør Silent Bob eller Jay.
Og i Prometheus vet du hvordan du gjør det også. Mye enklere enn før.
Og for å gjøre det også enkelt å gjøre i Grafana, la jeg til en slik innpakning som ligner veldig på PromQL. Det heter Rate Macros, eller hva du vil kalle det. I Grafana skriver du bare "rate", men et sted dypt nede forvandles det til en så stor forespørsel. Og du trenger ikke engang å se på det, det er der et sted, men du sparer mye tid, fordi det alltid er dyrt å skrive slike store SQL-spørringer. Du kan lett gjøre en feil og deretter ikke forstå hva som skjer på lenge.
Og dette er et søk som ikke en gang passet på ett lysbilde, og jeg måtte til og med dele det i to kolonner. Dette er også en forespørsel i ClickHouse, som gir samme rate, men for begge tidsseriene: Silent Bob og Jay, slik at vi har to tidsserier på panelet. Og dette er allerede veldig vanskelig, etter min mening.
Og ifølge Prometheus vil det være sum (rate). For ClickHouse laget jeg en egen makro kalt RateColumns som ser ut som en Prometheus-spørring.
Vi så og det ser ut til at PromQL er så kult, men det har selvfølgelig begrensninger.
De er:
- Begrenset UTVALG.
- Edge JOINs.
- Ingen støtte.
Og hvis du har jobbet lenge med det, så vet du at noen ganger er det veldig vanskelig å gjøre noe i PromQL, og i SQL kan du gjøre nesten alt, fordi alle disse alternativene vi nettopp snakket om kunne gjøres i SQL . Men ville det være praktisk å bruke det? Og dette får meg til å tenke at ikke alltid det kraftigste språket kan være det mest praktiske.
Derfor må du noen ganger velge et språk for oppgaver. Det er som en kamp mellom Batman og Superman. Det er tydelig at Superman er sterkere, men Batman klarte å beseire ham fordi han er mer praktisk og visste nøyaktig hva han gjorde.
Og neste del er Extending PromQL.
Nok en gang om VictoriaMetrics. Hva er VictoriaMetrics? Dette er en tidsseriedatabase, den er i OpenSource, vi distribuerer enkelt- og klyngeversjonene. I følge våre benchmarks er det den raskeste som er på markedet nå, og den er lik når det gjelder komprimering, dvs. levende mennesker rapporterer komprimering på ca. 0,4 byte per punkt, når Prometheus har 1,2-1,4.
Vi støtter ikke bare Prometheus. Vi støtter InfluxDB, Graphite, OpenTSDB.
Du kan "skrive" i oss, det vil si at du kan overføre gamle data.
Og vi fungerer også perfekt med Prometheus og Grafana, det vil si at vi støtter PromQL-motoren. Og i Grafana kan du ganske enkelt endre Prometheus-endepunktet til VictoriaMetrics og alle dashbordene dine vil fungere som de gjorde.
Men du kan også bruke ekstra sjetonger levert av VictoriaMetrics.
Vi går raskt gjennom funksjonene vi har lagt til.
Utelat intervallparam - du kan hoppe over parameterintervall i Grafana. Når du ikke ønsker å få merkelige grafer når du zoomer inn/ut i panelet, anbefales det å bruke variabelen $__interval. Dette er en intern Grafana-endring og den velger selv dataområdet. Og VictoriaMetrics kan selv forstå hva denne serien skal være. Og du trenger ikke å oppdatere alle forespørslene dine. Det blir mye lettere.
Den andre funksjonen er intervallreferanse. Du kan bruke denne avstanden i uttrykkene dine. Du kan multiplisere, dividere, overføre, referere til det.
Neste er rollup-funksjonsfamilien. Rollup-funksjonen forvandler hvilken som helst av tidsseriene dine til tre separate tidsserier. Disse er min, maks og avg. Jeg synes det er veldig praktisk, fordi noen ganger kan det vise noen avvik (avvik) og unøyaktigheter.
Og hvis du bare er rasende eller vurderer, kan du sannsynligvis gå glipp av noen tilfeller der tidsserien ikke oppfører seg slik du hadde tenkt. Det er mye lettere å se med denne funksjonen, la oss si at maks er veldig mye lavere enn avg.
Neste er standardvariabelen. Standard - dette betyr hvilken verdi vi trenger å tegne i Grafana hvis vi ikke har en tidsserie for øyeblikket. Når skjer det? La oss si at du eksporterer noen feilberegninger. Og du har en så kul applikasjon at når du starter, har du ingen feil og til og med ingen feil de neste tre timene eller til og med en dag. Og du har dashbord som viser sammenhenger fra suksess til feil. Og de vil ikke vise deg noe, fordi du ikke har en feilmåling. Og som standard kan du spesifisere hva som helst.
Keep_last_Value - lagrer den siste verdien av metrikken hvis den mangler. Hvis Prometheus etter neste skrap ikke fant den innen 5 minutter, vil vi her huske den siste verdien og diagrammene dine vil ikke gå i stykker igjen.
Scrape_interval – viser hvor ofte Prometheus samler inn data om metrikken din, med hvilken frekvens. Her kan du for eksempel se passet.
Etikettbytte er en populær funksjon. Men vi synes det er litt komplisert fordi det krever heltallsargumenter. Og du må ikke bare huske de 5 argumentene, men også huske rekkefølgen deres.
Derfor, hvorfor ikke gjøre dem enklere? Det vil si, bryte det ned i små funksjoner med klar syntaks.
Og nå det mest interessante. Hvorfor tror vi det er utvidet PromQL? Fordi vi støtter vanlige tabelluttrykk. Du kan følge QR-koden (), se lenker med eksempler, fra lekeplassen, der du kan kjøre spørringer direkte i VictoriaMetrics uten å installere det bare i nettleseren.
Og hva er det? Denne forespørselen ovenfra er en ganske populær forespørsel. Jeg tror at man i ethvert dashbord i mange selskaper bruker samme filter for alt. Vanligvis så. Men når du trenger å legge til et nytt filter, må du oppdatere hvert panel, eller laste ned dashbordet, åpne det i JSON, gjøre en finn erstatning, noe som også tar tid. Hvorfor ikke lagre denne verdien i en variabel og bruke den på nytt? Det ser etter min mening mye enklere og klarere ut.
For eksempel når jeg trenger å oppdatere filtre i Grafana i alle forespørsler, og dashbordet kan være stort eller det kan til og med være flere av dem. Og hvordan vil jeg løse dette problemet i Grafana?
Jeg løser dette problemet slik: Jeg lager et commonFilter og definerer dette filteret i det, og så gjenbruker jeg det i spørringer. Men hvis du gjør det samme nå, vil det ikke fungere fordi Grafana ikke tillater deg å bruke variabler i spørringsvariabler. Og det er litt rart.
Og så laget jeg et alternativ som lar deg gjøre dette. Og hvis du er interessert eller ønsker en slik funksjon, så støtt eller mislik hvis du ikke liker denne ideen.
Mer om PromQL utvidet. Her definerer vi ikke bare en variabel, men direkte en hel funksjon. Og vi kaller det ru (ressursbruk). Og denne funksjonen godtar gratis ressurser, en ressursgrense og et filter. Syntaksen ser ut til å være enkel. Og det er veldig enkelt å bruke denne funksjonen og beregne prosentandelen ledig minne vi har. Det vil si hvor mye minne vi har, hvilken grense og hvordan filtrere. Det ser mye bedre ut hvis du skriver det hele ved å bruke de samme filtrene på nytt, fordi det ville blitt et stort, stort søk.
Og her er et eksempel på en så stor, stor forespørsel. Det er fra det offisielle NodeExporter-dashbordet for Grafana. Men jeg skjønner ikke helt hva som skjer her. Det er selvfølgelig, jeg forstår hvis du ser nøye etter, men antall parentes kan umiddelbart redusere motivasjonen for å forstå hva som skjer her. Og hvorfor ikke gjøre det enklere og tydeligere?
For eksempel, som dette, fremheving av viktige ting eller deler i variabler. Og så gjør din grunnleggende regnestykke. Dette er allerede mer som programmering, dette er det jeg gjerne vil se i fremtiden i Grafana.
Her er et annet eksempel på hvordan vi kan gjøre det enda enklere hvis vi allerede hadde denne ru-funksjonen, og den eksisterer allerede direkte i VictoriaMetrics. Og så sender du bare den bufrede verdien som du deklarerte i CTE.
Jeg har allerede snakket om hvor viktig det er å bruke riktig programmeringsspråk. Og, sannsynligvis, skjer noe annerledes i Grafana i hvert selskap. Og sannsynligvis gir du fortsatt tilgang til Grafana til utviklerne dine, og utviklerne gjør noe av seg selv. Og alle gjør det på en annen måte. Men jeg ønsket det på en eller annen måte det samme, altså redusert til en felles standard.
La oss si at du ikke engang bare har systemingeniører, kanskje du til og med har eksperter, devops eller SRE-er. Kanskje har du eksperter som vet hva overvåking er, vet hva Grafana er, dvs. de har jobbet med dette i årevis og de vet nøyaktig hvordan de skal gjøre det riktig. Og de har allerede skrevet det 100 ganger og forklart det til alle, men av en eller annen grunn er det ingen som lytter.
Hva om de kunne legge denne kunnskapen direkte inn i Grafana slik at andre brukere kunne gjenbruke funksjonene? Og hvis det ville være nødvendig å beregne prosentandelen ledig minne, ville de ganske enkelt bruke funksjonen. Men hva om skaperne av eksportører, sammen med produktet deres, også ga et sett med funksjoner, hvordan de kan jobbe med deres beregninger, fordi de vet nøyaktig hva disse beregningene er og hvordan de skal beregne dem riktig?
Denne eksisterer egentlig ikke. Her er hva jeg gjorde selv. Dette er bibliotekstøtten i Grafana. La oss si at gutta som laget NodeExporter gjorde det jeg beskrev. Og ga også et sett med funksjoner.
Det vil si at det ser omtrent slik ut. Du kobler dette biblioteket til Grafana, du går inn i redigering, og her er det veldig enkelt i JSON hvordan du jobber med denne metrikken. Det vil si et sett med funksjoner, deres beskrivelse og hva de utfolder seg til.
Etter min mening kan dette være nyttig, for da ville du skrevet i Grafana akkurat sånn. Og Grafana "forteller" deg at det finnes en slik og en funksjon fra et slikt og et bibliotek - la oss bruke den. Jeg tror det ville vært veldig kult.
Litt om VictoriaMetrics. Vi gjør mye interessant. Les artiklene våre om komprimering, om vår konkurranse med andre tidsseriedataapplikasjoner, vår forklaring på hvordan du jobber med PromQL, fordi det er mange flere nybegynnere i dette, samt om vertikal skalerbarhet og om konfrontasjon med Thanos.
spørsmål:
Jeg starter spørsmålet mitt med en enkel livshistorie. Da jeg først begynte å bruke Grafana, skrev jeg en svært overbevisende 5-linjers spørring. Sluttresultatet er et veldig overbevisende diagram. Denne grafen har nesten gått i produksjon. Men ved nærmere ettersyn viste det seg at dette diagrammet viser absolutt tull som ikke har noe med virkeligheten å gjøre, selv om tallene faller innenfor området som vi forventet å se. Og spørsmålet mitt. Vi har biblioteker, vi har funksjoner, men hvordan skriver vi tester for Grafana? Du har skrevet en kompleks spørring som påvirker forretningsbeslutningen - å bestille en ekte beholder med servere eller ikke bestille. Og som vi vet, ligner denne funksjonen som tegner en graf på sannheten. Takk skal du ha.
Takk for spørsmålet. Det er to deler her. For det første får jeg inntrykk, basert på min erfaring, at de fleste brukere, når de ser på diagrammene sine, ikke forstår hva de viser dem. På en eller annen måte er folk veldig flinke til å komme med en unnskyldning for enhver anomali som skjer på listene, selv om det er en feil inne i en funksjon. Og den andre delen - det virker for meg at bruk av slike funksjoner ville være mye bedre egnet til å løse problemet ditt, i stedet for at hver av utviklerne dine gjør sin egen kapasitetsplanlegging og gjør feil med en viss sannsynlighet.
Hvordan sjekke?
Hvordan sjekke? Sannsynligvis ikke.
Som en test i Grafana.
Og hva med Grafana? Grafana oversetter denne forespørselen direkte til datakilden.
Ved å legge litt til parametrene.
Nei, ingenting er lagt til Grafana. Det kan være GET-parametere, for eksempel trinn. Det er ikke eksplisitt spesifisert, men du kan overstyre det, du kan ikke overstyre det, men det legges til automatisk. Du skriver ikke prøver her. Jeg tror ikke du skal stole på Grafana her som en kilde til sannhet.
Takk for rapporten! Takk for komprimeringen! Du husket om kartlegging av en variabel i en graf, at i Grafana kan du ikke bruke en variabel i en variabel. Forstår du hva jeg mener?
Ja.
Dette var i utgangspunktet en hodepine da jeg ønsket å varsle i Grafana. Og der må du gjøre varsling for hver vert separat. Her er denne tingen du gjorde, fungerer det for varsler i Grafana?
Hvis Grafana ikke får tilgang til variabler på en annen måte, ja, det vil fungere. Men mitt råd er å ikke bruke varsling i Grafana i det hele tatt, du bør heller bruke alertmanager.
Ja, jeg bruker det, men det virket bare enklere å sette opp i Grafana, men takk for tipset!
Kilde: www.habr.com