🥇VictoriaMetrics e monitoraggio delle nuvole private. Pavel Kolobaev

VictoriaMetrics — un database veloce e scalabile per la memorizzazione e l'elaborazione dei dati in forma di serie temporale (una registrazione forma il tempo e un insieme di valori corrispondenti a quel tempo, ad esempio, ottenuti tramite sondaggio periodico dello stato dei sensori o raccolta di metriche).

Mi chiamo Kolobayev Pavel. DevOps, SRE, LeroyMerlin, tutto come codice – è tutto su di noi: su di me e sugli altri dipendenti di LeroyMerlin.

https://bit.ly/3jf1fIK

C'è un cloud basato su OpenStack. Qui c'è un piccolo collegamento al tech radar.

È costruito su hardware Kubernetes, oltre a tutti i servizi ausiliari per OpenStack e registrazione.

Lo schema era questo durante lo sviluppo. Quando stavamo sviluppando tutto questo, avevamo un operatore Prometheus che memorizzava i dati all'interno del cluster K8s. Trova automaticamente ciò che deve essere estratto e lo mette ai suoi piedi, in parole povere.

Tutti i dati devono essere estratti dal cluster Kubernetes, perché se succede qualcosa, dobbiamo capire cosa e dove.

La prima soluzione è utilizzare la federation, quando abbiamo un Prometheus esterno e accediamo al cluster Kubernetes attraverso il meccanismo di federation.

Ma qui sorgono piccoli problemi. Nel nostro caso, i problemi sono iniziati quando avevamo 250.000 metriche, e quando sono diventate 400.000 metriche, ci siamo resi conto che non potevamo lavorare in questo modo. Abbiamo aumentato il scrape_timeout a 25 secondi.

Perché abbiamo dovuto farlo? Prometheus inizia a contare il tempo di timeout dall'inizio dell'estrazione. E non importa che i dati stiano ancora fluendo. Se entro quel periodo specificato i dati non vengono scaricati e la sessione non viene chiusa tramite http, si considera che la sessione sia fallita e i dati non entrano in Prometheus.

Tutti conosciamo i grafici che otteniamo quando parte dei dati è assente. I grafici sono frastagliati e ciò non ci soddisfa.

La prossima opzione è lo sharding basato su due Prometheus diversi tramite lo stesso meccanismo di federation.

Ad esempio, semplicemente prendere e shardarli per nome. Questo può essere utilizzato anch'esso, ma abbiamo deciso di andare oltre.

Ora dovremo in qualche modo gestire questi shard. Possiamo prendere promxy, che si collega all'area dello shard e moltiplica i dati. Funziona con due shard come un'unica porta di accesso. Questo può essere realizzato tramite promxy, ma è ancora troppo complicato.

La prima opzione è che vogliamo rinunciare al meccanismo di federation, perché è molto lento.

Gli sviluppatori di Prometheus dicono chiaramente: «Ragazzi, utilizzate altri TimescaleDB, perché non supporteremo a lungo la conservazione delle metriche». Non è compito loro.

Prendiamo nota su un pezzo di carta che abbiamo comunque bisogno di un'esportazione, per non conservare tutto in un unico posto.

Il secondo svantaggio è il consumo di memoria. Sì, capisco che molti diranno che nel 2020 un paio di gigabyte di memoria costano pochi, ma comunque.

Attualmente abbiamo un ambiente dev e uno prod. Nel dev, sono circa 9 gigabyte per 350.000 metriche. Nel prod, sono 14 gigabyte e poco più per 780.000 metriche. Inoltre, il tempo di retention è di soli 30 minuti. Questo è un problema. E ora spiegherò perché.

Stiamo facendo un calcolo, ossia con un milione e mezzo di metriche, e siamo già vicini a quel numero, in fase di progettazione riceviamo 35-37 gigabyte di memoria. Già a 4 milioni di metriche, abbiamo bisogno di circa 90 gigabyte di memoria. Questo è stato calcolato secondo la formula fornita dagli sviluppatori di Prometheus. Abbiamo esaminato la correlazione e capito che non vogliamo pagare un paio di milioni per un server solo per il monitoraggio.

Non solo aumenterà il numero delle macchine, ma monitoriamo anche le stesse macchine virtuali. Quindi, più macchine virtuali ci sono, più metriche di vario tipo avremo e così via. Ci sarà una crescita specifica del nostro cluster in termini di metriche.

