Ciao a tutti. Di seguito è fornita la trascrizione .
– un sistema di monitoraggio di vari sistemi e servizi, attraverso il quale gli amministratori di sistema possono raccogliere informazioni sui parametri attuali dei sistemi e configurare avvisi per ricevere notifiche sugli scostamenti nel funzionamento dei sistemi.
Nella presentazione verrà fatto un confronto e — progetti per l'archiviazione a lungo termine delle metriche di Prometheus.
Iniziamo a parlare di Prometheus. È un sistema di monitoraggio che raccoglie metriche da target specificati e le salva in un'archiviazione locale. Prometheus è in grado di registrare le metriche in un'archiviazione remota, di generare alert e regole di registrazione.
Limitazioni di Prometheus:
- Non ha una vista di query globale. Questo accade quando si hanno più istanze indipendenti di Prometheus. Raccolgono metriche e si desidera eseguire una query su tutte queste metriche raccolte da diverse istanze di Prometheus. Prometheus non lo consente.
- Le prestazioni di Prometheus sono limitate a un solo server. Prometheus non può scalare automaticamente su più server. Si può solo suddividere manualmente i propri target tra diversi Prometheus.
- Il volume delle metriche in Prometheus è limitato a un solo server per lo stesso motivo per cui non può scalare automaticamente su più server.
- In Prometheus non è facile organizzare la salvaguardia dei dati.
Soluzioni a queste problematiche?
Le soluzioni sono le seguenti:
Tutte queste soluzioni sono per l'archiviazione remota dei dati raccolti da Prometheus. Risolvono il problema dell'archiviazione remota in modi diversi rispetto alla diapositiva precedente. In questa presentazione parlerò solo delle prime due soluzioni: e .
Per la prima volta le informazioni su sono emerse nel . Qui viene descritta l'architettura e come funziona.
Thanos prende i dati salvati da Prometheus su disco locale e li copia in S3, in o in un altro storage a oggetti.
In questo modo Thanos offre una vista di query globale. È possibile richiedere dati salvati nello storage a oggetti da più istanze di Prometheus.
Thanos supporta PromQL e .
Thanos utilizza il codice di Prometheus per l'archiviazione dei dati.
Thanos è sviluppato dagli stessi sviluppatori di Prometheus.
Su . Ecco , dove abbiamo parlato per la prima volta di .
VictoriaMetrics ottiene i dati da più prometheus tramite protocollo supportato da Prometheus.
VictoriaMetrics offre una vista globale delle query, poiché più istanze di Prometheus possono registrare dati in un'unica VictoriaMetrics. Di conseguenza, puoi effettuare query su tutti questi dati.
VictoriaMetrics supporta anche, come Thanos, PromQL e l'API di query di Prometheus.
A differenza di Thanos, il codice sorgente di VictoriaMetrics è stato scritto da zero ed è ottimizzato per velocità e consumo di risorse.
VictoriaMetrics, a differenza di Thanos, scala sia verticalmente che orizzontalmente. C'è , che scala verticalmente. Puoi iniziare con una CPU e 1 GB di RAM e crescere gradualmente fino a cento CPU e 1 TB di RAM. VictoriaMetrics è in grado di utilizzare tutte queste risorse. Le sue prestazioni aumenteranno di circa 100 volte rispetto a un sistema a singolo core.
La storia di Thanos è iniziata nel novembre 2017, quando è stato effettuato il primo commit pubblico. Prima di ciò, Thanos è stato sviluppato internamente dall'azienda .
Nel giugno 2019 è stata rilasciata la versione 0.5.0, che il protocollo. È stato rimosso da Thanos perché ha mostrato diversi problemi. Spesso il cluster di Thanos non funzionava correttamente, le nodi si collegavano in modo errato a causa del protocollo gossip. Pertanto, è stata presa la decisione di rimuoverlo. Credo che sia stata una scelta corretta.
Nello stesso giugno 2019, hanno presentato la richiesta numero in .
E dopo un paio di mesi Thanos è stato accettato in , che include Prometheus, Kubernetes e altri progetti popolari.
Nel gennaio 2018 è iniziato lo sviluppo di VictoriaMetrics.
Nel settembre 2018 ho menzionato per la prima volta VictoriaMetrics pubblicamente.
Nel dicembre 2018 è stata pubblicata la versione single-node.
Nel maggio 2019 i sorgenti sia della versione single-node che di quella cluster.
Nel giugno 2019, come Thanos, abbiamo presentato una richiesta alla CNCF foundation con il numero . Abbiamo presentato la richiesta un giorno prima di Thanos.
Ma, sfortunatamente, non siamo ancora stati accettati. Abbiamo bisogno dell'aiuto della comunità.
Esaminiamo le diapositive più importanti che mostrano l'architettura di Thanos e VictoriaMetrics.
Iniziamo con Thanos. I componenti gialli sono i componenti di Prometheus. Il resto sono i componenti di Thanos. Partiamo dal componente principale. Thanos Sidecar è un componente che viene installato accanto a ogni Prometheus. Si occupa di caricare i dati di Prometheus dallo storage locale in S3 o in un altro Object Storage.
C'è anche un componente chiamato Thanos Store Gateway, che è in grado di leggere questi dati da Object Storage quando riceve richieste da Thanos Query. Thanos Query implementa PromQL e l'API di Prometheus. Quindi, da fuori, appare come Prometheus. Riceve richieste PromQL, le invia a Thanos Store Gateway, che recupera i dati necessari da Object Storage e li restituisce.
Tuttavia, nel nostro Object Storage vengono conservati dati che non coprono le ultime due ore a causa delle peculiarità dell'implementazione di Thanos Sidecar, che non riesce a caricare le ultime due ore in Object Storage S3, poiché per queste ultime due ore Prometheus non ha ancora creato i file nel suo archivio locale.
Come si può aggirare questo problema? Thanos Query, oltre a inviare richieste a Thanos Store Gateway, invia parallelamente richieste a ogni Thanos Sidecar che si trova vicino a Prometheus.
E Thanos Sidecar, a sua volta, inoltra le richieste a Prometheus e recupera i dati delle ultime due ore.
Oltre a questi componenti, c'è anche un componente opzionale, senza il quale Thanos si comporterebbe male. Questo è Thanos Compact, che si occupa della fusione di piccoli file in Object Storage in file più grandi, che sono stati caricati qui dai Thanos Sidecar. I Thanos Sidecar caricano lì file con i dati delle ultime due ore. Se questi file non vengono fusi in file più grandi, il loro numero può aumentare notevolmente. Maggiore è il numero di questi file, maggiore è la memoria necessaria per Thanos Store Gateway e maggiori sono le risorse necessarie per il trasferimento dei dati attraverso la rete, delle metadata. Il funzionamento di Thanos Store Gateway diventa inefficiente. Pertanto, è essenziale eseguire Thanos Compact, che fonde i piccoli file in file più grandi, per ridurre il numero di questi file e diminuire l'overhead su Thanos Store Gateway.
C'è anche un componente chiamato Thanos Ruler. Esso esegue le regole di allerta di Prometheus e può calcolare le regole di registrazione di Prometheus, per registrare nuovamente i dati in Object Storage. Tuttavia, questo componente non è raccomandato, poiché è .
Ecco uno schema semplice di Thanos.
Ora confrontiamo con lo schema di VictoriaMetrics.
VictoriaMetrics ha 2 versioni: Single-node e una versione cluster. Single-node funziona su un solo computer. Nella versione Single-node non ci sono questi componenti, solo un singolo binario. Questo binario nella diapositiva appare come questo quadrato. Tutto ciò che si trova all'interno del quadrato è il contenuto del file binario per la versione Single-node. Non è necessario sapere di questo. Basta avviare il binario e tutto funziona.
La versione cluster è più complessa. All'interno di essa si trovano tre componenti diverse: vmselect, vminsert e vmstorage. Dalla loro denominazione dovrebbe essere chiaro cosa ciascuno di essi fa. Il componente Insert accetta dati in diversi formati: dall'API Prometheus remote write, dal protocollo Influx line, dal protocollo Graphite e dal protocollo OpenTSDB. Il componente Insert li riceve, li analizza e li distribuisce tra i componenti storage esistenti, dove i dati vengono poi salvati. Il componente Select, a sua volta, accetta query PromQL. Implementa , così come l'API di query di Prometheus, e può essere utilizzato come sostituto di Prometheus in Grafana o in altri client API di Prometheus. Select accetta la query promql, la elabora, legge i dati necessari per eseguire tale query dai nodi storage, li processa e restituisce la risposta.
Confrontiamo la complessità di installazione di Thanos e VictoriaMetrics.
Iniziamo con Thanos. Prima di iniziare a lavorare con Thanos, è necessario creare un bucket nello Storage Object, come S3 o GCS, affinché il Thanos Sidecar possa scrivervi i dati.
Poi, per ogni Prometheus, è necessario installare il Thanos Sidecar. Prima di ciò, non dimenticate di disattivare la compressione dei dati in Prometheus. La compressione dei dati comprime periodicamente i dati nello storage locale di Prometheus per ridurre il consumo di risorse.
Quando installate il Thanos Sidecar ai vostri Prometheus, dovete disattivare questa compressione dei dati, poiché il Thanos Sidecar non può funzionare correttamente con la compressione dei dati attivata. Ciò significa che il vostro Prometheus inizia a salvare i dati in blocchi di due ore e smette di unire questi blocchi in uno più grande. Di conseguenza, se effettuate query che superano la durata delle ultime due ore, non funzioneranno in modo così efficiente rispetto a come potrebbero funzionare se la compressione dei dati fosse stata attivata.
Pertanto, Thanos consiglia di ridurre il periodo di conservazione dei dati nello storage locale a 6-8 ore, per diminuire questo overhead di un gran numero di piccoli blocchi.
Dopo aver installato il Thanos Sidecar, dovete installare due componenti per ogni bucket dello Storage Object. Questi sono Thanos Compactor e Thanos Store Gateway.
Dopo di che, è necessario installare Thanos Query e configurarlo affinché possa collegarsi a tutti i Thanos Store Gateway che avete, così come ai Thanos Sidecar.
Qui potrebbe esserci un piccolo problema.
È necessario configurare una connessione affidabile e sicura da Thanos Query a questi componenti. E se i vostri Prometheus si trovano in diversi data center, o in diverse VPC, allora le connessioni da esterne sono vietate. Ma per far funzionare Thanos Query è necessario trovare un modo per configurare la connessione.
Se avete molti di questi data center, di conseguenza, l'affidabilità dell'intero sistema diminuisce. Poiché Thanos Query deve mantenere costantemente le connessioni a tutti i Thanos Sidecar situati in diversi data center. Ad ogni richiesta in arrivo, invierà richieste a tutti i Thanos Sidecar. Se la connessione si interrompe, si riceverà un set di dati incompleto o la risposta "il cluster non funziona".
In VictoriaMetrics tutto è un po' più semplice. Per la versione Single-node, è sufficiente avviare un singolo binario e tutto funziona.
Nella versione cluster è sufficiente avviare tutti e tre i tipi di componenti sopra menzionati nel numero necessario, oppure utilizzare per automatizzare l'avvio dei componenti in Kubernetes. Stiamo anche pianificando di creare un operatore Kubernetes. Helm chart non copre alcuni casi e permette di farsi del male. Ad esempio, consente di ridurre il numero di storage node, il che porterà alla perdita di dati.
Dopo aver avviato un binario o la versione cluster, è sufficiente aggiungere nel config di Prometheus , affinché inizi a registrare i dati in parallelo nello storage locale e nello storage remoto. Come avrete notato, tale configurazione dovrebbe funzionare in modo molto più affidabile rispetto alla configurazione di Thanos. Non è necessario mantenere una connessione da VictoriaMetrics a tutti i Prometheus, poiché sono i Prometheus stessi a connettersi a VictoriaMetrics e a inviare i dati.
Consideriamo il supporto di Thanos e VictoriaMetrics.
Thanos deve monitorare Sidecar affinché non interrompa il caricamento dei dati in Object Storage. Possono interrompere questo caricamento a causa di errori, ad esempio se la connessione di rete con Object Storage si interrompe temporaneamente o se Object Storage diventa temporaneamente non disponibile. In questo momento, Thanos Sidecar lo noterà, segnalerà un errore, potrebbe bloccarsi e smettere di funzionare. Se non viene monitorato, i dati smetteranno di essere inviati a Object Storage. Se scade il tempo di retention (6-8 ore raccomandato), si perderanno i dati che non sono stati trasferiti in Object Storage.
I compattatori Thanos possono smettere di funzionare a causa di . I compattatori prendono i dati da Object Storage e li uniscono in pezzi di dati più grandi. Poiché i compattatori non sono sincronizzati con i Sidecar, può succedere quanto segue: il Sidecar non ha ancora completato la scrittura di un blocco, il Compattatore decide che questo blocco è completamente scritto. Il Compattatore inizia a leggerlo. Legge il blocco in modo incompleto e smette di funzionare. Vedi dettagli .
Lo Store Gateway può restituire dati inconsistenti a causa di race condition tra il Compattatore e i Sidecar. Qui si verifica la stessa situazione, perché lo Store Gateway non è affatto sincronizzato con i Compattatori e i Sidecar. Di conseguenza, possono sorgere condizioni di competizione, quando lo Store Gateway non vede parte dei dati o vede dati aggiuntivi.
Il componente Query in Thanos restituisce per impostazione predefinita un risultato parziale se alcune Sidecar o lo Store Gateway non sono disponibili in quel momento. Riceverai parte dei dati e nemmeno saprai che non hai ricevuto tutti i dati. Funziona così di default. In una situazione simile, VictoriaMetrics restituisce i dati contrassegnati come parziali.
A differenza di Thanos, VictoriaMetrics perde raramente dati. Anche se la connessione tra Prometheus e VictoriaMetrics si interrompe, non è un problema, poiché Prometheus continua a scrivere i nuovi dati in arrivo nel Write Ahead Log, la cui dimensione è di due ore. Se ripristini la connessione a VictoriaMetrics entro due ore, i dati non andranno persi. Prometheus .
A differenza di Thanos, che registra i dati nello storage oggetto solo dopo due ore, Prometheus replica automaticamente i dati tramite il protocollo remote write nello storage remoto, come VictoriaMetrics. La perdita dello storage locale in Prometheus non è un problema. Se dovesse perdere lo storage locale, nel peggiore dei casi si perderanno solo gli ultimi secondi di dati che non sono stati ancora registrati nello storage remoto.
Kubernetes gestisce automaticamente il cluster, a differenza di Thanos. Tutti i componenti di Thanos sono difficili da collocare in un unico cluster Kubernetes, a differenza dei componenti cluster di VictoriaMetrics.
L'aggiornamento a una nuova versione di VictoriaMetrics è molto semplice. Basta fermare VictoriaMetrics, aggiornare i binari e riavviarlo. Quando si ferma tramite segnale SIGINT, tutti i binari di VictoriaMetrics eseguono un arresto controllato. Essi salvano correttamente i dati necessari, chiudono correttamente le connessioni in ingresso per evitare perdite. Pertanto, non perderai nulla durante l'aggiornamento.
Espandere il cluster di VictoriaMetrics è molto semplice. Basta aggiungere i componenti necessari e continuare a lavorare.
Sui problemi di Thanos e VictoriaMetrics.
Thanos presenta i seguenti problemi. Prometheus deve conservare i dati degli ultimi due ore. Se vengono persi, si perderanno completamente, poiché non sono ancora stati registrati nello storage oggetto, come S3.
Il componente Store Gateway e il componente compattatore possono richiedere molta memoria per lavorare con un grande storage oggetto, se contiene molti piccoli file. Maggiore è il numero e le dimensioni dei file, maggiore è la memoria RAM richiesta da Store Gateway e dal compattatore per memorizzare le metainformazioni. Thanos ha molti problemi relativi a questo. .
Thanos viene pubblicizzato come in grado di scalare all'infinito con il numero dei tuoi Prometheus. In realtà, non è vero. Poiché tutte le richieste passano attraverso il componente Query, che deve interpellare in parallelo tutti i componenti Store Gateway e tutti i componenti Sidecar, estrarre i dati da lì e poi pre-elaborarli. È evidente che la velocità delle richieste è limitata dal collegamento più lento, ovvero il Store Gateway più lento o il Sidecar più lento.
Questi componenti possono essere caricati in modo non uniforme. Ad esempio, hai un Prometheus che raccoglie milioni di metriche al secondo. E c'è un Prometheus in cui vengono raccolte migliaia di metriche al secondo. Prometheus, in cui vengono raccolti milioni di metriche al secondo, carica molto di più il server su cui opera. Di conseguenza, il Sidecar qui funziona più lentamente. E in generale, tutto qui funziona lentamente. E il componente Query estrarrà i dati da lì molto lentamente. Pertanto, le prestazioni dell'intero cluster saranno limitate da questo Sidecar lento.
Per impostazione predefinita, Thanos restituisce dati parziali se alcuni Sidecar e/o Store Gateway non sono disponibili. Ad esempio, se hai Sidecar distribuiti in tutto il mondo in diversi data center, la probabilità di interruzione della connessione e la non disponibilità dei componenti aumenta notevolmente. Pertanto, nella maggior parte dei casi riceverai dati parziali senza nemmeno saperlo.
Anche VictoriaMetrics ha delle insidie. La prima insidia è l'opzione che limita la quantità di memoria RAM utilizzata dalla cache di VictoriaMetrics. Per impostazione predefinita, essa è pari al 60% della memoria RAM sulla macchina in cui è in esecuzione VictoriaMetrics o al 60% della RAM del pod di VictoriaMetrics su Kubernetes.
Se questo valore viene modificato in modo errato, le prestazioni di VictoriaMetrics possono deteriorarsi. Ad esempio, se imposti un valore troppo basso, i dati potrebbero smettere di essere memorizzati nella cache di VictoriaMetrics. Questo comporterebbe un lavoro aggiuntivo e un carico sul processore e sul disco. Se imposti questo valore troppo alto, aumenta, in primo luogo, la probabilità che VictoriaMetrics vada in errore per out of memory, e, in secondo luogo, ciò porterà a una scarsità di memoria RAM riservata per la cache di file nell'operating system. VictoriaMetrics si basa sulla cache di file per le prestazioni. Se non è sufficiente, il carico sul disco può aumentare notevolmente. Pertanto, consiglio: non modificare il parametro senza estrema necessità.
La seconda opzione è retentionPeriod — il periodo, che per impostazione predefinita è impostato a 1 mese. Questo è il tempo durante il quale VictoriaMetrics conserva i dati. Al termine di questo periodo, VictoriaMetrics elimina i dati.
Molti lanciano VictoriaMetrics senza questo parametro, registrando dati per un mese. E poi si chiedono: perché i dati sono scomparsi per il mese precedente? Perché il retentionPeriod per impostazione predefinita è di 1 mese. Quindi è necessario conoscere e impostare il retentionPeriod corretto.
Analizziamo le opportunità uniche.
Thanos ha una funzionalità chiamata downsampling: intervalli di 5 minuti e orari, che spesso . Se si fa una ricerca su Google e si guarda ai loro problemi su GitHub, ci sono molti problemi legati a questo downsampling, che a volte non funziona correttamente o funziona diversamente da come si aspettano gli utenti.
Thanos ha la deduplicazione dei dati per Prometheus HA pairs. Quando due Prometheus raccolgono le stesse metriche dagli stessi target e Thanos le accumula nell'Object Storage. Thanos sa deduplicare correttamente questi dati, a differenza di VictoriaMetrics.
Thanos ha un componente di allerta, che era nello schema di Thanos. Ma non è .
Thanos ha il vantaggio che il codice di Thanos e Prometheus è condiviso. Thanos e Prometheus sono sviluppati dagli stessi sviluppatori. Quando ci sono miglioramenti in Thanos o Prometheus, l'altra parte ne trae vantaggio.
La funzione principale di VictoriaMetrics è MetricsQL. Questo è un'estensione di VictoriaMetrics per PromQL, di cui ho parlato al precedente big monitoring meetup.
VictoriaMetrics supporta l'inserimento dei dati attraverso molti protocolli diversi. VictoriaMetrics non solo può ricevere dati da Prometheus, ma anche dai protocolli Influx, OpenTSDB e Graphite.
I dati di VictoriaMetrics occupano generalmente molto meno spazio rispetto a Thanos e Prometheus.
Se si registrano dati reali, gli utenti parlano di una riduzione da 2 a 5 volte della dimensione dei dati su disco rispetto a Prometheus e Thanos.
Un altro vantaggio di VictoriaMetrics è che è ottimizzata per la velocità.
Esploriamo il costo dell'infrastruttura.
Uno dei vantaggi di Thanos è che salva i dati nell'object storage, che è relativamente economico.
Quando si salvano dati nell'object storage, è necessario pagare per le operazioni di scrittura e lettura dei dati (10$ per milione di operazioni). Quando si scrivono dati nell'object storage, si pagano le spese di hosting per caricare i dati su internet, se il proprio cluster non si trova in AWS — lì è gratis. Quando si leggono dati, si pagano da 10$ a 230$ per 1TB. Questo può essere significativo se si richiedono frequentemente dati storici dal cluster Thanos.
Per il cluster Thanos è necessario pagare i server per i componenti Compact, Store Gateway e Query, che richiedono molta memoria e CPU per gestire grandi volumi di dati.
Per VictoriaMetrics i costi sono i seguenti. Se si archiviano i dati su dischi GCE HDD, si ha un costo di $40 per 1TB. Per VictoriaMetrics sono sufficienti normali dischi HDD, non sono necessari SSD che costano cinque volte di più. VictoriaMetrics è ottimizzata per gli HDD.
Per VictoriaMetrics sono necessari server per i componenti: o Single-node o per componenti cluster, che a differenza dei componenti Thanos, richiedono molto meno CPU e RAM, quindi saranno più economici.
Esempi di implementazione.
Un esempio di implementazione di Thanos è Gitlab. Gitlab funziona interamente su Thanos. Ma non è tutto roseo. Se si guarda ai loro , si possono vedere che hanno continuamente problemi : manca memoria per i componenti Store Gateway o Query. Devono constantemente aumentare la quantità di memoria.
A causa di ciò, aumentano i costi per risolvere questi problemi.
La seconda implementazione, che potrebbe essere più riuscita, è l'azienda Improbable, che ha iniziato lo sviluppo di Thanos. Hanno pubblicato il codice sorgente di Thanos. Improbable è un'azienda che sviluppa motori di gioco.
Esempi pubblici di implementazione di VictoriaMetrics sono:
- wix.com, costruttore di siti web
- Adidas implementa VictoriaMetrics e ha persino fatto una presentazione all'ultimo PromCon 2019
- TrafficStars — rete pubblicitaria
- Seznam.cz — motore di ricerca ceco popolare.
E poi ci sono aziende sconosciute che non posso nominare attualmente. Non hanno dato il consenso.
- Un grande sviluppatore di giochi. Più grande di Improbable.
- Un grande sviluppatore di software grafico.
- Una grande banca russa.
- Un produttore europeo di turbine eoliche che ha testato con successo VictoriaMetrics. Questo produttore implementa VictoriaMetrics per il monitoraggio dei dati ottenuti dalle turbine eoliche con una frequenza di 50 campioni al secondo per ogni sensore. Ogni turbina eolica ha diversi centinaia di sensori. Hanno diverse centinaia di turbine eoliche.
- Le compagnie aeree russe che vogliono implementare VictoriaMetrics, ma non ci riescono. Siamo con loro in fase di contratto.
Conclusioni.
VictoriaMetrics e Thanos affrontano problemi simili, ma in modi diversi:
- Visualizzazione globale delle query
- scalabilità orizzontale
- retention arbitraria
Grazie.
Vi aspettiamo sul nostro .
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Cosa usate come storage a lungo termine per Prometheus?
35,3%Thanos6
0,0%Cortex0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%altro4
Hanno votato 17 utenti. Si sono astenuti 16 utenti.
Fonte: habr.com
