La traduzione dell'articolo è stata preparata appositamente per gli studenti del corso .
— sviluppatore software, appassionato di Go e amante delle sfide complesse. È anche maintainer di Prometheus e co-fondatore di Kubernetes SIG instrumentation. In precedenza ha lavorato come ingegnere di produzione in SoundCloud e ha guidato il team di monitoraggio in CoreOS. Attualmente lavora in Google.
— ingegnere delle infrastrutture in Improbable. È appassionato di nuove tecnologie e delle sfide nei sistemi distribuiti. Ha esperienza nella programmazione a basso livello in Intel, esperienza come contributore in Mesos e un'esperienza SRE di livello mondiale in Improbable. Si dedica a migliorare il mondo dei microservizi. Le sue tre passioni: Golang, open source e pallavolo.
Guardando il nostro prodotto di punta SpatialOS, puoi immaginare che Improbable necessiti di un'infrastruttura cloud altamente dinamica su scala globale con decine di cluster Kubernetes. Siamo stati tra i primi a utilizzare il sistema di monitoraggio . Prometheus è in grado di monitorare milioni di metriche in tempo reale e viene fornito con un potente linguaggio di query che consente di estrarre le informazioni necessarie.
La semplicità e l'affidabilità di Prometheus sono alcuni dei suoi principali vantaggi. Tuttavia, superato un certo limite, ci siamo imbattuti in alcuni svantaggi. Per affrontare questi problemi abbiamo sviluppato — un progetto open source creato da Improbable, per trasformare senza soluzione di continuità i cluster esistenti di Prometheus in un sistema di monitoraggio unificato con archiviazione illimitata dei dati storici. Thanos è disponibile su Github .
I nostri obiettivi con Thanos
Con un certo livello di scala, emergono problemi che vanno oltre le capacità di un Prometheus standard. Come possiamo archiviare in modo sicuro ed economico petabyte di dati storici? È possibile farlo senza compromettere il tempo di risposta alle query? Possiamo accedere a tutte le metriche situate su server Prometheus diversi con una sola richiesta API? È possibile in qualche modo combinare i dati replicati raccolti tramite Prometheus HA?
Per affrontare queste questioni, abbiamo creato Thanos. Nelle sezioni seguenti descriviamo come abbiamo affrontato tali sfide e spieghiamo gli obiettivi che ci siamo prefissi.
Richiesta di dati da più istanze di Prometheus (query globale)
Prometheus offre un approccio funzionale al partizionamento. Anche un singolo server Prometheus fornisce una scalabilità sufficiente per sollevare gli utenti dalle complessità del partizionamento orizzontale nella maggior parte degli scenari.
Sebbene questo sia un ottimo modello di distribuzione, spesso è necessario accedere ai dati su diversi server Prometheus attraverso un'unica API o interfaccia utente — vista globale. Certo, è possibile visualizzare più richieste in un unico pannello Grafana, ma ogni richiesta può essere eseguita solo su un server Prometheus. D'altro canto, con Thanos puoi interrogare e aggregare dati da più server Prometheus poiché tutti sono accessibili da un unico endpoint.
In passato, per ottenere una vista globale in Improbable, abbiamo organizzato le nostre istanze Prometheus in una struttura a più livelli . Ciò significava creare un meta-server Prometheus che raccoglieva una parte delle metriche da ogni server "foglia".
Questo approccio si è rivelato problematico. Ha portato a una configurazione complessa, all'aggiunta di un ulteriore punto di guasto potenziale e all'applicazione di regole complicate per fornire al punto finale federato solo i dati necessari. Inoltre, una federazione di questo tipo non consente di ottenere una visione globale reale, poiché non tutti i dati sono accessibili tramite una sola richiesta API.
Questo è strettamente legato a una visione unificata dei dati raccolti su server Prometheus ad alta disponibilità (high-availability, 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, utilizzare una vista combinata e deduplicata di entrambi i flussi sarebbe molto più comodo.
Certamente, c'è bisogno di server Prometheus altamente disponibili. In Improbable prendiamo molto sul serio il monitoraggio dei dati minuto per minuto, ma avere un solo esemplare di Prometheus nel cluster rappresenta un punto di fallimento singolo. Qualsiasi errore di configurazione o guasto hardware può potenzialmente portare alla perdita di dati importanti. Anche un semplice deployment può causare piccoli problemi nella raccolta delle metriche, dato che un riavvio può richiedere significativamente più tempo dell'intervallo di scraping.
Storage affidabile dei dati storici
Uno storage di metriche economico, veloce e a lungo termine è il nostro sogno (condiviso dalla maggior parte degli utenti di Prometheus). In Improbable siamo stati costretti a impostare il periodo di conservazione delle metriche a nove giorni (per Prometheus 1.8). Questo aggiunge ovvie limitazioni su quanto lontano possiamo guardare indietro.
Prometheus 2.0 è migliorato sotto questo aspetto, poiché il numero di serie temporali non influisce più sulle prestazioni complessive del server (vedi ). Tuttavia, Prometheus memorizza i dati su disco locale. Anche se una compressione dei dati altamente efficiente può ridurre significativamente l'uso del SSD locale, esiste comunque un limite alla quantità di dati storici che possono essere conservati.
Inoltre, in Improbable ci preoccupiamo dell'affidabilità, della semplicità e dei costi. I grandi dischi locali sono più complessi da gestire e da eseguire il backup. Hanno costi maggiori e richiedono più strumenti per il backup, il che porta a una complessità eccessiva.
Downsampling
Non appena abbiamo cominciato a lavorare con i dati storici, ci siamo resi conto che ci sono difficoltà fondamentali con O-grande, che rendono le query sempre più lente se lavoriamo con dati di settimane, mesi e anni.
Una soluzione standard a questo problema è — ridurre la frequenza di campionamento del segnale. Con il downsampling possiamo 'ridurre la scala' a un intervallo di tempo più ampio e mantenere lo stesso numero di campioni, il che aiuterà a preservare la reattività delle query.
Il downsizing dei dati obsoleti è un requisito inevitabile di qualsiasi soluzione per l'archiviazione a lungo termine e va oltre il Prometheus vanilla.
Obiettivi aggiuntivi
Uno degli obiettivi iniziali del progetto Thanos era l'integrazione senza soluzione di continuità con qualsiasi installazione esistente di Prometheus. Il secondo obiettivo era un'implementazione semplice, con una barriera all'ingresso minima. Qualsiasi dipendenza deve essere facilmente soddisfatta sia per utenti piccoli che per grandi, il che implica anche un costo base poco significativo.
Architettura di Thanos
Dopo aver elencato i nostri obiettivi nella sezione precedente, approfondiamo questi aspetti e vediamo come Thanos affronta queste problematiche.
Vista globale
Per ottenere una vista globale sopra le istanze esistenti di Prometheus, dobbiamo collegare un unico punto di ingresso delle richieste a tutti i server. È esattamente ciò di cui si occupa il componente Thanos. . Viene distribuito accanto a ciascun server Prometheus e funge da proxy, servendo i dati locali di Prometheus tramite l'interfaccia gRPC Store API, che consente di selezionare i dati delle serie temporali in base alle etichette e all'intervallo di tempo.
Dall'altra parte si trova il componente Querier orizzontalmente scalabile senza stato, che fa qualcosa di più che rispondere alle richieste PromQL tramite l'API HTTP standard di Prometheus. I componenti Querier, Sidecar e altri Thanos comunicano tramite .
- Il Querier, quando riceve una richiesta, si connette al corrispondente server Store API, cioè ai nostri Sidecar, e ottiene i dati delle serie temporali dai corrispondenti server Prometheus.
- Successivamente, unisce le risposte e esegue la query PromQL su di esse. Il Querier può combinare dati sia non sovrapposti che duplicati dai server HA di Prometheus.
Questo risolve gran parte del nostro rompicapo: unire i dati da server Prometheus isolati in un'unica vista. Infatti, Thanos può essere utilizzato solo per questa capacità. Non è necessario apportare modifiche ai server Prometheus esistenti!
Storage illimitato!
Tuttavia, prima o poi, vorremo archiviare i dati che vanno oltre il normale periodo di conservazione di Prometheus. Per la conservazione dei dati storici, abbiamo scelto uno storage oggetti. È ampiamente disponibile in qualsiasi cloud, così come nei data center locali ed è molto economico. Inoltre, praticamente qualsiasi storage oggetti è accessibile tramite il ben noto API S3.
Prometheus scrive i dati dalla memoria operativa su disco circa ogni due ore. Il blocco di dati salvato contiene tutti i dati per un intervallo di tempo fisso ed è immutabile. Questo è molto comodo, poiché il Thanos Sidecar può semplicemente esaminare la directory dei dati di Prometheus e, man mano che nuovi blocchi appaiono, caricarli nei bucket dello storage oggetti.
Caricare nello storage oggetti immediatamente dopo la scrittura su disco consente anche di mantenere la semplicità del “scraper” (Prometheus e Thanos Sidecar). Questo semplifica la manutenzione, i costi e il design del sistema.
Come vedete, il backup dei dati si realizza molto semplicemente. Ma che dire delle query sui dati nello storage oggetti?
Il componente Thanos Store funge da proxy per accedere ai dati da uno storage object. Proprio come Thanos Sidecar, partecipa al gossip cluster e implementa lo Store API. In questo modo, i Querier esistenti possono considerarlo come un Sidecar, come un ulteriore fonte di dati di serie temporali — non è necessaria alcuna configurazione speciale.
I blocchi di dati di serie temporali sono composti da diversi file di grandi dimensioni. Caricarli su richiesta sarebbe piuttosto inefficiente, mentre la memorizzazione nella cache locale richiederebbe enormi quantità di memoria e spazio su disco.
Invece, lo Store Gateway sa come gestire il formato di archiviazione di Prometheus. Grazie a un intelligente pianificatore di richieste e alla memorizzazione nella cache solo delle parti indicizzate necessarie dei blocchi, è stato possibile ridurre richieste complesse al minimo numero di richieste HTTP ai file dello storage object. In questo modo, è possibile ridurre il numero di richieste di quattro-sei ordini di grandezza e ottenere tempi di risposta che in generale sono difficili da distinguere da richieste di dati su un SSD locale.
Come mostrato nel diagramma sopra, Thanos Querier riduce notevolmente i costi per ogni richiesta di dati nello storage a oggetti, utilizzando il formato di archiviazione Prometheus e posizionando i dati correlati vicini. Con questo approccio, possiamo combinare numerose singole richieste in un numero minimo di operazioni bulk.
Compattazione e downsampling
Dopo che un nuovo blocco di dati time series è stato caricato con successo nello storage a oggetti, lo trattiamo come dati “storici”, che diventano immediatamente accessibili tramite lo Store Gateway.
Tuttavia, dopo un certo periodo, i blocchi provenienti da una fonte (Prometheus con Sidecar) si accumulano e non sfruttano più tutto il potenziale di indicizzazione. Per risolvere questo problema, abbiamo introdotto un ulteriore componente chiamato Compactor. Questo applica semplicemente un meccanismo di compattazione locale di Prometheus ai dati storici nello storage a oggetti e può essere eseguito come un semplice job batch periodico.
Grazie a una compressione efficace, le richieste di archiviazione per lunghi periodi non rappresentano problemi in termini di dimensione dei dati. Tuttavia, il costo potenziale di decomprimere miliardi di valori e passarli attraverso il gestore delle richieste porterà inevitabilmente a un aumento significativo del tempo di esecuzione della richiesta. D'altra parte, poiché centinaia di punti dati corrispondono a ogni pixel dello schermo, diventa impossibile persino visualizzare i dati a piena risoluzione. Pertanto, il downsampling non solo è possibile, ma non comporterà una perdita di precisione apprezzabile.
Per il downsampling dei dati, Compactor aggrega continuamente i dati con una risoluzione di cinque minuti e un'ora. Per ogni frammento non elaborato, codificato utilizzando la compressione XOR TSDB, vengono memorizzati diversi tipi di dati aggregati, come min, max o somma per un blocco. Questo consente al Querier di selezionare automaticamente l'aggregato più appropriato per la data di richiesta PromQL.
Per utilizzare i dati a bassa precisione, l'utente non ha bisogno di alcuna configurazione speciale. Querier passa automaticamente tra diverse risoluzioni e dati grezzi quando l'utente ingrandisce o riduce il livello di zoom. Se desiderato, l'utente può gestire questo direttamente tramite il parametro 'step' nella richiesta.
Poiché il costo di archiviazione di un GB è contenuto, Thanos conserva per impostazione predefinita i dati originali, i dati a risoluzione di cinque minuti e quelli di un'ora. Non è necessario eliminare i dati originali.
Regole di registrazione
Anche con Thanos, le regole di registrazione sono una parte fondamentale dello stack di monitoraggio. Riducono la complessità, la latenza e i costi delle richieste. Inoltre, sono utili per gli utenti che desiderano ottenere dati aggregati sulle metriche. Thanos si basa su istanze vaniglia di Prometheus, quindi è perfettamente accettabile archiviare le regole di registrazione e di allerta sul server Prometheus esistente. Tuttavia, in alcuni casi, questo potrebbe non essere sufficiente:
- Allerta e regole globali (ad esempio, avviso quando un servizio non funziona su più di due dei tre cluster).
- Regola per dati al di fuori dello storage locale.
- Il desiderio di mantenere 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 un ben noto StoreAPI, il nodo Query può accedere a metriche fresche calcolate. Successivamente, queste vengono anche memorizzate in un archivio oggetti e diventano disponibili tramite Store Gateway.
La potenza di Thanos
Thanos è abbastanza flessibile da poter essere configurato secondo le tue esigenze. Questo è particolarmente utile durante la migrazione da un semplice Prometheus. Rivediamo rapidamente, con un piccolo esempio, ciò che abbiamo appreso sui componenti di Thanos. Ecco come trasferire il tuo Prometheus vanilla nel mondo della 'memoria illimitata delle metriche':
- Aggiungi Thanos Sidecar ai tuoi server Prometheus — ad esempio, un container adiacente nel pod Kubernetes.
- Distribuisci più repliche di Thanos Querier per la visualizzazione dei dati. A questo punto, è facile impostare il gossip tra Scraper e Querier. Per verificare l'interazione dei componenti, utilizza la metrica 'thanos_cluster_members'.
Bastano solo questi due passaggi per garantire una visione globale e una deduplicazione fluida dei dati dalle potenziali repliche HA di Prometheus! Collega semplicemente i tuoi dashboard al punto finale HTTP Querier o utilizza direttamente l'interfaccia Thanos UI.
Tuttavia, se hai bisogno di backup delle metriche e di archiviazione a lungo termine, saranno necessari altri tre passaggi:
- Crea un bucket AWS S3 o GCS. Configura il Sidecar per copiare i dati in questi bucket. Ora puoi minimizzare l'archiviazione locale dei dati.
- Distribuisci lo Store Gateway e connettilo al gossip-cluster esistente. Ora puoi inviare richieste ai dati nei backup!
- Distribuisci il Compactor per migliorare l'efficienza delle query per intervalli di tempo prolungati, utilizzando la compressione e il downsampling.
Se vuoi saperne di più, non esitare a dare un'occhiata ai nostri e !
In soli cinque passaggi abbiamo trasformato Prometheus in un sistema di monitoraggio affidabile con una visione globale, tempo di archiviazione illimitato e potenziale alta disponibilità delle metriche.
Pull request: abbiamo bisogno di te!
fin dall'inizio è stata un progetto open source. L'integrazione fluida con Prometheus e la possibilità di utilizzare solo una parte di Thanos lo rendono una scelta eccellente per scalare un sistema di monitoraggio senza sforzi eccessivi.
Accogliamo sempre richieste di Pull Request e Issues su GitHub. Allo stesso tempo, non esitate a contattarci tramite GitHub Issues o Slack., se avete domande o feedback, o volete condividere la vostra esperienza! Se vi piace ciò che facciamo in Improbable, non esitate a contattarci — !
Fonte: habr.com
