{"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":"

Traduzione dell'articolo 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 di sfide complesse. \u00c8 anche maintainer di Prometheus e cofondatore di Kubernetes SIG instrumentation. In precedenza, \u00e8 stato 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 infrastrutturale di Improbable. \u00c8 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.<\/i><\/p>\n

Guardando il nostro prodotto di punta SpatialOS, potete intuire che per Improbable \u00e8 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<\/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 uno dei suoi principali vantaggi. Tuttavia, una volta raggiunte certe dimensioni, ci siamo imbattuti in diversi svantaggi. Per risolvere questi problemi, abbiamo sviluppato Thanos<\/a><\/noindex> \u2014 un progetto open source sviluppato da Improbable, per trasformare senza soluzione di continuit\u00e0 i cluster Prometheus esistenti in un'unica sistema di monitoraggio con storage illimitato di dati storici. Thanos \u00e8 disponibile su Github qui<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Rimanete aggiornati con le ultime notizie da Improbable.<\/a><\/noindex><\/p>\n

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

\nA una certa scala sorgono problemi che vanno oltre le capacit\u00e0 del Prometheus standard. Come possiamo archiviare in modo sicuro ed economico petabyte di dati storici? \u00c8 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? \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 la risoluzione di queste questioni e spieghiamo gli obiettivi che ci siamo prefissati.<\/p>\n

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

\nPrometheus offre un approccio funzionale allo sharding. Anche un singolo server Prometheus fornisce una scalabilit\u00e0 sufficiente per liberare gli utenti dalle complessit\u00e0 dello sharding orizzontale nella maggior parte dei casi d'uso.<\/p>\n

Sebbene questo sia un ottimo modello di distribuzione, spesso \u00e8 necessario accedere ai dati su diversi server Prometheus tramite una singola API o UI \u2014 vista globale. Certamente, \u00e8 possibile visualizzare pi\u00f9 query in un singolo pannello di Grafana, ma ogni query pu\u00f2 essere eseguita solo su un server Prometheus. D'altra parte, con Thanos puoi richiedere e aggregare dati da pi\u00f9 server Prometheus, poich\u00e9 tutti sono accessibili da un unico endpoint.<\/p>\n

In precedenza, per ottenere una vista globale in Improbable, abbiamo organizzato le nostre istanze di Prometheus in una struttura multilivello Federazione gerarchica<\/a><\/noindex>. Questo significava creare un meta-server Prometheus che raccoglie parte delle metriche da ogni server \"leaf\".<\/p>\n

\"Thanos
\n
\nQuesto approccio si \u00e8 rivelato problematico. Ha portato a una complessit\u00e0 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\u00e9 non tutti i dati sono disponibili da una singola richiesta API.<\/p>\n

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

Certo, c'\u00e8 una necessit\u00e0 nei server ad alta disponibilit\u00e0 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\u00f2 causare lievi interruzioni nella raccolta delle metriche, poich\u00e9 il riavvio pu\u00f2 richiedere significativamente pi\u00f9 tempo dell'intervallo di scraping.<\/p>\n

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

\nUno storage dei metriche economico, veloce e a lungo termine \u00e8 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\u00f2 aggiunge evidenti limiti a quanto indietro possiamo guardare.<\/p>\n

Prometheus 2.0 in questo senso \u00e8 migliorato, poich\u00e9 il numero di serie temporali non influisce pi\u00f9 sulle prestazioni complessive del server (vedi KubeCon keynote 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 di SSD locale, alla fine esiste comunque un limite alla quantit\u00e0 di dati storici memorizzati.<\/p>\n

Inoltre, in Improbable ci preoccupiamo dell'affidabilit\u00e0, semplicit\u00e0 e costo. I grandi dischi locali sono pi\u00f9 complessi da gestire e da fare backup. Costano di pi\u00f9 e richiedono pi\u00f9 strumenti per il backup, portando a una complessit\u00e0 eccessiva.<\/p>\n

Downsampling<\/h4>\n

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

La soluzione standard a questo problema \u00e8 downsampling<\/a><\/noindex> \u2014 ridurre la frequenza di campionamento del segnale. Con il downsampling possiamo 'ridimensionare' su un intervallo di tempo pi\u00f9 ampio e mantenere lo stesso numero di campioni, il che consente di mantenere reattive le query.<\/p>\n

Il downsampling dei dati storici \u00e8 un requisito inevitabile di qualsiasi soluzione di 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 la semplicit\u00e0 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.<\/p>\n

Architettura di Thanos<\/h2>\n

\nDopo che nel precedente capitolo sono stati elencati i nostri obiettivi, lavoriamo su di essi e vediamo come Thanos affronta queste problematiche.<\/p>\n

Vista globale<\/h4>\n

\nPer 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 \u00e8 esattamente ci\u00f2 che fa il componente Thanos. Sidecar<\/a><\/noindex>. 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.<\/p>\n

Dall'altro lato c'\u00e8 un componente Querier orizzontalmente scalabile senza stato, che fa un po' pi\u00f9 che semplicemente rispondere alle richieste PromQL tramite il consueto API HTTP di Prometheus. I componenti Querier, Sidecar e altri Thanos interagiscono tramite il protocollo gossip.<\/a><\/noindex>.<\/p>\n

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

    \n
  1. 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.<\/li>\n
  2. Successivamente, unisce le risposte e esegue la richiesta PromQL su di esse. Il Querier pu\u00f2 unire sia dati non sovrapposti che dati duplicati dai server Prometheus HA.<\/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 funzionalit\u00e0. Non \u00e8 necessario apportare alcuna modifica ai server Prometheus esistenti!<\/p>\n

    Archiviazione illimitata!<\/h4>\n

    \nTuttavia, 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. \u00c8 ampiamente disponibile in qualsiasi cloud, cos\u00ec come nei data center locali, ed \u00e8 molto economico. Inoltre, praticamente qualsiasi storage a 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 Thanos Sidecar pu\u00f2 semplicemente controllare la directory dei dati di Prometheus e, man mano che emergono nuovi blocchi, caricarli nei bucket dello storage oggetto.<\/p>\n

    \"Thanos
    \n
    \nIl caricamento nello storage oggetto subito dopo la scrittura su disco permette anche di mantenere la semplicit\u00e0 dello \u201cscraper\u201d (Prometheus e Thanos Sidecar). Questo semplifica la manutenzione, i costi e il design del sistema.<\/p>\n

    Come potete vedere, il backup dei dati \u00e8 realizzato in modo molto semplice. Ma cosa possiamo dire delle richieste ai dati nello storage oggetto?<\/p>\n

    Il componente Thanos Store funge da proxy per ottenere dati dallo storage oggetto. Come Thanos Sidecar, \u00e8 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 \u2014 non sono necessarie configurazioni speciali.<\/p>\n

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

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

    \"Thanos
    \n
    \nCome 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\u00e0. Utilizzando questo approccio, possiamo combinare molte richieste singole nel numero minimo di operazioni bulk.<\/p>\n

    Compattazione e downsampling<\/h4>\n

    \nDopo che un nuovo blocco di dati delle time series \u00e8 stato caricato con successo nello storage oggetto, lo consideriamo come dati \u201cstorici\u201d, che diventano immediatamente disponibili tramite il Store Gateway.<\/p>\n

    Tuttavia, dopo un certo periodo di tempo, i blocchi provenienti da una sola 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 locale di compressione di Prometheus ai dati storici nello storage oggetti e pu\u00f2 essere eseguito come un semplice job batch periodico.<\/p>\n

    \"Thanos
    \n
    \nGrazie 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\u00e0 inevitabilmente a un aumento significativo del tempo di esecuzione della query. D'altra parte, poich\u00e9 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 \u00e8 possibile, ma non comporter\u00e0 una perdita di precisione significativa. <\/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 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\u00f9 adatto per la richiesta PromQL fornita. <\/p>\n

    Per utilizzare dati a precisione ridotta, all'utente non \u00e8 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\u00f2 gestire questo direttamente tramite il parametro \u201cstep\u201d nella query. <\/p>\n

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

    Regole di registrazione<\/h2>\n

    \nAnche con Thanos, le recording rules sono una parte sostanziale dello stack di monitoraggio. Riducono la complessit\u00e0, 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 \u00e8 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:<\/p>\n