Ciao a tutti. Di seguito la trascrizione. .
– un sistema per il monitoraggio di vari sistemi e servizi, con l'aiuto del quale gli amministratori di sistema possono raccogliere informazioni sui parametri di sistema correnti e impostare avvisi per ricevere notifiche sulle deviazioni nel funzionamento dei sistemi.
Il rapporto conterrà un confronto и — progetti per l'archiviazione a lungo termine delle metriche di Prometheus.
Per prima cosa, vi parlerò di Prometheus. È un sistema di monitoraggio che raccoglie metriche da target specifici e le salva su un archivio locale. Prometheus può registrare le metriche su un archivio remoto e generare avvisi e regole di registrazione.
Limitazioni di Prometheus:
- Non ha una vista di query globale. Questo accade quando si hanno più istanze di Prometheus indipendenti. Queste raccolgono metriche. E si desidera eseguire query su tutte queste metriche raccolte da diverse istanze di Prometheus. Prometheus non lo consente.
- Prometheus è limitato a un singolo server. Prometheus non può scalare automaticamente su più server. Puoi solo suddividere manualmente i tuoi obiettivi tra più Prometheus.
- Il volume delle metriche in Prometheus è limitato a un solo server per lo stesso motivo per cui non può essere ridimensionato automaticamente su più server.
- Prometheus non è un posto facile in cui organizzare la sicurezza dei dati.
Soluzioni a questi problemi/compiti?
Le soluzioni sono:
Tutte queste soluzioni riguardano l'archiviazione remota dei dati raccolti da Prometheus. Risolvono il problema dell'archiviazione remota illustrato nella diapositiva precedente in diversi modi. In questa presentazione, parlerò solo delle prime due soluzioni: и .
Per la prima volta informazioni su apparso su L'architettura è descritta lì. e come funziona.
Thanos prende i dati che Prometeo ha memorizzato sul disco locale e li copia su S3, o in un altro archivio di oggetti.
In questo modo Thanos fornisce una vista di query globale. È possibile interrogare i dati archiviati nell'archiviazione oggetti da più istanze di Prometheus.
Thanos supporta PromQL e .
Thanos utilizza il codice di Prometheus per memorizzare i dati.
Thanos è stato sviluppato dagli stessi sviluppatori di Prometheus.
Про . Ecco , dove abbiamo parlato per la prima volta di .
VictoriaMetrics riceve dati da più Prometeo protocollo supportato da Prometheus.
VictoriaMetrics offre una vista di query globale, poiché più istanze di Prometheus possono scrivere dati su un singolo VictoriaMetrics. Di conseguenza, è possibile eseguire query su tutti questi dati.
VictoriaMetrics supporta anche le API di query di Thanos, PromQL e Prometheus.
A differenza di Thanos, il codice sorgente di VictoriaMetrics è scritto da zero e ottimizzato per la velocità e il consumo di risorse.
VictoriaMetrics, a differenza di Thanos, scala sia verticalmente che orizzontalmente. C'è , che scala verticalmente. È possibile iniziare con un processore e 1 GB di memoria e aumentare gradualmente fino a centinaia di processori e 1 TB di memoria. VictoriaMetrics può utilizzare tutte queste risorse. Le sue prestazioni aumenteranno di circa 100 volte rispetto a un sistema a 1 core.
La storia di Thanos è iniziata nel novembre 2017, quando è apparso il primo commit pubblico. Prima di allora, Thanos era sviluppato internamente. .
Nel giugno 2019 è stata rilasciata la versione 0.5.0, che Protocollo. È stato rimosso da Thanos perché non si mostrava dal suo lato migliore. Il cluster di Thanos spesso non funzionava correttamente, i nodi non si connettevano correttamente a causa del protocollo di gossip. Pertanto, hanno deciso di rimuoverlo da lì. Penso che sia stata la decisione giusta.
Nello stesso giugno 2019 hanno inviato il numero di domanda в .
E dopo un paio di mesi, Thanos è stato accettato , che include Prometheus, Kubernetes e altri progetti popolari.
Lo sviluppo di VictoriaMetrics è iniziato a gennaio 2018.
Nel settembre 2018 ho menzionato pubblicamente per la prima volta VictoriaMetrics.
La versione a nodo singolo è stata pubblicata nel dicembre 2018.
A maggio 2019 fonti sia per le versioni a nodo singolo che per quelle a cluster.
Nel giugno 2019, proprio come Thanos, abbiamo presentato una domanda alla fondazione CNCF con il numero Abbiamo fatto domanda un giorno prima di Thanos.
Ma purtroppo non siamo ancora stati accettati. Abbiamo bisogno dell'aiuto della comunità.
Diamo un'occhiata alle diapositive più importanti che mostrano l'architettura di Thanos e VictoriaMetrics.
Iniziamo con Thanos. I componenti gialli sono componenti di Prometheus. Tutto il resto sono componenti di Thanos. Iniziamo con il componente più importante. Thanos Sidecar è un componente installato accanto a ogni Prometheus. Si occupa di caricare i dati di Prometheus dall'archiviazione locale a S3 o altri Object Storage.
Esiste anche un componente chiamato Thanos Store Gateway, che può leggere questi dati da Object Storage in base alle richieste in arrivo da Thanos Query. Thanos Query implementa PromQL e l'API Prometheus. Dall'esterno, quindi, sembra Prometheus. Accetta le richieste PromQL, le invia a Thanos Store Gateway, che riceve i dati necessari da Object Storage e li restituisce.
Tuttavia, memorizziamo i dati in Object Storage senza le ultime due ore a causa della funzionalità di implementazione di Thanos Sidecar, che non può caricare le ultime due ore su Object Storage S3, poiché Prometheus non ha ancora creato file nell'archiviazione locale per queste due ore.
Come hanno deciso di aggirare questo problema? Thanos Query, oltre alle query al Thanos Store Gateway, invia query parallele a ogni Thanos Sidecar situato accanto 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, ce n'è un altro opzionale, senza il quale Thanos non si sentirebbe a suo agio. Si tratta di Thanos Compact, che unisce i file di piccole dimensioni presenti su Object Storage in file più grandi caricati qui da Thanos Sidecars. Thanos Sidecar carica i file di dati in due ore. Se questi file non vengono uniti in file più grandi, il loro numero può aumentare in modo significativo. Più file di questo tipo sono presenti, maggiore è la memoria necessaria per Thanos Store Gateway, maggiori sono le risorse necessarie per trasferire dati e metadati in rete. Il funzionamento di Thanos Store Gateway diventa inefficiente. Pertanto, è necessario eseguire Thanos Compact, che unisce i file di piccole dimensioni in file più grandi, in modo da ridurre il numero di file di questo tipo e ridurre il sovraccarico su Thanos Store Gateway.
Esiste anche un componente chiamato Thanos Ruler. Esegue le regole di avviso di Prometheus e può calcolare le regole di registrazione di Prometheus per riscrivere i dati su Object Storage. Tuttavia, l'utilizzo di questo componente non è consigliato, perché .
Questo è un piano semplice per Thanos.
Ora confrontiamolo con lo schema VictoriaMetrics.
VictoriaMetrics è disponibile in due versioni: a nodo singolo e a cluster. La versione a nodo singolo funziona su un solo computer. La versione a nodo singolo non ha questi componenti, ma solo un binario. Questo binario ha l'aspetto di questo quadrato nella diapositiva. Tutto ciò che è all'interno del quadrato è il contenuto del file binario per la versione a nodo singolo. Non è necessario conoscerlo. Basta eseguire il binario e tutto funzionerà per noi.
La versione cluster è più complessa. Contiene tre componenti diversi: vmselect, vminsert e vmstorage. I loro nomi dovrebbero chiarire la funzione di ciascuno di essi. Il componente Insert accetta dati in diversi formati: dall'API di scrittura remota di Prometheus, dal protocollo di linea Influx, dal protocollo Graphite e dal protocollo OpenTSDB. Il componente Insert li accetta, li analizza e li distribuisce tra i componenti di storage esistenti, dove i dati sono già 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 altri client API di Prometheus. Select accetta una query promql, la analizza, legge i dati necessari per eseguirla dai nodi di archiviazione, elabora questi dati e restituisce una risposta.
Confrontiamo la complessità dell'installazione di Thanos e VictoriaMetrics.
Iniziamo con Thanos. Prima di poter iniziare a lavorare con Thanos, è necessario creare un bucket in Object Storage come S3 o GCS in modo che Thanos Sidecar possa scrivervi i dati.
Quindi, per ogni Prometheus, è necessario installare Thanos Sidecar. Prima di farlo, ricordatevi di disabilitare la compattazione dei dati in Prometheus. La compattazione dei dati comprime periodicamente i dati nell'archivio locale di Prometheus per ridurre il consumo di risorse.
Quando installi Thanos Sidecar su Prometheus, dovresti disattivare la compattazione dei dati, perché Thanos Sidecar non funziona bene con la compattazione dei dati abilitata. Ciò significa che Prometheus inizia a memorizzare i dati in blocchi di due ore e smette di unirli in blocchi più grandi. Di conseguenza, se esegui query che superano la durata delle ultime due ore, non funzioneranno in modo efficiente come potrebbero fare se la compattazione dei dati fosse abilitata.
Pertanto, Thanos consiglia di ridurre il tempo di conservazione dei dati nell'archiviazione locale a 6-8 ore per ridurre il sovraccarico di un gran numero di piccoli blocchi.
Una volta installato Thanos Sidecar, è necessario installare due componenti per ogni Object Storage Bucket: Thanos Compactor e Thanos Store Gateway.
Dopodiché, devi installare Thanos Query e configurarlo in modo che possa connettersi a tutti i Thanos Store Gateway in tuo possesso e anche a tutti i Thanos Sidecar.
Potrebbe esserci un piccolo problema.
È necessario impostare una connessione affidabile e sicura tra Thanos Query e questi componenti. E se i tuoi Prometheus si trovano in data center diversi o in VPC diverse, le connessioni dall'esterno sono vietate. Ma affinché Thanos Query funzioni, devi in qualche modo impostare una connessione lì, e devi trovare un modo.
Se si dispone di molti di questi data center, l'affidabilità dell'intero sistema diminuisce di conseguenza. Poiché Thanos Query deve mantenere costantemente le connessioni a tutti i Thanos Sidecar situati nei diversi data center, con ogni richiesta in arrivo, invierà richieste a tutti i Thanos Sidecar. Se la connessione viene interrotta, si riceverà un set di dati incompleto o la risposta "cluster non funzionante".
In VictoriaMetrics tutto è un po' più semplice. Per la versione a nodo singolo è sufficiente eseguire un solo binario e tutto funziona.
Nella versione cluster, è sufficiente eseguire tutti e tre i tipi di componenti sopra menzionati nella quantità necessaria oppure utilizzare Per automatizzare l'avvio dei componenti in Kubernetes. Stiamo ancora pianificando di creare un operatore Kubernetes. Il grafico Helm non copre alcuni casi e potrebbe rivelarsi un errore. Ad esempio, consente di ridurre il numero di nodi di storage, con conseguente perdita di dati.
Una volta che hai una singola versione binaria o cluster attiva e funzionante, devi solo aggiungere Prometheus alla tua configurazione. , in modo che inizi a scrivere dati in parallelo sullo storage locale e su quello remoto. Come avrete notato, una configurazione di questo tipo dovrebbe funzionare in modo molto più affidabile rispetto alla configurazione Thanos. Non è necessario mantenere una connessione da VictoriaMetrics a tutti i Prometheus, perché i Prometheus stessi si connettono a VictoriaMetrics e trasferiscono i dati.
Diamo un'occhiata al supporto di Thanos e VictoriaMetrics.
Con Thanos, è necessario monitorare Sidecar in modo che non interrompa il caricamento dei dati su Object Storage. Il caricamento dei dati potrebbe interrompersi a causa di errori di caricamento, ad esempio se la connessione di rete a Object Storage viene interrotta temporaneamente o se Object Storage non è temporaneamente disponibile. A questo punto, Sidecar di Thanos se ne accorgerà, segnalerà un errore, potrebbe bloccarsi e quindi smettere di funzionare. Se non lo monitori, il trasferimento dei dati su Object Storage verrà interrotto. Se il tempo di conservazione (consigliato 6-8 ore) scade, i dati che non sono arrivati su Object Storage andranno persi.
I compattatori Thanos potrebbero smettere di funzionare a causa di I compattatori prendono i dati dall'Object Storage e li uniscono in blocchi di dati più grandi. Poiché i compattatori non sono sincronizzati con Sidecar, può verificarsi quanto segue: Sidecar non è ancora riuscito a scrivere un blocco, il compattatore decide che questo blocco è completamente scritto. Il compattatore inizia a leggerlo. La lettura del blocco è incompleta e smette di funzionare. Vedi dettagli .
Store Gateway potrebbe restituire dati incoerenti a causa di conflitti tra Compactor e Sidecar. Lo stesso accade qui, perché Store Gateway non è sincronizzato con Compactor e Sidecar. Di conseguenza, potrebbero verificarsi condizioni di conflitto quando Store Gateway non vede parte dei dati o vede dati non necessari.
Il componente Query di Thanos restituisce risultati parziali per impostazione predefinita se alcuni Sidecar o Store Gateway non sono disponibili al momento. Otterrai una parte dei dati e il componente non saprà nemmeno di non averli ricevuti tutti. Questo è il funzionamento predefinito. In una situazione simile, VictoriaMetrics restituisce i dati contrassegnati come parziali.
A differenza di Thanos, VictoriaMetrics perde raramente dati. Anche se la connessione da Prometheus a VictoriaMetrics viene interrotta, non rappresenta un problema, poiché Prometheus continua a scrivere i nuovi dati in arrivo nel Write Ahead Log, la cui dimensione è di 2 ore. Se si ripristina la connessione a VictoriaMetrics entro due ore, i dati non andranno persi. Prometheus .
A differenza di Thanos, che scrive i dati sullo storage degli oggetti solo dopo due ore, Prometheus replica automaticamente i dati tramite il protocollo di scrittura remota su storage remoti, come VictoriaMetrics. Con Prometheus non si teme di perdere lo storage locale. Se improvvisamente perde lo storage locale, nel peggiore dei casi si perderanno gli ultimi secondi di dati che non hanno avuto il tempo di essere scritti sullo storage remoto.
Kubernetes gestisce automaticamente il cluster, a differenza di Thanos. È difficile collocare tutti i componenti di Thanos in un unico cluster Kubernetes, a differenza dei componenti del cluster VictoriaMetrics.
VictoriaMetrics ha un aggiornamento molto semplice alla nuova versione. Basta arrestare VictoriaMetrics, aggiornare i binari e riavviare. Quando arrestati tramite segnale SIGINT, tutti i binari di VictoriaMetrics eseguono un arresto regolare. Salvano correttamente i dati necessari e chiudono correttamente le connessioni in entrata per non perdere nulla. Pertanto, non si perderà nulla durante l'aggiornamento.
VictoriaMetrics semplifica l'espansione del tuo cluster. Basta aggiungere i componenti necessari e continuare a lavorare.
Sulle insidie di Thanos e VictoriaMetrics.
Thanos presenta le seguenti insidie. Prometeo deve archiviare le ultime due ore di dati. Se vengono persi, vengono persi completamente, poiché non sono ancora stati scritti su Object Storage come S3.
Il componente Store Gateway e il componente Compactor potrebbero richiedere molta memoria per funzionare con un Object Storage di grandi dimensioni se sono presenti molti file di piccole dimensioni. Maggiore è il numero e la dimensione dei file, maggiore è la RAM richiesta da Store Gateway e Compactor per archiviare i metadati. Thanos presenta molti problemi relativi al fatto che .
Thanos viene pubblicizzato come in grado di scalare all'infinito, fino al numero di Prometheus. In realtà, questo non è vero. Poiché tutte le richieste passano attraverso il componente Query, che deve interrogare in parallelo tutti i componenti Store Gateway e Sidecar, estrarre i dati da lì e quindi preelaborarli. Ovviamente, la velocità di query è limitata dal punto debole più lento, dallo Store Gateway più lento o dal Sidecar più lento.
Questi componenti potrebbero essere caricati in modo non uniforme. Ad esempio, Prometheus raccoglie milioni di metriche al secondo. E Prometheus ne raccoglie migliaia. Prometheus, che raccoglie milioni di metriche al secondo, carica il server su cui gira molto più pesantemente. Di conseguenza, Sidecar funziona più lentamente. E tutto funziona lentamente. E il componente Query estrarrà i dati da lì molto lentamente. Di conseguenza, le prestazioni dell'intero cluster saranno limitate da questa lentezza di Sidecar.
Per impostazione predefinita, Thanos restituisce dati parziali se alcuni Sidecar e/o Store Gateway non sono disponibili. Ad esempio, se i Sidecar sono sparsi in diversi data center in tutto il mondo, la probabilità di errore di connessione e di indisponibilità dei componenti aumenta significativamente. Di conseguenza, nella maggior parte dei casi, si riceveranno dati parziali senza nemmeno saperlo.
VictoriaMetrics presenta le sue insidie. La prima è l'opzione che limita la quantità di RAM utilizzata per la cache di VictoriaMetrics. Per impostazione predefinita, è pari al 60% della RAM della macchina su cui è in esecuzione VictoriaMetrics o al 60% della RAM del pod VictoriaMetrics in Kubernetes.
Se si modifica questo valore in modo errato, si possono compromettere le prestazioni di VictoriaMetrics. Ad esempio, se si imposta un valore troppo basso, i dati potrebbero non essere più contenuti nella cache di VictoriaMetrics. Di conseguenza, VictoriaMetrics dovrà eseguire un lavoro extra e caricare il processore e il disco. Se si imposta un valore troppo alto, aumenta, in primo luogo, la probabilità che VictoriaMetrics si arresti in modo anomalo con un errore di memoria insufficiente e, in secondo luogo, il sistema operativo avrà pochissima RAM per la cache dei file. VictoriaMetrics si basa sulla cache dei file per le prestazioni. Se non è sufficiente, il carico del disco potrebbe aumentare significativamente. Pertanto, il consiglio è: non modificare questo parametro a meno che non sia assolutamente necessario.
La seconda opzione è retentionPeriod, un periodo di tempo impostato di default su 1 mese. Questo è il periodo di tempo durante il quale VictoriaMetrics archivia i dati. Trascorso questo periodo, VictoriaMetrics li elimina.
Molti utenti avviano VictoriaMetrics senza questo parametro, registrano i dati di un mese e poi si chiedono: perché i dati del mese precedente sono scomparsi? Perché il retentionPeriod è impostato di default su 1 mese. Pertanto, è necessario conoscere e impostare il retentionPeriod corretto.
Passiamo in rassegna le caratteristiche uniche.
Thanos ha una caratteristica chiamata downsampling: intervalli di 5 minuti e orari, che sono spesso Se fai una ricerca su Google e dai un'occhiata al loro problema su GitHub, ci sono molti problemi legati a questo downsampling, che a volte non funziona correttamente o non funziona come gli utenti si aspettano.
Thanos dispone della deduplicazione dei dati per le coppie HA di Prometheus. Quando due Prometheus raccolgono le stesse metriche dagli stessi target e Thanos le memorizza nell'Object Storage, Thanos può deduplicare correttamente questi dati, a differenza di VictoriaMetrics.
Thanos ha un componente di allerta che era sullo schema di Thanos. Ma è .
Thanos ha il vantaggio di condividere lo stesso codice con Prometheus. Thanos e Prometheus sono sviluppati dagli stessi sviluppatori. Quando uno dei due migliora, la squadra avversaria vince.
La funzionalità principale di VictoriaMetrics è MetricsQL. Si tratta di estensioni di VictoriaMetrics per PromQL, di cui ho parlato al precedente grande incontro di monitoraggio.
VictoriaMetrics supporta l'iniezione di dati tramite numerosi protocolli diversi. VictoriaMetrics può ricevere dati non solo da Prometheus, ma anche tramite i protocolli Influx, OpenTSDB e Graphite.
I dati di VictoriaMetrics occupano in genere molto meno spazio rispetto a Thanos e Prometheus.
Durante la registrazione di dati reali, gli utenti segnalano una riduzione da 2 a 5 volte delle dimensioni dei dati su disco rispetto a Prometheus e Thanos.
Un altro vantaggio di VictoriaMetrics è che è ottimizzato per la velocità.
Passiamo ora ai costi delle infrastrutture.
Uno dei vantaggi di Thanos è che memorizza i dati in un archivio di oggetti, il che è relativamente economico.
Quando si archiviano dati in un archivio a oggetti, è necessario pagare per le operazioni di scrittura e lettura dei dati (10 dollari per milione di operazioni). Quando si scrivono dati in un archivio a oggetti, si pagano i costi di hosting per il caricamento dei dati su Internet, a meno che il cluster non si trovi in AWS, dove è gratuito. Quando si leggono dati, si pagano da 10 a 230 dollari per 1 TB. Questo può essere significativo se si richiedono frequentemente dati storici dal cluster Thanos.
Per il cluster Thanos è necessario pagare per i server per i componenti Compact, Store Gateway e Query che richiedono molta memoria e CPU per grandi quantità di dati.
VictoriaMetrics ha i seguenti costi. Se si archiviano i dati su dischi HDD GCE, il costo è di 40 dollari per 1 TB. Per VictoriaMetrics, i normali dischi HDD sono sufficienti, non sono necessari SSD, che sono cinque volte più costosi. VictoriaMetrics è ottimizzata per gli HDD.
VictoriaMetrics necessita di server per i componenti: sia per i componenti a nodo singolo che per quelli a cluster, che, a differenza dei componenti Thanos, richiedono molta meno CPU e RAM e saranno quindi più economici.
Esempi di implementazione.
Thanos ha un esempio di implementazione: Gitlab. Gitlab gira interamente su Thanos. Ma non tutto è così fluido lì. Se guardate il loro , allora puoi vedere che hanno costantemente una sorta di : Non c'è abbastanza memoria per i componenti Store Gateway o Query. Devono aumentare costantemente la quantità di memoria.
Ciò aumenta i costi per risolvere questi problemi.
La seconda implementazione, che potrebbe avere più successo, è Improbable, che ha iniziato a sviluppare Thanos e ne ha pubblicato il codice sorgente. Improbable è un'azienda che sviluppa motori di gioco.
Esempi pubblici di implementazione di VictoriaMetrics sono:
- costruttore di siti web wix.com
- Adidas sta lanciando VictoriaMetrics e ha persino tenuto un discorso all'ultimo PromCon 2019
- TrafficStars — rete pubblicitaria
- Seznam.cz è un popolare motore di ricerca ceco.
E poi sono arrivate le aziende senza nome, di cui ora non posso fare i nomi. Non hanno dato il loro consenso.
- Uno dei principali sviluppatori di videogiochi. Più grande dell'improbabile.
- Un importante sviluppatore di software di grafica.
- Una grande banca russa.
- Un produttore europeo di turbine eoliche che ha testato con successo VictoriaMetrics. Questo produttore sta implementando VictoriaMetrics per monitorare i dati delle turbine eoliche a una velocità di 50 campioni al secondo per sensore. Ogni turbina eolica ha diverse centinaia di sensori. Hanno diverse centinaia di turbine eoliche.
- Compagnie aeree russe che vogliono implementare VictoriaMetrics, ma non ci riescono ancora. Siamo nella fase di accordo con loro.
Conclusioni.
VictoriaMetrics e Thanos risolvono problemi simili, ma in modi diversi:
- Visualizzazione query globale
- ridimensionamento orizzontale
- conservazione arbitraria
Grazie.
Vi aspettiamo sul nostro .
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Cosa usi come archivio a lungo termine per Prometheus?
35,3%Thanos6
0,0%Corteccia0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%altro4
17 utenti hanno votato. 16 utenti si sono astenuti.
Fonte: habr.com
