{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 Prometheus scalabile.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduzione dell'articolo \u00e8 stata preparata appositamente per gli studenti del corso \u00abPratiche e strumenti DevOps\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 sviluppatore software, appassionato di Go e amante delle sfide complesse. \u00c8 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.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 ingegnere delle infrastrutture in Improbable. \u00c8 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.<\/i><\/p>\n

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<\/a><\/noindex>. Prometheus \u00e8 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.<\/p>\n

La semplicit\u00e0 e l'affidabilit\u00e0 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 Thanos<\/a><\/noindex> \u2014 un progetto open source creato da Improbable, per trasformare senza soluzione di continuit\u00e0 i cluster esistenti di Prometheus in un sistema di monitoraggio unificato con archiviazione illimitata dei dati storici. Thanos \u00e8 disponibile su Github qui<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Rimani aggiornato sulle ultime novit\u00e0 da Improbable.<\/a><\/noindex><\/p>\n

I nostri obiettivi con Thanos<\/h2>\n

\nCon un certo livello di scala, emergono problemi che vanno oltre le capacit\u00e0 di un Prometheus standard. Come possiamo archiviare in modo sicuro ed economico petabyte di dati storici? \u00c8 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? \u00c8 possibile in qualche modo combinare i dati replicati raccolti tramite Prometheus HA?<\/p>\n

Per affrontare queste questioni, abbiamo creato Thanos. Nelle sezioni seguenti descriviamo come abbiamo affrontato tali sfide e spieghiamo gli obiettivi che ci siamo prefissi.<\/p>\n

Richiesta di dati da pi\u00f9 istanze di Prometheus (query globale)<\/h4>\n

\nPrometheus offre un approccio funzionale al partizionamento. Anche un singolo server Prometheus fornisce una scalabilit\u00e0 sufficiente per sollevare gli utenti dalle complessit\u00e0 del partizionamento orizzontale nella maggior parte degli scenari.<\/p>\n

Sebbene questo sia un ottimo modello di distribuzione, spesso \u00e8 necessario accedere ai dati su diversi server Prometheus attraverso un'unica API o interfaccia utente \u2014 vista globale. Certo, \u00e8 possibile visualizzare pi\u00f9 richieste in un unico pannello Grafana, ma ogni richiesta pu\u00f2 essere eseguita solo su un server Prometheus. D'altro canto, con Thanos puoi interrogare e aggregare dati da pi\u00f9 server Prometheus poich\u00e9 tutti sono accessibili da un unico endpoint.<\/p>\n

In passato, per ottenere una vista globale in Improbable, abbiamo organizzato le nostre istanze Prometheus in una struttura a pi\u00f9 livelli Federazione Gerarchica<\/a><\/noindex>. \u042d\u0442\u043e \u043e\u0437\u043d\u0430\u0447\u0430\u043b\u043e \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0434\u043d\u043e\u0433\u043e \u043c\u0435\u0442\u0430-\u0441\u0435\u0440\u0432\u0435\u0440\u0430 Prometheus, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442 \u0447\u0430\u0441\u0442\u044c \u043c\u0435\u0442\u0440\u0438\u043a \u0441 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u201c\u043b\u0438\u0441\u0442\u043e\u0432\u043e\u0433\u043e" \u0441\u0435\u0440\u0432\u0435\u0440\u0430.<\/p>\n

\"Thanos
\n
\nQuesto approccio si \u00e8 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\u00e9 non tutti i dati sono accessibili tramite una sola richiesta API.<\/p>\n

Questo \u00e8 strettamente legato a una visione unificata dei dati raccolti su server Prometheus ad alta disponibilit\u00e0 (high-availability, HA). Il modello HA di Prometheus raccoglie i dati in modo indipendente due volte, il che \u00e8 cos\u00ec semplice che non potrebbe essere pi\u00f9 semplice. Tuttavia, utilizzare una vista combinata e deduplicata di entrambi i flussi sarebbe molto pi\u00f9 comodo.<\/p>\n

Certamente, c'\u00e8 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\u00f2 potenzialmente portare alla perdita di dati importanti. Anche un semplice deployment pu\u00f2 causare piccoli problemi nella raccolta delle metriche, dato che un riavvio pu\u00f2 richiedere significativamente pi\u00f9 tempo dell'intervallo di scraping.<\/p>\n

Storage affidabile dei dati storici<\/h4>\n

\nUno storage di metriche economico, veloce e a lungo termine \u00e8 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.<\/p>\n

Prometheus 2.0 \u00e8 migliorato sotto questo aspetto, poich\u00e9 il numero di serie temporali non influisce pi\u00f9 sulle prestazioni complessive del server (vedi il keynote di KubeCon su Prometheus 2<\/a><\/noindex>). Tuttavia, Prometheus memorizza i dati su disco locale. Anche se una compressione dei dati altamente efficiente pu\u00f2 ridurre significativamente l'uso del SSD locale, esiste comunque un limite alla quantit\u00e0 di dati storici che possono essere conservati.<\/p>\n

Inoltre, in Improbable ci preoccupiamo dell'affidabilit\u00e0, della semplicit\u00e0 e dei costi. I grandi dischi locali sono pi\u00f9 complessi da gestire e da eseguire il backup. Hanno costi maggiori e richiedono pi\u00f9 strumenti per il backup, il che porta a una complessit\u00e0 eccessiva.<\/p>\n

Downsampling<\/h4>\n

\nNon appena abbiamo cominciato a lavorare con i dati storici, ci siamo resi conto che ci sono difficolt\u00e0 fondamentali con O-grande, che rendono le query sempre pi\u00f9 lente se lavoriamo con dati di settimane, mesi e anni.<\/p>\n

Una soluzione standard a questo problema \u00e8 downsampling<\/a><\/noindex> \u2014 ridurre la frequenza di campionamento del segnale. Con il downsampling possiamo 'ridurre la scala' a un intervallo di tempo pi\u00f9 ampio e mantenere lo stesso numero di campioni, il che aiuter\u00e0 a preservare la reattivit\u00e0 delle query.<\/p>\n

Il downsizing dei dati obsoleti \u00e8 un requisito inevitabile di qualsiasi soluzione per l'archiviazione a lungo termine e va oltre il Prometheus vanilla.<\/p>\n

Obiettivi aggiuntivi<\/h4>\n

\nUno degli obiettivi iniziali del progetto Thanos era l'integrazione senza soluzione di continuit\u00e0 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.<\/p>\n

Architettura di Thanos<\/h2>\n

\nDopo aver elencato i nostri obiettivi nella sezione precedente, approfondiamo questi aspetti e vediamo come Thanos affronta queste problematiche.<\/p>\n

Vista globale<\/h4>\n

\nPer ottenere una vista globale sopra le istanze esistenti di Prometheus, dobbiamo collegare un unico punto di ingresso delle richieste a tutti i server. \u00c8 esattamente ci\u00f2 di cui si occupa il componente Thanos. Sidecar<\/a><\/noindex>. 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.<\/p>\n

Dall'altra parte si trova il componente Querier orizzontalmente scalabile senza stato, che fa qualcosa di pi\u00f9 che rispondere alle richieste PromQL tramite l'API HTTP standard di Prometheus. I componenti Querier, Sidecar e altri Thanos comunicano tramite protocollo gossip<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. Il Querier, quando riceve una richiesta, si connette al corrispondente server Store API, cio\u00e8 ai nostri Sidecar, e ottiene i dati delle serie temporali dai corrispondenti server Prometheus.<\/li>\n
  2. Successivamente, unisce le risposte e esegue la query PromQL su di esse. Il Querier pu\u00f2 combinare dati sia non sovrapposti che duplicati dai server HA di Prometheus.<\/li>\n<\/ol>\n

    \nQuesto risolve gran parte del nostro rompicapo: unire i dati da server Prometheus isolati in un'unica vista. Infatti, Thanos pu\u00f2 essere utilizzato solo per questa capacit\u00e0. Non \u00e8 necessario apportare modifiche ai server Prometheus esistenti!<\/p>\n

    Storage illimitato!<\/h4>\n

    \nTuttavia, 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. \u00c8 ampiamente disponibile in qualsiasi cloud, cos\u00ec come nei data center locali ed \u00e8 molto economico. Inoltre, praticamente qualsiasi storage oggetti \u00e8 accessibile tramite il ben noto API S3.<\/p>\n

    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 \u00e8 immutabile. Questo \u00e8 molto comodo, poich\u00e9 il Thanos Sidecar pu\u00f2 semplicemente esaminare la directory dei dati di Prometheus e, man mano che nuovi blocchi appaiono, caricarli nei bucket dello storage oggetti.<\/p>\n

    \"Thanos
    \n
    \nCaricare nello storage oggetti immediatamente dopo la scrittura su disco consente anche di mantenere la semplicit\u00e0 del \u201cscraper\u201d (Prometheus e Thanos Sidecar). Questo semplifica la manutenzione, i costi e il design del sistema.<\/p>\n

    Come vedete, il backup dei dati si realizza molto semplicemente. Ma che dire delle query sui dati nello storage oggetti?<\/p>\n

    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 \u2014 non \u00e8 necessaria alcuna configurazione speciale.<\/p>\n

    \"Thanos
    \n
    \nI 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\u00e0 di memoria e spazio su disco.<\/p>\n

    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, \u00e8 stato possibile ridurre richieste complesse al minimo numero di richieste HTTP ai file dello storage object. In questo modo, \u00e8 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.<\/p>\n

    \"Thanos
    \n
    \nCome 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.<\/p>\n

    Compattazione e downsampling<\/h4>\n

    \nDopo che un nuovo blocco di dati time series \u00e8 stato caricato con successo nello storage a oggetti, lo trattiamo come dati \u201cstorici\u201d, che diventano immediatamente accessibili tramite lo Store Gateway.<\/p>\n

    Tuttavia, dopo un certo periodo, i blocchi provenienti da una fonte (Prometheus con Sidecar) si accumulano e non sfruttano pi\u00f9 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\u00f2 essere eseguito come un semplice job batch periodico.<\/p>\n

    \"Thanos
    \n
    \nGrazie 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\u00e0 inevitabilmente a un aumento significativo del tempo di esecuzione della richiesta. D'altra parte, poich\u00e9 centinaia di punti dati corrispondono a ogni pixel dello schermo, diventa impossibile persino visualizzare i dati a piena risoluzione. Pertanto, il downsampling non solo \u00e8 possibile, ma non comporter\u00e0 una perdita di precisione apprezzabile. <\/p>\n

    \"Thanos
    \n
    \nPer 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\u00f9 appropriato per la data di richiesta PromQL. <\/p>\n

    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\u00f2 gestire questo direttamente tramite il parametro 'step' nella richiesta. <\/p>\n

    Poich\u00e9 il costo di archiviazione di un GB \u00e8 contenuto, Thanos conserva per impostazione predefinita i dati originali, i dati a risoluzione di cinque minuti e quelli di un'ora. Non \u00e8 necessario eliminare i dati originali.<\/p>\n

    Regole di registrazione<\/h2>\n

    \nAnche con Thanos, le regole di registrazione sono una parte fondamentale dello stack di monitoraggio. Riducono la complessit\u00e0, 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 \u00e8 perfettamente accettabile archiviare le regole di registrazione e di allerta sul server Prometheus esistente. Tuttavia, in alcuni casi, questo potrebbe non essere sufficiente:<\/p>\n