Us suggereixo que llegiu la transcripció de l'informe de Roman Khavronenko "ExtendedPromQL"
Breument sobre mi. Em dic Roman. Treballo a CloudFlare i visc a Londres. Però també sóc un mantenedor de VictoriaMetrics.
I jo en sóc l'autor per Grafana i és un petit proxy per a ClickHouse.
Començarem per la primera part, que es diu “Dificultats de la traducció” i en ella parlaré del fet que qualsevol llengua o fins i tot només una llengua de comunicació és molt important. Perquè així és com transmets els teus pensaments a una altra persona o sistema, com formules una sol·licitud. La gent a Internet discuteix sobre quin idioma és millor: java o algun altre. Per mi mateix, vaig decidir que he de triar segons la tasca, perquè tot això és específic.
Comencem des del principi. Què és PromQL? PromQL és el llenguatge de consulta de Prometheus. Així és com formem consultes a Prometheus per obtenir dades de sèries temporals.
Què són les dades de sèries temporals? Literalment, aquests són tres paràmetres.
Són els següents:
- Què estem mirant?
- Quan ens ho mirem.
- I quin valor mostra?
Si mireu aquest gràfic (aquest gràfic és del meu telèfon que mostra les meves estadístiques de passos), pot respondre ràpidament aquestes preguntes.
Mirem els passos. Veiem el significat i veiem el temps quan el mirem. És a dir, mirant aquest diagrama, es pot dir fàcilment que diumenge vaig fer uns 15 passos. Aquestes són dades de sèries temporals.
Ara anem a "dividir" (convertir) en un altre model de dades en forma de taula. Aquí també tenim el que estem mirant. Aquí he afegit una mica de dades addicionals, que anomenarem metadades, és a dir, no vaig ser jo qui ho vaig passar, sinó dues persones, per exemple, Jay i Silent Bob. Això és el que estem mirant; què mostra i quan mostra aquest valor.
Ara intentem emmagatzemar totes aquestes dades en una base de dades. Per exemple, vaig agafar la sintaxi ClickHouse. I aquí creem una taula anomenada "Pasos", és a dir, el que estem mirant. Hi ha un moment en què ens ho mirem; què mostra i algunes metadades on guardarem qui és: Jay i Silent Bob.
I per intentar visualitzar tot això, farem servir Grafana perquè, en primer lloc, és bonic.
També utilitzarem aquest connector. Hi ha dues raons per això. El primer és perquè el vaig escriure jo. I sé exactament com de difícil és extreure dades de sèries temporals de ClickHouse per mostrar-les a Grafana.
Ho mostrarem al panell de gràfics. Aquest és el panell més popular de Grafana, que mostra la dependència d'un valor en el temps, de manera que només necessitem dos paràmetres.
Escrivim la consulta més senzilla: com mostrar les estadístiques de passos a Grafana, emmagatzemant aquestes dades a ClickHouse, a la taula que hem creat. I escrivim aquesta senzilla petició. Triem entre passos. Seleccionem un valor i seleccionem el temps d'aquests valors, és a dir, els mateixos tres paràmetres dels quals hem parlat.
I com a resultat, obtindrem un gràfic com aquest. Qui sap per què és tan estrany?
És cert, hem d'ordenar per temps.
I al final tindrem un horari millor, però encara estrany. Qui sap per què? Així és, hi ha dos participants, i nosaltres a Grafana regalem dues sèries temporals, perquè si torneu a mirar el model de dades, aleshores cada sèrie temporal és una combinació única de nom i totes les etiquetes de valor-clau.
Per tant, hem de triar una persona concreta. Triem en Jay.
I tornem a dibuixar. Ara el gràfic sembla la veritat. Ara aquest és un horari normal i tot funciona bé.
I probablement sabeu com fer aproximadament el mateix, però a Prometheus mitjançant PromQL. Alguna cosa com això. Una mica més senzill. I desglossem-ho tot. Hem fet passos. I filtra per Jay. No estem especificant aquí que hem d'obtenir un valor i no estem escollint un moment.
Ara intentem calcular la velocitat de moviment de Jay o Silent Bob. A ClickHouse haurem de fer runningDifference, és a dir, calcular la diferència entre parells de punts i dividir-los per temps per obtenir la velocitat exacta. La sol·licitud tindrà un aspecte semblant a això.
I mostrarà aproximadament aquests valors, és a dir, Silent Bob o Jay triguen aproximadament 1,8 passos per segon.
I a Prometeu també saps com fer-ho. Molt més fàcil que abans.
I perquè també sigui fàcil de fer a Grafana, he afegit aquest embolcall, que s'assembla molt a PromQL. Es diu Rate Macros o com vulgueu anomenar-lo. A Grafana simplement escriviu "taxa", però en el fons es transforma en aquesta gran petició. I ni tan sols cal mirar-ho, és allà en algun lloc, però estalvieu molt de temps, perquè escriure consultes SQL tan grans sempre és car. Podeu equivocar-vos fàcilment i després no entendre què està passant durant molt de temps.
I aquesta és una petició que ni tan sols encaixava en una diapositiva i fins i tot vaig haver de dividir-la en dues columnes. Aquesta també és una sol·licitud a ClickHouse, que fa la mateixa tarifa, però per a les dues sèries temporals: Silent Bob i Jay, de manera que tinguem dues sèries temporals al panell. I això ja és molt difícil, al meu entendre.
I segons Prometeu serà suma (taxa). Per a ClickHouse, vaig fer una macro independent anomenada RateColumns, que sembla una consulta a Prometheus.
Ens ho vam mirar i sembla que PromQL és genial, però té, per descomptat, limitacions.
Són els següents:
- SELECCIÓ LIMITADA.
- Borderline JOINs.
- NO TENIR suport.
I si heu treballat amb ell durant molt de temps, aleshores sabeu que de vegades és molt difícil fer alguna cosa a PromQL, però en SQL es pot fer gairebé tot, perquè totes aquestes opcions de les que acabem de parlar es podrien fer en SQL. . Però seria convenient utilitzar-lo? I això em fa pensar que el llenguatge més potent potser no sempre és el més convenient.
Per tant, de vegades cal triar un idioma per a la tasca. És com Batman lluitant contra Superman. Està clar que Superman és més fort, però Batman va ser capaç de derrotar-lo perquè és més pràctic i sabia exactament el que estava fent.
I la següent part és l'extensió de PromQL.
Un cop més sobre VictoriaMetrics. Què és VictoriaMetrics? Aquesta és una base de dades de sèries temporals, està en OpenSource, distribuïm les seves versions single i cluster. Segons els nostres punts de referència, és més ràpid que qualsevol cosa que hi ha al mercat ara i la compressió és similar, és a dir, la gent real informa d'una compressió d'uns 0,4 bytes per punt, mentre que la de Prometheus és d'1,2-1,4.
Donem més suport a Prometeu. Admetem InfluxDB, Graphite, OpenTSDB.
Ens pots "escriure", és a dir, pots transferir dades antigues.
I també treballem perfectament amb Prometheus i Grafana, és a dir, donem suport al motor PromQL. I a Grafana, simplement podeu canviar el punt final de Prometheus a VictoriaMetrics i tots els vostres taulers funcionaran com ho feien.
Però també podeu utilitzar funcions addicionals que proporciona VictoriaMetrics.
Repassarem ràpidament les funcions que hem afegit.
Omet el paràmetre d'interval: podeu ometre els paràmetres d'interval a Grafana. Quan no voleu obtenir gràfics estranys quan feu zoom al panell, es recomana utilitzar la variable $__interval. Aquest és un canvi intern de Grafana i selecciona el mateix rang de dades. I la mateixa VictoriaMetrics pot entendre què hauria de ser aquest rang. I no cal que actualitzeu totes les vostres sol·licituds. Serà molt més fàcil.
La segona funció és la referència a intervals. Podeu utilitzar aquest interval a les vostres expressions. Podeu multiplicar, dividir, transferir, referir-vos-hi.
El següent és la família de funcions acumulatives. La funció Rollup transforma qualsevol de les vostres sèries temporals en tres sèries temporals separades. Aquests són el mínim, el màxim i la mitjana. Ho trobo molt convenient perquè de vegades pot mostrar alguns punts atípics i imprecisions.
I si només esteu enfurismats o valorats, probablement us perdreu alguns casos en què la sèrie temporal no es comporta com esperàveu. Amb aquesta funció és molt més fàcil de veure, diguem que max és molt de la mitjana.
La següent és la variable predeterminada. Per defecte: això significa quin valor hem de dibuixar a Grafana si no tenim una sèrie temporal en aquest moment. Quan passa això? Suposem que exporteu algunes mètriques d'error. I tens una aplicació tan fantàstica que quan inicies, no tens errors i fins i tot cap error durant les properes tres hores o fins i tot un dia. I teniu taulers que mostren la relació entre l'èxit i l'error. I no us mostraran res perquè no teniu una mètrica d'error. I per defecte podeu especificar qualsevol cosa.
Keep_last_Value: desa l'últim valor de la mètrica si falta. Si Prometheus no el troba en un termini de 5 minuts després del següent raspat, aquí recordarem el seu darrer valor i els vostres gràfics no es tornaran a trencar.
Scrape_interval: mostra amb quina freqüència Prometheus recopila dades de la vostra mètrica i amb quina freqüència. Aquí podeu veure una passada, per exemple.
La substitució d'etiquetes és una característica popular. Però creiem que és una mica complicat perquè requereix arguments sencers. I no només cal recordar 5 arguments, sinó també la seva seqüència.
Per tant, per què no fer-los més senzills? És a dir, dividir-lo en petites funcions amb una sintaxi comprensible.
I ara la part divertida. Per què creiem que això és PromQL estès? Perquè admetem Common Table Expressions. Podeu seguir el codi QR (), vegeu enllaços amb exemples, des del pati, on podeu executar consultes directament a VictoriaMetrics sense instal·lar-lo simplement al navegador.
I això què és? Aquesta sol·licitud anterior és una sol·licitud força popular. Crec que en qualsevol tauler de moltes empreses s'utilitza el mateix filtre per a tot. Normalment així. Però quan necessiteu afegir algun filtre nou, heu d'actualitzar cada panell, o descarregar el tauler, obrir-lo en JSON, trobar substitució, la qual cosa també requereix temps. Per què no emmagatzemar aquest valor en una variable i reutilitzar-lo? Això sembla, al meu entendre, molt més senzill i clar.
Per exemple, quan necessito actualitzar filtres a Grafana en totes les sol·licituds, i el tauler pot ser enorme o fins i tot n'hi pot haver diversos. I com m'agradaria resoldre aquest problema a Grafana?
Resol aquest problema d'aquesta manera: faig un filtre comú i hi defineixo aquest filtre, i després el reutilizo en les consultes. Però si feu el mateix ara, no funcionarà perquè Grafana no us permet utilitzar variables dins de variables de consulta. I és una mica estrany.
I així vaig fer una opció que et permet fer-ho. I si esteu interessats o voleu aquesta funció, doneu-hi suport o no us agrada si no us agrada aquesta idea.
Més informació sobre PromQL ampliat. Aquí definim no només una variable, sinó una funció sencera. I l'anomenem ru (ús de recursos). I aquesta funció accepta recursos gratuïts, limitació de recursos i filtre. La sintaxi sembla ser senzilla. I és molt fàcil utilitzar aquesta funció i calcular el percentatge de memòria lliure que tenim. És a dir, quanta memòria tenim, quina és la limitació i com filtrar. Sembla molt més convenient si ho escriviu tot, reutilitzant els mateixos filtres, perquè es convertiria en una consulta gran i gran.
I aquí hi ha un exemple d'una petició tan gran i gran. Prové del tauler de control oficial de NodeExporter per a Grafana. Però amb prou feines entenc què passa aquí. És a dir, per descomptat, ho entenc si mireu bé, però el nombre de parèntesis pot reduir immediatament la motivació per entendre què està passant aquí. I per què no fer-ho més senzill i clar?
Per exemple, com aquest, separant coses o parts significatives en variables. I després fes les teves matemàtiques bàsiques. Això ja s'assembla més a la programació, això és el que m'agradaria veure en un futur a Grafana.
Aquí teniu un segon exemple de com podríem fer-ho encara més fàcil si ja tinguéssim aquesta funció ru, i ja existeix directament a VictoriaMetrics. I després simplement passeu el valor a la memòria cau que heu declarat al CTE.
Ja he parlat de l'important que és utilitzar el llenguatge de programació adequat. I, probablement, cada empresa de Grafana té alguna cosa diferent. I probablement també doneu accés a Grafana als vostres desenvolupadors, i els desenvolupadors fan el seu. I tots ho fan d'una manera diferent. Però volia que d'alguna manera fos el mateix, és a dir, reduir-lo a un estàndard comú.
Suposem que ni tan sols teniu enginyers de sistemes, potser fins i tot teniu experts, devops o SRE. Potser teniu experts que saben què és el monitoratge, que saben què és Grafana, és a dir, fa anys que hi treballen i saben com fer-ho bé. I això ja ho han escrit 100 vegades i ho han explicat a tothom, però per alguna raó ningú no escolta.
Què passaria si poguessin posar aquest coneixement directament a Grafana perquè altres usuaris poguessin reutilitzar les funcions? I si necessitessin calcular el percentatge de memòria lliure, simplement aplicarien la funció. I si els creadors d'exportadors, juntament amb el seu producte, també proporcionessin un conjunt de funcions sobre com treballar amb les seves mètriques, perquè saben exactament què són aquestes mètriques i com calcular-les correctament?
Això realment no existeix. Això és el que vaig fer jo mateix. Aquest és el suport de la biblioteca a Grafana. Diguem que els nois que van fer NodeExporter van fer el que vaig parlar. I també van oferir un conjunt de funcions.
És a dir, sembla una cosa així. Connecteu aquesta biblioteca a Grafana, entreu en l'edició i està escrit de manera molt senzilla en JSON com treballar amb aquesta mètrica. És a dir, un conjunt de funcions, la seva descripció i en què es converteixen.
Crec que això podria ser útil, perquè llavors a Grafana escriuries així. I Grafana us "diu" que hi ha tal i tal funció de tal o tal biblioteca: utilitzem-la. Crec que seria molt xulo.
Una mica sobre VictoriaMetrics. Fem moltes coses interessants. Llegiu els nostres articles sobre compressió, sobre les nostres competicions amb altres aplicacions de dades de sèries temporals, la nostra explicació de com treballar amb PromQL, perquè encara hi ha molts principiants en això, així com sobre l'escalabilitat vertical i sobre la confrontació amb Thanos.
Preguntes:
Començaré la meva pregunta amb una història de vida senzilla. Quan vaig començar a utilitzar Grafana, vaig escriure una consulta molt convincent de 5 línies. El resultat final és un gràfic molt convincent. Aquesta programació gairebé ha entrat en producció. Però després d'una inspecció més propera, va resultar que aquest gràfic mostra una absurditat absoluta que no té res a veure amb la realitat, tot i que les xifres es troben dins del rang que esperàvem veure. I la meva pregunta. Tenim biblioteques, tenim funcions, però com escrivim proves per a Grafana? Heu escrit una sol·licitud complexa de la qual depèn una decisió empresarial: demanar un contenidor real de servidors o no demanar. I com sabem, aquesta funció que dibuixa el gràfic és semblant a la veritat. Gràcies.
Gràcies per la pregunta. Hi ha dues parts. En primer lloc, tinc la impressió, segons la meva experiència, que la majoria d'usuaris, quan miren els seus gràfics, no entenen què els estan mostrant. Per alguna raó, la gent és molt bona per trobar una excusa per a qualsevol anomalia que es produeixi als gràfics, fins i tot si es tracta d'un error dins d'una funció. I la segona part: em sembla que utilitzar aquestes funcions seria un enfocament molt millor per resoldre el vostre problema, en lloc que cadascun dels vostres desenvolupadors faci la seva pròpia planificació de la capacitat i comet errors amb certa probabilitat.
Com comprovar?
Com comprovar? Probablement no.
Com a prova a Grafana.
Què hi té a veure Grafana? Grafana tradueix aquesta sol·licitud directament a DataSource.
Afegeix una mica als paràmetres.
No, no s'afegeix res a Grafana. Pot haver-hi paràmetres GET, com, per exemple, el pas. No s'especifica explícitament, però podeu anul·lar-lo, o potser no l'anul·leu, però s'afegeix automàticament. Aquí no escriureu proves. No crec que hauríem de confiar aquí en Grafana com a font de veritat.
Gràcies pel reportatge! Gràcies per la compressió! Heu esmentat l'assignació d'una variable en un gràfic, que a Grafana no podeu utilitzar una variable dins d'una variable. Saps el que vull dir?
Sí
Això va ser inicialment un mal de cap quan volia crear una alerta a Grafana. I allà heu de fer una alerta per a cada host per separat. Això que has fet, funciona per a les alertes a Grafana?
Si Grafana no accedeix a les variables de manera diferent, llavors sí, funcionarà. Però el meu consell és que no utilitzeu les alertes a Grafana, és millor utilitzar alertmanager.
Sí, el faig servir, però semblava més fàcil de configurar a Grafana, però gràcies pel consell!
Font: www.habr.com