La traduko de la artikolo estis preparita specife por la kursanoj .
estas programisto, Go fanatika, kaj problemo solvanto. Li ankaŭ estas Prometheus prizorganto kaj kunfondinto de Kubernetes SIG-instrumentado. En la pasinteco, li estis produkta inĝeniero ĉe SoundCloud kaj gvidis la monitoran teamon ĉe CoreOS. Nuntempe laboras ĉe Google.
- Infrastruktura Inĝeniero ĉe Improbable. Li interesiĝas pri novaj teknologioj kaj problemoj de distribuitaj sistemoj. Li havas malaltnivelan programan sperton ĉe Intel, kontribuansperton ĉe Mesos, kaj mondklasan SRE-produktadsperton ĉe Improbable. Dediĉita al plibonigo de la mondo de mikroservoj. Liaj tri amoj: Golang, malfermfonteco kaj flugpilko.
Rigardante nian ĉefan produkton SpatialOS, vi povas konjekti, ke Improbable postulas tre dinamikan, tutmondan nuban infrastrukturon kun dekoj da Kubernetes-aretoj. Ni estis unu el la unuaj, kiuj uzis monitoran sistemon . Prometheus kapablas spuri milionojn da metrikoj en reala tempo kaj venas kun potenca demanda lingvo, kiu ebligas al vi ĉerpi la informojn, kiujn vi bezonas.
La simpleco kaj fidindeco de Prometheus estas unu el ĝiaj ĉefaj avantaĝoj. Tamen, post kiam ni preterpasis certan skalon, ni renkontis plurajn malavantaĝojn. Por solvi ĉi tiujn problemojn ni evoluigis estas malfermfontecprojekto kreita de Improbable por perfekte transformi ekzistantajn Prometheus-aretojn en ununuran monitoradsistemon kun senlima historia datumstokado. Thanos estas havebla sur Github .
Niaj celoj kun Thanos
Je certa skalo, aperas problemoj kiuj superas la kapablojn de vanilo Prometeo. Kiel fidinde kaj ekonomie stoki petabajtojn da historiaj datumoj? Ĉu tio povas esti farita sen kompromiti respondan tempon? Ĉu eblas aliri ĉiujn metrikojn situantajn sur malsamaj Prometheus-serviloj kun ununura API-peto? Ĉu ekzistas iu maniero kombini kopiitajn datumojn kolektitajn per Prometheus HA?
Por trakti ĉi tiujn problemojn, ni kreis Thanos. La sekvaj sekcioj priskribas kiel ni traktis ĉi tiujn aferojn kaj klarigas niajn celojn.
Pridemando de datumoj de pluraj Prometheus-kazoj (tutmonda demando)
Prometheus ofertas funkcian aliron al sharding. Eĉ ununura Prometheus-servilo disponigas sufiĉe da skaleblo por liberigi uzantojn de la komplekseco de horizontala sharding en preskaŭ ĉiuj uzkazoj.
Kvankam ĉi tio estas bonega deplojmodelo, ofte necesas aliri datumojn sur malsamaj Prometheus-serviloj per ununura API aŭ UI - tutmonda vido. Kompreneble, eblas montri plurajn demandojn en unu Grafana panelo, sed ĉiu demando povas esti efektivigita nur sur unu Prometheus-servilo. Aliflanke, kun Thanos vi povas pridemandi kaj aldoni datumojn de pluraj Prometheus-serviloj ĉar ili ĉiuj estas alireblaj de ununura finpunkto.
Antaŭe, por akiri tutmondan vidon en Improbable, ni organizis niajn Prometheus-instancojn en plurnivelan . Ĉi tio signifis krei unu metaservilon de Prometheus, kiu kolektas kelkajn el la metrikoj de ĉiu foliservilo.
Ĉi tiu aliro pruvis problema. Tio rezultigis pli kompleksajn konfiguraciojn, la aldonon de plia ebla punkto de fiasko, kaj la aplikon de kompleksaj reguloj por certigi ke la federacia finpunkto nur ricevas la datenojn kiujn ĝi bezonas. Krome, ĉi tiu speco de federacio ne permesas al vi akiri veran tutmondan vidon, ĉar ne ĉiuj datumoj haveblas de ununura API-peto.
Proksime rilata al ĉi tio estas unuigita vido de la datumoj kolektitaj sur alt-haveblaj (HA) Prometheus-serviloj. La HA-modelo de Prometeo sendepende kolektas datumojn dufoje, kio estas tiel simpla, ke ĝi ne povus esti pli simpla. Tamen, uzi kombinitan kaj deduplikitan vidon de ambaŭ riveretoj estus multe pli oportuna.
Kompreneble, necesas tre disponeblaj Prometheus-serviloj. Ĉe Improbable, ni prenas minuto-post-minutan datuman monitoradon vere serioze, sed havi unu Prometheus-instancon per areto estas ununura punkto de fiasko. Ajna eraro de agordo aŭ fiasko de aparataro eble povas kaŭzi perdon de gravaj datumoj. Eĉ simpla deplojo povas kaŭzi negravajn interrompojn en metrika kolekto ĉar rekomencoj povas esti signife pli longaj ol la skrapintervalo.
Fidinda konservado de historiaj datumoj
Malmultekosta, rapida, longperspektiva metrika stokado estas nia revo (dividata de plej multaj uzantoj de Prometheus). En Neprobabla, ni estis devigitaj agordi la metrikan retenperiodon al naŭ tagoj (por Prometheus 1.8). Ĉi tio aldonas evidentajn limojn al kiom malproksime ni povas rigardi.
Prometheus 2.0 pliboniĝis ĉi-rilate, ĉar la nombro da temposerio ne plu influas la ĝeneralan rendimenton de la servilo (vidu. ). Tamen, Prometheus stokas datumojn sur loka disko. Kvankam alt-efikeca datumkunpremo povas signife redukti lokan SSD-uzadon, finfine ankoraŭ ekzistas limo al la kvanto de historiaj datumoj stokeblaj.
Aldone, ĉe Improbable ni zorgas pri fidindeco, simpleco kaj kosto. Grandaj lokaj diskoj estas pli malfacile funkciigi kaj sekurigi. Ili kostas pli kaj postulas pli da rezerva iloj, rezultigante nenecesan kompleksecon.
Subspecimeno
Post kiam ni komencis labori kun historiaj datumoj, ni rimarkis, ke ekzistas fundamentaj malfacilaĵoj kun big-O, kiuj faras demandojn pli kaj pli malrapidaj dum ni laboras kun semajnoj, monatoj kaj jaroj da datumoj.
La norma solvo al ĉi tiu problemo estus (downsampling) - reduktante la signal-specimenfrekvencon. Kun subspecimeno, ni povas "malpligrandigi" al pli granda tempointervalo kaj konservi la saman nombron da specimenoj, tenante demandojn respondemaj.
Malaltigi malnovajn datumojn estas neevitebla postulo de iu longtempa stokada solvo kaj estas preter la amplekso de vanilo Prometeo.
Pliaj celoj
Unu el la originaj celoj de la projekto Thanos estis perfekte integriĝi kun iuj ekzistantaj Prometheus-instalaĵoj. La dua celo estis facileco de operacio kun minimumaj barieroj al eniro. Ajnaj dependecoj devas esti facile kontentigitaj por malgrandaj kaj grandaj uzantoj, kio ankaŭ signifas malaltan bazan koston.
Thanos-arkitekturo
Post listigi niajn celojn en la antaŭa sekcio, ni tralaboru ilin kaj vidu kiel Thanos solvas ĉi tiujn problemojn.
Tutmonda vido
Por akiri tutmondan vidon al la ekzistantaj Prometheus-instancoj, ni devas ligi ununuran petan enirpunkton al ĉiuj serviloj. Ĝuste tion faras la komponanto Thanos. . Ĝi estas deplojita apud ĉiu Prometheus-servilo kaj funkcias kiel prokurilo, servante lokajn Prometheus-datenojn per la gRPC Store API, permesante al temposeriodatenoj esti prenitaj per etikedo kaj tempointervalo.
Aliflanke estas la sennacia Querier-komponanto, kiu faras malmulton pli ol simple respondi PromQL-demandojn per la norma Prometheus HTTP API. Querier, Sidecar kaj aliaj Thanos-komponentoj komunikas per .
- Querier, ricevinte peton, konektas al la responda Store API-servilo, tio estas, al niaj Sidecars kaj ricevas tempajn datumojn de la respondaj Prometheus-serviloj.
- Post tio, ĝi kombinas la respondojn kaj efektivigas PromQL-demandon sur ili. Querier povas kunfandi ambaŭ disajn datumojn kaj duplikatajn datumojn de Prometheus HA-serviloj.
Ĉi tio solvas gravan pecon de nia enigmo - kombinante datumojn de izolitaj Prometheus-serviloj en ununuran vidon. Fakte, Thanos nur povas esti uzata por ĉi tiu funkcio. Neniuj ŝanĝoj devas esti faritaj al ekzistantaj Prometheus-serviloj!
Senlima konservodaŭro!
Tamen, baldaŭ aŭ malfrue ni volos stoki datumojn preter la normala Prometheus retentempo. Ni elektis objektan stokadon por stoki historiajn datumojn. Ĝi estas vaste havebla en iu ajn nubo same kiel enlokaj datumcentroj kaj estas tre kostefika. Krome, preskaŭ ajna objekto stokado disponeblas per la konata S3 API.
Prometheus skribas datumojn de RAM al disko proksimume ĉiujn du horojn. La stokita datumbloko enhavas ĉiujn datumojn por fiksa tempodaŭro kaj estas neŝanĝebla. Ĉi tio estas tre oportuna ĉar Thanos Sidecar povas simple rigardi la datumdosierujon de Prometheus kaj, kiam novaj blokoj iĝas disponeblaj, ŝarĝi ilin en objektajn stokadsitelojn.
Ŝarĝi en objektan stokadon tuj post skribado al disko ankaŭ permesas konservi la simplecon de la skrapilo (Prometheus kaj Thanos Sidecar). Kiu simpligas subtenon, koston kaj sisteman dezajnon.
Kiel vi povas vidi, sekurkopio de datumoj estas tre simpla. Sed kio pri pridemandado de datumoj en objektostokado?
La Thanos Store-komponento funkcias kiel prokurilo por preni datumojn de objektostokado. Kiel Thanos Sidecar, ĝi partoprenas en la klaĉgrupo kaj efektivigas la Store API. Tiel, ekzistanta Querier povas trakti ĝin kiel Sidecar, kiel alian fonton de temposeriodatenoj - neniu speciala agordo necesa.
Tempseriaj datumblokoj konsistas el pluraj grandaj dosieroj. Ŝarĝi ilin laŭpostule estus sufiĉe malefika, kaj konservi ilin loke postulus grandegan kvanton da memoro kaj diskospaco.
Anstataŭe, Store Gateway scias kiel manipuli la Prometheus-stokan formaton. Danke al inteligenta konsulta planisto kaj konservado de nur la necesaj indekspartoj de blokoj, eblas redukti kompleksajn demandojn al minimuma nombro da HTTP-petoj al objektaj stokaj dosieroj. Tiamaniere, vi povas redukti la nombron da petoj je kvar ĝis ses grandecoj kaj atingi respondajn tempojn, kiuj ĝenerale malfacilas distingi de petoj al datumoj sur loka SSD.
Kiel montrite en la supra diagramo, Thanos Querier signife reduktas la koston por demando de objektaj stokado-datumoj utiligante la Prometheus-stokadoformaton kaj metante rilatajn datumojn flank-al-flanke. Uzante ĉi tiun aliron, ni povas kombini multajn ununurajn petojn en minimuman nombron da pograndaj operacioj.
Kompaktado kaj subspecimeno
Post kiam nova bloko de temposerio-datumoj estas sukcese ŝarĝita en objektan stokadon, ni traktas ĝin kiel "historiajn" datumojn, kiuj tuj haveblas per la Store Gateway.
Tamen, post iom da tempo, blokoj de unu fonto (Prometeo kun Sidecar) amasiĝas kaj ne plu uzas la plenan indeksan potencialon. Por solvi ĉi tiun problemon, ni enkondukis alian komponanton nomatan Kompaktilo. Ĝi simple aplikas la lokan kompaktan motoron de Prometheus al historiaj datumoj en objektostokado kaj povas esti rulita kiel simpla perioda bata laboro.
Dank' al efika kunpremo, pridemandi la stokadon dum longa tempo ne prezentas problemon laŭ datumgrandeco. Tamen, la ebla kosto de malpakado de miliardo da valoroj kaj prizorgado de ili tra demanda procesoro neeviteble rezultos en rimarkinda pliiĝo de la demanda ekzekuttempo. Aliflanke, ĉar ekzistas centoj da datumpunktoj per pikselo sur la ekrano, fariĝas neeble eĉ bildigi la datumojn je plena rezolucio. Tiel, subspecimeno ne nur eblas, sed ankaŭ ne kondukos al rimarkinda perdo de precizeco.
Por malpligrandigi datumojn, Compactor senĉese kunigas datumojn je rezolucio de kvin minutoj kaj unu horo. Por ĉiu kruda peco kodita uzante TSDB XOR-kunpremadon, malsamaj specoj de entutaj datumoj estas stokitaj, kiel ekzemple min, max aŭ sumo por unu bloko. Ĉi tio permesas al Querier aŭtomate elekti agregaĵon, kiu taŭgas por donita PromQL-demando.
Neniu speciala agordo estas postulata por la uzanto uzi reduktitajn precizecajn datumojn. Querier aŭtomate ŝanĝas inter malsamaj rezolucioj kaj krudaj datumoj kiam la uzanto zomas en kaj eksteren. Se vi deziras, la uzanto povas kontroli ĉi tion rekte per la parametro "paŝo" en la peto.
Ĉar la kosto de stokado de unu GB estas malalta, defaŭlte Thanos stokas krudajn datumojn, kvin-minutajn kaj unu-horajn rezoluciajn datumojn. Ne necesas forigi la originalajn datumojn.
Reguloj pri registrado
Eĉ kun Thanos, registraj reguloj estas esenca parto de la monitora stako. Ili reduktas kompleksecon, latentecon kaj koston de demandoj. Ili ankaŭ estas oportunaj por uzantoj akiri agregitajn datumojn per metriko. Thanos baziĝas sur vanilaj Prometheus-instancoj, do estas perfekte akcepteble konservi registrajn regulojn kaj atentigi regulojn sur ekzistanta Prometheus-servilo. Tamen, en iuj kazoj ĉi tio eble ne sufiĉas:
- Tutmonda atentigo kaj regulo (ekzemple, atentigo kiam servo ne funkcias en pli ol du el tri aretoj).
- Regulo por datumoj ekster loka stokado.
- La deziro konservi ĉiujn regulojn kaj atentigojn en unu loko.
Por ĉiuj ĉi tiuj kazoj, Thanos inkluzivas apartan komponanton nomatan Reganto, kiu komputas regulon kaj atentigon per Thanos Queries. Provizante konatan StoreAPI, la Query-nodo povas aliri ĵus komputitajn metrikojn. Poste ili ankaŭ estas stokitaj en objektostokado kaj disponigitaj tra la Butiko-Enirejo.
La Potenco de Thanos
Thanos estas sufiĉe fleksebla por esti personecigita laŭ viaj bezonoj. Ĉi tio estas precipe utila dum migrado de ebenaĵo Prometeo. Ni rapide resumu tion, kion ni lernis pri Thanos-komponentoj kun rapida ekzemplo. Jen kiel preni vian vanilon Prometheus en la mondon de "senlima metra stokado":
- Aldonu Thanos Sidecar al viaj Prometheus-serviloj - ekzemple, kromĉaro-ujo en Kubernetes-podo.
- Deploji plurajn kopiojn de Thanos Querier por povi vidi datumojn. En ĉi tiu etapo estas facile agordi klaĉon inter Scraper kaj Querier. Por kontroli la interagadon de komponantoj, uzu la metrikon 'thanos_cluster_members'.
Nur ĉi tiuj du paŝoj sufiĉas por provizi tutmondan vidon kaj senjuntan deduplikadon de datumoj de eblaj kopioj de Prometheus HA! Simple konektu viajn instrumentpanelojn al la Querier HTTP-finpunkto aŭ uzu la Thanos UI rekte.
Tamen, se vi postulas metrajn sekurkopion kaj longdaŭran konservadon, vi devos plenumi tri pliajn paŝojn:
- Kreu AWS S3 aŭ GCS sitelon. Agordu Sidecar por kopii datumojn al ĉi tiuj siteloj. Loka datumstokado nun povas esti minimumigita.
- Deploji Store Gateway kaj konektu ĝin al via ekzistanta klaĉgrupo. Nun vi povas pridemandi la subtenitajn datumojn!
- Deploji Kompakilon por plibonigi demandan efikecon dum longaj tempodaŭroj per kompaktado kaj subspecimeno.
Se vi volas scii pli, ne hezitu rigardi nian и !
En nur kvin paŝoj, ni transformis Prometheus en fidindan monitoran sistemon kun tutmonda vido, senlima stokado kaj ebla alta havebleco de metrikoj.
Tiru peton: ni bezonas vin!
estis malfermkoda projekto ekde la komenco. Senjunta integriĝo kun Prometheus kaj la kapablo uzi nur parton de Thanos faras ĝin bonega elekto por senpene grimpi vian monitoran sistemon.
Ni ĉiam bonvenigas GitHub Pull Petojn kaj Problemojn. Intertempe bonvolu kontakti nin per Github Issues aŭ malstreĉose vi havas demandojn aŭ komentojn, aŭ volas dividi vian sperton uzante ĝin! Se vi ŝatas tion, kion ni faras ĉe Improbable, ne hezitu kontakti nin - !
fonto: www.habr.com