Thanos ā€” mērogojams Prometejs

Raksta tulkojums tika sagatavots speciāli kursa studentiem "DevOps prakse un rīki".

Fabians Reinarts ir programmatÅ«ras izstrādātājs, aizrautÄ«gs un problēmu risinātājs. ViņŔ ir arÄ« Prometheus uzturētājs un Kubernetes SIG instrumentācijas lÄ«dzdibinātājs. Agrāk viņŔ bija ražoÅ”anas inženieris uzņēmumā SoundCloud un vadÄ«ja CoreOS uzraudzÄ«bas komandu. PaÅ”laik strādā Google.

Barteks Plotka - infrastruktÅ«ras inženieris uzņēmumā Improbable. Viņu interesē jaunās tehnoloÄ£ijas un sadalÄ«to sistēmu problēmas. Viņam ir zema lÄ«meņa programmÄ“Å”anas pieredze uzņēmumā Intel, lÄ«dzstrādnieku pieredze uzņēmumā Mesos un pasaules lÄ«meņa SRE ražoÅ”anas pieredze uzņēmumā Improbable. VeltÄ«ts mikropakalpojumu pasaules uzlaboÅ”anai. Viņa trÄ«s mÄ«lestÄ«bas: Golang, atvērtā koda un volejbols.

AplÅ«kojot mÅ«su vadoÅ”o produktu SpatialOS, varat nojaust, ka Improbable ir nepiecieÅ”ama ļoti dinamiska, globāla mēroga mākoņa infrastruktÅ«ra ar desmitiem Kubernetes klasteru. Mēs bijām vieni no pirmajiem, kas izmantoja uzraudzÄ«bas sistēmu Prometejs. Prometheus spēj reāllaikā izsekot miljoniem metrikas, un tam ir jaudÄ«ga vaicājumu valoda, kas ļauj iegÅ«t nepiecieÅ”amo informāciju.

Prometheus vienkārŔība un uzticamÄ«ba ir viena no tā galvenajām priekÅ”rocÄ«bām. Tomēr, tiklÄ«dz esam pārsnieguÅ”i noteiktu mērogu, mēs saskārāmies ar vairākiem trÅ«kumiem. Lai atrisinātu Ŕīs problēmas, mēs esam izstrādājuÅ”i Thanos ir Improbable izveidots atvērtā pirmkoda projekts, lai nemanāmi pārveidotu esoŔās Prometheus kopas vienā uzraudzÄ«bas sistēmā ar neierobežotu vēsturisko datu glabāŔanu. Thanos ir pieejams vietnē Github Å”eit.

Esiet informēts par jaunākajām ziņām no Improbable.

Mūsu mērķi ar Thanos

Noteiktā mērogā rodas problēmas, kas pārsniedz vaniļas Prometeja iespējas. Kā droÅ”i un ekonomiski uzglabāt vēsturisko datu petabaitus? Vai to var izdarÄ«t, nesamazinot reakcijas laiku? Vai ar vienu API pieprasÄ«jumu ir iespējams piekļūt visiem rādÄ«tājiem, kas atrodas dažādos Prometheus serveros? Vai ir kāds veids, kā apvienot replicētos datus, kas savākti, izmantojot Prometheus HA?

Lai risinātu Ŕīs problēmas, mēs izveidojām Thanos. Nākamajās sadaļās ir aprakstÄ«ts, kā mēs risinājām Å”os jautājumus, un izskaidroti mÅ«su mērÄ·i.

Datu vaicāŔana no vairākiem Prometheus gadījumiem (globāls vaicājums)

Prometheus piedāvā funkcionālu pieeju sadalÄ«Å”anai. Pat viens Prometheus serveris nodroÅ”ina pietiekamu mērogojamÄ«bu, lai gandrÄ«z visos lietoÅ”anas gadÄ«jumos atbrÄ«votu lietotājus no sarežģītās horizontālās sadalÄ«Å”anas.

Lai gan Å”is ir lielisks izvietoÅ”anas modelis, bieži vien ir nepiecieÅ”ams piekļūt datiem dažādos Prometheus serveros, izmantojot vienu API vai UI ā€” globālo skatu. Protams, vienā Grafana panelÄ« ir iespējams attēlot vairākus vaicājumus, taču katru vaicājumu var izpildÄ«t tikai vienā Prometheus serverÄ«. No otras puses, izmantojot Thanos, varat meklēt un apkopot datus no vairākiem Prometheus serveriem, jo ā€‹ā€‹tie visi ir pieejami no viena galapunkta.

