Traducerea articolului a fost pregătită special pentru studenții cursului .
este un dezvoltator de software, fanatic și rezolvă probleme. El este, de asemenea, întreținător Prometheus și co-fondator al instrumentării Kubernetes SIG. În trecut, a fost inginer de producție la SoundCloud și a condus echipa de monitorizare la CoreOS. În prezent lucrează la Google.
- Inginer Infrastructură la Improbable. Este interesat de noile tehnologii și problemele sistemelor distribuite. Are experiență de programare de nivel scăzut la Intel, experiență de colaborator la Mesos și experiență de producție SRE de clasă mondială la Improbable. Dedicat îmbunătățirii lumii microserviciilor. Cele trei iubiri ale lui: Golang, open source și volei.
Privind la produsul nostru emblematic SpatialOS, puteți ghici că Improbable necesită o infrastructură cloud extrem de dinamică, la scară globală, cu zeci de clustere Kubernetes. Am fost printre primii care au folosit un sistem de monitorizare . Prometheus este capabil să urmărească milioane de valori în timp real și vine cu un limbaj de interogare puternic care vă permite să extrageți informațiile de care aveți nevoie.
Simplitatea și fiabilitatea lui Prometheus este unul dintre principalele sale avantaje. Cu toate acestea, odată ce am depășit o anumită scară, am întâlnit mai multe dezavantaje. Pentru a rezolva aceste probleme ne-am dezvoltat este un proiect open source creat de Improbable pentru a transforma fără probleme clusterele existente Prometheus într-un singur sistem de monitorizare cu stocare nelimitată a datelor istorice. Thanos este disponibil pe Github .
Obiectivele noastre cu Thanos
La o anumită scară, apar probleme care depășesc capacitățile Vanilla Prometheus. Cum să stocați în mod fiabil și economic petaocteți de date istorice? Se poate face acest lucru fără a compromite timpul de răspuns? Este posibil să accesați toate valorile situate pe diferite servere Prometheus cu o singură solicitare API? Există vreo modalitate de a combina datele replicate colectate folosind Prometheus HA?
Pentru a rezolva aceste probleme, am creat Thanos. Următoarele secțiuni descriu modul în care am abordat aceste probleme și explicăm obiectivele noastre.
Interogarea datelor din mai multe instanțe Prometheus (interogare globală)
Prometheus oferă o abordare funcțională a fragmentării. Chiar și un singur server Prometheus oferă suficientă scalabilitate pentru a elibera utilizatorii de complexitatea fragmentării orizontale în aproape toate cazurile de utilizare.
Deși acesta este un model de implementare excelent, este adesea necesar să accesați datele de pe diferite servere Prometheus printr-un singur API sau UI - o vedere globală. Desigur, este posibil să afișați mai multe interogări într-un singur panou Grafana, dar fiecare interogare poate fi executată doar pe un server Prometheus. Pe de altă parte, cu Thanos puteți interoga și agrega date de pe mai multe servere Prometheus, deoarece toate sunt accesibile de la un singur punct final.
Anterior, pentru a obține o vedere globală în Improbable, am organizat instanțele noastre Prometheus într-un nivel pe mai multe . Aceasta a însemnat crearea unui meta server Prometheus care colectează unele dintre valorile de la fiecare server frunză.
Această abordare s-a dovedit problematică. Acest lucru a dus la configurații mai complexe, adăugarea unui punct de eșec potențial suplimentar și aplicarea unor reguli complexe pentru a se asigura că punctul final federal primește doar datele de care are nevoie. În plus, acest tip de federație nu vă permite să obțineți o imagine globală adevărată, deoarece nu toate datele sunt disponibile dintr-o singură solicitare API.
Strâns legată de aceasta este o vizualizare unificată a datelor colectate pe serverele Prometheus de înaltă disponibilitate (HA). Modelul HA al lui Prometheus colectează în mod independent date de două ori, ceea ce este atât de simplu încât nu ar putea fi mai simplu. Cu toate acestea, utilizarea unei vizualizări combinate și deduplicate a ambelor fluxuri ar fi mult mai convenabilă.
Desigur, este nevoie de servere Prometheus foarte disponibile. La Improbable, luăm în serios monitorizarea datelor minut cu minut, dar a avea o instanță Prometheus per cluster este un singur punct de eșec. Orice eroare de configurare sau defecțiune hardware poate duce la pierderea de date importante. Chiar și o simplă implementare poate cauza întreruperi minore în colectarea valorilor, deoarece repornirile pot fi semnificativ mai lungi decât intervalul de scraping.
Stocarea de încredere a datelor istorice
Stocarea de valori ieftine, rapide și pe termen lung este visul nostru (împărtășit de majoritatea utilizatorilor Prometheus). În Improbable, am fost forțați să configuram perioada de păstrare a valorilor la nouă zile (pentru Prometheus 1.8). Acest lucru adaugă limite evidente la cât de departe putem privi.
Prometheus 2.0 s-a îmbunătățit în acest sens, deoarece numărul de serii cronologice nu mai afectează performanța generală a serverului (vezi. ). Cu toate acestea, Prometheus stochează datele pe discul local. Deși compresia de înaltă eficiență a datelor poate reduce semnificativ utilizarea SSD-ului local, în cele din urmă există încă o limită a cantității de date istorice care pot fi stocate.
În plus, la Improbable ne pasă de fiabilitate, simplitate și cost. Discurile locale mari sunt mai dificil de operat și de backup. Acestea costă mai mult și necesită mai multe instrumente de rezervă, rezultând o complexitate inutilă.
Reducerea eșantionării
Odată ce am început să lucrăm cu date istorice, am realizat că există dificultăți fundamentale cu big-O care fac interogările din ce în ce mai lente pe măsură ce lucrăm cu săptămâni, luni și ani de date.
Soluția standard la această problemă ar fi (downsampling) - reducerea frecvenței de eșantionare a semnalului. Cu reducerea eșantionării, putem „scădea” la un interval de timp mai mare și putem menține același număr de mostre, menținând interogările receptive.
Reducerea de eșantionare a datelor vechi este o cerință inevitabilă a oricărei soluții de stocare pe termen lung și depășește scopul Vanilla Prometheus.
Obiective suplimentare
Unul dintre obiectivele inițiale ale proiectului Thanos a fost să se integreze perfect cu orice instalații existente Prometheus. Al doilea obiectiv a fost ușurința în operare cu bariere minime la intrare. Orice dependențe ar trebui să fie ușor satisfăcute atât pentru utilizatorii mici, cât și pentru cei mari, ceea ce înseamnă și un cost de bază scăzut.
Arhitectura Thanos
După ce ne-am enumerat obiectivele în secțiunea anterioară, să le analizăm și să vedem cum rezolvă Thanos aceste probleme.
Vedere globală
Pentru a obține o vedere globală asupra instanțelor Prometheus existente, trebuie să conectăm un singur punct de intrare a cererii la toate serverele. Este exact ceea ce face componenta Thanos. . Este implementat lângă fiecare server Prometheus și acționează ca un proxy, servind date locale Prometheus prin API-ul gRPC Store, permițând recuperarea datelor din seria temporală în funcție de etichetă și interval de timp.
Pe de altă parte este componenta de interogare apatridă, cu scalabilitate, care nu face altceva decât să răspundă la interogări PromQL prin API-ul standard Prometheus HTTP. Querier, Sidecar și alte componente Thanos comunică prin .
- Querier, la primirea unei solicitări, se conectează la serverul Store API corespunzător, adică la Sidecar-urile noastre și primește date din seria temporală de la serverele Prometheus corespunzătoare.
- După aceea, combină răspunsurile și execută o interogare PromQL asupra lor. Querier poate îmbina atât datele disjunse, cât și datele duplicate de la serverele Prometheus HA.
Aceasta rezolvă o piesă majoră a puzzle-ului nostru - combinând datele de la serverele izolate Prometheus într-o singură vizualizare. De fapt, Thanos poate fi folosit doar pentru această funcție. Nu este nevoie să se facă modificări la serverele Prometheus existente!
Perioada de valabilitate nelimitată!
Cu toate acestea, mai devreme sau mai târziu vom dori să stocăm datele dincolo de timpul normal de păstrare al Prometheus. Am ales stocarea obiectelor pentru a stoca datele istorice. Este disponibil pe scară largă în orice cloud, precum și în centrele de date locale și este foarte rentabil. În plus, aproape orice stocare de obiecte este disponibilă prin binecunoscutul API S3.
Prometheus scrie date de pe RAM pe disc aproximativ la fiecare două ore. Blocul de date stocat conține toate datele pentru o perioadă fixă de timp și este imuabil. Acest lucru este foarte convenabil deoarece Thanos Sidecar poate privi pur și simplu directorul de date Prometheus și, pe măsură ce noi blocuri devin disponibile, le poate încărca în găleți de stocare a obiectelor.
Încărcarea în stocarea obiectelor imediat după scrierea pe disc vă permite, de asemenea, să mențineți simplitatea scraper-ului (Prometheus și Thanos Sidecar). Ceea ce simplifică suportul, costurile și proiectarea sistemului.
După cum puteți vedea, copierea de rezervă a datelor este foarte simplă. Dar cum rămâne cu interogarea datelor în stocarea obiectelor?
Componenta Thanos Store acționează ca un proxy pentru a prelua date din stocarea obiectelor. La fel ca Thanos Sidecar, participă la grupul de bârfe și implementează API-ul Store. În acest fel, Querier-ul existent îl poate trata ca pe un Sidecar, ca o altă sursă de date din seria temporală - nu este necesară o configurație specială.
Blocurile de date din seria temporală constau din mai multe fișiere mari. Încărcarea lor la cerere ar fi destul de ineficientă, iar stocarea lor în cache local ar necesita o cantitate mare de memorie și spațiu pe disc.
În schimb, Store Gateway știe cum să gestioneze formatul de stocare Prometheus. Datorită unui planificator inteligent de interogări și stocării în cache numai a părților de index necesare ale blocurilor, este posibil să se reducă interogările complexe la un număr minim de solicitări HTTP către fișierele de stocare a obiectelor. În acest fel, puteți reduce numărul de solicitări cu patru până la șase ordine de mărime și puteți obține timpi de răspuns care sunt, în general, dificil de distins de cererile de date de pe un SSD local.
După cum se arată în diagrama de mai sus, Thanos Querier reduce semnificativ costul pe interogare al datelor de stocare a obiectelor prin valorificarea formatului de stocare Prometheus și plasarea datelor aferente una lângă alta. Folosind această abordare, putem combina multe cereri individuale într-un număr minim de operațiuni în bloc.
Compactare și eșantionare
Odată ce un nou bloc de date din seria temporală este încărcat cu succes în stocarea obiectelor, îl tratăm ca date „istorice”, care sunt disponibile imediat prin Store Gateway.
Cu toate acestea, după ceva timp, blocurile dintr-o singură sursă (Prometheus cu Sidecar) se acumulează și nu mai folosesc întregul potențial de indexare. Pentru a rezolva această problemă, am introdus o altă componentă numită Compactor. Pur și simplu aplică motorul de compactare local al lui Prometheus la datele istorice din stocarea obiectelor și poate fi rulat ca un simplu job periodic în lot.
Datorită compresiei eficiente, interogarea stocării pe o perioadă lungă de timp nu reprezintă o problemă în ceea ce privește dimensiunea datelor. Cu toate acestea, costul potențial al despachetării unui miliard de valori și al rulării lor printr-un procesor de interogări va duce inevitabil la o creștere dramatică a timpului de execuție a interogărilor. Pe de altă parte, deoarece există sute de puncte de date per pixel pe ecran, devine imposibil să vizualizați datele la rezoluție maximă. Astfel, eșantionarea nu este numai posibilă, dar nici nu va duce la o pierdere vizibilă a preciziei.
Pentru a reduce eșantionarea datelor, Compactor agregează continuu datele la o rezoluție de cinci minute și o oră. Pentru fiecare bucată brută codificată folosind compresia TSDB XOR, sunt stocate diferite tipuri de date agregate, cum ar fi min, max sau sumă pentru un bloc. Acest lucru permite Querier să selecteze automat un agregat care este adecvat pentru o anumită interogare PromQL.
Nu este necesară nicio configurație specială pentru ca utilizatorul să utilizeze date cu precizie redusă. Querier comută automat între diferite rezoluții și date brute pe măsură ce utilizatorul mărește și micșorează. Dacă dorește, utilizatorul poate controla acest lucru direct prin parametrul „pas” din cerere.
Deoarece costul stocării unui GB este scăzut, Thanos stochează implicit date brute, date de rezoluție de cinci minute și de o oră. Nu este nevoie să ștergeți datele originale.
Reguli de înregistrare
Chiar și cu Thanos, regulile de înregistrare sunt o parte esențială a stivei de monitorizare. Acestea reduc complexitatea, latența și costul interogărilor. De asemenea, sunt convenabile pentru utilizatori să obțină date agregate după valori. Thanos se bazează pe instanțe Vanilla Prometheus, deci este perfect acceptabil să stocați regulile de înregistrare și regulile de alertă pe un server Prometheus existent. Cu toate acestea, în unele cazuri, acest lucru poate să nu fie suficient:
- Alertă și regulă globală (de exemplu, o alertă atunci când un serviciu nu funcționează în mai mult de două din trei clustere).
- Regula pentru datele din afara stocării locale.
- Dorința de a stoca toate regulile și alertele într-un singur loc.
Pentru toate aceste cazuri, Thanos include o componentă separată numită Ruler, care calculează regula și alerta prin Thanos Queries. Prin furnizarea unui StoreAPI bine-cunoscut, nodul Query poate accesa valorile proaspăt calculate. Ulterior, acestea sunt stocate și în stocarea obiectelor și puse la dispoziție prin Store Gateway.
Puterea lui Thanos
Thanos este suficient de flexibil pentru a fi personalizat pentru a se potrivi nevoilor dvs. Acest lucru este util în special atunci când migrați din simplu Prometheus. Să recapitulăm rapid ceea ce am învățat despre componentele Thanos cu un exemplu rapid. Iată cum să-ți duci Vanilla Prometheus în lumea „stocării nelimitate de valori”:
- Adăugați Thanos Sidecar la serverele dvs. Prometheus - de exemplu, un container sidecar într-un pod Kubernetes.
- Implementați mai multe replici Thanos Querier pentru a putea vizualiza datele. În această etapă, este ușor să configurați bârfe între Scraper și Querier. Pentru a verifica interacțiunea componentelor, utilizați valoarea „thanos_cluster_members”.
Doar acești doi pași sunt suficienți pentru a oferi vizualizare globală și deduplicare fără întreruperi a datelor din potențialele replici Prometheus HA! Pur și simplu conectați-vă tablourile de bord la punctul final HTTP Querier sau utilizați direct interfața de utilizare Thanos.
Cu toate acestea, dacă aveți nevoie de backup pentru valori și de stocare pe termen lung, va trebui să parcurgeți încă trei pași:
- Creați o găleată AWS S3 sau GCS. Configurați Sidecar pentru a copia datele în aceste compartimente. Stocarea locală a datelor poate fi acum redusă la minimum.
- Implementați Store Gateway și conectați-l la clusterul dvs. de bârfă existent. Acum puteți interoga datele pentru care faceți backup!
- Implementați Compactor pentru a îmbunătăți eficiența interogărilor pe perioade lungi de timp folosind compactarea și eșantionarea.
Dacă doriți să aflați mai multe, nu ezitați să aruncați o privire asupra noastră и !
În doar cinci pași, am transformat Prometheus într-un sistem de monitorizare fiabil, cu vedere globală, timp de stocare nelimitat și posibilă disponibilitate ridicată a indicilor.
Cerere de tragere: avem nevoie de tine!
a fost un proiect open source de la bun început. Integrarea perfectă cu Prometheus și capacitatea de a utiliza doar o parte din Thanos îl fac o alegere excelentă pentru scalarea sistemului de monitorizare fără efort.
Întotdeauna salutăm solicitările și problemele GitHub Pull. Între timp, nu ezitați să ne contactați prin Github Issues sau slackdacă aveți întrebări sau feedback sau doriți să împărtășiți experiența dvs. de utilizare! Dacă vă place ceea ce facem la Improbable, nu ezitați să ne contactați - !
Sursa: www.habr.com