Ik stel voor om het transcript van het rapport van Roman Khavronenko "ExtendedPromQL" te lezen
Kort over mij. Mijn naam is Roman. Ik werk voor CloudFlare en woon in Londen. Maar ik ben ook een VictoriaMetrics-onderhouder.
En ik ben de auteur voor Grafana en is een kleine proxy voor ClickHouse.
We beginnen met het eerste deel, genaamd "Translation Difficulties" en daarin zal ik het hebben over het feit dat elke taal of zelfs alleen een taal van communicatie erg belangrijk is. Want zo breng je je gedachten over op een ander persoon of systeem, zo formuleer je een verzoek. Mensen op internet maken ruzie over welke taal beter is - java of een andere. Voor mezelf besloot ik dat het nodig is om een taak te kiezen, omdat dit allemaal specifiek is.
Laten we bij het begin beginnen. Wat is PromQL? PromQL is Prometheus Query-taal. Dit is hoe we query's in Prometheus vormen om tijdreeksgegevens, tijdreeksen te krijgen.
Wat zijn tijdreeksgegevens? Letterlijk zijn dit drie parameters.
Is Dit:
- Waar kijken we naar.
- Als we ernaar kijken.
- En welke waarde laat het zien.
Als je naar deze grafiek kijkt (deze grafiek is van mijn telefoon, die de statistieken van mijn stappen laat zien), dan kun je deze vragen hier snel beantwoorden.
We kijken naar stappen. We zien de betekenis en we zien de tijd als we ernaar kijken. Dat wil zeggen, als je naar dit diagram kijkt, kun je gemakkelijk zeggen dat ik zondag ongeveer 15 stappen heb gelopen. Dit zijn tijdreeksgegevens.
Laten we ze nu "breken" (transformeren) in een ander gegevensmodel in de vorm van een tabel. Hier hebben we ook waar we naar kijken. Hier heb ik een beetje aanvullende gegevens toegevoegd, die we metagegevens zullen noemen, dat wil zeggen, ik was het niet die doorging, maar twee mensen, bijvoorbeeld Jay en Silent Bob. Dat is waar we naar kijken; wat het laat zien en wanneer het die waarde laat zien.
Laten we nu proberen al deze gegevens in de database op te slaan. Ik nam bijvoorbeeld de ClickHouse-syntaxis. En hier maken we een tabel met de naam "Stappen", d.w.z. waar we naar kijken. Er is een tijd dat we ernaar kijken; wat het laat zien en wat metadata waar we zullen opslaan wie het is: Jay en Silent Bob.
En om te proberen het allemaal te visualiseren, zullen we Grafana gebruiken, omdat het ten eerste mooi is.
Ook zullen we deze plug-in gebruiken. Hiervoor zijn twee redenen. De eerste is omdat ik het heb geschreven. En ik weet precies hoe moeilijk het is om tijdreeksgegevens uit ClickHouse te halen om ze in Grafana weer te geven.
We zullen weergeven in het grafiekpaneel. Dit is het meest populaire paneel in Grafana en toont waarde versus tijd, dus we hebben maar twee parameters nodig.
Laten we de eenvoudigste query schrijven - hoe stapstatistieken in Grafana te tonen, deze gegevens op te slaan in ClickHouse, in de tabel die we hebben gemaakt. En we schrijven zo'n simpele vraag. We kiezen uit trappen. We selecteren een waarde en selecteren de tijd van deze waarden, d.w.z. dezelfde drie parameters waar we het over hadden.
En als resultaat krijgen we deze grafiek. Wie weet waarom hij zo raar is?
Dat klopt, je moet sorteren op tijd.
En uiteindelijk krijgen we een beter, maar nog steeds vreemd schema. Wie weet waarom? Dat klopt, er zijn twee deelnemers, en we geven twee tijdreeksen weg in Grafana, want als we het datamodel opnieuw behandelen, dan is elke tijdreeks een unieke combinatie van een naam en alle labels sleutel-waarden.
Daarom moeten we een specifieke persoon kiezen. Wij kiezen Jay.
En teken opnieuw. Nu lijkt de grafiek op de waarheid. Nu is het een normaal schema en werkt alles goed.
En waarschijnlijk weet u hoe u ongeveer hetzelfde moet doen, maar dan in Prometheus via PromQL. Ongeveer zo. Een beetje makkelijker. En laten we het allemaal opsplitsen. We hebben stappen gezet. En filter op Jay. We specificeren hier niet dat we een waarde moeten krijgen en we kiezen geen tijd.
Laten we nu proberen de bewegingssnelheid van Jay of Silent Bob te berekenen. In ClickHouse zullen we runningDifference moeten doen, d.w.z. het verschil tussen puntenparen berekenen en ze delen door de tijd om de exacte snelheid te krijgen. Het verzoek zal er ongeveer zo uitzien.
En hij zal ongeveer deze waarden laten zien, d.w.z. ongeveer 1,8 stappen per seconde doet Silent Bob of Jay.
En in Prometheus weet je ook hoe het moet. Veel makkelijker dan voorheen.
En om het ook makkelijk te maken in Grafana, heb ik zo'n wrapper toegevoegd die erg lijkt op PromQL. Het heet Rate Macros, of hoe je het ook wilt noemen. In Grafana schrijf je gewoon "rate", maar ergens diep van binnen verandert het in zo'n groot verzoek. En je hoeft er niet eens naar te kijken, het ligt ergens, maar je bespaart er veel tijd mee, want het schrijven van zulke enorme SQL-query's is altijd duur. Je kunt gemakkelijk een fout maken en dan lange tijd niet begrijpen wat er gebeurt.
En dit is een vraag die niet eens op één dia paste, en ik moest hem zelfs in twee kolommen splitsen. Dit is ook een verzoek in ClickHouse, die hetzelfde tarief maakt, maar dan voor beide tijdreeksen: Silent Bob en Jay, zodat we twee tijdreeksen op het paneel hebben. En dit is naar mijn mening al erg moeilijk.
En volgens Prometheus zal het som (tarief) zijn. Voor ClickHouse heb ik een aparte macro gemaakt genaamd RateColumns die lijkt op een Prometheus-query.
We hebben gekeken en het lijkt erop dat PromQL allemaal zo cool is, maar het heeft natuurlijk beperkingen.
Is Dit:
- Beperkte KEUZE.
- Edge JOIN's.
- Geen steun HEBBEN.
En als je er lang mee hebt gewerkt, dan weet je dat het soms erg moeilijk is om iets in PromQL te doen, en in SQL kun je bijna alles doen, want al deze opties waar we het net over hadden, zouden in SQL kunnen worden gedaan . Maar zou het handig zijn om het te gebruiken? En dit doet me denken dat niet altijd de krachtigste taal de handigste kan zijn.
Daarom moet u soms een taal voor taken kiezen. Het is als een gevecht tussen Batman en Superman. Het is duidelijk dat Superman sterker is, maar Batman kon hem verslaan omdat hij praktischer is en precies wist wat hij deed.
En het volgende deel is PromQL uitbreiden.
Nogmaals over VictoriaMetrics. Wat is VictoriaMetrics? Dit is een tijdreeksdatabase, het is in OpenSource, we distribueren de enkele en clusterversies. Volgens onze benchmarks is het de snelste die nu op de markt is en qua compressie vergelijkbaar, d.w.z. levende mensen rapporteren compressie van ongeveer 0,4 bytes per punt, terwijl Prometheus 1,2-1,4 heeft.
We ondersteunen niet alleen Prometheus. We ondersteunen InfluxDB, Graphite, OpenTSDB.
U kunt in ons "schrijven", dat wil zeggen, u kunt oude gegevens overdragen.
En we werken ook perfect samen met Prometheus en Grafana, d.w.z. we ondersteunen de PromQL-engine. En in Grafana kunt u eenvoudig het Prometheus-eindpunt wijzigen in VictoriaMetrics en al uw dashboards zullen werken zoals ze deden.
Maar u kunt ook extra fiches van VictoriaMetrics gebruiken.
We gaan snel door de functies die we hebben toegevoegd.
Intervalparameter weglaten - u kunt parameterinterval in Grafana overslaan. Als u geen vreemde grafieken wilt krijgen bij het in-/uitzoomen in het paneel, is het raadzaam om de variabele te gebruiken $__interval. Dit is een interne Grafana-wijziging en kiest zelf het gegevensbereik. En VictoriaMetrics kan zelf begrijpen wat dit bereik zou moeten zijn. En u hoeft niet al uw verzoeken bij te werken. Het zal veel gemakkelijker zijn.
De tweede functie is intervalreferentie. U kunt deze spatiëring gebruiken in uw uitdrukkingen. Je kunt vermenigvuldigen, delen, overdragen, ernaar verwijzen.
Het volgende is de rollup-functiefamilie. De rollup-functie transformeert elk van uw tijdreeksen in drie afzonderlijke tijdreeksen. Dit zijn min, max en gem. Ik vind het erg handig, omdat het soms wat uitschieters (afwijkingen) en onnauwkeurigheden kan vertonen.
En als u alleen maar woedend of razend bent, kunt u waarschijnlijk enkele gevallen over het hoofd zien waarin de tijdreeks zich niet gedraagt zoals u van plan was. Het is veel gemakkelijker te zien met deze functie, laten we zeggen dat max erg afwijkt van het gemiddelde.
Het volgende is de standaardvariabele. Standaard - dit betekent welke waarde we in Grafana moeten tekenen als we op dit moment geen tijdreeks hebben. Wanneer gebeurt het? Stel dat u enkele foutstatistieken exporteert. En je hebt zo'n coole applicatie dat als je begint, je de komende drie uur of zelfs een dag geen fouten en zelfs geen fouten hebt. En je hebt dashboards die relaties tussen succes en fouten laten zien. En ze laten je niets zien omdat je geen foutstatistiek hebt. En standaard kun je alles specificeren.
Keep_last_Value - slaat de laatste waarde van de metriek op als deze ontbreekt. Als Prometheus na de volgende schraap het niet binnen 5 minuten heeft gevonden, dan zullen we hier de laatste waarde onthouden en zullen uw grafieken niet opnieuw breken.
Scrape_interval - laat zien hoe vaak Prometheus gegevens over uw statistiek verzamelt, met welke frequentie. Hier zie je bijvoorbeeld de pas.
Label vervangen is een populaire functie. Maar we denken dat het een beetje ingewikkeld is omdat er integer-argumenten voor nodig zijn. En je moet niet alleen de 5 argumenten onthouden, maar ook hun volgorde onthouden.
Waarom zou u ze daarom niet eenvoudiger maken? Dat wil zeggen, splits het op in kleine functies met een duidelijke syntaxis.
En nu het meest interessante. Waarom denken we dat het PromQL is verlengd? Omdat we Common Table Expressions ondersteunen. U kunt de QR-code volgen (), zie links met voorbeelden, van de playground, waar je queries direct in VictoriaMetrics kunt uitvoeren zonder het alleen in de browser te installeren.
En wat is het? Dit verzoek van bovenaf is een redelijk populair verzoek. Ik denk dat je in elk dashboard in veel bedrijven voor alles hetzelfde filter gebruikt. Meestal zo. Maar wanneer u een nieuw filter moet toevoegen, moet u elk paneel bijwerken, of het dashboard downloaden, openen in JSON, zoeken en vervangen, wat ook tijd kost. Waarom slaat u deze waarde niet op in een variabele en hergebruikt u deze? Het ziet er naar mijn mening veel eenvoudiger en overzichtelijker uit.
Als ik bijvoorbeeld filters in Grafana in alle verzoeken moet updaten, en het dashboard kan enorm zijn of er kunnen er zelfs meerdere zijn. En hoe zou ik dit probleem in Grafana willen oplossen?
Ik los dit probleem als volgt op: ik maak een commonFilter en definieer dit filter erin, en dan hergebruik ik het in queries. Maar als u nu hetzelfde doet, werkt het niet omdat u met Grafana geen variabelen binnen queryvariabelen kunt gebruiken. En het is een beetje raar.
En dus heb ik een optie gemaakt waarmee je dit kunt doen. En als je geïnteresseerd bent of zo'n functie wilt, ondersteun dan of vind het niet leuk als je dit idee niet leuk vindt.
Meer over PromQL uitgebreid. Hier definiëren we niet alleen een variabele, maar direct een hele functie. En we noemen het ru (brongebruik). En deze functie accepteert gratis resources, een resourcelimiet en een filter. De syntaxis lijkt eenvoudig. En het is heel gemakkelijk om deze functie te gebruiken en het percentage vrij geheugen te berekenen dat we hebben. Dat wil zeggen, hoeveel geheugen we hebben, welke limiet en hoe te filteren. Het ziet er veel handiger uit als je alles zou schrijven met dezelfde filters, omdat het een grote, grote zoekopdracht zou worden.
En hier is een voorbeeld van zo'n groot, groot verzoek. Het komt van het officiële NodeExporter-dashboard voor Grafana. Maar ik begrijp niet goed wat hier aan de hand is. Dat wil ik natuurlijk begrijpen als je goed kijkt, maar het aantal haakjes kan meteen de motivatie verminderen om te begrijpen wat hier gebeurt. En waarom zou u het niet eenvoudiger en duidelijker maken?
Bijvoorbeeld, zoals dit, het markeren van belangrijke dingen of delen in variabelen. En doe dan je basis wiskunde. Dit lijkt al meer op programmeren, dit is wat ik in de toekomst graag zou willen zien in Grafana.
Hier is een tweede voorbeeld van hoe we het nog gemakkelijker kunnen maken als we deze ru-functie al hadden en deze al direct in VictoriaMetrics bestaat. En dan geef je gewoon de cachewaarde door die je in de CTE hebt opgegeven.
Ik heb het er al over gehad hoe belangrijk het is om de juiste programmeertaal te gebruiken. En waarschijnlijk is er in elk bedrijf iets anders aan de hand in Grafana. En waarschijnlijk geef je nog steeds toegang tot Grafana aan je ontwikkelaars, en de ontwikkelaars doen iets van zichzelf. En ze doen het allemaal op een andere manier. Maar ik wilde het op de een of andere manier hetzelfde, dat wil zeggen teruggebracht tot een gemeenschappelijke standaard.
Laten we zeggen dat je niet eens alleen systeemingenieurs hebt, misschien zelfs experts, devops of SRE's. Misschien heb je experts die weten wat monitoring is, weten wat Grafana is, d.w.z. ze werken hier al jaren mee en weten precies hoe ze het goed moeten doen. En ze hebben het al 100 keer geschreven en aan iedereen uitgelegd, maar om de een of andere reden luistert niemand.
Wat als ze deze kennis direct in Grafana zouden kunnen stoppen zodat andere gebruikers de functies kunnen hergebruiken? En als het nodig zou zijn om het percentage vrij geheugen te berekenen, dan zouden ze de functie gewoon toepassen. Maar wat als de makers van exporteurs, samen met hun product, ook een reeks functies zouden bieden, hoe ze met hun statistieken moeten werken, omdat ze precies weten wat deze statistieken zijn en hoe ze correct moeten worden berekend?
Deze bestaat niet echt. Dit is wat ik zelf heb gedaan. Dit is de bibliotheekondersteuning in Grafana. Laten we zeggen dat de jongens die NodeExporter hebben gemaakt, deden wat ik beschreef. En bood ook een reeks functies.
Dat wil zeggen, het ziet er ongeveer zo uit. Je verbindt deze bibliotheek met Grafana, je gaat bewerken, en hier is het heel eenvoudig in JSON hoe je met deze metric werkt. Dat wil zeggen, een aantal functies, hun beschrijving en waarin ze zich ontvouwen.
Dit zou naar mijn mening handig kunnen zijn, want dan zou je zomaar in Grafana schrijven. En Grafana "vertelt" je dat er die en die functie is van die en die bibliotheek - laten we die gebruiken. Ik denk dat dat heel gaaf zou zijn.
Een beetje over VictoriaMetrics. We doen veel interessante dingen. Lees onze artikelen over compressie, over onze concurrentie met andere time series data-applicaties, onze uitleg over hoe je met PromQL werkt, want daar zijn nog veel meer beginners in, maar ook over verticale schaalbaarheid en over confrontatie met Thanos.
Vragen:
Ik zal mijn vraag beginnen met een eenvoudig levensverhaal. Toen ik Grafana voor het eerst begon te gebruiken, schreef ik een zeer overtuigende vraag van 5 regels. Het eindresultaat is een zeer overtuigende grafiek. Deze grafiek is bijna in productie gegaan. Maar bij nadere inspectie bleek dat deze grafiek absolute onzin laat zien die niets met de werkelijkheid te maken heeft, hoewel de cijfers binnen het bereik vallen dat we verwachtten te zien. En mijn vraag. We hebben bibliotheken, we hebben functies, maar hoe schrijven we tests voor Grafana? U hebt een complexe vraag geschreven die van invloed is op de zakelijke beslissing: een echte container met servers bestellen of niet bestellen. En zoals we weten, is deze functie die een grafiek tekent vergelijkbaar met de waarheid. Bedankt.
Bedankt voor de vraag. Er zijn hier twee delen. Ten eerste heb ik op basis van mijn ervaring de indruk dat de meeste gebruikers, als ze naar hun grafieken kijken, niet begrijpen wat ze laten zien. Op de een of andere manier zijn mensen erg goed in het bedenken van een excuus voor elke afwijking die in de hitlijsten voorkomt, zelfs als het een bug in een functie is. En het tweede deel - het lijkt mij dat het gebruik van dergelijke functies veel beter geschikt zou zijn om uw probleem op te lossen, in plaats van dat elk van uw ontwikkelaars hun eigen capaciteitsplanning doet en met enige waarschijnlijkheid fouten maakt.
Hoe controleren?
Hoe te controleren? Waarschijnlijk niet.
Als test in Grafana.
En hoe zit het met Grafana? Grafana vertaalt deze aanvraag direct naar de DataSource.
Door een beetje toe te voegen aan de parameters.
Nee, er wordt niets toegevoegd aan Grafana. Er kunnen GET-parameters zijn, zoals step. Het is niet expliciet gespecificeerd, maar u kunt het overschrijven, u kunt het niet overschrijven, maar het wordt automatisch toegevoegd. Je schrijft hier geen toetsen. Ik denk niet dat je hier op Grafana moet vertrouwen als bron van waarheid.
Bedankt voor het verslag! Bedankt voor de compressie! U herinnerde zich hoe u een variabele in een grafiek afbeeldt, dat u in Grafana geen variabele in een variabele kunt gebruiken. Snap je wat ik bedoel?
Да.
Dit was aanvankelijk hoofdpijn toen ik een waarschuwing wilde maken in Grafana. En daar moet je voor elke host afzonderlijk een melding doen. Dit is wat je deed, werkt het voor waarschuwingen in Grafana?
Als Grafana op een andere manier geen toegang heeft tot variabelen, dan zal het inderdaad werken. Maar mijn advies is om helemaal geen alerting in Grafana te gebruiken, je kunt beter alertmanager gebruiken.
Ja, ik gebruik het, maar het leek me gewoon makkelijker om het op te zetten in Grafana, maar bedankt voor de tip!
Bron: www.habr.com