Ti suggerisco di leggere la trascrizione del rapporto di Roman Khavronenko “ExtendedPromQL”
Brevemente su di me. Il mio nome è Romano. Lavoro presso CloudFlare e vivo a Londra. Ma sono anche un manutentore di VictoriaMetrics.
E io sono l'autore per Grafana e è un piccolo proxy per ClickHouse.
Inizieremo con la prima parte, che si chiama “Difficoltà di traduzione” e in essa parlerò del fatto che qualsiasi lingua o anche solo una lingua di comunicazione è molto importante. Perché è così che trasmetti i tuoi pensieri a un'altra persona o sistema, come formuli una richiesta. Le persone su Internet discutono su quale lingua sia migliore: Java o qualche altra. Per quanto mi riguarda, ho deciso che dovevo scegliere in base al compito, perché tutto questo è specifico.
Cominciamo dall'inizio. Cos'è PromQL? PromQL è il linguaggio di query di Prometheus. Questo è il modo in cui formiamo le query in Prometheus per ottenere dati di serie temporali.
Che cosa sono i dati delle serie temporali? Letteralmente, questi sono tre parametri.
È Questo:
- Cosa stiamo guardando?
- Quando lo guardiamo.
- E che valore mostra?
Se guardi questo grafico (questo grafico proviene dal mio telefono e mostra le statistiche dei miei passi), può rispondere rapidamente a queste domande.
Osserviamo i passaggi. Vediamo il significato e vediamo il tempo quando lo guardiamo. Cioè, guardando questo diagramma, puoi facilmente dire che domenica ho fatto circa 15 passi. Si tratta di dati di serie temporali.
Ora "dividiamoli" (convertiamoli) in un altro modello di dati sotto forma di tabella. Anche qui abbiamo quello che stiamo guardando. Qui ho aggiunto alcuni dati aggiuntivi, che chiameremo metadati, ad es. non sono stato io a passare attraverso questo, ma due persone, ad esempio Jay e Silent Bob. Questo è ciò che stiamo guardando; cosa mostra e quando mostra quel valore.
Ora proviamo a memorizzare tutti questi dati in un database. Ad esempio, ho preso la sintassi ClickHouse. E qui creiamo una tabella chiamata “Steps”, ovvero ciò che stiamo guardando. C'è un momento in cui lo guardiamo; cosa mostra e alcuni metadati in cui memorizzeremo chi è: Jay e Silent Bob.
E per provare a visualizzare tutto questo utilizzeremo Grafana perché, prima di tutto, è bella.
Utilizzeremo anche questo plugin. Ci sono due ragioni per questo. Il primo è perché l'ho scritto io. E so esattamente quanto sia difficile estrarre i dati delle serie temporali da ClickHouse per mostrarli in Grafana.
Lo visualizzeremo nel pannello grafico. Questo è il pannello più popolare in Grafana, che mostra la dipendenza di un valore dal tempo, quindi abbiamo solo bisogno di due parametri.
Scriviamo la query più semplice: come mostrare le statistiche dei passaggi in Grafana, memorizzando questi dati in ClickHouse, nella tabella che abbiamo creato. E scriviamo questa semplice richiesta. Scegliamo dai passaggi. Selezioniamo un valore e selezioniamo il tempo di questi valori, ovvero gli stessi tre parametri di cui abbiamo parlato.
E di conseguenza, otterremo un grafico come questo. Chissà perché è così strano?
Esatto, dobbiamo ordinare in base al tempo.
E alla fine otterremo un programma migliore, ma comunque strano. Chissà perché? Esatto, ci sono due partecipanti e noi di Grafana distribuiamo due serie temporali, perché se guardi di nuovo il modello di dati, ogni serie temporale è una combinazione univoca di nome e tutte le etichette dei valori-chiave.
Pertanto, dobbiamo scegliere una persona specifica. Scegliamo Jay.
E disegniamo di nuovo. Ora il grafico sembra vero. Ora questo è un programma normale e tutto funziona bene.
E probabilmente sai come fare più o meno la stessa cosa, ma in Prometheus tramite PromQL. Qualcosa come questo. Un po' più semplice. E analizziamo tutto. Abbiamo fatto dei passi. E filtra per Jay. Non stiamo specificando qui che dobbiamo ottenere un valore e non stiamo scegliendo un momento.
Ora proviamo a calcolare la velocità di movimento di Jay o Silent Bob. In ClickHouse dovremo fare runningDifference, cioè calcolare la differenza tra coppie di punti e dividerli per il tempo per ottenere la velocità esatta. La richiesta sarà simile a questa.
E mostrerà approssimativamente questi valori, cioè Silent Bob o Jay impiega circa 1,8 passi al secondo.
E in Prometeo sai fare anche questo. Molto più facile di prima.
E per renderlo più semplice anche in Grafana, ho aggiunto questo wrapper, che sembra molto simile a PromQL. Si chiama Rate Macro o come vuoi chiamarlo. In Grafana scrivi semplicemente “tariffa”, ma da qualche parte nel profondo si trasforma in questa grande richiesta. E non devi nemmeno guardarlo, è lì da qualche parte, ma risparmi molto tempo, perché scrivere query SQL così grandi è sempre costoso. Puoi facilmente commettere un errore e poi non capire cosa sta succedendo per molto tempo.
E questa è una richiesta che non entrava nemmeno in una diapositiva e ho dovuto addirittura dividerla in due colonne. Questa è anche una richiesta in ClickHouse, che applica la stessa tariffa, ma per entrambe le serie temporali: Silent Bob e Jay, in modo da avere due serie temporali sul pannello. E questo è già molto difficile, secondo me.
E secondo Prometeo sarà somma (tasso). Per ClickHouse, ho creato una macro separata chiamata RateColumns, che assomiglia a una query in Prometheus.
L'abbiamo guardato e sembra che PromQL sia fantastico, ma ovviamente ha dei limiti.
È Questo:
- SELEZIONE limitata.
- JOIN borderline.
- Nessun supporto.
E se ci lavori da molto tempo, allora sai che a volte è molto difficile fare qualcosa in PromQL, ma in SQL puoi fare quasi tutto, perché tutte queste opzioni di cui abbiamo appena parlato potrebbero essere fatte in SQL . Ma sarebbe conveniente utilizzarlo? E questo mi fa pensare che non sempre il linguaggio più potente sia quello più conveniente.
Pertanto, a volte è necessario scegliere una lingua per l'attività. È come se Batman combattesse Superman. È chiaro che Superman è più forte, ma Batman è riuscito a sconfiggerlo perché è più pratico e sapeva esattamente cosa stava facendo.
E la parte successiva è l'estensione di PromQL.
Ancora una volta su VictoriaMetrics. Cos'è VictoriaMetrics? Questo è un database di serie temporali, è in OpenSource, distribuiamo le sue versioni singole e cluster. Secondo i nostri benchmark, è più veloce di qualsiasi cosa sia attualmente sul mercato e la compressione è simile, ovvero le persone reali riportano una compressione di circa 0,4 byte per punto, mentre quella di Prometheus è 1,2-1,4.
Supportiamo molto più che solo Prometeo. Supportiamo InfluxDB, Graphite, OpenTSDB.
Puoi “scriverci”, cioè puoi trasferire i vecchi dati.
E lavoriamo perfettamente anche con Prometheus e Grafana, ovvero supportiamo il motore PromQL. E in Grafana puoi semplicemente cambiare l'endpoint Prometheus in VictoriaMetrics e tutti i tuoi dashboard funzioneranno come prima.
Ma puoi anche utilizzare funzionalità aggiuntive fornite da VictoriaMetrics.
Esamineremo rapidamente le funzionalità che abbiamo aggiunto.
Ometti parametro intervallo: puoi omettere i parametri di intervallo in Grafana. Quando non si desidera ottenere grafici strani quando si esegue lo zoom avanti/indietro nel pannello, si consiglia di utilizzare la variabile $__interval. Questa è una modifica interna di Grafana e seleziona l'intervallo di dati stesso. E la stessa VictoriaMetrics può capire quale dovrebbe essere questo intervallo. E non è necessario aggiornare tutte le tue richieste. Sarà molto più facile.
La seconda funzione è il riferimento agli intervalli. Puoi utilizzare questo intervallo nelle tue espressioni. Puoi moltiplicare, dividere, trasferire, fare riferimento ad esso.
La prossima è la famiglia di funzioni di rollup. La funzione Rollup trasforma qualsiasi serie temporale in tre serie temporali separate. Questi sono minimo, massimo e medio. Lo trovo molto comodo perché a volte può mostrare alcuni valori anomali e imprecisioni.
E se ti stai solo arrabbiando o valutando, probabilmente ti perderai alcuni casi in cui le serie temporali non si comportano come previsto. Con questa funzione è molto più semplice vedere, diciamo che il max è molto diverso dall'avg.
La prossima è la variabile predefinita. Predefinito: significa quale valore dobbiamo disegnare in Grafana se al momento non disponiamo di una serie temporale. Quando succede questo? Supponiamo che tu stia esportando alcune metriche di errore. E hai un'applicazione così interessante che quando la avvii non ci sono errori e nemmeno errori per le prossime tre ore o addirittura un giorno. E hai dashboard che mostrano la relazione dal successo all'errore. E non ti mostreranno nulla perché non hai una metrica di errore. E per impostazione predefinita puoi specificare qualsiasi cosa.
Keep_last_Value: salva l'ultimo valore della metrica se manca. Se Prometheus non lo trova entro 5 minuti dal successivo scraping, qui ricorderemo il suo ultimo valore e i tuoi grafici non si romperanno più.
Scrape_interval: mostra la frequenza con cui Prometheus raccoglie dati sulla tua metrica e con quale frequenza. Qui puoi vedere un passaggio, per esempio.
La sostituzione dell'etichetta è una funzionalità popolare. Ma pensiamo che sia un po' complicato perché richiede interi argomenti. E devi ricordare non solo 5 argomenti, ma anche ricordare la loro sequenza.
Allora perché non renderli più semplici? Cioè, suddividilo in piccole funzioni con una sintassi comprensibile.
E ora la parte divertente. Perché pensiamo che questo sia PromQL esteso? Perché supportiamo le espressioni di tabella comuni. Puoi seguire il codice QR (), vedere i collegamenti con esempi, dal parco giochi, dove è possibile eseguire query direttamente in VictoriaMetrics senza installarlo semplicemente nel browser.
E questo che cos'è? Questa richiesta sopra è una richiesta abbastanza popolare. Penso che in qualsiasi dashboard di molte aziende si utilizzi lo stesso filtro per tutto. Di solito è così. Ma quando è necessario aggiungere qualche nuovo filtro, è necessario aggiornare ciascun pannello o scaricare la dashboard, aprirla in JSON e trovare la sostituzione, il che richiede tempo. Perché non memorizzare questo valore in una variabile e riutilizzarlo? Questo mi sembra molto più semplice e chiaro.
Ad esempio, quando devo aggiornare i filtri in Grafana in tutte le richieste, la dashboard può essere enorme o addirittura essercene diverse. E come vorrei risolvere questo problema a Grafana?
Risolvo questo problema in questo modo: creo un commonFilter e definisco questo filtro al suo interno, quindi lo riutilizzo nelle query. Ma se fai lo stesso ora, non funzionerà perché Grafana non ti consente di utilizzare variabili all'interno delle variabili di query. Ed è un po' strano.
E quindi ho creato un'opzione che ti consente di farlo. E se sei interessato o desideri una funzionalità del genere, supportala o non piacerla se non ti piace questa idea.
Ulteriori informazioni su PromQL esteso. Qui definiamo non solo una variabile, ma un'intera funzione. E lo chiamiamo ru (utilizzo delle risorse). E questa funzione accetta risorse gratuite, limitazione delle risorse e filtro. La sintassi sembra essere semplice. Ed è molto semplice utilizzare questa funzione e calcolare la percentuale di memoria libera che abbiamo. Cioè quanta memoria abbiamo, qual è il limite e come filtrare. Sembra molto più conveniente se scrivessi tutto, riutilizzando gli stessi filtri, perché si trasformerebbe in una query molto, molto grande.
Ed ecco un esempio di una richiesta così grande. Proviene dalla dashboard ufficiale di NodeExporter per Grafana. Ma capisco a malapena cosa sta succedendo qui. Questo, ovviamente, lo capisco se guardi da vicino, ma il numero di parentesi può ridurre immediatamente la motivazione a capire cosa sta succedendo qui. E perché non renderlo più semplice e chiaro?
Ad esempio, in questo modo, separando cose o parti significative in variabili. E poi fai i tuoi calcoli di base. Questo è già più come programmare, questo è quello che mi piacerebbe vedere in futuro in Grafana.
Ecco un secondo esempio di come potremmo renderlo ancora più semplice se avessimo già questa funzione ru ed esiste già direttamente in VictoriaMetrics. E quindi passi semplicemente il valore memorizzato nella cache che hai dichiarato nel CTE.
Ho già parlato di quanto sia importante utilizzare il giusto linguaggio di programmazione. E, probabilmente, ogni azienda di Grafana ha qualcosa di diverso. E probabilmente dai accesso a Grafana anche ai tuoi sviluppatori, e gli sviluppatori fanno le loro cose. E tutti lo fanno in qualche modo in modo diverso. Ma volevo che fosse in qualche modo la stessa cosa, cioè ridurla a uno standard comune.
Diciamo che non hai nemmeno solo ingegneri di sistema, forse hai anche esperti, devops o SRE. Forse avete degli esperti che sanno cos'è il monitoraggio, che sanno cos'è Grafana, cioè ci lavorano da anni e sanno esattamente come farlo nel modo giusto. E lo hanno già scritto 100 volte e lo hanno spiegato a tutti, ma per qualche motivo nessuno ascolta.
E se potessero inserire questa conoscenza direttamente in Grafana in modo che altri utenti possano riutilizzarne le funzionalità? E se avessero bisogno di calcolare la percentuale di memoria libera, applicherebbero semplicemente la funzione. E se i creatori degli esportatori, insieme al loro prodotto, fornissero anche una serie di funzioni su come lavorare con i loro parametri, perché sanno esattamente quali sono questi parametri e come calcolarli correttamente?
Questo in realtà non esiste. Questo è quello che ho fatto io stesso. Questo è il supporto della libreria in Grafana. Diciamo che i ragazzi che hanno creato NodeExporter hanno fatto quello di cui ho parlato. E fornivano anche una serie di funzioni.
Cioè, assomiglia a questo. Colleghi questa libreria a Grafana, vai in modifica ed è scritto molto semplicemente in JSON come lavorare con questa metrica. Cioè, un insieme di funzioni, la loro descrizione e in cosa si trasformano.
Penso che questo possa essere utile, perché poi in Grafana scriveresti proprio così. E Grafana ti "dice" che esiste questa o quella funzione da questa o quella libreria: usiamola. Penso che sarebbe molto bello.
Un po' di VictoriaMetrics. Facciamo molte cose interessanti. Leggi i nostri articoli sulla compressione, sulle nostre competizioni con altre applicazioni di dati di serie temporali, la nostra spiegazione su come lavorare con PromQL, perché ci sono ancora molti principianti in questo, così come sulla scalabilità verticale e sul confronto con Thanos.
Domande:
Inizierò la mia domanda con una semplice storia di vita. Quando ho iniziato a utilizzare Grafana, ho scritto una query molto avvincente lunga 5 righe. Il risultato finale è un grafico molto convincente. Questo programma è quasi entrato in produzione. Ma dopo un esame più attento, si è scoperto che questo grafico mostra un'assoluta assurdità che non ha nulla a che fare con la realtà, sebbene i numeri rientrino nell'intervallo che ci aspettavamo di vedere. E la mia domanda. Abbiamo librerie, abbiamo funzioni, ma come scriviamo test per Grafana? Hai scritto una richiesta complessa da cui dipende la decisione aziendale: ordinare o meno un vero contenitore di server. E come sappiamo, questa funzione che disegna il grafico è simile alla verità. Grazie.
Grazie per la domanda Ci sono due parti. Innanzitutto, ho l'impressione, in base alla mia esperienza, che la maggior parte degli utenti, quando guardano i propri grafici, non capiscono cosa stanno mostrando loro. Per qualche ragione, le persone sono molto brave a trovare una scusa per qualsiasi anomalia che si verifica nei grafici, anche se si tratta di un errore all'interno di una funzione. E la seconda parte: mi sembra che l'utilizzo di tali funzioni sarebbe un approccio molto migliore per risolvere il tuo problema, invece di ciascuno dei tuoi sviluppatori che pianifica la propria capacità e commette errori con una certa probabilità.
Come controllare?
Come controllare? Probabilmente no.
Come prova a Grafana.
Cosa c'entra Grafana? Grafana traduce questa richiesta direttamente nel DataSource.
Aggiungendo un po' ai parametri.
No, a Grafana non viene aggiunto nulla. Potrebbero esserci parametri GET, come, ad esempio, step. Non è specificato esplicitamente, ma puoi sovrascriverlo oppure non sovrascriverlo, ma viene aggiunto automaticamente. Non scriverai test qui. Non penso che dovremmo fare affidamento su Grafana come fonte di verità qui.
Grazie per la segnalazione! Grazie per la compressione! Hai menzionato la mappatura di una variabile in un grafico, che in Grafana non è possibile utilizzare una variabile all'interno di una variabile. Sai cosa intendo?
Sì.
Inizialmente questo era un mal di testa quando volevo creare un avviso in Grafana. E lì devi fare un avviso per ciascun host separatamente. Questa cosa che hai realizzato, funziona per gli avvisi in Grafana?
Se Grafana non accede alle variabili in modo diverso, allora sì, funzionerà. Ma il mio consiglio è di non usare affatto gli avvisi in Grafana, è meglio usare alertmanager.
Sì, lo uso, ma mi sembrava più semplice da configurare in Grafana, ma grazie per il consiglio!
Fonte: habr.com