IepriekÅ”, lai iegÅ«tu globālu skatÄ«jumu programmā Improbable, mēs organizējām Prometheus gadÄ«jumus vairākos lÄ«meņos. Hierarhiskā federācija. Tas nozÄ«mēja viena Prometheus meta servera izveidi, kas apkopo dažus rādÄ«tājus no katra lapu servera.

Thanos ā€” mērogojams Prometejs

Å Ä« pieeja izrādÄ«jās problemātiska. Tā rezultātā ir izveidotas sarežģītākas konfigurācijas, ir pievienots papildu potenciāls atteices punkts un tiek piemēroti sarežģīti noteikumi, lai nodroÅ”inātu, ka apvienotais galapunkts saņem tikai tam nepiecieÅ”amos datus. Turklāt Ŕāda veida federācija neļauj iegÅ«t patiesu globālu skatÄ«jumu, jo ne visi dati ir pieejami no viena API pieprasÄ«juma.

Ar to ir cieÅ”i saistÄ«ts vienots skatÄ«jums uz datiem, kas savākti augstas pieejamÄ«bas (HA) Prometheus serveros. Prometheus HA modelis neatkarÄ«gi savāc datus divas reizes, kas ir tik vienkārÅ”i, ka nevar bÅ«t vienkārŔāk. Tomēr daudz ērtāk bÅ«tu izmantot abu straumju kombinētu un atdalÄ«tu skatu.

Protams, ir nepiecieÅ”ami augsti pieejami Prometheus serveri. Uzņēmumā Improbable mēs ļoti nopietni uztveram datu pārraudzÄ«bu minÅ«tēs, taču viena Prometheus instance katrā klasterÄ« ir vienÄ«gais kļūmes punkts. Jebkura konfigurācijas kļūda vai aparatÅ«ras kļūme var izraisÄ«t svarÄ«gu datu zudumu. Pat vienkārÅ”a izvietoÅ”ana var radÄ«t nelielus traucējumus metrikas apkopoÅ”anā, jo restartÄ“Å”ana var bÅ«t ievērojami ilgāka par nokasÄ«Å”anas intervālu.

Uzticama vēsturisko datu glabāŔana

Lēta, ātra un ilgtermiņa metrikas glabāŔana ir mÅ«su sapnis (kopÄ«gojas ar lielāko daļu Prometheus lietotāju). Neticamā gadÄ«jumā mēs bijām spiesti konfigurēt metrikas saglabāŔanas periodu uz deviņām dienām (Prometheus 1.8). Tas rada acÄ«mredzamas robežas tam, cik tālu mēs varam skatÄ«ties atpakaļ.

Prometheus 2.0 Å”ajā ziņā ir uzlabojies, jo laikrindu skaits vairs neietekmē servera kopējo veiktspēju (sk. KubeCon pamatruna par Prometheus 2). Tomēr Prometheus datus saglabā vietējā diskā. Lai gan augstas efektivitātes datu saspieÅ”ana var ievērojami samazināt vietējā SSD lietojumu, galu galā joprojām ir ierobežots vēsturisko datu apjoms, ko var uzglabāt.

Turklāt Improbable mums rÅ«p uzticamÄ«ba, vienkārŔība un izmaksas. Lielus lokālos diskus ir grÅ«tāk darbināt un dublēt. Tie maksā vairāk un prasa vairāk dublÄ“Å”anas rÄ«ku, kas rada nevajadzÄ«gu sarežģītÄ«bu.

IztverŔanas samazināŔana

Kad sākām strādāt ar vēsturiskiem datiem, mēs sapratām, ka pastāv bÅ«tiskas problēmas ar big-O, kas padara vaicājumus lēnākus un lēnākus, strādājot ar nedēļu, mēneÅ”u un gadu datiem.

Standarta risinājums Å”ai problēmai bÅ«tu samazināŔana (downsampling) - signāla paraugu ņemÅ”anas frekvences samazināŔana. Izmantojot samazinātu iztverÅ”anu, mēs varam ā€œsamazinātā€ lÄ«dz lielākam laika diapazonam un uzturēt tādu paÅ”u paraugu skaitu, saglabājot vaicājumu atsaucÄ«bu.

Veco datu samazināŔana ir neizbēgama jebkura ilgtermiņa uzglabāŔanas risinājuma prasÄ«ba, un tā ir ārpus vaniļas Prometheus darbÄ«bas jomas.

Papildu mērķi

Viens no sākotnējiem Thanos projekta mērÄ·iem bija nemanāmi integrēties ar visām esoÅ”ajām Prometheus instalācijām. Otrais mērÄ·is bija darbÄ«bas vieglums ar minimāliem ŔķērŔļiem ienākÅ”anai. Jebkuras atkarÄ«bas ir viegli apmierināmas gan maziem, gan lieliem lietotājiem, kas nozÄ«mē arÄ« zemas bāzes izmaksas.

