VictoriaMetrics è un DBMS veloce e scalabile per l'archiviazione e l'elaborazione dei dati sotto forma di serie temporali (un record è costituito dal tempo e da un insieme di valori corrispondenti a questo tempo, ad esempio ottenuti attraverso polling periodici dello stato dei sensori o raccolta di metriche).
Mi chiamo Kolobaev Pavel. DevOps, SRE, LeroyMerlin, tutto è come un codice: è tutto incentrato su di noi: su di me e sugli altri dipendenti LeroyMerlin.
Esiste un cloud basato su OpenStack. C'è un piccolo collegamento al radar tecnico.
È basato sull'hardware Kubernetes, nonché su tutti i servizi correlati per OpenStack e il logging.
Questo è lo schema che avevamo in fase di sviluppo. Quando stavamo sviluppando tutto questo, avevamo un operatore Prometheus che memorizzava i dati all'interno del cluster K8 stesso. Trova automaticamente ciò che deve essere strofinato e lo mette sotto i piedi, grosso modo.
Bisognerà spostare tutti i dati fuori dal cluster Kubernetes, perché se succede qualcosa bisognerà capire cosa e dove.
La prima soluzione è utilizzare la federazione quando disponiamo di un Prometheus di terze parti, quando andiamo al cluster Kubernetes attraverso il meccanismo di federazione.
Ma qui ci sono alcuni piccoli problemi. Nel nostro caso, i problemi sono iniziati quando avevamo 250 metriche e quando erano 000 ci siamo resi conto che non potevamo lavorare così. Abbiamo aumentato scrape_timeout a 400 secondi.
Perché abbiamo dovuto farlo? Prometeo inizia a contare il timeout dall'inizio della recinzione. Non importa che i dati continuino a circolare. Se durante questo periodo di tempo specificato i dati non vengono uniti e la sessione non viene chiusa tramite http, la sessione viene considerata fallita e i dati non entrano nello stesso Prometheus.
Tutti conoscono i grafici che otteniamo quando mancano alcuni dati. I programmi sono lacerati e di questo non siamo contenti.
L'opzione successiva è lo sharding basato su due diversi Prometheus attraverso lo stesso meccanismo di federazione.
Ad esempio, prendili e suddividili per nome. Anche questo può essere utilizzato, ma abbiamo deciso di andare avanti.
Ora dovremo elaborare questi frammenti in qualche modo. Puoi prendere promxy, che va nell'area shard e moltiplica i dati. Funziona con due frammenti come un unico punto di ingresso. Questo può essere implementato tramite promxy, ma è ancora troppo difficile.
La prima opzione è abbandonare il meccanismo della federazione perché è molto lento.
Gli sviluppatori di Prometheus dicono chiaramente: "Ragazzi, usate un TimescaleDB diverso perché non supporteremo l'archiviazione a lungo termine dei parametri". Questo non è il loro compito.
Scriviamo su un pezzo di carta che dobbiamo ancora scaricare fuori, per non riporre tutto in un unico posto.
Il secondo inconveniente è il consumo di memoria. Sì, capisco che molti diranno che nel 2020 un paio di gigabyte di memoria costano un centesimo, ma comunque.
Ora abbiamo un ambiente di sviluppo e produzione. In fase di sviluppo sono circa 9 gigabyte per 350 parametri. In produzione sono 000 gigabyte e poco più di 14 parametri. Allo stesso tempo, il nostro tempo di conservazione è di soli 780 minuti. Questo non va bene. E ora ti spiegherò perché.
Facciamo un calcolo, cioè con un milione e mezzo di parametri, e siamo già vicini a loro, in fase di progettazione otteniamo 35-37 gigabyte di memoria. Ma già 4 milioni di parametri richiedono circa 90 gigabyte di memoria. Cioè, è stato calcolato utilizzando la formula fornita dagli sviluppatori Prometheus. Abbiamo esaminato la correlazione e ci siamo resi conto che non volevamo pagare un paio di milioni per un server solo per il monitoraggio.
Non solo aumenteremo il numero di macchine, ma monitoreremo anche le macchine virtuali stesse. Quindi più macchine virtuali ci sono, più metriche di vario genere, ecc. Avremo una crescita particolare del nostro cluster in termini di metriche.
Con lo spazio su disco, qui non tutto è così male, ma vorrei migliorarlo. Abbiamo ricevuto un totale di 15 gigabyte in 120 giorni, di cui 100 dati compressi, 20 dati non compressi, ma ne vogliamo sempre di meno.
Di conseguenza, scriviamo un altro punto: si tratta di un grande consumo di risorse, che vogliamo comunque risparmiare, perché non vogliamo che il nostro cluster di monitoraggio consumi più risorse del nostro cluster, che gestisce OpenStack.
C'è un altro inconveniente di Prometeo, che abbiamo identificato da soli, è almeno una sorta di limitazione della memoria. Con Prometeo, qui tutto è molto peggio, perché non ha affatto questi colpi di scena. Anche l'uso di un limite nella finestra mobile non è un'opzione. Se all'improvviso la tua RAF cade e ci sono 20-30 gigabyte, ci vorrà molto tempo per aumentare.
Questo è un altro motivo per cui Prometheus non è adatto a noi, ovvero non possiamo limitare il consumo di memoria.
Sarebbe possibile elaborare uno schema del genere. Abbiamo bisogno di questo schema per organizzare un cluster HA. Vogliamo che i nostri parametri siano disponibili sempre e ovunque, anche se il server che li memorizza si blocca. E quindi dovremo costruire un tale schema.
Questo schema afferma che avremo una duplicazione dei frammenti e, di conseguenza, una duplicazione dei costi delle risorse consumate. Può essere scalato quasi orizzontalmente, ma il consumo di risorse sarà comunque infernale.
Svantaggi in ordine nella forma in cui li abbiamo scritti per noi stessi:
- Richiede il caricamento delle metriche esternamente.
- Elevato consumo di risorse.
- Non è possibile limitare il consumo di memoria.
- Implementazione complessa e ad alta intensità di risorse di HA.
Per quanto ci riguarda, abbiamo deciso che ci saremmo allontanati da Prometheus come struttura di stoccaggio.
Abbiamo identificato per noi stessi ulteriori requisiti di cui abbiamo bisogno. Questo:
- Questo è il supporto promql, perché molte cose sono già state scritte per Prometheus: query, avvisi.
- E poi abbiamo Grafana, che è già scritto esattamente allo stesso modo per Prometheus come backend. Non voglio riscrivere i dashboard.
- Vogliamo costruire una normale architettura HA.
- Vogliamo ridurre il consumo di qualsiasi risorsa.
- C'è un'altra piccola sfumatura. Non possiamo utilizzare vari tipi di sistemi di raccolta delle metriche cloud. Non sappiamo ancora cosa rientrerà in questi parametri. E poiché lì tutto può volare, dobbiamo limitarci al posizionamento locale.
C'era poca scelta. Abbiamo raccolto tutto ciò di cui avevamo esperienza. Abbiamo guardato la pagina di Prometheus nella sezione integrazione, letto un sacco di articoli e visto cosa c'era là fuori. E per quanto riguarda noi stessi, abbiamo scelto VictoriaMetrics in sostituzione di Prometheus.
Perché? Perché:
- Conosce Promql.
- C'è un'architettura modulare.
- Non richiede modifiche a Grafana.
- E, cosa più importante, probabilmente forniremo l'archiviazione delle metriche all'interno della nostra azienda come servizio, quindi stiamo guardando in anticipo a restrizioni di vario tipo in modo che gli utenti possano utilizzare tutte le risorse del cluster in modo limitato, perché c'è la possibilità che sarà multitenancy.
Facciamo il primo confronto. Prendiamo lo stesso Prometeo all'interno dell'ammasso, il Prometeo esterno va ad esso. Aggiungi tramite remoteWrite VictoriaMetrics.
Faccio subito una prenotazione che qui abbiamo riscontrato un leggero aumento del consumo di CPU da VictoriaMetrics. Il wiki VictoriaMetrics ti dice quali sono i parametri migliori. Li abbiamo controllati. Hanno ridotto molto bene il consumo della CPU.
Nel nostro caso, il consumo di memoria di Prometheus, che si trova nel cluster Kubernetes, non è aumentato in modo significativo.
Confrontiamo due fonti di dati degli stessi dati. In Prometeo vediamo gli stessi dati mancanti. Va tutto bene a VictoriaMetrics.
Risultati del test dello spazio su disco. Noi di Prometheus abbiamo ricevuto 120 gigabyte in totale. A VictoriaMetrics riceviamo già 4 gigabyte al giorno. C’è un meccanismo leggermente diverso da quello che siamo abituati a vedere in Prometeo. Cioè, i dati sono già compressi abbastanza bene in un giorno, in mezz'ora. Sono già stati raccolti bene in un giorno, in mezz'ora, nonostante i dati andranno comunque persi in seguito. Di conseguenza, abbiamo risparmiato spazio su disco.
Risparmiamo anche sul consumo delle risorse di memoria. Al momento del test, Prometheus era distribuito su una macchina virtuale: 8 core, 24 gigabyte. Prometeo mangia quasi tutto. È caduto su OOM Killer. Allo stesso tempo, sono stati inseriti solo 900 parametri attivi. Si tratta di circa 000-25 parametri al secondo.
Abbiamo eseguito VictoriaMetrics su una macchina virtuale dual-core con 8 gigabyte di RAM. Siamo riusciti a far funzionare bene VictoriaMetrics armeggiando con alcune cose su una macchina da 8 GB. Alla fine lo abbiamo mantenuto a 7 gigabyte. Allo stesso tempo, la velocità di consegna dei contenuti, cioè le metriche, era addirittura superiore a quella di Prometheus.
La CPU è diventata molto migliore rispetto a Prometheus. Qui Prometheus consuma 2,5 core e VictoriaMetrics consuma solo 0,25 core. All'inizio: 0,5 core. Quando si fonde, raggiunge un nucleo, ma questo è estremamente, estremamente raro.
Nel nostro caso la scelta è ricaduta su VictoriaMetrics per ovvi motivi: volevamo risparmiare e lo abbiamo fatto.
Eliminiamo subito due punti: il caricamento delle metriche e l’elevato consumo di risorse. E non ci resta che decidere due punti che ci restano ancora.
Qui effettuerò subito una prenotazione, consideriamo VictoriaMetrics come un deposito di metriche. Ma poiché molto probabilmente forniremo VictoriaMetrics come spazio di archiviazione per tutta Leroy, dobbiamo limitare coloro che utilizzeranno questo cluster in modo che non ce lo forniscano.
Esiste un parametro meraviglioso che ti consente di limitare in base al tempo, al volume di dati e al tempo di esecuzione.
C'è anche un'ottima opzione che ci permette di limitare il consumo di memoria, così possiamo trovare l'equilibrio che ci permetterà di ottenere la normale velocità operativa e un adeguato consumo di risorse.
Meno un altro punto, ad es. cancella il punto: non puoi limitare il consumo di memoria.
Nelle prime iterazioni, abbiamo testato VictoriaMetrics Single Node. Successivamente passiamo alla versione VictoriaMetrics Cluster.
Qui abbiamo mano libera per separare i diversi servizi in VictoriaMetrics a seconda di cosa verranno eseguiti e delle risorse che consumeranno. Questa è una soluzione molto flessibile e conveniente. L'abbiamo usato su noi stessi.
I componenti principali della versione VictoriaMetrics Cluster sono vmstsorage. Possono essercene N numero. Nel nostro caso finora ce ne sono 2.
E c'è vminsert. Questo è un server proxy che ci permette di: organizzare lo sharding tra tutti gli storage di cui abbiamo parlato, e permette anche una replica, cioè avrai sia lo sharding che una replica.
Vminsert supporta i protocolli OpenTSDB, Graphite, InfluxDB e remoteWrite di Prometheus.
C'è anche vmselect. Il suo compito principale è andare su vmstorage, ricevere dati da loro, deduplicarli e fornirli al client.
C'è una cosa meravigliosa chiamata vmagent. Ci piace davvero. Ti consente di configurare esattamente come Prometheus e di fare comunque tutto esattamente come Prometheus. Raccoglie cioè parametri da diverse entità e servizi e li invia a vminsert. Allora tutto dipende da te.
Un altro ottimo servizio è vmalert, che ti consente di utilizzare VictoriaMetrics come backend, ricevere i dati elaborati da vminsert e inviarli a vmselect. Elabora gli avvisi stessi e le regole. In caso di avvisi, riceviamo l'avviso tramite alertmanager.
C'è un componente wmauth. Potremo o meno (non abbiamo ancora deciso in merito) utilizzarlo come sistema di autorizzazione per la versione multi-tenancy dei cluster. Supporta remoteWrite per Prometheus e può autorizzare in base all'url, o meglio alla seconda parte di esso, dove puoi o non puoi scrivere.
C'è anche vmbackup, vmrestore. Questo è, in sostanza, il ripristino e il backup di tutti i dati. Può eseguire S3, GCS, file.
La prima iterazione del nostro cluster è stata effettuata durante la quarantena. A quel tempo non esisteva alcuna replica, quindi la nostra iterazione consisteva in due cluster diversi e indipendenti in cui ricevevamo i dati tramite remoteWrite.
Qui farò una prenotazione che quando siamo passati da VictoriaMetrics Single Node a VictoriaMetrics Cluster Version, siamo rimasti con le stesse risorse consumate, ad es. quella principale è la memoria. Questo è approssimativamente il modo in cui sono stati distribuiti i nostri dati, ovvero il consumo di risorse.
Una replica è già stata aggiunta qui. Abbiamo combinato tutto questo in un unico cluster relativamente grande. Tutti i nostri dati sono sia frammentati che replicati.
L'intero cluster ha N punti di ingresso, il che significa che Prometheus può aggiungere dati tramite HAPROXY. Qui abbiamo questo punto di ingresso. E attraverso questo entry point potrai accedere da Grafana.
Nel nostro caso, HAPROXY è l'unica porta che i proxy selezionano, inseriscono e altri servizi all'interno di questo cluster. Nel nostro caso, era impossibile creare un indirizzo; abbiamo dovuto creare diversi punti di ingresso, perché le macchine virtuali stesse su cui viene eseguito il cluster VictoriaMetrics si trovano in zone diverse dello stesso fornitore di servizi cloud, cioè non all'interno del nostro cloud, ma all'esterno. .
Abbiamo avvisi. Lo usiamo. Usiamo alertmanager di Prometheus. Utilizziamo Opsgenie e Telegram come canale di consegna degli avvisi. In Telegram arrivano dallo sviluppo, forse qualcosa dal prodotto, ma soprattutto qualcosa di statistico, necessario agli ingegneri. E Opsgenie è fondamentale. Queste sono chiamate, gestione degli incidenti.
L’eterna domanda: “Chi controlla il monitoraggio?” Nel nostro caso, il monitoraggio monitora il monitoraggio stesso, poiché utilizziamo vmagent su ciascun nodo. E poiché i nostri nodi sono distribuiti in diversi data center dello stesso provider, ogni data center ha il proprio canale, sono indipendenti e, anche se arriva uno split brain, riceveremo comunque avvisi. Sì, ce ne saranno di più, ma è meglio ricevere più avvisi che nessuno.
Concludiamo il nostro elenco con un'implementazione HA.
E inoltre vorrei sottolineare l'esperienza di comunicazione con la comunità VictoriaMetrics. Si è rivelato molto positivo. I ragazzi sono reattivi. Cercano di approfondire ogni caso offerto.
Ho avviato problemi su GitHub. Sono stati risolti molto rapidamente. Ci sono ancora un paio di problemi che non sono completamente risolti, ma posso già vedere dal codice che si sta lavorando in questa direzione.
Il problema principale per me durante le iterazioni era che se spegnevo un nodo, per i primi 30 secondi vminsert non riusciva a capire che non esisteva il backend. Questo ora è stato deciso. E letteralmente in un secondo o due, i dati vengono presi da tutti i nodi rimanenti e la richiesta smette di attendere il nodo mancante.
Ad un certo punto volevamo che VictoriaMetrics diventasse un operatore VictoriaMetrics. Lo abbiamo aspettato. Stiamo ora costruendo attivamente un framework per l'operatore VictoriaMetrics per prendere tutte le regole di precalcolo, ecc. Prometheus, perché stiamo utilizzando abbastanza attivamente le regole fornite con l'operatore Prometheus.
Ci sono proposte per migliorare l'implementazione del cluster. Li ho delineati sopra.
E voglio davvero effettuare un downsampling. Nel nostro caso il downsampling è necessario esclusivamente per visualizzare i trend. In parole povere, una metrica mi basta durante il giorno. Queste tendenze sono necessarie per un anno, tre, cinque, dieci anni. E un valore metrico è abbastanza.
- Abbiamo conosciuto il dolore, così come alcuni dei nostri colleghi, durante l'utilizzo di Prometheus.
- Abbiamo scelto VictoriaMetrics per noi stessi.
- Si ridimensiona abbastanza bene sia verticalmente che orizzontalmente.
- Possiamo distribuire diversi componenti a diversi numeri di nodi nel cluster, limitarli in base alla memoria, aggiungere memoria, ecc.
Utilizzeremo VictoriaMetrics a casa perché ci è piaciuto molto. Questo è ciò che era e ciò che è diventato.
Un paio di codici QR per la chat di VictoriaMetrics, i miei contatti, il radar tecnico di LeroyMerlin.
Fonte: habr.com