Jeg foreslår at læse udskriften af rapporten af Roman Khavronenko "ExtendedPromQL"
Kort om mig. Mit navn er Roman. Jeg arbejder for CloudFlare og bor i London. Men jeg er også VictoriaMetrics-vedligeholder.
Og jeg er forfatteren for Grafana og er en lille proxy for ClickHouse.
Vi starter med den første del, som kaldes "Oversættelsesproblemer", og i den vil jeg tale om, at ethvert sprog eller endda blot et kommunikationssprog er meget vigtigt. For det er sådan, du formidler dine tanker til en anden person eller system, hvordan du formulerer en anmodning. Folk på internettet skændes om, hvilket sprog der er bedre - java eller et andet. For mig selv besluttede jeg, at det er nødvendigt at vælge en opgave, fordi alt dette er specifikt.
Lad os starte helt fra begyndelsen. Hvad er PromQL? PromQL er Prometheus Query Language. Det er sådan, vi danner forespørgsler i Prometheus for at få tidsseriedata, tidsserier.
Hvad er tidsseriedata? Bogstaveligt talt er disse tre parametre.
De er:
- Hvad kigger vi på.
- Når vi ser på det.
- Og hvilken værdi viser det.
Hvis du ser på dette diagram (dette diagram er fra min telefon, som viser statistikken over mine skridt), så kan du her hurtigt svare på disse spørgsmål.
Vi kigger på trin. Vi ser meningen, og vi ser tiden, når vi ser på den. Det vil sige, når man ser på dette diagram, kan man sagtens sige, at jeg søndag gik omkring 15 skridt. Dette er tidsseriedata.
Lad os nu "bryde" (transformere) dem til en anden datamodel i form af en tabel. Her har vi også det, vi kigger på. Her tilføjede jeg lidt ekstra data, som vi vil kalde meta-data, det vil sige, det var ikke mig, der gik igennem, men to personer, for eksempel Jay og Silent Bob. Det er det, vi kigger på; hvad den viser, og hvornår den viser den værdi.
Lad os nu prøve at gemme alle disse data i databasen. For eksempel tog jeg ClickHouse-syntaksen. Og her laver vi en tabel kaldet "Steps", altså det vi kigger på. Der er et tidspunkt her, hvor vi ser på det; hvad det viser og nogle metadata, hvor vi vil gemme, hvem det er: Jay og Silent Bob.
Og for at prøve at visualisere det hele, vil vi bruge Grafana, fordi det for det første er smukt.
Vi vil også bruge dette plugin. Det er der to grunde til. Det første er, fordi jeg skrev det. Og jeg ved præcis, hvor svært det er at trække tidsseriedata ud fra ClickHouse for at vise det i Grafana.
Vi vil vise i grafpanelet. Dette er det mest populære panel i Grafana og viser værdi i forhold til tid, så vi behøver kun to parametre.
Lad os skrive den enkleste forespørgsel - hvordan man viser trinstatistikker i Grafana, gemmer disse data i ClickHouse, i den tabel, vi oprettede. Og vi skriver sådan en simpel forespørgsel. Vi vælger fra trin. Vi vælger en værdi og vælger tidspunktet for disse værdier, det vil sige de samme tre parametre, som vi talte om.
Og som et resultat får vi denne graf. Hvem ved hvorfor han er så mærkelig?
Det er rigtigt, du skal sortere efter tid.
Og i sidste ende får vi et bedre, men stadig mærkeligt skema. Hvem ved hvorfor? Det er rigtigt, der er to deltagere, og vi udlodder to tidsserier i Grafana, for hvis vi beskæftiger os med datamodellen igen, så er hver tidsserie en unik kombination af et navn og alle etiketter nøgleværdier.
Derfor skal vi vælge en bestemt person. Vi vælger Jay.
Og tegne igen. Nu ligner grafen sandheden. Nu er det en normal tidsplan, og alt fungerer godt.
Og sandsynligvis ved du, hvordan du gør omtrent det samme, men i Prometheus via PromQL. Sådan nogenlunde. Lidt nemmere. Og lad os bryde det hele ned. Vi tog skridt. Og filtrer efter Jay. Vi specificerer ikke her, at vi skal have en værdi, og vi vælger ikke et tidspunkt.
Lad os nu prøve at beregne bevægelseshastigheden for Jay eller Silent Bob. I ClickHouse skal vi lave runningDifference, dvs. beregne forskellen mellem par af point og dividere dem med tid for at få den nøjagtige hastighed. Anmodningen vil se nogenlunde sådan ud.
Og han vil vise cirka disse værdier, dvs. cirka 1,8 skridt i sekundet gør Silent Bob eller Jay.
Og i Prometheus ved du også, hvordan du gør det. Meget nemmere end før.
Og for at gøre det også nemt at gøre i Grafana, tilføjede jeg sådan en indpakning, der ligner PromQL meget. Det hedder Rate Macros, eller hvad man nu vil kalde det. I Grafana skriver man bare "rate", men et eller andet sted inderst inde forvandles det til en så stor anmodning. Og du behøver ikke engang at se på det, det er der et sted, men du sparer en masse tid, fordi det altid er dyrt at skrive så store SQL-forespørgsler. Man kan nemt lave en fejl og så ikke forstå, hvad der sker i lang tid.
Og dette er en forespørgsel, der ikke engang passede på et dias, og jeg var endda nødt til at opdele det i to kolonner. Dette er også en anmodning i ClickHouse, som laver samme rate, men for begge tidsserier: Silent Bob og Jay, så vi har to tidsserier på panelet. Og dette er allerede meget svært, efter min mening.
Og ifølge Prometheus vil det være sum (rate). Til ClickHouse lavede jeg en separat makro kaldet RateColumns, som ligner en Prometheus-forespørgsel.
Vi kiggede, og det ser ud til, at PromQL alt sammen er så cool, men det har selvfølgelig begrænsninger.
De er:
- Begrænset UDVALG.
- Edge JOINs.
- IKKE HAR støtte.
Og hvis du har arbejdet med det i lang tid, så ved du, at nogle gange er det meget svært at lave noget i PromQL, og i SQL kan du næsten alt, fordi alle disse muligheder, som vi lige har talt om, kunne gøres i SQL . Men ville det være praktisk at bruge det? Og det får mig til at tro, at det ikke altid er det mest kraftfulde sprog, der kan være det mest bekvemme.
Derfor skal du nogle gange vælge et sprog til opgaver. Det er som en kamp mellem Batman og Superman. Det er klart, at Superman er stærkere, men Batman var i stand til at besejre ham, fordi han er mere praktisk og vidste præcis, hvad han lavede.
Og den næste del er Extending PromQL.
Endnu en gang om VictoriaMetrics. Hvad er VictoriaMetrics? Dette er en tidsseriedatabase, den er i OpenSource, vi distribuerer dens enkelt- og klyngeversioner. Ifølge vores benchmarks er det den hurtigste, der er på markedet nu, og den er ens med hensyn til komprimering, dvs. levende mennesker rapporterer komprimering på omkring 0,4 bytes pr. punkt, når Prometheus har 1,2-1,4.
Vi støtter ikke kun Prometheus. Vi understøtter InfluxDB, Graphite, OpenTSDB.
Du kan "skrive" i os, det vil sige, du kan overføre gamle data.
Og vi arbejder også perfekt med Prometheus og Grafana, det vil sige vi understøtter PromQL-motoren. Og i Grafana kan du blot ændre Prometheus-endepunktet til VictoriaMetrics, og alle dine dashboards vil fungere, som de gjorde.
Men du kan også bruge yderligere chips leveret af VictoriaMetrics.
Vi vil hurtigt gennemgå de funktioner, vi har tilføjet.
Udelad intervalparam - du kan springe parameterinterval over i Grafana. Når du ikke ønsker at få mærkelige grafer ved zoom ind/ud i panelet, anbefales det at bruge variablen $__interval. Dette er en intern Grafana-ændring, og den vælger selv dataområdet. Og VictoriaMetrics kan selv forstå, hvad denne serie skal være. Og du behøver ikke at opdatere alle dine anmodninger. Det bliver meget nemmere.
Den anden funktion er intervalreference. Du kan bruge denne afstand i dine udtryk. Du kan gange, dividere, overføre, henvise til det.
Dernæst er rollup-funktionsfamilien. Rollup-funktionen omdanner enhver af dine tidsserier til tre separate tidsserier. Disse er min, max og gns. Jeg finder det meget praktisk, fordi det nogle gange kan vise nogle afvigelser (anomalier) og unøjagtigheder.
Og hvis du bare er vred eller rate, så kan du sikkert gå glip af nogle tilfælde, hvor tidsserien ikke opfører sig, som du havde tænkt dig. Det er meget nemmere at se med denne funktion, lad os sige, at maks. er meget lavere end gns.
Næste er standardvariablen. Standard - dette betyder, hvilken værdi vi skal tegne i Grafana, hvis vi ikke har en tidsserie i øjeblikket. Hvornår sker det? Lad os sige, at du eksporterer nogle fejlmålinger. Og du har så cool en applikation, at når du starter, har du ingen fejl og endda ingen fejl i de næste tre timer eller endda en dag. Og du har dashboards, der viser sammenhænge fra succes til fejl. Og de vil ikke vise dig noget, fordi du ikke har en fejlmåling. Og som standard kan du angive hvad som helst.
Keep_last_Value - gemmer den sidste værdi af metrikken, hvis den mangler. Hvis Prometheus efter den næste skrabe ikke fandt den inden for 5 minutter, så vil vi her huske dens sidste værdi, og dine diagrammer vil ikke gå i stykker igen.
Scrape_interval - viser, hvor ofte Prometheus indsamler data på din metric, med hvilken frekvens. Her kan du f.eks. se passet.
Etiketudskiftning er en populær funktion. Men vi synes, det er lidt kompliceret, fordi det kræver heltalsargumenter. Og du skal ikke kun huske de 5 argumenter, men også huske deres rækkefølge.
Derfor, hvorfor ikke gøre dem enklere? Det vil sige, opdele det i små funktioner med klar syntaks.
Og nu det mest interessante. Hvorfor tror vi, det er udvidet PromQL? Fordi vi understøtter almindelige tabeludtryk. Du kan følge QR-koden (), se links med eksempler, fra legepladsen, hvor du kan køre forespørgsler direkte i VictoriaMetrics uden blot at installere det i browseren.
Og hvad er det? Denne anmodning fra oven er en ret populær anmodning. Jeg tror, at man i ethvert dashboard i mange virksomheder bruger det samme filter til alt. Normalt sådan. Men når du skal tilføje et nyt filter, skal du opdatere hvert panel, eller downloade dashboardet, åbne det i JSON, foretage en find replace, hvilket også tager tid. Hvorfor ikke gemme denne værdi i en variabel og genbruge den? Det ser efter min mening meget enklere og klarere ud.
For eksempel når jeg skal opdatere filtre i Grafana i alle forespørgsler, og dashboardet kan være enormt, eller der kan endda være flere af dem. Og hvordan kunne jeg tænke mig at løse dette problem i Grafana?
Jeg løser dette problem sådan her: Jeg laver et commonFilter og definerer dette filter i det, og så genbruger jeg det i forespørgsler. Men hvis du gør det samme nu, vil det ikke fungere, fordi Grafana ikke tillader dig at bruge variabler i forespørgselsvariabler. Og det er lidt underligt.
Og så lavede jeg en mulighed, der giver dig mulighed for at gøre dette. Og hvis du er interesseret eller ønsker en sådan funktion, så støtte eller ikke lide, hvis du ikke kan lide denne idé.
Mere om PromQL udvidet. Her definerer vi ikke kun en variabel, men direkte en hel funktion. Og vi kalder det ru (ressourceforbrug). Og denne funktion accepterer gratis ressourcer, en ressourcegrænse og et filter. Syntaksen ser ud til at være enkel. Og det er meget nemt at bruge denne funktion og beregne den procentdel af ledig hukommelse, vi har. Det vil sige, hvor meget hukommelse vi har, hvilken grænse og hvordan man filtrerer. Det ser meget bedre ud, hvis du skulle skrive det hele ved at genbruge de samme filtre, fordi det ville blive til en stor, stor forespørgsel.
Og her er et eksempel på sådan en stor, stor anmodning. Det er fra det officielle NodeExporter-dashboard til Grafana. Men jeg forstår ikke rigtig, hvad der foregår her. Det er selvfølgelig, jeg forstår, hvis man ser godt efter, men antallet af parenteser kan umiddelbart mindske motivationen til at forstå, hvad der sker her. Og hvorfor ikke gøre det mere enkelt og overskueligt?
For eksempel, som dette, fremhæve væsentlige ting eller dele i variabler. Og lav derefter din grundlæggende matematik. Dette er allerede mere som programmering, det er det, jeg gerne vil se i fremtiden i Grafana.
Her er et andet eksempel på, hvordan vi kan gøre det endnu nemmere, hvis vi allerede havde denne ru-funktion, og den allerede eksisterer direkte i VictoriaMetrics. Og så sender du bare den cachelagrede værdi, som du deklarerede i CTE.
Jeg har allerede talt om, hvor vigtigt det er at bruge det rigtige programmeringssprog. Og sandsynligvis sker der noget andet i Grafana i alle virksomheder. Og sandsynligvis giver du stadig adgang til Grafana til dine udviklere, og udviklerne gør noget af deres eget. Og de gør det alle sammen på en anden måde. Men jeg ville have det på en eller anden måde det samme, altså reduceret til en fælles standard.
Lad os sige, at du ikke engang kun har systemingeniører, måske har du endda eksperter, devops eller SRE'er. Måske har du eksperter, der ved, hvad overvågning er, ved, hvad Grafana er, dvs. de har arbejdet med dette i årevis, og de ved præcis, hvordan man gør det rigtigt. Og de har allerede skrevet det 100 gange og forklaret det til alle, men af en eller anden grund er der ingen, der lytter.
Hvad hvis de kunne sætte denne viden direkte ind i Grafana, så andre brugere kunne genbruge funktionerne? Og hvis det ville være nødvendigt at beregne procentdelen af ledig hukommelse, så ville de blot anvende funktionen. Men hvad nu hvis skaberne af eksportører, sammen med deres produkt, også leverede et sæt funktioner, hvordan man arbejder med deres metrikker, fordi de ved præcis, hvad disse metrikker er, og hvordan man beregner dem korrekt?
Denne findes ikke rigtig. Her er hvad jeg selv gjorde. Dette er biblioteksstøtten i Grafana. Lad os sige, at de fyre, der lavede NodeExporter, gjorde det, jeg beskrev. Og leverede også et sæt funktioner.
Det vil sige, at det ser sådan ud. Du forbinder dette bibliotek med Grafana, du går ind i redigering, og her er det meget enkelt i JSON, hvordan man arbejder med denne metrik. Det vil sige nogle sæt funktioner, deres beskrivelse og hvad de udfolder sig til.
Det kunne efter min mening være nyttigt, for så ville man bare sådan skrive i Grafana. Og Grafana "fortæller" dig, at der er sådan og sådan en funktion fra sådan og sådan et bibliotek - lad os bruge det. Jeg synes, det ville være meget fedt.
Lidt om VictoriaMetrics. Vi laver mange interessante ting. Læs vores artikler om komprimering, om vores konkurrence med andre tidsseriedataapplikationer, vores forklaring på hvordan man arbejder med PromQL, fordi der er mange flere begyndere i dette, samt om vertikal skalerbarhed og om konfrontation med Thanos.
Spørgsmål:
Jeg starter mit spørgsmål med en simpel livshistorie. Da jeg først begyndte at bruge Grafana, skrev jeg en meget overbevisende forespørgsel på 5 linjer. Slutresultatet er et meget overbevisende diagram. Denne graf er næsten gået i produktion. Men ved nærmere eftersyn viste det sig, at dette diagram viser absolut nonsens, der ikke har noget med virkeligheden at gøre, selvom tallene falder inden for det interval, som vi forventede at se. Og mit spørgsmål. Vi har biblioteker, vi har funktioner, men hvordan skriver vi test til Grafana? Du har skrevet en kompleks forespørgsel, der påvirker forretningsbeslutningen - at bestille en rigtig beholder med servere eller ikke at bestille. Og som vi ved, ligner denne funktion, der tegner en graf, sandheden. Tak skal du have.
Tak for spørgsmålet. Der er to dele her. For det første får jeg det indtryk, baseret på min erfaring, at de fleste brugere, når de ser på deres diagrammer, ikke forstår, hvad de viser dem. På en eller anden måde er folk meget gode til at komme med en undskyldning for enhver anomali, der sker på diagrammet, selvom det er en fejl inde i en funktion. Og den anden del - det forekommer mig, at brug af sådanne funktioner ville være meget bedre egnet til at løse dit problem, i stedet for at hver af dine udviklere laver deres egen kapacitetsplanlægning og laver fejl med en vis sandsynlighed.
Hvordan man tjekker
Hvordan tjekker man? Sikkert ikke.
Som en test i Grafana.
Og hvad med Grafana? Grafana oversætter denne anmodning direkte til DataSource.
Ved at tilføje lidt til parametrene.
Nej, intet er tilføjet til Grafana. Der kan være GET-parametre, såsom step. Det er ikke eksplicit angivet, men du kan tilsidesætte det, du kan ikke tilsidesætte det, men det tilføjes automatisk. Du skriver ikke prøver her. Jeg tror ikke du skal stole på Grafana her som en kilde til sandhed.
Tak for rapporten! Tak for kompressionen! Du huskede om at kortlægge en variabel i en graf, at i Grafana kan du ikke bruge en variabel i en variabel. Forstår du hvad jeg mener?
Ja.
Dette var oprindeligt en hovedpine, da jeg ville lave en alarm i Grafana. Og der skal du lave alarm for hver vært separat. Her er denne ting, du gjorde, virker det for alarmer i Grafana?
Hvis Grafana ikke får adgang til variabler på en anden måde, så ja, det vil virke. Men mit råd er slet ikke at bruge alarmering i Grafana, du må hellere bruge alertmanager.
Ja, jeg bruger det, men det virkede bare nemmere at sætte op i Grafana, men tak for tippet!
Kilde: www.habr.com