Con lo spazio su disco non è tutto così tragico, ma ci piacerebbe migliorare. Abbiamo ottenuto in 15 giorni un totale di 120 gigabyte, di cui 100 sono dati compressi e 20 non compressi, ma si vorrebbe sempre avere meno.

Di conseguenza, aggiungiamo un altro punto: è un grande consumo di risorse che vorremmo comunque risparmiare, perché non vogliamo che il nostro cluster di monitoraggio consumi più risorse del nostro cluster che gestisce OpenStack.

C'è anche un altro svantaggio di Prometheus che abbiamo identificato, ed è una qualche forma di limitazione della memoria. Con Prometheus la situazione è molto peggiore, perché non ha affatto queste regolazioni. Utilizzare un limite in Docker non è neanche un'opzione. Se il vostro RAF si arresta e ci sono 20-30 gigabyte, ci vorrà un bel po' per rialzarsi.

Questa è un'altra ragione per cui Prometheus non è adatto a noi, cioè non si può limitare il consumo di memoria.

Si potrebbe arrivare a una tale configurazione. Questa configurazione ci serve per organizzare un cluster HA. Vogliamo che le nostre metriche siano sempre e ovunque disponibili, anche in caso di fallimento del server che le memorizza. Pertanto, dovremo costruire una configurazione del genere.

Questa configurazione prevede che ci sarà duplicazione delle shard e, di conseguenza, anche duplicazione dei costi delle risorse consumate. Può essere scalata quasi orizzontalmente, ma il consumo di risorse sarà comunque enorme.

Gli svantaggi in ordine, così come li abbiamo annotati:

Richiede il caricamento delle metriche all'esterno.
Elevato consumo di risorse.
Non è possibile limitare l'uso della memoria.
Implementazione complessa e costosa in termini di risorse per HA.

Per noi, abbiamo deciso di allontanarci da Prometheus come sistema di archiviazione.

Abbiamo definito ulteriori requisiti che ci servono. Questi sono:

Supporto per promql, perché sono già stati scritti molti strumenti per Prometheus: interrogazioni, avvisi.
E poi abbiamo Grafana, anch'essa scritta per Prometheus come backend. Non vogliamo riscrivere i dashboard.
Vogliamo costruire un'architettura HA adeguata.
Vogliamo ridurre il consumo di tutte le risorse.
C'è anche un piccolo particolare. Non possiamo utilizzare vari tipi di sistemi cloud per la raccolta delle metriche. Non sappiamo cosa verrà inviato in queste metriche per ora. E poiché può andare a finire tutto ciò che si vuole, dobbiamo limitarci a una collocazione locale.

Le opzioni erano limitate. Abbiamo raccolto tutto ciò che ci era familiare. Abbiamo guardato nella pagina di Prometheus nella sezione integrazione, letto molti articoli, visto cosa c'è in giro. E per noi abbiamo scelto VictoriaMetrics come sostituto di Prometheus.

Perché? Perché:

Supporta promql.
Ha un'architettura modulare.
Non richiede modifiche a Grafana.
E, cosa più importante, forse forniremo un servizio di archiviazione delle metriche all'interno della nostra azienda, quindi stiamo già considerando limitazioni di varia natura, affinché gli utenti possano utilizzare le risorse del cluster in modo limitato, poiché c'è la possibilità che sia multitenancy.

Facciamo il primo confronto. Prendiamo lo stesso Prometheus all'interno del cluster, al quale accede un Prometheus esterno. Aggiungiamo VictoriaMetrics tramite remoteWrite.

Voglio subito precisare che qui abbiamo registrato un leggero aumento del consumo di CPU da parte di VictoriaMetrics. Nella wiki di VictoriaMetrics è indicato quali parametri siano più adatti. Li abbiamo testati. Hanno ridotto molto bene il consumo di CPU.

Nel nostro caso, il consumo di memoria di Prometheus, che si trova nel cluster Kubernetes, è aumentato solo leggermente.

Stiamo confrontando due data source con gli stessi dati. In Prometheus vediamo tutti i dati mancanti. In VictoriaMetrics va tutto bene.

Risultati dei test con lo spazio su disco. Abbiamo ottenuto 120 gigabyte in totale in Prometheus. In VictoriaMetrics otteniamo già 4 gigabyte al giorno. Lì c'è un meccanismo un po' diverso rispetto a quello che siamo abituati a vedere in Prometheus. Cioè, i dati vengono già compressi abbastanza bene in un giorno, in mezz'ora. Sono già compressi bene in un giorno, in mezz'ora, nonostante ci sarà un'ulteriore fusione dei dati. Alla fine abbiamo risparmiato spazio su disco.

