A traduzzione di l'articulu hè stata preparata apposta per i studienti di u corsu .
hè un sviluppatore di software, Go fanatic, è risolve i prublemi. Hè ancu un mantene Prometheus è cofundatore di Kubernetes SIG instrumentation. In u passatu, era un ingegnere di produzzione in SoundCloud è guidò u squadra di monitoraghju in CoreOS. Attualmente travaglia in Google.
- Ingegnere di l'infrastruttura à Improbable. Hè interessatu à e tecnulugia novi è i prublemi di sistemi distribuiti. Hà una sperienza di prugrammazione di bassu livellu in Intel, una sperienza di cuntributore in Mesos, è una sperienza di produzzione SRE di classe mundiale in Improbable. Dedicatu à migliurà u mondu di i microservizi. I so trè amori: Golang, open source è volleyball.
Fighjendu u nostru pruduttu di punta SpatialOS, pudete indovinà chì Improbable richiede una infrastruttura di nuvola altamente dinamica à scala globale cù decine di cluster Kubernetes. Eramu unu di i primi à aduprà un sistema di surviglianza . Prometheus hè capaci di seguità milioni di metriche in tempu reale è vene cun una lingua di quistione putente chì permette di estrae l'infurmazioni chì avete bisognu.
A simplicità è affidabilità di Prometheus hè unu di i so vantaghji principali. Tuttavia, quandu avemu passatu una certa scala, avemu scontru parechji inconvenienti. Per risolve questi prublemi avemu sviluppatu hè un prughjettu open source creatu da Improbable per trasfurmà senza saldatura i clusters Prometheus esistenti in un sistema di monitoraghju unicu cù un almacenamentu di dati storichi illimitatu. Thanos hè dispunibule nantu à Github .
I nostri scopi cù Thanos
À una certa scala, si sviluppanu prublemi chì sò fora di e capacità di vaniglia Prometheus. Cumu almacenà in modu affidabile è economicu petabytes di dati storichi? Pò esse fattu senza compromette u tempu di risposta? Hè pussibule accede à tutte e metriche situate in diversi servitori Prometheus cù una sola dumanda API? Ci hè un modu per cumminà e dati replicati raccolti cù Prometheus HA?
Per affruntà questi prublemi, avemu creatu Thanos. I seguenti rùbbriche descrizanu cumu avemu avvicinatu sti prublemi è spiegà i nostri scopi.
Interrogazione di dati da parechje istanze Prometheus (interrogazione globale)
Prometheus offre un accostu funziunale à sharding. Ancu un unicu servitore Prometheus furnisce una scalabilità abbastanza per liberà l'utilizatori da e cumplessità di sharding horizontale in quasi tutti i casi d'usu.
Mentre chì questu hè un grande mudellu di implementazione, hè spessu necessariu d'accede à e dati nantu à diversi servitori Prometheus attraversu una sola API o UI - una vista globale. Di sicuru, hè pussibule di visualizà parechje dumande in un pannellu Grafana, ma ogni dumanda pò esse eseguita solu nantu à un servitore Prometheus. Per d 'altra banda, cù Thanos pudete dumandà è aggregate dati da parechji servitori Prometheus postu chì sò tutti accessibili da un unicu endpoint.
In precedenza, per avè una vista globale in Improbable, avemu urganizatu i nostri casi Prometheus in un multi-livellu. . Questu significava a creazione di un meta server Prometheus chì raccoglie alcune di e metriche da ogni servitore foglia.
Stu approcciu hè statu prublema. Questu hà risultatu in cunfigurazioni più cumplesse, l'aghjunzione di un puntu di fallimentu potenziale supplementu, è l'applicazione di reguli cumplessi per assicurà chì l'endpoint federatu riceve solu e dati chì hà bisognu. Inoltre, stu tipu di federazione ùn permette micca di ottene una vera vista globale, postu chì micca tutti i dati sò dispunibuli da una sola dumanda API.
In stretta relazione cù questu hè una vista unificata di e dati raccolti nantu à i servitori Prometheus d'alta dispunibilità (HA). U mudellu HA di Prometheus raccoglie dati in modu indipendenti duie volte, chì hè cusì simplice chì ùn puderia micca esse più simplice. Tuttavia, aduprendu una vista cumminata è deduplicata di i dui flussi seria assai più còmuda.
Di sicuru, ci hè bisognu di servitori Prometheus assai dispunibili. À Improbable, pigliamu u monitoraghju di dati minutu per minutu veramente seriamente, ma avè una istanza di Prometheus per cluster hè un puntu unicu di fallimentu. Qualchese errore di cunfigurazione o fallimentu di hardware pò purtà à a perdita di dati impurtanti. Ancu una implementazione simplice pò causà disrupzioni minori in a cullizzioni di metrica perchè i riavvii ponu esse significativamente più longu di l'intervallu di scraping.
Almacenamiento affidabile di dati storichi
L'almacenamiento di metrica economica, rapida è longu hè u nostru sognu (spartitu da a maiò parte di l'utilizatori di Prometheus). In Improbable, avemu statu obligatu à cunfigurà u periodu di retenzioni di metrica à novi ghjorni (per Prometheus 1.8). Questu aghjusta limiti evidenti à quantu retrocede pudemu vede.
Prometheus 2.0 hà migliuratu in questu sensu, postu chì u numeru di serie di tempu ùn affetta più u rendiment generale di u servitore (vede. ). In ogni casu, Prometheus guarda dati nantu à u discu locale. Ancu s'è a cumpressione di dati d'alta efficienza pò riduce significativamente l'usu SSD locale, ci hè sempre un limitu per a quantità di dati storichi chì ponu esse almacenati.
Inoltre, à Improbable ci importa di affidabilità, simplicità è costu. I grandi dischi lucali sò più difficiuli di operare è di salvezza. Custanu più è necessitanu più strumenti di salvezza, risultatu in una cumplessità inutile.
Downsampling
Una volta avemu cuminciatu à travaglià cù dati storichi, avemu capitu chì ci sò difficultà fundamentali cù big-O chì facenu e dumande più lente è più lente mentre travagliemu cù settimane, mesi è anni di dati.
A suluzione standard à stu prublema seria (downsampling) - riducendu a frequenza di campionamentu di u signale. Cù downsampling, pudemu "scala" à un intervallu di tempu più grande è mantene u listessu numeru di campioni, mantenendu e dumande responsive.
Downsampling di dati vechji hè un requisitu inevitabbile di qualsiasi suluzione di almacenamiento à longu andà è hè fora di u scopu di Vanilla Prometheus.
Obiettivi supplementari
Unu di l'ugettivi originali di u prugettu Thanos era di integrà perfettamente cù qualsiasi installazione Prometheus esistente. U sicondu scopu era facilità di operazione cù barriere minimi à l'ingressu. Ogni dependenza deve esse facilmente soddisfatta per l'utilizatori chjuchi è grandi, chì significa ancu un costu di basa bassu.
L'architettura di Thanos
Dopu elencu i nostri scopi in a sezione precedente, travagliemu per elli è vedemu cumu Thanos risolve questi prublemi.
Visione globale
Per avè una vista globale nantu à l'istanze di Prometheus esistenti, avemu bisognu di ligà un unicu puntu di ingressu di dumanda à tutti i servitori. Questu hè esattamente ciò chì face u cumpunente Thanos. . Hè implementatu accantu à ogni servitore Prometheus è agisce cum'è un proxy, servendu dati Prometheus lucali attraversu l'API di gRPC Store, chì permette di ricuperà e dati di serie temporale per tag è intervallu di tempu.
Da l'altra parte hè u cumpunente di Querier scale-out, senza statu, chì face pocu più cà solu risponde à e dumande PromQL via l'API standard Prometheus HTTP. Querier, Sidecar è altri cumpunenti Thanos cumunicanu via .
- Querier, dopu avè ricivutu una dumanda, cunnetta à u servitore API Store currispundente, vale à dì à i nostri Sidecars è riceve dati di serie temporale da i servitori Prometheus currispondenti.
- Dopu questu, combina e risposte è eseguisce una dumanda PromQL nantu à elli. Querier pò unisce e dati disgiunti è dati duplicati da i servitori Prometheus HA.
Questu risolve un pezzu maiò di u nostru puzzle - cumminendu dati da i servitori Prometheus isolati in una sola vista. In fatti, Thanos pò esse usatu solu per sta funzione. Ùn ci vole micca cambiamenti à i servitori Prometheus esistenti!
Durata di conservazione illimitata!
In ogni casu, prima o dopu vulemu almacenà e dati oltre u tempu di ritenzione normale di Prometheus. Avemu sceltu u almacenamentu di l'ughjettu per almacenà e dati storichi. Hè largamente dispunibule in ogni nuvola è ancu in centri di dati in u locu è hè assai costu efficace. Inoltre, quasi tutti l'almacenamiento d'ughjettu hè dispunibule attraversu a famosa API S3.
Prometheus scrive dati da a RAM à u discu circa ogni duie ore. U bloccu di dati almacenatu cuntene tutte e dati per un periudu fissu di tempu è hè immutable. Questu hè assai convenientu perchè Thanos Sidecar pò solu fighjà u repertoriu di dati Prometheus è, cum'è novi blocchi diventanu dispunibuli, caricali in buckets di almacenamiento d'oggetti.
Caricà in u almacenamentu di l'ughjettu immediatamente dopu à scrive à u discu permette ancu di mantene a simplicità di u scraper (Prometheus è Thanos Sidecar). Chì simplificà u supportu, u costu è u disignu di u sistema.
Comu pudete vede, a salvezza di dati hè assai simplice. Ma chì circate di e dumande di dati in u almacenamentu di l'ughjettu?
U cumpunente Thanos Store agisce cum'è un proxy per ricuperà e dati da u almacenamentu di l'ughjettu. Cum'è Thanos Sidecar, participa à u cluster di gossip è implementa l'API Store. In questu modu, Querier esistenti pò trattà cum'è un Sidecar, cum'è una altra fonte di dati di serie temporale - ùn hè micca necessariu cunfigurazione speciale.
I blocchi di dati di serie temporali sò custituiti da parechji schedarii grandi. Caricà nantu à a dumanda seria abbastanza inefficiente, è a cache in u locu necessitaria una quantità enorme di memoria è spaziu di discu.
Invece, Store Gateway sapi cumu trattà u formatu di almacenamiento Prometheus. Grazie à un pianificatore di query intelligente è cachendu solu l'indici necessarii di i blocchi, hè pussibule di riduce e dumande cumplesse à un minimu numeru di richieste HTTP à i fugliali di almacenamiento d'ughjettu. In questu modu, pudete riduce u nùmeru di richieste da quattru à sei ordini di grandezza è ottene tempi di risposta chì sò generalmente difficiuli di distingue da e dumande à e dati nantu à un SSD locale.
Cum'è mostratu in u diagramma sopra, Thanos Querier reduce significativamente u costu per dumanda di dati di almacenamentu di l'ughjettu sfruttendu u formatu di almacenamiento Prometheus è mettendu e dati cunnessi fiancu à fiancu. Utilizendu stu approcciu, pudemu cumminà parechje richieste singuli in un numeru minimu di operazioni di massa.
Compattazione è downsampling
Una volta chì un novu bloccu di dati di serie temporale hè caricatu cù successu in u almacenamentu di l'ughjettu, u trattemu cum'è dati "storici", chì sò immediatamente dispunibuli attraversu u Store Gateway.
In ogni casu, dopu à qualchì tempu, i blocchi da una fonte (Prometheus cù Sidecar) s'accumulanu è ùn utilizanu più u potenziale di indexazione sanu. Per risolve stu prublema, avemu introduttu un altru cumpunente chjamatu Compactor. Simply applicà u mutore di compactazione lucale di Prometheus à e dati storichi in u almacenamentu di l'ughjettu è pò esse eseguitu cum'è un semplice travagliu di batch periodicu.
Grazie à a compressione efficiente, l'interrogazione di l'almacenamiento per un longu periodu di tempu ùn pone micca un prublema in quantu à a dimensione di dati. Tuttavia, u costu potenziale di sballà un miliardo di valori è di eseguisce per mezu di un processore di dumanda inevitabbilmente risultatu in un aumentu drammaticu di u tempu di esecuzione di a dumanda. Per d 'altra banda, postu chì ci sò centinaie di punti di dati per pixel nantu à u screnu, diventa impussibile ancu di visualizà e dati à a risuluzione completa. Cusì, u downsampling ùn hè micca solu pussibule, ma ancu ùn porta micca à una perdita notevuli di precisione.
Per riduzzione di dati, Compactor aggrega continuamente dati à una risoluzione di cinque minuti è una ora. Per ogni chunk prima codificata cù a compressione TSDB XOR, diversi tipi di dati aggregati sò almacenati, cum'è min, max o sum per un bloccu. Questu permette à Querier selezziunà automaticamente un aggregatu chì hè appruvatu per una determinata dumanda PromQL.
Nisuna cunfigurazione speciale hè necessaria per l'utilizatore per utilizà dati di precisione ridutta. Querier cambia automaticamente trà e diverse risoluzioni è dati crudi cum'è l'utilizatore zoom in è alluntanassi. Se vulete, l'utilizatore pò cuntrullà questu direttamente attraversu u paràmetru "passu" in a dumanda.
Siccomu u costu di almacenà un GB hè bassu, per difettu Thanos almacena dati crudi, dati di risoluzione di cinque minuti è di una ora. Ùn ci hè bisognu di sguassà i dati uriginale.
Reguli di registrazione
Ancu cù Thanos, e regule di registrazione sò una parte essenziale di a pila di monitoraghju. Reducenu a cumplessità, a latenza è u costu di e dumande. Sò ancu convenienti per l'utilizatori per ottene dati aggregati per metriche. Thanos hè basatu annantu à l'istanze di vaniglia Prometheus, cusì hè perfettamente accettabile per almacenà e regule di registrazione è e regule d'alerta in un servitore Prometheus esistente. Tuttavia, in certi casi, questu pò esse micca abbastanza:
- Alerta globale è regula (per esempiu, una alerta quandu un serviziu ùn funziona micca più di dui di trè clusters).
- Regula per i dati fora di u almacenamentu locale.
- U desideriu di almacenà tutte e regule è alerti in un locu.
Per tutti questi casi, Thanos include un cumpunente separatu chjamatu Ruler, chì calcula a regula è l'alerta via Thanos Queries. Fornendu una StoreAPI ben cunnisciuta, u node di Query pò accede à metriche appena calculate. In seguitu sò ancu almacenati in u almacenamentu di l'ughjettu è dispunibuli attraversu u Store Gateway.
U putere di Thanos
Thanos hè abbastanza flessibile per esse persunalizatu per adattà à i vostri bisogni. Questu hè soprattuttu utile quandu migrate da u pianu Prometheus. Riassumemu rapidamente ciò chì avemu amparatu nantu à i cumpunenti di Thanos cun un esempiu rapidu. Eccu cumu piglià a vostra vaniglia Prometheus in u mondu di "almacenamiento di metrica illimitatu":
- Aghjunghjite Thanos Sidecar à i vostri servitori Prometheus - per esempiu, un containeru sidecar in un pod Kubernetes.
- Implantate multiple répliques Thanos Querier per pudè vede e dati. In questu stadiu, hè faciule d'istruisce gossip trà Scraper è Querier. Per verificà l'interazzione di cumpunenti, utilizate a metrica "thanos_cluster_members".
Solu questi dui passi sò abbastanza per furnisce una vista globale è una deduplicazione di dati senza saldatura da potenziali rèpliche Prometheus HA! Simply connect your dashboards to the Querier HTTP endpoint o utilizate direttamente l'UI Thanos.
Tuttavia, se avete bisognu di una copia di salvezza di metriche è un almacenamentu à longu andà, vi tuccherà à compie trè passi più:
- Crea un bucket AWS S3 o GCS. Configurate Sidecar per copià e dati in questi buckets. L'almacenamiento di dati lucali pò avà esse minimizatu.
- Implementa Store Gateway è cunnette lu à u vostru cluster di gossip esistente. Avà pudete dumandà i dati salvati!
- Implementa Compactor per migliurà l'efficienza di e dumande nantu à longu periodi di tempu utilizendu compattazione è downsampling.
Sè vo vulete sapè di più, ùn esitate à dà un ochju à i nostri и !
In solu cinque passi, avemu trasfurmatu Prometheus in un sistema di monitoraghju affidabile cù vista globale, tempu di almacenamento illimitatu è putenziale alta dispunibilità di metriche.
Pull request: avemu bisognu di voi!
hè statu un prughjettu open source da u principiu. L'integrazione perfetta cù Prometheus è a capacità di utilizà solu una parte di Thanos facenu una scelta eccellente per scalà u vostru sistema di monitoraghju senza sforzu.
Avemu sempre benvenutu GitHub Pull Requests and Issues. Intantu, sentite liberu di cuntattateci via Github Issues o slacksè vo avete dumande o feedback, o vulete sparte a vostra sperienza usendu! Se ti piace ciò chì facemu in Improbable, ùn esitate à cuntattateci - !
Source: www.habr.com