Thanos arhitektūra

Pēc mÅ«su mērÄ·u uzskaitÄ«Å”anas iepriekŔējā sadaļā, strādāsim ar tiem un redzēsim, kā Thanos atrisina Ŕīs problēmas.

Globālais skats

Lai iegÅ«tu globālu skatu uz esoÅ”ajiem Prometheus gadÄ«jumiem, mums ir jāsaista viens pieprasÄ«juma ievades punkts ar visiem serveriem. TieÅ”i to dara Thanos komponents. Sānu kaste. Tas tiek izvietots blakus katram Prometheus serverim un darbojas kā starpniekserveris, apkalpojot vietējos Prometheus datus, izmantojot gRPC Store API, ļaujot izgÅ«t laikrindu datus pēc taga un laika diapazona.

No otras puses, ir mērogojams, bezstāvoklis Querier komponents, kas sniedz tikai atbildes uz PromQL vaicājumiem, izmantojot standarta Prometheus HTTP API. Querier, Sidecar un citi Thanos komponenti sazinās, izmantojot tenku protokols.

Thanos ā€” mērogojams Prometejs

  1. Querier, saņemot pieprasÄ«jumu, izveido savienojumu ar atbilstoÅ”o Store API serveri, tas ir, ar mÅ«su blakusvāģiem un saņem laikrindu datus no atbilstoÅ”ajiem Prometheus serveriem.
  2. Pēc tam tas apvieno atbildes un izpilda tām PromQL vaicājumu. Querier var sapludināt gan nesadalītos datus, gan dublētos datus no Prometheus HA serveriem.

Tas atrisina galveno mÅ«su mÄ«klas daļu ā€” datus no izolētiem Prometheus serveriem apvienojot vienā skatā. Faktiski Thanos var izmantot tikai Å”ai funkcijai. EsoÅ”ajos Prometheus serveros nekādas izmaiņas nav jāveic!

Neierobežots glabāŔanas laiks!

Tomēr agrāk vai vēlāk mēs vēlēsimies glabāt datus, kas pārsniedz parasto Prometheus saglabāŔanas laiku. Vēsturisko datu glabāŔanai izvēlējāmies objektu krātuvi. Tas ir plaÅ”i pieejams jebkurā mākonÄ«, kā arÄ« lokālajos datu centros un ir ļoti rentabls. Turklāt gandrÄ«z jebkura objektu krātuve ir pieejama, izmantojot labi zināmo S3 API.

Prometheus ieraksta datus no RAM diskā aptuveni ik pēc divām stundām. Saglabātais datu bloks satur visus datus uz noteiktu laiku un ir nemainÄ«gs. Tas ir ļoti ērti, jo Thanos Sidecar var vienkārÅ”i apskatÄ«t Prometheus datu direktoriju un, tiklÄ«dz kļūst pieejami jauni bloki, ielādēt tos objektu uzglabāŔanas spainÄ«Å”os.

Thanos ā€” mērogojams Prometejs

IekrauÅ”ana objektu krātuvē tÅ«lÄ«t pēc ierakstÄ«Å”anas diskā ļauj arÄ« saglabāt skrāpja vienkārŔību (Prometheus un Thanos Sidecar). Kas vienkārÅ”o atbalstu, izmaksas un sistēmas dizainu.

Kā redzat, datu dublÄ“Å”ana ir ļoti vienkārÅ”a. Bet kā ir ar datu vaicāŔanu objektu krātuvē?

Thanos Store komponents darbojas kā starpniekserveris datu izgÅ«Å”anai no objektu krātuves. Tāpat kā Thanos Sidecar, tas piedalās tenku klasterÄ« un ievieÅ” Store API. Tādā veidā esoÅ”ais vaicātājs to var uzskatÄ«t par blakusvāģi kā citu laikrindu datu avotu ā€” nav nepiecieÅ”ama Ä«paÅ”a konfigurācija.

Thanos ā€” mērogojams Prometejs

Laika rindu datu bloki sastāv no vairākiem lieliem failiem. To ielāde pēc pieprasÄ«juma bÅ«tu diezgan neefektÄ«va, un lokālai saglabāŔanai keÅ”atmiņā bÅ«tu nepiecieÅ”ams milzÄ«gs atmiņas un diska vietas apjoms.