Inoltre risparmiamo sul consumo delle risorse di memoria. Al momento dei test, Prometheus era distribuito su una macchina virtuale – 8 core, 24 gigabyte. Prometheus consuma praticamente tutto. È andato in OOM Killer. Tuttavia, stavamo gestendo solo 900.000 metriche attive. Si tratta di circa 25.000-27.000 metriche al secondo.

VictoriaMetrics era in esecuzione su una macchina virtuale a due core con 8 gigabyte di RAM. Siamo riusciti a far funzionare bene VictoriaMetrics, modificando alcune impostazioni su una macchina da 8 gigabyte. Alla fine, siamo riusciti a rimanere entro 7 gigabyte, ottenendo anche una velocità di erogazione dei contenuti, cioè delle metriche, addirittura superiore a quella di Prometheus.

La situazione per la CPU è migliorata notevolmente rispetto a Prometheus. Qui Prometheus consuma 2,5 core, mentre VictoriaMetrics solo 0,25 core. All'avvio consuma 0,5 core. Man mano che avviene la fusione, può arrivare a un core, ma questo accade raramente.

Nel nostro caso, abbiamo scelto VictoriaMetrics per motivi ovvi, volevamo risparmiare e ci siamo riusciti.

Escludiamo subito due punti – il caricamento delle metriche e il grande consumo di risorse. Ci restano due punti su cui dobbiamo ancora decidere.

Qui voglio precisare che consideriamo VictoriaMetrics come un repository di metriche. Ma poiché probabilmente forniremo VictoriaMetrics come repository per tutto Leroy, dobbiamo limitare coloro che utilizzeranno questo cluster, affinché non lo sovraccarichino.

C'è un'ottima opzione che consente di limitare il tempo, il volume dei dati e il tempo di esecuzione.

C'è anche un'ottima opzione che consente di limitare il consumo di memoria, in questo modo possiamo trovare l'equilibrio che ci permetterà di ottenere una velocità di lavoro adeguata e un consumo di risorse ragionevole.

Un altro svantaggio, cioè cancelliamo il punto - non è possibile limitare il consumo di memoria.

Nelle prime iterazioni abbiamo testato VictoriaMetrics Single Node. Ora passiamo a VictoriaMetrics Cluster Version.

Qui abbiamo la possibilità di separare diversi servizi in VictoriaMetrics a seconda della piattaforma su cui gireranno e delle risorse che consumeranno. È una soluzione molto flessibile e conveniente. L'abbiamo utilizzata in prima persona.

I componenti principali della VictoriaMetrics Cluster Version sono vmstorage. Possono esserci N istanze. Nel nostro caso, al momento ce ne sono 2.

E c'è vminsert. Questo è un server proxy che ci consente di: organizzare lo sharding tra tutti gli storage che gli abbiamo indicato e fornisce anche una replica, cioè avrete sia lo sharding che la replica.

Vminsert supporta i protocolli OpenTSDB, Graphite, InfluxDB e remoteWrite di Prometheus.

C'è anche vmselect. Il suo compito principale è quello di interrogare vmstorage, ottenere da loro i dati, deduplicarli e restituirli al client.

C'è una strepitosa funzionalità chiamata vmagent. Ci piace molto. Permette di configurare esattamente come Prometheus e di funzionare allo stesso modo di Prometheus. Cioè, raccoglie metriche da diverse entità, servizi e le invia a vminsert. Da lì, tutto dipende da te.

Un altro servizio fantastico è vmalert, che consente di utilizzare VictoriaMetrics come backend, ricevere dati elaborati da vminsert e inviarli a vmselect. Elabora sia gli avvisi che le regole. Nel caso degli avvisi, riceviamo un avviso tramite alertmanager.

C'è un componente wmauth. Potrebbe essere utilizzato da noi, o potrebbe non esserlo (non ci siamo ancora decisi in merito) come sistema di autorizzazione nella versione multitenancy dei cluster. Supporta remoteWrite per Prometheus e può autorizzare in base all'URL, più precisamente alla sua seconda parte, dove è possibile o meno scrivere.

Ci sono anche vmbackup, vmrestore. Questo è, in sostanza, il ripristino e il backup di tutti i dati. Supporta S3, GCS, file.

