La traduzione dell'articolo è stata preparata appositamente per gli studenti del corso .
è uno sviluppatore di software, un fanatico di Go e un risolutore di problemi. È anche manutentore di Prometheus e co-fondatore della strumentazione SIG Kubernetes. In passato, è stato ingegnere di produzione presso SoundCloud e ha guidato il team di monitoraggio presso CoreOS. Attualmente lavora presso Google.
- Ingegnere delle infrastrutture presso Improbable. È interessato alle nuove tecnologie e ai problemi dei sistemi distribuiti. Ha esperienza di programmazione di basso livello presso Intel, esperienza come collaboratore presso Mesos ed esperienza di produzione SRE di livello mondiale presso Improbable. Dedicato a migliorare il mondo dei microservizi. I suoi tre amori: Golang, open source e pallavolo.
Osservando il nostro prodotto di punta SpatialOS, puoi immaginare che Improbable richieda un'infrastruttura cloud altamente dinamica e su scala globale con dozzine di cluster Kubernetes. Siamo stati tra i primi a utilizzare un sistema di monitoraggio . Prometheus è in grado di monitorare milioni di parametri in tempo reale e viene fornito con un potente linguaggio di query che ti consente di estrarre le informazioni di cui hai bisogno.
La semplicità e l'affidabilità di Prometheus sono uno dei suoi principali vantaggi. Tuttavia, una volta superata una certa scala, abbiamo riscontrato diversi inconvenienti. Per risolvere questi problemi abbiamo sviluppato è un progetto open source creato da Improbable per trasformare senza soluzione di continuità i cluster Prometheus esistenti in un unico sistema di monitoraggio con archiviazione illimitata di dati storici. Thanos è disponibile su Github .
I nostri obiettivi con Thanos
Su una certa scala, sorgono problemi che vanno oltre le capacità di Vanilla Prometheus. Come archiviare in modo affidabile ed economico petabyte di dati storici? È possibile farlo senza compromettere i tempi di risposta? È possibile accedere a tutte le metriche situate su diversi server Prometheus con un'unica richiesta API? Esiste un modo per combinare i dati replicati raccolti utilizzando Prometheus HA?
Per affrontare questi problemi, abbiamo creato Thanos. Le sezioni seguenti descrivono il modo in cui abbiamo affrontato questi problemi e spiegano i nostri obiettivi.
Interrogazione di dati da più istanze di Prometheus (query globale)
Prometheus offre un approccio funzionale allo sharding. Anche un singolo server Prometheus fornisce una scalabilità sufficiente per liberare gli utenti dalle complessità dello sharding orizzontale in quasi tutti i casi d'uso.
Sebbene si tratti di un ottimo modello di distribuzione, spesso è necessario accedere ai dati su diversi server Prometheus tramite un'unica API o interfaccia utente: una visione globale. Naturalmente è possibile visualizzare più query in un pannello Grafana, ma ciascuna query può essere eseguita solo su un server Prometheus. D'altra parte, con Thanos puoi interrogare e aggregare dati da più server Prometheus poiché sono tutti accessibili da un unico endpoint.
In precedenza, per ottenere una visione globale in Improbable, organizzavamo le nostre istanze Prometheus in un sistema multi-livello . Ciò significava creare un meta server Prometheus che raccogliesse alcuni parametri da ciascun server foglia.
Questo approccio si è rivelato problematico. Ciò ha comportato configurazioni più complesse, l'aggiunta di un ulteriore potenziale punto di errore e l'applicazione di regole complesse per garantire che l'endpoint federato riceva solo i dati di cui ha bisogno. Inoltre, questo tipo di federazione non consente di avere una vera visione globale, poiché non tutti i dati sono disponibili da una singola richiesta API.
Strettamente correlata a questa è una visione unificata dei dati raccolti sui server Prometheus ad alta disponibilità (HA). Il modello HA di Prometheus raccoglie i dati in modo indipendente due volte, il che è così semplice che non potrebbe essere più semplice. Tuttavia, sarebbe molto più conveniente utilizzare una vista combinata e deduplicata di entrambi i flussi.
Naturalmente, sono necessari server Prometheus altamente disponibili. Noi di Improbable prendiamo molto sul serio il monitoraggio dei dati minuto per minuto, ma avere un'istanza di Prometheus per cluster è un singolo punto di errore. Qualsiasi errore di configurazione o guasto hardware può potenzialmente portare alla perdita di dati importanti. Anche una semplice distribuzione può causare piccole interruzioni nella raccolta dei parametri perché i riavvii possono essere significativamente più lunghi dell'intervallo di scraping.
Archiviazione affidabile dei dati storici
L'archiviazione delle metriche economica, veloce e a lungo termine è il nostro sogno (condiviso dalla maggior parte degli utenti di Prometheus). In Improbabile, siamo stati costretti a configurare il periodo di conservazione delle metriche su nove giorni (per Prometheus 1.8). Ciò aggiunge evidenti limiti a quanto lontano possiamo guardare.
Prometheus 2.0 è migliorato in questo senso, poiché il numero di serie temporali non influisce più sulle prestazioni complessive del server (vedi. ). Tuttavia, Prometheus memorizza i dati sul disco locale. Sebbene la compressione dei dati ad alta efficienza possa ridurre significativamente l'utilizzo dell'SSD locale, in definitiva esiste ancora un limite alla quantità di dati storici che possono essere archiviati.
Inoltre, a Improbable ci preoccupiamo dell'affidabilità, della semplicità e dei costi. I dischi locali di grandi dimensioni sono più difficili da utilizzare e da sottoporre a backup. Costano di più e richiedono più strumenti di backup, con conseguente complessità inutile.
Downsampling
Una volta che abbiamo iniziato a lavorare con i dati storici, ci siamo resi conto che esistono difficoltà fondamentali con il big-O che rendono le query sempre più lente mentre lavoriamo con settimane, mesi e anni di dati.
La soluzione standard a questo problema sarebbe (downsampling) - riduzione della frequenza di campionamento del segnale. Con il downsampling, possiamo “ridimensionarci” su un intervallo di tempo più ampio e mantenere lo stesso numero di campioni, mantenendo le query reattive.
Il downsampling dei vecchi dati è un requisito inevitabile di qualsiasi soluzione di archiviazione a lungo termine e va oltre l'ambito di Prometheus vanilla.
Obiettivi aggiuntivi
Uno degli obiettivi originali del progetto Thanos era quello di integrarsi perfettamente con qualsiasi installazione Prometheus esistente. Il secondo obiettivo era la facilità d'uso con barriere all'ingresso minime. Eventuali dipendenze dovrebbero essere facilmente soddisfatte sia per gli utenti piccoli che per quelli grandi, il che significa anche un costo base basso.
Architettura di Thanos
Dopo aver elencato i nostri obiettivi nella sezione precedente, esaminiamoli e vediamo come Thanos risolve questi problemi.
Visione globale
Per ottenere una visione globale delle istanze Prometheus esistenti, dobbiamo collegare un singolo punto di ingresso della richiesta a tutti i server. Questo è esattamente ciò che fa il componente Thanos. . Viene distribuito accanto a ciascun server Prometheus e funge da proxy, servendo i dati Prometheus locali tramite l'API gRPC Store, consentendo il recupero dei dati delle serie temporali in base al tag e all'intervallo di tempo.
Dall'altro lato c'è il componente Querier scale-out e stateless, che non fa altro che rispondere semplicemente alle query PromQL tramite l'API HTTP Prometheus standard. Querier, Sidecar e altri componenti Thanos comunicano tramite .
- Querier, dopo aver ricevuto una richiesta, si connette al corrispondente server API dello Store, ovvero ai nostri Sidecar e riceve i dati delle serie temporali dai corrispondenti server Prometheus.
- Successivamente, combina le risposte ed esegue una query PromQL su di esse. Querier può unire sia dati disgiunti che dati duplicati dai server Prometheus HA.
Ciò risolve un pezzo importante del nostro puzzle: combinare i dati provenienti da server Prometheus isolati in un'unica visualizzazione. Infatti Thanos può essere utilizzato solo per questa funzione. Non è necessario apportare modifiche ai server Prometheus esistenti!
Durata di conservazione illimitata!
Tuttavia, prima o poi vorremo archiviare i dati oltre il normale tempo di conservazione di Prometheus. Abbiamo scelto l'archiviazione di oggetti per archiviare dati storici. È ampiamente disponibile in qualsiasi cloud e nei data center locali ed è molto conveniente. Inoltre, quasi tutti gli oggetti di storage sono disponibili tramite la nota API S3.
Prometheus scrive i dati dalla RAM al disco circa ogni due ore. Il blocco dati memorizzato contiene tutti i dati per un periodo di tempo fisso ed è immutabile. Questo è molto comodo perché Thanos Sidecar può semplicemente guardare la directory dei dati di Prometheus e, non appena diventano disponibili nuovi blocchi, caricarli nei bucket di archiviazione degli oggetti.
Il caricamento nell'archivio oggetti immediatamente dopo la scrittura su disco consente inoltre di mantenere la semplicità dello scraper (Prometheus e Thanos Sidecar). Ciò semplifica il supporto, i costi e la progettazione del sistema.
Come puoi vedere, il backup dei dati è molto semplice. Ma che dire dell'interrogazione dei dati nell'object storage?
Il componente Thanos Store funge da proxy per recuperare i dati dall'archiviazione degli oggetti. Come Thanos Sidecar, partecipa al cluster di gossip e implementa l'API Store. In questo modo, il Querier esistente può trattarlo come un Sidecar, come un'altra fonte di dati di serie temporali, senza alcuna configurazione speciale richiesta.
I blocchi di dati delle serie temporali sono costituiti da diversi file di grandi dimensioni. Caricarli su richiesta sarebbe piuttosto inefficiente e memorizzarli nella cache locale richiederebbe un'enorme quantità di memoria e spazio su disco.
Store Gateway sa invece come gestire il formato di archiviazione Prometheus. Grazie a un pianificatore di query intelligente e alla memorizzazione nella cache solo delle parti di indice necessarie dei blocchi, è possibile ridurre le query complesse a un numero minimo di richieste HTTP per i file di archiviazione degli oggetti. In questo modo è possibile ridurre il numero di richieste da quattro a sei ordini di grandezza e ottenere tempi di risposta generalmente difficilmente distinguibili dalle richieste ai dati su un SSD locale.
Come mostrato nel diagramma sopra, Thanos Querier riduce significativamente il costo per query dei dati di archiviazione degli oggetti sfruttando il formato di archiviazione Prometheus e affiancando i dati correlati. Utilizzando questo approccio, possiamo combinare molte richieste singole in un numero minimo di operazioni collettive.
Compattazione e downsampling
Una volta caricato correttamente un nuovo blocco di dati di serie temporali nell'object storage, lo trattiamo come dati "storici", immediatamente disponibili tramite Store Gateway.
Tuttavia, dopo un po' di tempo, i blocchi provenienti da una fonte (Prometheus con Sidecar) si accumulano e non sfruttano più l'intero potenziale di indicizzazione. Per risolvere questo problema, abbiamo introdotto un altro componente chiamato Compactor. Applica semplicemente il motore di compattazione locale di Prometheus ai dati storici nell'archiviazione degli oggetti e può essere eseguito come un semplice lavoro batch periodico.
Grazie all'efficiente compressione, interrogare la memoria per un lungo periodo di tempo non rappresenta un problema in termini di dimensione dei dati. Tuttavia, il costo potenziale derivante dalla decompressione di un miliardo di valori e dalla loro esecuzione tramite un processore di query comporterà inevitabilmente un notevole aumento del tempo di esecuzione delle query. D'altra parte, poiché sullo schermo sono presenti centinaia di punti dati per pixel, diventa impossibile persino visualizzare i dati alla massima risoluzione. Pertanto, il downsampling non solo è possibile, ma non comporta nemmeno una notevole perdita di precisione.
Per eseguire il downsampling dei dati, Compactor aggrega continuamente i dati con una risoluzione di cinque minuti e un'ora. Per ogni blocco grezzo codificato utilizzando la compressione TSDB XOR, vengono archiviati diversi tipi di dati aggregati, come minimo, massimo o somma per un blocco. Ciò consente a Querier di selezionare automaticamente un aggregato appropriato per una determinata query PromQL.
Non è richiesta alcuna configurazione speciale affinché l'utente possa utilizzare dati a precisione ridotta. Querier passa automaticamente tra diverse risoluzioni e dati grezzi mentre l'utente ingrandisce e rimpicciolisce. Se lo desidera, l'utente può controllarlo direttamente tramite il parametro “step” nella richiesta.
Poiché il costo di archiviazione di un GB è basso, per impostazione predefinita Thanos archivia dati grezzi, dati con risoluzione di cinque minuti e un'ora. Non è necessario eliminare i dati originali.
Regole di registrazione
Anche con Thanos, le regole di registrazione sono una parte essenziale dello stack di monitoraggio. Riducono la complessità, la latenza e il costo delle query. Sono inoltre utili per gli utenti per ottenere dati aggregati in base a metriche. Thanos è basato su istanze Prometheus vanilla, quindi è perfettamente accettabile archiviare regole di registrazione e regole di avviso su un server Prometheus esistente. Tuttavia, in alcuni casi ciò potrebbe non essere sufficiente:
- Avviso e regola globale (ad esempio, un avviso quando un servizio non funziona su più di due cluster su tre).
- Regola per i dati esterni all'archiviazione locale.
- Il desiderio di archiviare tutte le regole e gli avvisi in un unico posto.
Per tutti questi casi, Thanos include un componente separato chiamato Ruler, che calcola regole e avvisi tramite Thanos Queries. Fornendo una StoreAPI nota, il nodo Query può accedere ai parametri appena calcolati. Successivamente vengono anche archiviati nell'object storage e resi disponibili tramite Store Gateway.
Il potere di Thanos
Thanos è abbastanza flessibile da poter essere personalizzato in base alle tue esigenze. Ciò è particolarmente utile quando si migra dal semplice Prometeo. Ricapitoliamo rapidamente ciò che abbiamo imparato sui componenti di Thanos con un rapido esempio. Ecco come portare il tuo Prometheus vanilla nel mondo dello “storage illimitato di parametri”:
- Aggiungi Thanos Sidecar ai tuoi server Prometheus, ad esempio un contenitore sidecar in un pod Kubernetes.
- Distribuisci più repliche di Thanos Querier per poter visualizzare i dati. In questa fase è facile creare pettegolezzi tra Scraper e Querier. Per verificare l'interazione dei componenti, utilizzare la metrica "thanos_cluster_members".
Sono sufficienti solo questi due passaggi per fornire una visione globale e una deduplicazione continua dei dati da potenziali repliche Prometheus HA! Collega semplicemente le tue dashboard all'endpoint HTTP Querier o utilizza direttamente l'interfaccia utente di Thanos.
Tuttavia, se hai bisogno del backup delle metriche e dell'archiviazione a lungo termine, dovrai completare altri tre passaggi:
- Crea un bucket AWS S3 o GCS. Configura Sidecar per copiare i dati in questi bucket. L'archiviazione dei dati locali ora può essere ridotta al minimo.
- Distribuisci Store Gateway e collegalo al tuo cluster di gossip esistente. Ora puoi interrogare i dati di cui è stato eseguito il backup!
- Distribuisci Compactor per migliorare l'efficienza delle query per lunghi periodi di tempo utilizzando la compattazione e il downsampling.
Se vuoi saperne di più non esitare a dare un'occhiata al ns и !
In soli cinque passaggi, abbiamo trasformato Prometheus in un sistema di monitoraggio affidabile con visione globale, tempo di archiviazione illimitato e potenziale elevata disponibilità dei parametri.
Pull request: abbiamo bisogno di te!
è stato un progetto open source fin dall'inizio. La perfetta integrazione con Prometheus e la possibilità di utilizzare solo una parte di Thanos lo rendono una scelta eccellente per ridimensionare senza sforzo il tuo sistema di monitoraggio.
Accogliamo sempre con favore richieste e problemi pull di GitHub. Nel frattempo, non esitate a contattarci tramite Github Issues o Slackse hai domande o feedback o vuoi condividere la tua esperienza nell'utilizzo! Se ti piace quello che facciamo a Improbable, non esitare a contattarci - !
Fonte: habr.com