Tā vietā Store Gateway zina, kā rÄ«koties ar Prometheus krātuves formātu. Pateicoties viedam vaicājumu plānotājam un tikai nepiecieÅ”amo bloku indeksa daļu saglabāŔanai keÅ”atmiņā, ir iespējams samazināt sarežģītus vaicājumus lÄ«dz minimālam HTTP pieprasÄ«jumu skaitam objektu krātuves failiem. Tādā veidā jÅ«s varat samazināt pieprasÄ«jumu skaitu par četrām lÄ«dz seŔām kārtām un sasniegt atbildes laiku, ko parasti ir grÅ«ti atŔķirt no pieprasÄ«jumiem uz datiem vietējā SSD.

Thanos ā€” mērogojams Prometejs

Kā parādÄ«ts iepriekÅ” redzamajā diagrammā, Thanos Querier ievērojami samazina maksu par objektu uzglabāŔanas datu vaicājumu, izmantojot Prometheus krātuves formātu un novietojot saistÄ«tos datus blakus. Izmantojot Å”o pieeju, mēs varam apvienot daudzus atseviŔķus pieprasÄ«jumus minimālā lielapjoma darbÄ«bu skaitā.

BlÄ«vÄ“Å”ana un samazināŔana

Kad jauns laikrindu datu bloks ir veiksmÄ«gi ielādēts objektu krātuvē, mēs tos apstrādājam kā ā€œvēsturiskusā€ datus, kas ir uzreiz pieejami, izmantojot veikala vārteju.

Tomēr pēc kāda laika bloki no viena avota (Prometheus ar blakusvāģi) uzkrājas un vairs neizmanto pilnu indeksÄ“Å”anas potenciālu. Lai atrisinātu Å”o problēmu, mēs ieviesām vēl vienu komponentu ar nosaukumu Compactor. Tas vienkārÅ”i piemēro Prometheus lokālo blÄ«vÄ“Å”anas dzinēju vēsturiskajiem datiem objektu krātuvē, un to var palaist kā vienkārÅ”u periodisku pakeÅ”u darbu.

Thanos ā€” mērogojams Prometejs

Pateicoties efektÄ«vai saspieÅ”anai, vaicājumi par krātuvi ilgā laika periodā nerada problēmas datu apjoma ziņā. Tomēr iespējamās izmaksas, kas saistÄ«tas ar miljarda vērtÄ«bu izpakoÅ”anu un to palaiÅ”anu, izmantojot vaicājumu procesoru, neizbēgami radÄ«s dramatisku vaicājuma izpildes laika pieaugumu. No otras puses, tā kā ekrānā ir simtiem datu punktu uz vienu pikseļu, kļūst neiespējami pat vizualizēt datus ar pilnu izŔķirtspēju. Tādējādi paraugu samazināŔana ir ne tikai iespējama, bet arÄ« neradÄ«s ievērojamu precizitātes zudumu.

Thanos ā€” mērogojams Prometejs

Lai samazinātu datu izlasi, Compactor nepārtraukti apkopo datus ar piecu minÅ«Å”u un vienas stundas izŔķirtspēju. Katrai neapstrādātai daļai, kas kodēta, izmantojot TSDB XOR saspieÅ”anu, tiek saglabāti dažāda veida apkopotie dati, piemēram, min, max vai summa vienam blokam. Tas ļauj Querier automātiski atlasÄ«t apkopojumu, kas ir piemērots konkrētajam PromQL vaicājumam.

Lai lietotājs varētu izmantot samazinātas precizitātes datus, nav nepiecieÅ”ama Ä«paÅ”a konfigurācija. Querier automātiski pārslēdzas starp dažādām izŔķirtspējām un neapstrādātajiem datiem, lietotājam tuvinot un tālinot. Ja vēlas, lietotājs to var tieÅ”i kontrolēt, izmantojot pieprasÄ«juma parametru ā€œsolisā€.

Tā kā viena GB uzglabāŔanas izmaksas ir zemas, pēc noklusējuma Thanos saglabā neapstrādātus datus, piecu minÅ«Å”u un vienas stundas izŔķirtspējas datus. Nav nepiecieÅ”ams dzēst sākotnējos datus.

IerakstīŔanas noteikumi

Pat ar Thanos ierakstÄ«Å”anas noteikumi ir bÅ«tiska uzraudzÄ«bas steka sastāvdaļa. Tie samazina vaicājumu sarežģītÄ«bu, latentumu un izmaksas. Tie ir arÄ« ērti lietotājiem, lai iegÅ«tu apkopotus datus pēc metrikas. Thanos pamatā ir vaniļas Prometheus gadÄ«jumi, tāpēc ir pilnÄ«gi pieņemami saglabāt ierakstÄ«Å”anas noteikumus un brÄ«dinājumu noteikumus esoŔā Prometheus serverÄ«. Tomēr dažos gadÄ«jumos ar to var nepietikt:

  • Globālais brÄ«dinājums un noteikums (piemēram, brÄ«dinājums, ja pakalpojums nedarbojas vairāk nekā divās no trim klasteriem).
  • Noteikums datiem ārpus vietējās krātuves.
  • Vēlme glabāt visus noteikumus un brÄ«dinājumus vienuviet.

