{"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\/ro\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 Prometheus scalabil","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Traducerea articolului a fost preg\u0103tit\u0103 special pentru studen\u021bii cursului \u201ePracticile \u0219i instrumentele DevOps\u201d<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 dezvoltator de software, pasionat de Go \u0219i iubitor de provoc\u0103ri complexe. De asemenea, este mentinator pentru Prometheus \u0219i cofondator al Kubernetes SIG instrumentation. \u00cen trecut, a fost inginer de produc\u021bie la SoundCloud \u0219i a condus echipa de monitorizare la CoreOS. \u00cen prezent, lucreaz\u0103 la Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 inginer de infrastructur\u0103 la Improbable. Este interesat de tehnologiile noi \u0219i de problemele sistemelor distribuite. Are experien\u021b\u0103 \u00een programarea la nivel de baz\u0103 la Intel, experien\u021b\u0103 ca contributor \u00een Mesos \u0219i experien\u021b\u0103 de produc\u021bie SRE la nivel global la Improbable. Lucreaz\u0103 la \u00eembun\u0103t\u0103\u021birea lumii microserviciilor. Cele trei iubiri ale sale sunt: Golang, codul surs\u0103 deschis \u0219i voleiul.<\/i><\/p>\n

Privind produsul nostru de v\u00e2rf, SpatialOS, po\u021bi intui c\u0103 Improbable necesit\u0103 o infrastructur\u0103 cloud dinamic\u0103, la scar\u0103 global\u0103, cu zeci de clustere Kubernetes. Am fost printre primii care au \u00eenceput s\u0103 utilizeze sistemul de monitorizare Prometheus<\/a><\/noindex>. Prometheus poate urm\u0103ri milioane de metrici \u00een timp real \u0219i vine cu un limbaj de interogare puternic, care permite extragerea informa\u021biilor necesare.<\/p>\n

Simplicity and reliability of Prometheus is one of its main advantages. However, after reaching a certain scale, we encountered several shortcomings. To address these issues, we developed Thanos<\/a><\/noindex> \u2014 un proiect open-source, creat de Improbable, pentru transformarea seamless a clusterelor existente Prometheus \u00eentr-un sistem de monitorizare unificat cu stocare nelimitat\u0103 a datelor istorice. Thanos este disponibil pe Github aici<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

R\u0103m\u00e2i la curent cu ultimele nout\u0103\u021bi de la Improbable.<\/a><\/noindex><\/p>\n

Obiectivele noastre cu Thanos<\/h2>\n

\nLa o anumit\u0103 scar\u0103, apar probleme care dep\u0103\u0219esc capacit\u0103\u021bile vaniliei Prometheus. Cum putem stoca \u00een mod fiabil \u0219i economic petabytes de date istorice? Se poate face acest lucru f\u0103r\u0103 a afecta timpii de r\u0103spuns la interog\u0103ri? Putem accesa toate metricile afl\u00e2ndu-se pe servere Prometheus diferite printr-o singur\u0103 interogare API? Putem cumva s\u0103 unim datele replicate, adunate folosind Prometheus HA?<\/p>\n

Pentru a r\u0103spunde acestor \u00eentreb\u0103ri, am creat Thanos. \u00cen sec\u021biunile urm\u0103toare, v\u0103 vom descrie cum am abordat aceste \u00eentreb\u0103ri \u0219i vom explica obiectivele pe care le-am urm\u0103rit.<\/p>\n

Interogarea datelor din mai multe instan\u021be Prometheus (interogare global\u0103)<\/h4>\n

\nPrometheus ofer\u0103 o abordare func\u021bional\u0103 pentru shard-ing. Chiar \u0219i un singur server Prometheus asigur\u0103 o scalabilitate adecvat\u0103 pentru a elibera utilizatorii de complexit\u0103\u021bile shard-ului orizontal, practic \u00een toate cazurile de utilizare.<\/p>\n

De\u0219i este un model excelent de desf\u0103\u0219urare, adesea este necesar s\u0103 accesa\u021bi datele de pe diferite servere Prometheus printr-un API sau UI unic \u2014 global view. Desigur, exist\u0103 posibilitatea de a afi\u0219a mai multe cereri \u00eentr-un singur panou Grafana, dar fiecare cerere poate fi efectuat\u0103 doar pe un singur server Prometheus. Pe de alt\u0103 parte, cu ajutorul Thanos, pute\u021bi solicita \u0219i agrega date de la mai multe servere Prometheus, deoarece toate sunt disponibile de la un singur punct final.<\/p>\n

Anterior, pentru a ob\u021bine global view \u00een Improbable, ne-am organizat instan\u021bele Prometheus \u00eentr-o structur\u0103 ierarhic\u0103. Federarea Ierarhic\u0103<\/a><\/noindex>. Aceasta a \u00eensemnat crearea unui meta-server Prometheus, care colecteaz\u0103 o parte din metricile fiec\u0103rui server \u201eleaf\u201d.<\/p>\n

\"Thanos
\n
\nAceast\u0103 abordare s-a dovedit a fi problematic\u0103. A dus la complicarea configura\u021biei, ad\u0103ugarea unui poten\u021bial punct de e\u0219ec suplimentar \u0219i aplicarea unor reguli complexe pentru a oferi punctului final federat doar datele necesare. \u00cen plus, o astfel de federare nu permite ob\u021binerea unui adev\u0103rat global view, deoarece nu toate datele sunt disponibile dintr-o singur\u0103 cerere API.<\/p>\n

Acest lucru este str\u00e2ns legat de viziunea unitar\u0103 a datelor colectate pe servere Prometheus cu \u00eenalt\u0103 disponibilitate (high-availability, HA). Modelul HA Prometheus colecteaz\u0103 datele independent de dou\u0103 ori, ceea ce este at\u00e2t de simplu \u00eenc\u00e2t nu poate fi mai simplu. Cu toate acestea, utilizarea unei viziuni combinate \u0219i deduplicat\u0103 a ambelor fluxuri ar fi mult mai convenabil\u0103.<\/p>\n

Desigur, exist\u0103 o nevoie de servere Prometheus cu \u00eenalt\u0103 disponibilitate. La Improbable, trat\u0103m foarte serios monitorizarea datelor la fiecare minut, dar a avea o singur\u0103 instan\u021b\u0103 Prometheus pe cluster este un punct unic de e\u0219ec. Orice eroare de configurare sau defec\u021biune hardware poate duce poten\u021bial la pierderea unor date importante. Chiar \u0219i o desf\u0103\u0219urare simpl\u0103 poate duce la mici \u00eentreruperi \u00een colectarea metricilor, deoarece repornirea poate dura semnificativ mai mult dec\u00e2t intervalul de scraping.<\/p>\n

Stocare fiabil\u0103 a datelor istorice<\/h4>\n

\nStocarea metricelor ieftin\u0103, rapid\u0103 \u0219i de lung\u0103 durat\u0103 este visul nostru (\u00eemp\u0103rt\u0103\u0219it de majoritatea utilizatorilor Prometheus). La Improbable, a trebuit s\u0103 set\u0103m perioada de stocare a metricelor pe nou\u0103 zile (pentru Prometheus 1.8). Aceasta aduce limit\u0103ri evidente asupra c\u00e2t de departe putem privi \u00eenapoi.<\/p>\n

Prometheus 2.0 a devenit mai bun \u00een aceast\u0103 privin\u021b\u0103, deoarece num\u0103rul de serii temporale nu mai influen\u021beaz\u0103 performan\u021ba general\u0103 a serverului (vezi. prezentarea de la KubeCon despre Prometheus 2<\/a><\/noindex>). Cu toate acestea, Prometheus stocheaz\u0103 datele pe discul local. De\u0219i compresia de date de \u00eenalt\u0103 performan\u021b\u0103 poate reduce semnificativ utilizarea SSD-ului local, totu\u0219i exist\u0103 o limitare asupra volumului de date istorice stocate.<\/p>\n

\u00cen plus, la Improbable, ne pas\u0103 de fiabilitate, simplitate \u0219i costuri. Discurile locale mari sunt mai greu de operat \u0219i de realizat backup. Acestea sunt mai scumpe \u0219i necesit\u0103 mai multe instrumente pentru backup, ceea ce duce la o complexitate excesiv\u0103.<\/p>\n

Reducerea<\/h4>\n

\nOdat\u0103 ce am \u00eenceput s\u0103 lucr\u0103m cu datele istorice, am realizat c\u0103 exist\u0103 dificult\u0103\u021bi fundamentale cu O-mare, care fac ca interog\u0103rile s\u0103 devin\u0103 din ce \u00een ce mai lente atunci c\u00e2nd lucr\u0103m cu date pe s\u0103pt\u0103m\u00e2ni, luni \u0219i ani.<\/p>\n

Solu\u021bia standard pentru aceast\u0103 problem\u0103 este reducing<\/a><\/noindex> (downsampling) \u2013 reducerea frecven\u021bei de e\u0219antionare a semnalului. Prin sc\u0103derea e\u0219antion\u0103rii, putem \u201ereduce scala\u201d la un interval de timp mai mare \u0219i p\u0103stra acela\u0219i num\u0103r de e\u0219antioane, ceea ce va permite men\u021binerea rapidit\u0103\u021bii interog\u0103rilor.<\/p>\n

Reducerea datelor vechi este o cerin\u021b\u0103 inevitabil\u0103 a oric\u0103rei solu\u021bii pentru stocarea pe termen lung \u0219i dep\u0103\u0219e\u0219te Prometheus-ul vanilat.<\/p>\n

Obiective suplimentare<\/h4>\n

\nUnul dintre obiectivele ini\u021biale ale proiectului Thanos a fost integrarea f\u0103r\u0103 cusur cu orice instalare existent\u0103 a Prometheus. Al doilea obiectiv a fost u\u0219urin\u021ba \u00een utilizare cu o barier\u0103 de intrare minim\u0103. Orice dependen\u021be trebuie s\u0103 fie u\u0219or satisf\u0103cute at\u00e2t pentru utilizatori mici, c\u00e2t \u0219i pentru cei mari, ceea ce implic\u0103, de asemenea, costuri de baz\u0103 reduse.<\/p>\n

Arhitectura Thanos<\/h2>\n

\nDup\u0103 ce am enumerat obiectivele noastre \u00een sec\u021biunea anterioar\u0103, haide\u021bi s\u0103 lucr\u0103m la ele \u0219i s\u0103 vedem cum Thanos abordeaz\u0103 aceste probleme.<\/p>\n

Vizuinea global\u0103<\/h4>\n

\nPentru a ob\u021bine o vedere global\u0103 asupra instan\u021belor existente Prometheus, trebuie s\u0103 conect\u0103m un punct unic de intrare al cererilor cu toate serverele. Acesta este rolul componentului Thanos. Sidecar<\/a><\/noindex>. Acesta este desf\u0103\u0219urat l\u00e2ng\u0103 fiecare server Prometheus \u0219i func\u021bioneaz\u0103 ca un proxy, servind datele locale Prometheus prin intermediul interfe\u021bei gRPC Store API, permi\u021b\u00e2nd selectarea datelor time series pe baza etichetelor \u0219i intervalului de timp.<\/p>\n

Pe de alt\u0103 parte, se afl\u0103 componenta Querier, care este scalabil\u0103 orizontal \u0219i f\u0103r\u0103 stocare de stare, care face mai mult dec\u00e2t s\u0103 r\u0103spund\u0103 la cererile PromQL prin intermediul standard HTTP API al Prometheus. Componentele Querier, Sidecar \u0219i alte module Thanos interac\u021bioneaz\u0103 prin protocul gossip.<\/a><\/noindex>.<\/p>\n

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

    \n
  1. Querier, la primirea unei cereri, se conecteaz\u0103 la serverul corespunz\u0103tor Store API, adic\u0103 la Sidecar-urile noastre, \u0219i ob\u021bine datele time series de la serverele Prometheus corespunz\u0103toare.<\/li>\n
  2. Apoi, acesta combin\u0103 r\u0103spunsurile \u0219i execut\u0103 cererea PromQL. Querier poate combina date at\u00e2t din surse necorelate, c\u00e2t \u0219i date duplicate de la serverele HA Prometheus.<\/li>\n<\/ol>\n

    \nAceasta rezolv\u0103 cea mai mare parte a problemei noastre \u2014 combinarea datelor de pe serverele izolate Prometheus \u00eentr-o singur\u0103 imagine. Practic, Thanos poate fi utilizat doar pentru aceast\u0103 func\u021bionalitate. Nu sunt necesare modific\u0103ri \u00een serverele Prometheus existente!<\/p>\n

    Stocare nelimitat\u0103!<\/h4>\n

    \nCu toate acestea, mai devreme sau mai t\u00e2rziu, vom dori s\u0103 p\u0103str\u0103m datele care dep\u0103\u0219esc perioada obi\u0219nuit\u0103 de stocare Prometheus. Pentru stocarea datelor istorice, am ales un serviciu de stocare de obiecte. Acesta este disponibil pe scar\u0103 larg\u0103 \u00een orice cloud, precum \u0219i \u00een centre de date locale, \u0219i este foarte economic. \u00cen plus, aproape orice serviciu de stocare de obiecte este accesibil prin binecunoscutul S3 API.<\/p>\n

    Prometheus scrie datele din memoria opera\u021bional\u0103 pe disc la aproximativ fiecare dou\u0103 ore. Modul \u00een care datele sunt salvate con\u021bine toate datele pentru o perioad\u0103 fix\u0103 de timp \u0219i este imuabil. Acest lucru este foarte convenabil, deoarece Thanos Sidecar poate doar s\u0103 verifice catalogul de date Prometheus \u0219i, pe m\u0103sur\u0103 ce apar noi module, s\u0103 le \u00eencarce \u00een bucketurile serviciului de stocare de obiecte.<\/p>\n

    \"Thanos
    \n
    \n\u00cenc\u0103rcarea \u00een serviciul de stocare de obiecte imediat dup\u0103 scrierea pe disc permite de asemenea men\u021binerea simplit\u0103\u021bii \u201escraper-ului\u201d (Prometheus \u0219i Thanos Sidecar). Acest lucru simplific\u0103 \u00eentre\u021binerea, costurile \u0219i designul sistemului.<\/p>\n

    Dup\u0103 cum pute\u021bi vedea, backup-ul datelor se realizeaz\u0103 foarte simplu. Dar ce zicem despre cererea de date din stocarea obiectelor?<\/p>\n

    Componenta Thanos Store ac\u021bioneaz\u0103 ca un proxy pentru ob\u021binerea datelor din stocarea obiectelor. La fel ca Thanos Sidecar, acesta particip\u0103 la clusterul gossip \u0219i implementeaz\u0103 API-ul Store. Astfel, Querier-urile existente \u00eel pot considera ca pe un Sidecar, ca o alt\u0103 surs\u0103 de date time series \u2014 nicio configurare special\u0103 nu este necesar\u0103.<\/p>\n

    \"Thanos
    \n
    \nBlocurile de date time series sunt formate din mai multe fi\u0219iere mari. Desc\u0103rcarea lor la cerere ar fi destul de ineficient\u0103, iar stocarea local\u0103 \u00een cache ar necesita o cantitate uria\u0219\u0103 de memorie \u0219i spa\u021biu pe disc.<\/p>\n

    \u00cen schimb, Store Gateway \u0219tie cum s\u0103 gestioneze formatul de stocare Prometheus. Datorit\u0103 unui planificator de cereri inteligent \u0219i a stoc\u0103rii \u00een cache doar a p\u0103r\u021bilor index necesare ale blocurilor, a devenit posibil s\u0103 reducem cererile complexe la un num\u0103r minim de cereri HTTP c\u0103tre fi\u0219ierele din stocarea obiectelor. Astfel, se poate reduce num\u0103rul de cereri cu patru p\u00e2n\u0103 la \u0219ase ordine de m\u0103rime \u0219i se poate ob\u021bine un timp de r\u0103spuns care este, \u00een general, greu de deosebit de cererile de date pe un SSD local.<\/p>\n

    \"Thanos
    \n
    \nDup\u0103 cum este ar\u0103tat \u00een diagrama de mai sus, Thanos Querier reduce semnificativ costurile pentru o cerere de date din stocarea obiectelor, folosind formatul de stocare Prometheus \u0219i plas\u00e2nd datele conexe aproape. Folosind aceast\u0103 abordare, putem combina numeroase cereri individuale \u00eentr-un num\u0103r minim de opera\u021bii bulk.<\/p>\n

    Compresia \u0219i downsampling-ul<\/h4>\n

    \nDup\u0103 ce un nou bloc de date time series a fost \u00eenc\u0103rcat cu succes \u00een stocarea obiectelor, \u00eel consider\u0103m date \u201eistorice\u201d, care devin imediat disponibile prin Store Gateway.<\/p>\n

    Cu toate acestea, dup\u0103 un timp, blocurile dintr-o singur\u0103 surs\u0103 (Prometheus cu Sidecar) se acumuleaz\u0103 \u0219i nu mai profit\u0103 din plin de poten\u021bialul de indexare. Pentru a rezolva aceast\u0103 problem\u0103, am introdus un alt component numit Compactor. Acesta aplic\u0103 pur \u0219i simplu mecanismul local de compresie Prometheus datelor istorice din stocarea obiectelor \u0219i poate fi rulat ca o simpl\u0103 sarcin\u0103 programat\u0103 periodic.<\/p>\n

    \"Thanos
    \n
    \nDatorit\u0103 comprim\u0103rii eficiente, solicit\u0103rile de stocare pe o perioad\u0103 lung\u0103 de timp nu reprezint\u0103 o problem\u0103 din punct de vedere al dimensiunii datelor. Totu\u0219i, costul poten\u021bial de descompresie a unui miliard de valori \u0219i de procesare a acestora va duce inevitabil la o cre\u0219tere semnificativ\u0103 a timpului de execu\u021bie al cererii. Pe de alt\u0103 parte, deoarece pentru fiecare pixel de pe ecran exist\u0103 sute de puncte de date, devine imposibil s\u0103 se vizualizeze chiar \u0219i datele \u00een rezolu\u021bie maxim\u0103. Astfel, downsampling-ul nu este doar posibil, ci nu va duce la o pierdere semnificativ\u0103 a preciziei. <\/p>\n

    \"Thanos
    \n
    \nPentru downsampling-ul datelor, Compactor agreg\u0103 continuu datele cu o rezolu\u021bie de cinci minute \u0219i o or\u0103. Pentru fiecare fragment nestructurat, codificat cu compresia TSDB XOR, sunt stocate diferite tipuri de date agregate, cum ar fi min, max sau sum pentru un singur bloc. Aceasta permite Querier-ului s\u0103 selecteze automat agregatul care se potrive\u0219te pentru solicitarea PromQL dat\u0103. <\/p>\n

    Pentru utilizarea datelor cu precizie redus\u0103, utilizatorul nu necesit\u0103 nicio configurare special\u0103. Querier-ul trece automat \u00eentre diferite rezolu\u021bii \u0219i date nestructurate pe m\u0103sur\u0103 ce utilizatorul m\u0103re\u0219te sau mic\u0219oreaz\u0103 scala. Dac\u0103 dore\u0219te, utilizatorul poate gestiona acest lucru direct prin parametrul 'step' din solicitare. <\/p>\n

    Av\u00e2nd \u00een vedere c\u0103 costul stoc\u0103rii unui GB este redus, Thanos p\u0103streaz\u0103 implicit datele originale, datele cu rezolu\u021bie de cinci minute \u0219i de o or\u0103. Nu este necesar s\u0103 se elimine datele originale.<\/p>\n

    Reguli de \u00eenregistrare<\/h2>\n

    \nChiar \u0219i cu Thanos, regulile de \u00eenregistrare sunt o parte esen\u021bial\u0103 a stivei de monitorizare. Acestea reduc complexitatea, laten\u021ba \u0219i costul solicit\u0103rilor. De asemenea, sunt utile utilizatorilor pentru a ob\u021bine date agregate pe metrici. Thanos se bazeaz\u0103 pe instan\u021bele vanille ale Prometheus, a\u0219a c\u0103 este absolut acceptabil s\u0103 se p\u0103streze regulile de \u00eenregistrare \u0219i regulile de alert\u0103 pe serverul Prometheus existent. Totu\u0219i, \u00een unele cazuri, acest lucru poate s\u0103 nu fie suficient:<\/p>\n