Vi invitiamo a prendere visione della trascrizione della presentazione di Roman Khavronenko "ExtendedPromQL"
Un breve riepilogo su di me. Mi chiamo Roman. Lavoro per CloudFlare e vivo a Londra. Ma sono anche il mantenitore di VictoriaMetrics.
E sono l'autore del per Grafana e – un piccolo proxy per ClickHouse.
Inizieremo con la prima parte, intitolata "Le difficoltà della traduzione" nella quale parlerò di come ogni lingua o anche semplicemente un linguaggio di comunicazione sia molto importante. Perché è il modo in cui si trasmettono i propri pensieri a un'altra persona o sistema, come si formula una richiesta. La gente su Internet discute su quale linguaggio sia migliore – Java o un altro. Per me, ho deciso che bisogna scegliere in base al compito, poiché tutto è molto specifico.
Partiamo dalle basi. Cos'è PromQL? PromQL è il linguaggio di query di Prometheus. È così che formuliamo le richieste in Prometheus per ottenere dati di serie temporali.
Cosa sono i dati di serie temporali? In parole semplici, sono tre parametri.
Essi sono:
- Cosa stiamo osservando.
- Quando lo stiamo osservando.
- E quale valore mostra.
Se guardiamo questo grafico (questo grafico è stato fatto con il mio telefono e mostra le statistiche dei miei passi), possiamo rispondere rapidamente a queste domande.
Stiamo analizzando i passi. Vediamo il valore e vediamo anche l'ora, quando lo osserviamo. Cioè, guardando questo grafico è facile dire che domenica ho fatto circa 15.000 passi. Si tratta di dati della serie temporale.
Adesso trasformiamo questi dati in un'altra modalità di visualizzazione, in forma di tabella. Qui abbiamo anche ciò che stiamo analizzando. Ho aggiunto alcuni dati aggiuntivi, che chiamiamo metadati, cioè non li ho percorsi io, ma due persone, come Jay e Silent Bob. Questo è ciò che stiamo analizzando; cosa mostra e quando mostra questo valore.
Ora proviamo a memorizzare tutti questi dati in un database. Per esempio, ho utilizzato la sintassi di ClickHouse. Qui stiamo creando una tabella chiamata "Steps", cioè ciò che stiamo analizzando. Ci sono il tempo in cui lo osserviamo; cosa mostra e alcuni metadati, dove conserveremo chi sono: Jay e Silent Bob.
E per cercare di visualizzare tutto questo, useremo Grafana, perché, in primo luogo, è bellissimo.
Useremo anche questo plugin. Ci sono due motivi per questo. Il primo è che l'ho scritto io. E so perfettamente quanto sia difficile estrarre dati di serie temporali da ClickHouse per mostrarli in Grafana.
Visualizzeremo nel Graph Panel. Questo è il pannello più popolare in Grafana, che mostra la dipendenza del valore rispetto al tempo, quindi abbiamo bisogno solo di due parametri.
Scriviamo la query più semplice: come mostrare le statistiche dei passi in Grafana, memorizzando questi dati in ClickHouse, nella tabella che abbiamo creato. Scriviamo quindi questa semplice query. Selezioniamo dai passi. Selezioniamo il valore e selezioniamo il tempo di questi valori, cioè i medesimi tre parametri di cui abbiamo parlato.
E come risultato otterremo un grafico come questo. Chi sa perché è così strano?
Esatto, bisogna ordinare per tempo.
E alla fine otterremo un grafico migliore, ma ancora strano. Chi lo sa perché? Giusto, ci sono due partecipanti, e in Grafana stiamo restituendo due serie temporali, perché se rivediamo il modello di dati, ogni serie temporale è una combinazione unica di nome e di tutte le coppie chiave-valore delle etichette.
Quindi dobbiamo scegliere una persona specifica. Scegliamo Jay.
E disegniamo di nuovo. Ora il grafico è più vicino alla realtà. Ora è un grafico normale e tutto funziona bene.
E probabilmente sapete come fare più o meno la stessa cosa, ma in Prometheus attraverso PromQL. Circa in questo modo. Un po' più semplice. E suddivideremo tutto. Abbiamo preso i Passi. E filtriamo per Jay. Qui non specifichiamo che vogliamo ottenere un valore e non scegliamo il tempo.
Ora proviamo a calcolare la velocità di movimento di Jay o Silent Bob. In ClickHouse dobbiamo eseguire un runningDifference, cioè calcolare la differenza tra coppie di punti e dividerle per il tempo, per ottenere la velocità esatta. La query apparirà più o meno in questo modo.
E mostrerà valori simili, cioè circa 1,8 passi al secondo per Silent Bob o Jay.
E in Prometheus sapete come farlo anche. Molto più semplice di prima.
E per mantenere questa semplicità in Grafana, ho aggiunto un wrapper che assomiglia molto a PromQL. Si chiama Rate Macros, oppure come volete chiamarla. In Grafana scrivete semplicemente «rate», ma in profondità viene trasformato in una grande query. Non dovete nemmeno osservare questa query, esiste da qualche parte, ma risparmiate un sacco di tempo, perché scrivere query SQL gigantesche è sempre dispendioso. Potete facilmente commettere un errore e poi impiegare molto tempo per capire cosa stia succedendo.
Ecco una query che non è riuscita a stare nemmeno in un singolo slide e ho dovuto dividerla addirittura in due colonne. Anche questa è una query in ClickHouse che esegue lo stesso rate, ma per entrambe le time series: sia per Silent Bob che per Jay, in modo che sulla nostra dashboard ci siano due time series. Già questo è molto complicato, secondo il mio parere.
E in Prometheus sarebbe sum(rate). Per ClickHouse ho creato un macro separato chiamato RateColumns, che appare come una query in Prometheus.
Abbiamo guardato e sembra che PromQL sia davvero fantastico, ma ha sicuramente delle limitazioni.
Essi sono:
- SELECT limitato.
- JOIN limitati.
- Nessun supporto per HAVING.
E se hai lavorato a lungo con esso, sai che a volte è molto difficile fare qualcosa in PromQL, mentre in SQL puoi praticamente fare tutto, perché tutte queste opzioni di cui abbiamo parlato possono essere realizzate in SQL. Ma sarebbe comodo usarle? Questo mi porta a pensare che non sempre il linguaggio più potente sia il più pratico.
Pertanto, a volte bisogna scegliere il linguaggio in base alle esigenze. È come una battaglia tra Batman e Superman. È chiaro che Superman è più forte, ma Batman è riuscito a sconfiggerlo perché è più pratico e sapeva esattamente cosa fare.
E la parte successiva è l'estensione di PromQL.
Ancora una volta su VictoriaMetrics. Cos'è VictoriaMetrics? È un database time series, è open source, distribuiamo versioni single e cluster. Dai nostri benchmark, è il più veloce sul mercato attualmente e offre una compressione simile, ovvero le persone riportano una compressione di circa 0,4 byte per punto, mentre per Prometheus è di 1,2-1,4.
Non supportiamo solo Prometheus. Supportiamo anche InfluxDB, Graphite, OpenTSDB.
In noi è possibile "scrivere", cioè è possibile trasferire dati storici.
Inoltre, lavoriamo perfettamente con Prometheus e Grafana, ovvero supportiamo il motore PromQL. In Grafana puoi semplicemente cambiare l'endpoint di Prometheus con VictoriaMetrics e tutte le tue dashboard continueranno a funzionare come prima.
Ma puoi anche utilizzare le funzionalità aggiuntive che offre VictoriaMetrics.
Passiamo rapidamente attraverso le funzioni che abbiamo aggiunto.
Ometti il parametro dell'intervallo – puoi saltare i parametri dell'intervallo in Grafana. Quando non vuoi ottenere grafici strani durante lo zoom in/out nel pannello, è consigliabile utilizzare la variabile $__interval. Questa è una variabile interna di Grafana e sceglie automaticamente l'intervallo dei dati. E VictoriaMetrics può capire da sola quale dovrebbe essere questo intervallo. Non è necessario aggiornare tutte le tue query. Sarà molto più semplice.
La seconda funzione è il riferimento all'intervallo. Puoi utilizzare questo intervallo nelle tue espressioni. Puoi moltiplicarlo, dividerlo, passarci sopra o fare riferimento ad esso.
Infine, la famiglia delle funzioni rollup. Le funzioni rollup trasformano qualsiasi tua serie temporale in tre serie temporali separate: min, max e avg. Trovo che sia molto utile perché a volte può mostrare fuori norma (anomalia) e imprecisioni.
E se stai semplicemente utilizzando irate o rate, probabilmente potresti perdere alcuni casi in cui la serie temporale si comporta in modo diverso da quanto previsto. Con questa funzione è molto più semplice vedere, ad esempio, che il max è molto superiore all'avg.
Poi c'è la variabile default. Default significa quale valore dobbiamo visualizzare in Grafana se non abbiamo una serie temporale in quel momento. Quando succede? Supponiamo che tu stia esportando una certa metrica sugli errori. E hai un'app così fantastica che quando hai avviato, non hai avuto errori e nemmeno errori nei successivi tre ore o persino un giorno. E hai dei dashboard che mostrano il rapporto tra successi ed errori. E ti mostreranno nulla, perché non hai la metrica degli errori. In default puoi specificare qualsiasi valore.
Keep_last_Value – mantiene l'ultimo valore della metrica se scompare. Se Prometheus non riesce a trovarla durante il prossimo scraping per 5 minuti, qui ricorderemo il suo ultimo valore e i tuoi grafici non si romperanno di nuovo.
Scrape_interval – mostra con che frequenza Prometheus raccoglie i dati sulla tua metrica, a quale frequenza. Qui puoi vedere ad esempio un'interruzione.
La sostituzione dell'etichetta è una funzione popolare. Tuttavia, riteniamo che sia un po' complicata, poiché richiede argomenti interi. Devi non solo ricordare 5 argomenti, ma anche tener conto della loro sequenza.
Perché non rendere le cose più semplici? Cioè, suddividerle in funzioni più piccole con una sintassi chiara.
E ora arriva la parte interessante. Perché consideriamo questa una PromQL estesa? Perché supportiamo le Common Table Expressions. Puoi scansionare il codice QR (), visualizzare i collegamenti con esempi e un playground dove puoi eseguire query direttamente in VictoriaMetrics senza doverla installare, semplicemente nel browser.
E cos'è questo? Quella query sopra è una query abbastanza comune. Penso che in qualsiasi dashboard di molte aziende tu utilizzi lo stesso filtro per tutto. Di solito è così. Ma quando hai bisogno di aggiungere un nuovo filtro, devi aggiornare ogni pannello o scaricare la dashboard, aprirla in JSON, fare find replace, il che richiede tempo. Perché non memorizzare questo valore in una variabile e riutilizzarlo? Questo, a mio avviso, sembra molto più semplice e chiaro.
Ad esempio, quando ho bisogno di aggiornare i filtri in Grafana in tutte le query, e il dashboard può essere molto grande o addirittura averne più di uno. Come posso risolvere questo problema in Grafana?
Affronta questo problema in questo modo: creo un commonFilter e in esso definisco questo filtro, poi lo riutilizzo nelle query. Ma se fai così adesso, non funzionerà, perché Grafana non ti consente di utilizzare variabili all'interno delle variabili delle query. È un po' strano.
E quindi ho realizzato una soluzione che permette di farlo. Se ti interessa o vuoi questa funzionalità, sostienila o metti un dislike se non ti piace questa idea.
Vediamo ora PromQL esteso. Qui definiamo non solo una variabile, ma anche un'intera funzione. La chiamiamo ru (utilizzo delle risorse). Questa funzione riceve le risorse disponibili, un limite per le risorse e un filtro. Il sintassi è piuttosto semplice. È molto facile utilizzare questa funzione e calcolare la percentuale di memoria libera. Cioè, quanti MB abbiamo a disposizione, qual è il limite e come filtrare. Risulterebbe molto più comodo se scrivessi tutto questo riutilizzando gli stessi filtri, altrimenti diventa una query molto complessa.
Ed ecco un esempio di una query molto complessa. Proviene dal dashboard ufficiale di NodeExporter per Grafana. Ma io fatico a capire cosa stia succedendo. Cioè, certo, capisco se ci faccio attenzione, ma il numero di parentesi può subito scoraggiare dal cercare di capire cosa stia accadendo. Perché non semplificarla e renderla più comprensibile?
Ad esempio, potremmo farlo in questo modo, evidenziando i punti o le parti significative in variabili. E poi eseguire i nostri calcoli di base. Questo assomiglia di più alla programmazione ed è ciò che vorrei vedere in futuro in Grafana.
Ecco un secondo esempio di come possiamo semplificare ulteriormente, se avessimo già questa funzione ru, che è già presente direttamente in VictoriaMetrics. E quindi basta passare 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, in ogni azienda in Grafana succede qualcosa di diverso. E, probabilmente, dai anche accesso a Grafana ai tuoi sviluppatori, e gli sviluppatori fanno qualcosa di diverso. E tutti lo fanno in modi differenti. Vorremmo che fosse più uniforme, cioè ridurre tutto a uno standard comune.
Supponiamo che tu abbia non solo ingegneri di sistema, forse hai anche esperti, devops o SRE. Potresti avere esperti che sanno cos'è il monitoraggio, sanno cos'è Grafana, cioè lavorano con questo da anni e sanno esattamente come fare nel modo giusto. E lo hanno già scritto 100 volte e l'hanno spiegato a tutti, ma per qualche motivo nessuno ascolta.
E se potessero inserire direttamente queste conoscenze in Grafana, in modo che altri utenti potessero riutilizzare le funzionalità? E se fosse necessario calcolare la percentuale di memoria libera, basterebbe applicare la funzione. E se i creatori degli exporter, insieme al loro prodotto, fornissero anche un insieme di funzioni su come lavorare con le loro metriche, perché sanno esattamente quali sono queste metriche e come calcolarle correttamente?
In realtà, questo non esiste. Questo l'ho fatto io stesso. È il supporto delle librerie in Grafana. Supponiamo che i ragazzi che hanno creato NodeExporter abbiano fatto quanto ho descritto, e abbiano anche fornito un insieme di funzioni.
Cioè, appare più o meno così. Colleghi questa libreria a Grafana, entri in modifica e qui è scritto molto semplicemente in JSON come lavorare con questa metrica. Cioè, un certo insieme di funzioni, loro descrizioni e in cosa si sviluppano.
Secondo me, questo potrebbe essere utile, perché allora in Grafana scriveresti semplicemente in questo modo. E Grafana "ti dice" che c'è questa funzione di quella libreria – usiamola. Mi sembra che sarebbe davvero grandioso.
Un po' su VictoriaMetrics. Facciamo molte cose interessanti. Leggi i nostri articoli sulla compressione, sulle nostre competizioni con altre applicazioni di time series, sulla nostra spiegazione su come lavorare con PromQL, perché ci sono ancora molti principianti, e anche sulla scalabilità verticale e sulla nostra sfida con Thanos.
Domande:
Inizio la mia domanda con una semplice storia della vita reale. Quando ho iniziato a usare Grafana, ho scritto una query molto convincente di cinque righe. Ne è risultato un grafico davvero interessante. Questo grafico era quasi pronto per essere messo in produzione. Ma, a un'attenta analisi, si è scoperto che mostrava assolute sciocchezze, del tutto scollegate dalla realtà, anche se i numeri rientravano nell'intervallo che ci aspettavamo. Ecco la mia domanda. Abbiamo delle librerie, abbiamo delle funzioni, ma come scriviamo i test per Grafana? Hai scritto una query complessa, dalla quale dipende una decisione aziendale: ordinare un vero container di server o no. E come possiamo sapere che la funzione che disegna il grafico assomiglia alla verità? Grazie.
Grazie per la domanda. Ci sono due parti. Prima di tutto, mi sembra, sulla base della mia esperienza, che la maggior parte degli utenti, quando osserva i propri grafici, non capisca cosa stiano mostrando. In qualche modo, le persone sono molto abili nel trovare giustificazioni per qualsiasi anomalia che appare nei grafici, anche quando si tratta di un errore all'interno della funzione. La seconda parte è che penso che usare questo tipo di funzioni sarebbe molto più utile per risolvere il vostro problema, invece che ogni vostro sviluppatore faccia il proprio capacity planning e commetta errori con qualche probabilità.
Come verificare?
Come verificare? Probabilmente, non si può.
Sotto forma di test in Grafana.
Cosa c'entra Grafana? Grafana trasmette questa richiesta direttamente nel DataSource.
Aggiungendo un po' nei parametri.
No, in Grafana non aggiungono nulla. Possono esserci parametri GET, come ad esempio step. Non viene specificato esplicitamente, ma puoi sovrascriverlo o meno, ma viene aggiunto automaticamente. Non puoi scrivere test qui. Penso che non dovresti fare affidamento su Grafana come fonte di verità.
Grazie per la relazione! Grazie per la compressione! Hai menzionato il mapping delle variabili nel grafico, dove in Grafana non è possibile usare una variabile all'interno di un'altra. Capisci di cosa parlo?
Sì.
È stata inizialmente una seccatura quando volevo impostare gli avvisi in Grafana. E lì devi impostare un avviso separato per ogni host. Questa cosa che hai fatto, funziona per gli avvisi in Grafana?
Se Grafana non gestisce le variabili in un modo diverso, allora sì, funzionerà. Ma il mio consiglio è di non usare affatto gli avvisi in Grafana, è meglio utilizzare alertmanager.
Sì, lo utilizzo, ma mi è sembrato più facile configurarlo in Grafana, comunque grazie per il consiglio!
Fonte: habr.com