Thanos ā€” mērogojams Prometejs

Visos Å”ajos gadÄ«jumos Thanos ietver atseviŔķu komponentu ar nosaukumu Ruler, kas aprēķina noteikumu un brÄ«dinājumus, izmantojot Thanos Queries. NodroÅ”inot labi zināmu StoreAPI, vaicājuma mezgls var piekļūt tikko aprēķinātajiem rādÄ«tājiem. Vēlāk tie tiek glabāti arÄ« objektu krātuvē un padarÄ«ti pieejami, izmantojot Store Gateway.

Tanosa spēks

Thanos ir pietiekami elastÄ«gs, lai to pielāgotu jÅ«su vajadzÄ«bām. Tas ir Ä«paÅ”i noderÄ«gi, migrējot no vienkārŔā Prometeja. ÄŖsi apkoposim to, ko esam iemācÄ«juÅ”ies par Thanos komponentiem, izmantojot Ä«su piemēru. LÅ«k, kā izmantot savu vaniļas Prometheus ā€œneierobežotas metrikas krātuvesā€ pasaulē:

Thanos ā€” mērogojams Prometejs

  1. Pievienojiet Thanos Sidecar saviem Prometheus serveriem, piemēram, blakusvāģa konteineru Kubernetes podā.
  2. Izvietojiet vairākas Thanos Querier replikas, lai varētu skatÄ«t datus. Å ajā posmā ir viegli izveidot tenkas starp Scraper un Querier. Lai pārbaudÄ«tu komponentu mijiedarbÄ«bu, izmantojiet metriku ā€œthanos_cluster_membersā€.

Ar Å”iem diviem soļiem pietiek, lai nodroÅ”inātu globālu skatÄ«jumu un netraucētu datu atdalÄ«Å”anu no potenciālajām Prometheus HA replikām! VienkārÅ”i savienojiet savus informācijas paneļus ar Querier HTTP galapunktu vai tieÅ”i izmantojiet Thanos lietotāja interfeisu.

Tomēr, ja jums ir nepiecieÅ”ama metrikas dublÄ“Å”ana un ilgtermiņa glabāŔana, jums bÅ«s jāveic vēl trÄ«s darbÄ«bas.

  1. Izveidojiet AWS S3 vai GCS spaini. Konfigurējiet Sidecar, lai kopētu datus uz Å”iem segmentiem. Vietējo datu krātuvi tagad var samazināt lÄ«dz minimumam.
  2. Izvietojiet veikala vārteju un savienojiet to ar savu esoÅ”o tenku kopu. Tagad varat pieprasÄ«t dublētos datus!
  3. Izvietojiet Compactor, lai uzlabotu vaicājumu efektivitāti ilgā laika periodā, izmantojot blÄ«vÄ“Å”anu un iztverÅ”anu.

Ja vēlaties uzzināt vairāk, nevilcinieties apskatÄ«t mÅ«su kubernetes manifestu piemri Šø uzsākÅ”ana!

Tikai piecos soļos mēs pārvērtām Prometheus par uzticamu uzraudzÄ«bas sistēmu ar globālu skatu, neierobežotu uzglabāŔanas laiku un potenciāli augstu metrikas pieejamÄ«bu.

IzvilkŔanas pieprasījums: mums tu esi vajadzīgs!

Thanos jau no paÅ”a sākuma ir bijis atvērtā koda projekts. Nevainojama integrācija ar Prometheus un iespēja izmantot tikai daļu Thanos padara to par lielisku izvēli, lai bez piepÅ«les mērogotu jÅ«su uzraudzÄ«bas sistēmu.

Mēs vienmēr atzinīgi vērtējam GitHub Pull pieprasījumus un problēmas. Tikmēr sazinieties ar mums, izmantojot Github Issues vai slack Neticami-eng #thanosja jums ir jautājumi vai atsauksmes, vai vēlaties dalīties pieredzē, izmantojot to! Ja jums patīk tas, ko mēs darām uzņēmumā Improbable, nevilcinieties sazināties ar mums - mums vienmēr ir brīvas vietas!

Uzziniet vairāk par kursu.

Avots: www.habr.com

Pievieno komentāru