La prima iterazione del nostro cluster è stata effettuata durante il periodo di quarantena. In quel momento non c'era una replica, quindi la nostra iterazione si è presentata come due cluster diversi e indipendenti, da cui ricevevamo dati tramite remoteWrite.

Qui mi preme notare che, quando siamo passati da VictoriaMetrics Single Node a VictoriaMetrics Cluster Version, siamo rimasti con le stesse risorse consumate, cioè principalmente la memoria. In questo modo si sono distribuiti i nostri dati, cioè il consumo delle risorse.

Qui era già stata aggiunta una replica. Abbiamo unito tutto questo in un cluster relativamente grande. Tutti i nostri dati si shardano e si replicano.

L'intero cluster ha N punti di accesso, cioè Prometheus può aggiungere dati tramite HAPROXY. Ecco il nostro punto di accesso. E tramite questo punto di accesso si può accedere con Grafana.

Nel nostro caso, HAPROXY è l'unica porta che proxyza select, insert e i restanti servizi all'interno di questo cluster. Non è stato possibile creare un solo indirizzo, abbiamo dovuto realizzare diversi punti di accesso, perché le macchine virtuali su cui gira il cluster VictoriaMetrics si trovano in diverse zone di un fornitore di servizi cloud, cioè non all'interno del nostro cloud, ma all'esterno.

Abbiamo un sistema di alerting. Lo utilizziamo. Usiamo alertmanager di Prometheus. Come canale di consegna degli alert utilizziamo Opsgenie e Telegram. Su Telegram riceviamo alert dal dev, forse qualcosa dal prod, ma per lo più qualcosa di statistico, utile per gli ingegneri. Opsgenie è per gli alert critici. Questi sono chiamate e gestione degli incidenti.

Il classico interrogativo: «Chi monitora il monitoraggio?». Nel nostro caso il monitoraggio si monitora da solo, perché utilizziamo vmagent su ogni nodo. Poiché i nostri nodi sono distribuiti in diversi data center di uno stesso fornitore, ogni data center ha il suo canale, sono indipendenti e anche se si verifica un split brain, riceveremo comunque alert. Sì, ce ne saranno di più, ma è meglio ricevere più alert piuttosto che nessuno.

Concludiamo la nostra lista con l'implementazione dell'HA.

E in seguito vorrei sottolineare l'esperienza di interazione con la community di VictoriaMetrics. È stata molto positiva. I ragazzi sono disponibili. Cercano di approfondire ogni caso proposto.

Ho aperto delle segnalazioni su GitHub. Sono state risolte molto rapidamente. Ci sono ancora un paio di segnalazioni che non sono completamente chiuse, ma vedo già dal codice che il lavoro in questa direzione sta procedendo.

Il principale problema durante le iterazioni per me era che se spegnevo un nodo, dopo i primi 30 secondi vminsert non riusciva a capire che il backend non c'era. Ora questo è già stato risolto. E in appena un secondo o due, i dati vengono recuperati da tutti gli altri nodi rimanenti e la richiesta smette di attendere quel nodo mancante.

In un certo momento volevamo che fosse un operatore VictoriaMetrics. Finalmente l'abbiamo ottenuto. Ora siamo in fase attiva di costruzione di un'interfaccia per l'operatore VictoriaMetrics, per raccogliere tutte le regole di pre-calcolo, ecc. Prometheus, poiché utilizziamo abbastanza attivamente le regole che vanno insieme all'operatore Prometheus.

Ci sono suggerimenti per migliorare l'implementazione del cluster. Li ho esposti sopra.

Inoltre, desideriamo molto il downsampling. Nel nostro caso, il downsampling è necessario esclusivamente per visualizzare le tendenze. Semplificando, durante il giorno una singola metrica mi basta. Queste tendenze sono necessarie per un anno, tre, cinque, dieci anni. E un singolo valore di metrica è assolutamente sufficiente.

Abbiamo vissuto il dolore, come alcuni dei nostri colleghi, utilizzando Prometheus.
Abbiamo scelto VictoriaMetrics.
Si scalda molto bene sia verticalmente che orizzontalmente.
Possiamo distribuire diversi componenti su un numero diverso di nodi nel cluster, limitarli in base alla quantità di memoria, aggiungere memoria, ecc.

Utilizzeremo VictoriaMetrics, perché ci è piaciuta molto. Ecco com'era e com'è diventata.