Traduzione dell'articolo preparata appositamente per gli studenti del corso .
— sviluppatore software, appassionato di Go e amante di sfide complesse. È anche maintainer di Prometheus e cofondatore di Kubernetes SIG instrumentation. In precedenza, è stato ingegnere di produzione in SoundCloud e ha guidato il team di monitoraggio in CoreOS. Attualmente lavora in Google.
— ingegnere infrastrutturale di Improbable. È appassionato di nuove tecnologie e problemi di sistemi distribuiti. Ha esperienza in programmazione a basso livello in Intel, come contribuente in Mesos e ha esperienza di produzione SRE su scala globale in Improbable. Si occupa di migliorare il mondo dei microservizi. Le sue tre passioni: Golang, open source e pallavolo.
Guardando il nostro prodotto di punta SpatialOS, potete intuire che per Improbable è necessaria un'infrastruttura cloud ad alta dinamica di scala globale con decine di cluster Kubernetes. Siamo stati tra i primi a iniziare a utilizzare un 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 uno dei suoi principali vantaggi. Tuttavia, una volta raggiunte certe dimensioni, ci siamo imbattuti in diversi svantaggi. Per risolvere questi problemi, abbiamo sviluppato — un progetto open source sviluppato da Improbable, per trasformare senza soluzione di continuità i cluster Prometheus esistenti in un'unica sistema di monitoraggio con storage illimitato di dati storici. Thanos è disponibile su Github .
I nostri obiettivi con Thanos
A una certa scala sorgono problemi che vanno oltre le capacità del Prometheus standard. Come possiamo archiviare in modo sicuro ed economico petabyte di dati storici? È possibile farlo senza compromettere i tempi di risposta delle query? Possiamo accedere a tutte le metriche, situate su diversi server Prometheus, tramite 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 la risoluzione di queste questioni e spieghiamo gli obiettivi che ci siamo prefissati.
Richiesta 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 nella maggior parte dei casi d'uso.
Sebbene questo sia un ottimo modello di distribuzione, spesso è necessario accedere ai dati su diversi server Prometheus tramite una singola API o UI — vista globale. Certamente, è possibile visualizzare più query in un singolo pannello di Grafana, ma ogni query può essere eseguita solo su un server Prometheus. D'altra parte, con Thanos puoi richiedere e aggregare dati da più server Prometheus, poiché tutti sono accessibili da un unico endpoint.
In precedenza, per ottenere una vista globale in Improbable, abbiamo organizzato le nostre istanze di Prometheus in una struttura multilivello . Questo significava creare un meta-server Prometheus che raccoglieva una parte delle metriche da ciascun server "foglia".
Questo approccio si è rivelato problematico. Ha portato a una complessità della configurazione, all'aggiunta di un ulteriore potenziale punto di guasto e all'applicazione di regole complesse per fornire all'endpoint federato solo i dati necessari. Inoltre, una federazione di questo tipo non consente di ottenere una vera vista globale, poiché non tutti i dati sono disponibili da una singola richiesta API.
A questo è strettamente correlata la visione unificata dei dati raccolti su server Prometheus ad alta disponibilità (high-availability, HA). Il modello HA di Prometheus raccoglie indipendentemente i dati due volte, il che è così semplice che non potrebbe essere più facile. Tuttavia, sarebbe molto più comodo utilizzare una visione combinata e deduplicata di entrambi i flussi.
Certo, c'è una necessità nei server ad alta disponibilità di Prometheus. In Improbable prendiamo molto sul serio il monitoraggio dei dati minuto per minuto, ma avere un'unica istanza di Prometheus nel cluster rappresenta un unico punto di guasto. Qualsiasi errore di configurazione o guasto hardware potrebbe potenzialmente portare alla perdita di dati importanti. Anche un semplice deployment può causare lievi interruzioni nella raccolta delle metriche, poiché il riavvio può richiedere significativamente più tempo dell'intervallo di scraping.
Archiviazione affidabile dei dati storici
Uno storage dei metriche economico, veloce e a lungo termine è il nostro sogno (condiviso dalla maggior parte degli utenti di Prometheus). In Improbable abbiamo dovuto impostare il periodo di conservazione dei metriche a nove giorni (per Prometheus 1.8). Ciò aggiunge evidenti limiti a quanto indietro possiamo guardare.
Prometheus 2.0 in questo senso è migliorato, 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 di SSD locale, alla fine esiste comunque un limite alla quantità di dati storici memorizzati.
Inoltre, in Improbable ci preoccupiamo dell'affidabilità, semplicità e costo. I grandi dischi locali sono più complessi da gestire e da fare backup. Costano di più e richiedono più strumenti per il backup, portando a una complessità eccessiva.
Downsampling
Non appena abbiamo iniziato a lavorare con i dati storici, ci siamo resi conto che ci sono complessità fondamentali con O-grande, che rendono le query sempre più lente se lavoriamo con dati di settimane, mesi e anni.
La soluzione standard a questo problema è — ridurre la frequenza di campionamento del segnale. Con il downsampling possiamo 'ridimensionare' su un intervallo di tempo più ampio e mantenere lo stesso numero di campioni, il che consente di mantenere reattive le query.
Il downsampling dei dati storici è un requisito inevitabile di qualsiasi soluzione di 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 la semplicità d'uso con una barriera all'ingresso minima. Tutte le dipendenze devono essere facilmente soddisfatte sia per piccoli che per grandi utenti, il che implica anche un costo di base trascurabile.
Architettura di Thanos
Dopo che nel precedente capitolo sono stati elencati i nostri obiettivi, lavoriamo su di essi e vediamo come Thanos affronta queste problematiche.
Vista globale
Per ottenere una vista globale sopra gli esemplari esistenti di Prometheus, abbiamo bisogno di unificare un punto di accesso per le richieste con tutti i server. Questo è esattamente ciò che fa il componente Thanos. . Viene distribuito accanto a ogni server Prometheus e funziona come un proxy, servendo i dati locali di Prometheus tramite l'interfaccia gRPC dello Store API, consentendo di selezionare i dati delle serie temporali in base ai tag e all'intervallo di tempo.
Dall'altro lato c'è un componente Querier orizzontalmente scalabile senza stato, che fa un po' più che semplicemente rispondere alle richieste PromQL tramite il consueto API HTTP di Prometheus. I componenti Querier, Sidecar e altri Thanos interagiscono tramite .
- Il Querier, una volta ricevuta la richiesta, si connette al server corrispondente dello Store API, ovvero ai nostri Sidecar, e recupera i dati delle serie temporali dai server Prometheus corrispondenti.
- Successivamente, unisce le risposte e esegue la richiesta PromQL su di esse. Il Querier può unire sia dati non sovrapposti che dati duplicati dai server Prometheus HA.
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 funzionalità. Non è necessario apportare alcuna modifica ai server Prometheus esistenti!
Archiviazione illimitata!
Tuttavia, prima o poi vorremo conservare i dati che superano i normali tempi di conservazione di Prometheus. Per l'archiviazione dei dati storici, abbiamo scelto lo storage a oggetti. È ampiamente disponibile in qualsiasi cloud, così come nei data center locali, ed è molto economico. Inoltre, praticamente qualsiasi storage a 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é Thanos Sidecar può semplicemente controllare la directory dei dati di Prometheus e, man mano che emergono nuovi blocchi, caricarli nei bucket dello storage oggetto.
Il caricamento nello storage oggetto subito dopo la scrittura su disco permette anche di mantenere la semplicità dello “scraper” (Prometheus e Thanos Sidecar). Questo semplifica la manutenzione, i costi e il design del sistema.
Come potete vedere, il backup dei dati è realizzato in modo molto semplice. Ma cosa possiamo dire delle richieste ai dati nello storage oggetto?
Il componente Thanos Store funge da proxy per ottenere dati dallo storage oggetto. Come Thanos Sidecar, è coinvolto nel gossip cluster e implementa lo Store API. In questo modo, i Querier esistenti possono considerarlo come Sidecar, come un'ulteriore fonte di dati delle time series — non sono necessarie configurazioni speciali.
I blocchi dei dati delle time series sono composti da diversi grandi file. Scaricarli su richiesta sarebbe piuttosto inefficiente, mentre la memorizzazione nella cache locale richiederebbe una quantità enorme di memoria e spazio su disco.
Invece, il Store Gateway sa come gestire il formato di memorizzazione di Prometheus. Grazie a uno scheduler intelligente delle richieste e alla memorizzazione nella cache delle sole parti indice necessarie dei blocchi, è possibile ridurre le richieste complesse al numero minimo di richieste HTTP ai file dello storage oggetto. In questo modo, si può ridurre il numero di richieste di quattro-sei ordini di grandezza e ottenere tempi di risposta che in generale sono difficili da differenziare dalle richieste ai dati su SSD locali.
Come mostrato nel diagramma sopra, Thanos Querier riduce significativamente i costi per una singola richiesta ai dati nello storage oggetto, utilizzando il formato di memorizzazione di Prometheus e collocando i dati correlati in prossimità. Utilizzando questo approccio, possiamo combinare molte richieste singole nel numero minimo di operazioni bulk.
Compattazione e downsampling
Dopo che un nuovo blocco di dati delle time series è stato caricato con successo nello storage oggetto, lo consideriamo come dati “storici”, che diventano immediatamente disponibili tramite il Store Gateway.
Tuttavia, dopo un certo periodo di tempo, i blocchi provenienti da una sola 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 locale di compressione di Prometheus ai dati storici nello storage oggetti e può essere eseguito come un semplice job batch periodico.
Grazie a una compressione efficace, una query nello storage per un lungo periodo di tempo non comporta problemi dal punto di vista delle dimensioni dei dati. Tuttavia, il costo potenziale di decomprimere un miliardo di valori e di passarli attraverso il gestore di query porterà inevitabilmente a un aumento significativo del tempo di esecuzione della query. D'altra parte, poiché per ogni pixel dello schermo ci sono centinaia di punti dati, diventa impossibile anche solo visualizzare i dati a piena risoluzione. Pertanto, il downsampling non solo è possibile, ma non comporterà una perdita di precisione significativa.
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 con la compressione XOR di TSDB, vengono memorizzati diversi tipi di dati aggregati, come min, max o somma per un singolo blocco. Questo consente a Querier di selezionare automaticamente l'aggregato più adatto per la richiesta PromQL fornita.
Per utilizzare dati a precisione ridotta, all'utente non è richiesta alcuna configurazione speciale. Querier passa automaticamente tra diverse risoluzioni e dati non elaborati mentre l'utente ingrandisce o riduce lo zoom. Se lo desidera, l'utente può gestire questo direttamente tramite il parametro “step” nella query.
Poiché il costo di archiviare un GB è contenuto, per impostazione predefinita Thanos conserva i dati originali, i dati con risoluzione di cinque minuti e un'ora. Non è necessario eliminare i dati originali.
Regole di registrazione
Anche con Thanos, le recording rules sono una parte sostanziale dello stack di monitoraggio. Riducono la complessità, la latenza e il costo delle query. Sono anche utili per gli utenti per ottenere dati aggregati sulle metriche. Thanos si basa su istanze vanilla di Prometheus, quindi è del tutto accettabile conservare le recording rules e le alerting rules su un server Prometheus esistente. Tuttavia, in alcuni casi questo potrebbe non essere sufficiente:
- Alert e rule globali (ad esempio, avviso quando un servizio non funziona in più di due su tre cluster).
- Rule per dati al di fuori dello storage locale.
- Tendenza a mantenere tutte le rule e alert in un unico luogo.
Per tutti questi casi, Thanos include un componente separato chiamato Ruler, che calcola rule e alert attraverso le Thanos Queries. Fornendo uno StoreAPI ben noto, il nodo Query può accedere a metriche calcolate fresche. Successivamente, vengono anche memorizzate nello storage a oggetti e diventano accessibili tramite Store Gateway.
La potenza di Thanos
Thanos è abbastanza flessibile da poter essere configurato in base alle tue esigenze. Questo è particolarmente utile durante la migrazione da un semplice Prometheus. Rivediamo rapidamente, con un piccolo esempio, cosa abbiamo imparato 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 in un pod Kubernetes.
- Distribuisci più repliche di Thanos Querier per la possibilità di visualizzare i dati. A questo punto, è facile configurare il gossip tra Scraper e Querier. Per verificare l'interazione tra i componenti, usa la metrica ‘thanos_cluster_members’.
Solo questi due passaggi sono sufficienti per garantire una vista globale e una deduplica delle informazioni senza soluzione di continuità dalle potenziali repliche HA di Prometheus! Basta collegare i tuoi dashboard all'endpoint HTTP Querier o utilizzare direttamente l'interfaccia Thanos UI.
Tuttavia, se hai bisogno di backup delle metriche e di storage a lungo termine, sarà necessario eseguire ancora tre passaggi:
- Crea un bucket AWS S3 o GCS. Configura il Sidecar per copiare i dati in questi bucket. Ora puoi ridurre al minimo lo storage locale dei dati.
- Distribuisci Store Gateway e collegalo all'attuale cluster gossip. Ora puoi inviare richieste ai dati nei backup!
- Espandi il Compactor per migliorare l'efficienza delle query su 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 vista globale, senza limiti di tempo di conservazione e con una potenziale alta disponibilità delle metriche.
Richiesta di pull: abbiamo bisogno di te!
è stato un progetto open source sin dall'inizio. L'integrazione fluida con Prometheus e la possibilità di utilizzare solo una parte di Thanos lo rendono una scelta eccellente per scalare il sistema di monitoraggio senza sforzi aggiuntivi.
Siamo sempre felici di ricevere richieste di pull e segnalazioni su GitHub. Nel frattempo, non esitare a contattarci tramite GitHub Issues o slack, se hai domande o feedback, o se vuoi condividere la tua esperienza! Se ti piace quello che facciamo in Improbable, non esitare a contattarci — !
Fonte: habr.com
