Ang pagsasalin ng artikulo ay partikular na inihanda para sa mga mag-aaral ng kurso .
ay isang software developer, Go fanatic, at problem solver. Isa rin siyang Prometheus maintainer at co-founder ng Kubernetes SIG instrumentation. Noong nakaraan, isa siyang production engineer sa SoundCloud at pinamunuan ang monitoring team sa CoreOS. Kasalukuyang gumagana sa Google.
- Infrastructure Engineer sa Improbable. Interesado siya sa mga bagong teknolohiya at problema ng mga distributed system. Siya ay may mababang antas na karanasan sa programming sa Intel, karanasan sa contributor sa Mesos, at world-class na karanasan sa produksyon ng SRE sa Improbable. Nakatuon sa pagpapabuti ng mundo ng mga microservice. Ang kanyang tatlong mahal: Golang, open source at volleyball.
Sa pagtingin sa aming pangunahing produkto na SpatialOS, maaari mong hulaan na ang Improbable ay nangangailangan ng isang napaka-dynamic, global-scale na imprastraktura ng ulap na may dose-dosenang mga Kubernetes cluster. Isa kami sa mga unang gumamit ng monitoring system . Ang Prometheus ay may kakayahang sumubaybay ng milyun-milyong sukatan sa real time at may kasamang malakas na wika ng query na nagbibigay-daan sa iyong kunin ang impormasyong kailangan mo.
Ang pagiging simple at pagiging maaasahan ng Prometheus ay isa sa mga pangunahing bentahe nito. Gayunpaman, kapag nalampasan namin ang isang tiyak na sukat, nakatagpo kami ng ilang mga kakulangan. Upang malutas ang mga problemang ito ay binuo namin ay isang open source na proyekto na nilikha ng Improbable upang walang putol na baguhin ang mga kasalukuyang Prometheus cluster sa isang solong sistema ng pagsubaybay na may walang limitasyong makasaysayang pag-iimbak ng data. Available ang Thanos sa Github .
Ang aming mga layunin sa Thanos
Sa isang tiyak na sukat, lumitaw ang mga problema na lampas sa mga kakayahan ng vanilla Prometheus. Paano mapagkakatiwalaan at matipid na mag-imbak ng mga petabytes ng makasaysayang data? Magagawa ba ito nang hindi nakompromiso ang oras ng pagtugon? Posible bang ma-access ang lahat ng mga sukatan na matatagpuan sa iba't ibang mga server ng Prometheus na may isang kahilingan sa API? Mayroon bang anumang paraan upang pagsamahin ang kinolektong data na nakolekta gamit ang Prometheus HA?
Upang matugunan ang mga isyung ito, ginawa namin ang Thanos. Ang mga sumusunod na seksyon ay naglalarawan kung paano namin nilapitan ang mga isyung ito at ipinapaliwanag ang aming mga layunin.
Pag-query ng data mula sa maraming instance ng Prometheus (global na query)
Nag-aalok ang Prometheus ng functional na diskarte sa sharding. Kahit na ang isang server ng Prometheus ay nagbibigay ng sapat na scalability upang palayain ang mga user mula sa mga kumplikado ng pahalang na sharding sa halos lahat ng mga kaso ng paggamit.
Bagama't ito ay isang mahusay na modelo ng pag-deploy, madalas na kinakailangan upang ma-access ang data sa iba't ibang mga server ng Prometheus sa pamamagitan ng isang API o UI - isang pangkalahatang view. Siyempre, posibleng magpakita ng maraming query sa isang panel ng Grafana, ngunit ang bawat query ay maaari lamang isagawa sa isang Prometheus server. Sa kabilang banda, sa Thanos maaari kang mag-query at magsama-sama ng data mula sa maraming Prometheus server dahil lahat sila ay naa-access mula sa isang endpoint.
Dati, para makakuha ng pandaigdigang view sa Improbable, inayos namin ang aming Prometheus instance sa isang multi-level . Nangangahulugan ito ng paglikha ng isang Prometheus meta server na nangongolekta ng ilan sa mga sukatan mula sa bawat server ng dahon.
Ang pamamaraang ito ay napatunayang may problema. Nagresulta ito sa mas kumplikadong mga pagsasaayos, pagdaragdag ng karagdagang potensyal na punto ng pagkabigo, at paggamit ng mga kumplikadong panuntunan upang matiyak na ang data na kailangan lang ng federated endpoint ang natatanggap nito. Bilang karagdagan, ang ganitong uri ng federation ay hindi nagpapahintulot sa iyo na makakuha ng isang tunay na pandaigdigang view, dahil hindi lahat ng data ay magagamit mula sa isang kahilingan sa API.
Ang malapit na nauugnay dito ay isang pinag-isang view ng data na nakolekta sa mga high-availability (HA) Prometheus server. Ang modelo ng HA ng Prometheus ay nakapag-iisa na nangongolekta ng data nang dalawang beses, na napakasimple at hindi ito maaaring maging mas simple. Gayunpaman, ang paggamit ng pinagsama at deduplicated na view ng parehong stream ay magiging mas maginhawa.
Siyempre, may pangangailangan para sa mataas na magagamit na mga server ng Prometheus. Sa Improbable, sineseryoso namin ang bawat minutong pagsubaybay sa data, ngunit ang pagkakaroon ng isang instance ng Prometheus bawat cluster ay isang punto ng pagkabigo. Ang anumang error sa pagsasaayos o pagkabigo ng hardware ay maaaring humantong sa pagkawala ng mahalagang data. Kahit na ang isang simpleng deployment ay maaaring magdulot ng mga maliliit na abala sa pagkolekta ng mga sukatan dahil ang mga pag-restart ay maaaring mas matagal kaysa sa pagitan ng pag-scrape.
Maaasahang imbakan ng makasaysayang data
Ang mura, mabilis, pangmatagalang imbakan ng mga sukatan ang aming pangarap (ibinahagi ng karamihan sa mga user ng Prometheus). Sa Improbable, napilitan kaming i-configure ang panahon ng pagpapanatili ng mga sukatan sa siyam na araw (para sa Prometheus 1.8). Ito ay nagdaragdag ng malinaw na mga limitasyon sa kung gaano kalayo tayo makakatingin.
Ang Prometheus 2.0 ay bumuti sa bagay na ito, dahil ang bilang ng mga serye ng oras ay hindi na nakakaapekto sa pangkalahatang pagganap ng server (tingnan. ). Gayunpaman, ang Prometheus ay nag-iimbak ng data sa lokal na disk. Bagama't ang napakahusay na data compression ay maaaring makabuluhang bawasan ang lokal na paggamit ng SSD, sa huli ay may limitasyon pa rin sa dami ng makasaysayang data na maaaring maimbak.
Bukod pa rito, sa Improbable, pinapahalagahan namin ang pagiging maaasahan, pagiging simple at gastos. Ang malalaking lokal na disk ay mas mahirap patakbuhin at i-back up. Mas mahal ang mga ito at nangangailangan ng mas maraming backup na tool, na nagreresulta sa hindi kinakailangang kumplikado.
Downsampling
Sa sandaling nagsimula kaming magtrabaho sa makasaysayang data, napagtanto namin na may mga pangunahing paghihirap sa big-O na nagpapabagal at nagpapabagal sa mga query habang nagtatrabaho kami sa mga linggo, buwan, at taon ng data.
Ang karaniwang solusyon sa problemang ito ay (downsampling) - binabawasan ang frequency sampling ng signal. Sa pag-downsampling, maaari naming "pababain" sa isang mas malaking hanay ng oras at mapanatili ang parehong bilang ng mga sample, na panatilihing tumutugon ang mga query.
Ang pag-downsampling ng lumang data ay isang hindi maiiwasang pangangailangan ng anumang pangmatagalang solusyon sa pag-iimbak at lampas sa saklaw ng vanilla Prometheus.
Mga karagdagang layunin
Isa sa mga orihinal na layunin ng proyektong Thanos ay ang walang putol na pagsasama sa anumang umiiral na mga pag-install ng Prometheus. Ang pangalawang layunin ay kadalian ng operasyon na may kaunting mga hadlang sa pagpasok. Ang anumang mga dependency ay dapat na madaling masiyahan para sa parehong maliliit at malalaking user, na nangangahulugan din ng mababang base na gastos.
Arkitektura ng Thanos
Pagkatapos ilista ang aming mga layunin sa nakaraang seksyon, pag-aralan natin ang mga ito at tingnan kung paano nilulutas ni Thanos ang mga problemang ito.
Global view
Upang makakuha ng pandaigdigang view sa itaas ng mga umiiral na Prometheus instance, kailangan naming i-link ang isang entry point ng kahilingan sa lahat ng server. Ito mismo ang ginagawa ng bahagi ng Thanos. . Naka-deploy ito sa tabi ng bawat server ng Prometheus at nagsisilbing proxy, na naghahatid ng lokal na data ng Prometheus sa pamamagitan ng gRPC Store API, na nagbibigay-daan sa data ng time series na makuha sa pamamagitan ng tag at hanay ng oras.
Sa kabilang panig ay ang scale-out, stateless Querier component, na higit pa sa pagsagot sa mga query sa PromQL sa pamamagitan ng karaniwang Prometheus HTTP API. Ang Querier, Sidecar at iba pang bahagi ng Thanos ay nakikipag-ugnayan sa pamamagitan ng .
- Ang Querier, kapag nakatanggap ng kahilingan, ay kumokonekta sa kaukulang server ng Store API, iyon ay, sa aming Sidecars at tumatanggap ng data ng time series mula sa kaukulang mga server ng Prometheus.
- Pagkatapos nito, pinagsasama nito ang mga tugon at nagsasagawa ng isang PromQL na query sa kanila. Maaaring pagsamahin ng Querier ang magkahiwalay na data at duplicate na data mula sa mga server ng Prometheus HA.
Nalulutas nito ang isang pangunahing bahagi ng aming palaisipan - pagsasama-sama ng data mula sa mga nakahiwalay na Prometheus server sa iisang view. Sa katunayan, magagamit lang ang Thanos para sa feature na ito. Walang mga pagbabagong kailangang gawin sa mga umiiral nang Prometheus server!
Walang limitasyong buhay ng istante!
Gayunpaman, maaga o huli ay gusto naming mag-imbak ng data nang lampas sa normal na oras ng pagpapanatili ng Prometheus. Pinili namin ang imbakan ng bagay upang mag-imbak ng makasaysayang data. Malawak itong magagamit sa anumang cloud pati na rin sa mga nasa nasasakupang data center at napaka-epektibo sa gastos. Bilang karagdagan, halos anumang imbakan ng bagay ay magagamit sa pamamagitan ng kilalang S3 API.
Ang Prometheus ay nagsusulat ng data mula sa RAM patungo sa disk humigit-kumulang bawat dalawang oras. Ang naka-imbak na data block ay naglalaman ng lahat ng data para sa isang nakapirming yugto ng panahon at hindi nababago. Ito ay napaka-maginhawa dahil ang Thanos Sidecar ay maaaring tumingin lamang sa Prometheus data directory at, habang ang mga bagong bloke ay naging available, i-load ang mga ito sa mga object storage bucket.
Ang paglo-load sa imbakan ng bagay kaagad pagkatapos magsulat sa disk ay nagpapahintulot din sa iyo na mapanatili ang pagiging simple ng scraper (Prometheus at Thanos Sidecar). Na pinapasimple ang suporta, gastos at disenyo ng system.
Tulad ng nakikita mo, ang pag-backup ng data ay napaka-simple. Ngunit ano ang tungkol sa pag-query ng data sa imbakan ng bagay?
Ang bahagi ng Thanos Store ay gumaganap bilang isang proxy upang kunin ang data mula sa imbakan ng bagay. Tulad ng Thanos Sidecar, nakikilahok ito sa cluster ng tsismis at nagpapatupad ng Store API. Sa ganitong paraan, maaaring ituring ito ng kasalukuyang Querier na parang Sidecar, bilang isa pang pinagmumulan ng data ng time series - walang kinakailangang espesyal na configuration.
Ang mga bloke ng data ng serye ng oras ay binubuo ng ilang malalaking file. Ang paglo-load ng mga ito kapag hinihingi ay medyo hindi mabisa, at ang pag-cache sa mga ito nang lokal ay mangangailangan ng malaking halaga ng memorya at espasyo sa disk.
Sa halip, alam ng Store Gateway kung paano pangasiwaan ang format ng storage ng Prometheus. Salamat sa isang matalinong scheduler ng query at pag-cache lamang ng mga kinakailangang bahagi ng index ng mga bloke, posibleng bawasan ang mga kumplikadong query sa pinakamababang bilang ng mga kahilingan sa HTTP para sa mga object ng storage file. Sa ganitong paraan, maaari mong bawasan ang bilang ng mga kahilingan ng apat hanggang anim na mga order ng magnitude at makamit ang mga oras ng pagtugon na sa pangkalahatan ay mahirap na makilala mula sa mga kahilingan sa data sa isang lokal na SSD.
Gaya ng ipinapakita sa diagram sa itaas, makabuluhang binabawasan ng Thanos Querier ang gastos sa bawat query ng data ng pag-iimbak ng bagay sa pamamagitan ng paggamit sa format ng imbakan ng Prometheus at paglalagay ng magkakaugnay na data nang magkatabi. Gamit ang diskarteng ito, maaari naming pagsamahin ang maraming iisang kahilingan sa pinakamababang bilang ng maramihang pagpapatakbo.
Compaction at downsampling
Kapag ang isang bagong bloke ng data ng serye ng oras ay matagumpay na na-load sa imbakan ng bagay, tinatrato namin ito bilang "makasaysayang" data, na agad na makukuha sa pamamagitan ng Store Gateway.
Gayunpaman, pagkaraan ng ilang oras, ang mga bloke mula sa isang pinagmulan (Prometheus na may Sidecar) ay naipon at hindi na ginagamit ang buong potensyal sa pag-index. Upang malutas ang problemang ito, ipinakilala namin ang isa pang bahagi na tinatawag na Compactor. Inilalapat lang nito ang lokal na compaction engine ng Prometheus sa makasaysayang data sa imbakan ng bagay at maaaring patakbuhin bilang isang simpleng pana-panahong batch job.
Salamat sa mahusay na compression, ang pag-query sa storage sa loob ng mahabang panahon ay hindi nagdudulot ng problema sa laki ng data. Gayunpaman, ang potensyal na gastos sa pag-unpack ng isang bilyong halaga at pagpapatakbo ng mga ito sa pamamagitan ng isang query processor ay hindi maiiwasang magreresulta sa isang kapansin-pansing pagtaas sa oras ng pagpapatupad ng query. Sa kabilang banda, dahil may daan-daang data point sa bawat pixel sa screen, nagiging imposible na kahit na maisalarawan ang data sa buong resolution. Kaya, ang downsampling ay hindi lamang posible, ngunit hindi rin hahantong sa isang kapansin-pansing pagkawala ng katumpakan.
Upang i-downsample ang data, patuloy na pinagsasama-sama ng Compactor ang data sa isang resolusyon na limang minuto at isang oras. Para sa bawat raw chunk na naka-encode gamit ang TSDB XOR compression, iba't ibang uri ng pinagsama-samang data ang iniimbak, gaya ng min, max o sum para sa isang block. Nagbibigay-daan ito sa Querier na awtomatikong pumili ng pinagsama-samang naaangkop para sa isang partikular na query sa PromQL.
Walang kinakailangang espesyal na pagsasaayos para magamit ng user ang pinababang data ng katumpakan. Awtomatikong nagpapalipat-lipat ang Querier sa pagitan ng iba't ibang resolution at raw data habang nag-zoom in at out ang user. Kung ninanais, makokontrol ito ng user nang direkta sa pamamagitan ng parameter na "hakbang" sa kahilingan.
Dahil mababa ang halaga ng pag-iimbak ng isang GB, bilang default ay nag-iimbak si Thanos ng raw data, limang minuto at isang oras na data ng resolusyon. Hindi na kailangang tanggalin ang orihinal na data.
Mga panuntunan sa pagre-record
Kahit sa Thanos, ang mga panuntunan sa pag-record ay isang mahalagang bahagi ng monitoring stack. Binabawasan ng mga ito ang pagiging kumplikado, latency, at gastos ng mga query. Maginhawa rin ang mga ito para sa mga user na makakuha ng pinagsama-samang data ayon sa mga sukatan. Nakabatay ang Thanos sa mga instance ng vanilla Prometheus, kaya ganap na katanggap-tanggap na mag-imbak ng mga panuntunan sa pag-record at mga panuntunan sa pag-aalerto sa isang umiiral nang Prometheus server. Gayunpaman, sa ilang mga kaso, maaaring hindi ito sapat:
- Pandaigdigang alerto at panuntunan (halimbawa, isang alerto kapag ang isang serbisyo ay hindi gumagana sa higit sa dalawa sa tatlong kumpol).
- Panuntunan para sa data sa labas ng lokal na imbakan.
- Ang pagnanais na iimbak ang lahat ng mga patakaran at alerto sa isang lugar.
Para sa lahat ng sitwasyong ito, may kasamang hiwalay na bahagi ang Thanos na tinatawag na Ruler, na kumukwenta ng panuntunan at alerto sa pamamagitan ng Thanos Queries. Sa pamamagitan ng pagbibigay ng kilalang StoreAPI, maa-access ng Query node ang mga bagong kalkuladong sukatan. Sa ibang pagkakataon, sila ay iniimbak din sa imbakan ng bagay at ginawang available sa pamamagitan ng Store Gateway.
Ang Kapangyarihan ni Thanos
Ang Thanos ay sapat na kakayahang umangkop upang ma-customize upang umangkop sa iyong mga pangangailangan. Ito ay lalong kapaki-pakinabang kapag lumilipat mula sa payak na Prometheus. Mabilis nating i-recap kung ano ang natutunan natin tungkol sa mga bahagi ng Thanos gamit ang isang mabilis na halimbawa. Narito kung paano dalhin ang iyong vanilla Prometheus sa mundo ng "walang limitasyong imbakan ng sukatan":
- Magdagdag ng Thanos Sidecar sa iyong mga Prometheus server - halimbawa, isang sidecar container sa isang Kubernetes pod.
- Mag-deploy ng maraming replika ng Thanos Querier upang matingnan ang data. Sa yugtong ito, madaling mag-set up ng tsismis sa pagitan ng Scraper at Querier. Upang suriin ang pakikipag-ugnayan ng mga bahagi, gamitin ang sukatan ng 'thanos_cluster_members'.
Ang dalawang hakbang lang na ito ay sapat na upang magbigay ng pandaigdigang view at tuluy-tuloy na pag-deduplication ng data mula sa mga potensyal na Prometheus HA na mga replika! Ikonekta lang ang iyong mga dashboard sa Querier HTTP endpoint o direktang gamitin ang Thanos UI.
Gayunpaman, kung kailangan mo ng pag-backup ng mga sukatan at pangmatagalang storage, kakailanganin mong kumpletuhin ang tatlo pang hakbang:
- Gumawa ng AWS S3 o GCS bucket. I-configure ang Sidecar para kopyahin ang data sa mga bucket na ito. Ang lokal na imbakan ng data ay maaari na ngayong mabawasan.
- I-deploy ang Gateway ng Store at ikonekta ito sa iyong kasalukuyang cluster ng tsismis. Maaari mo na ngayong i-query ang naka-back up na data!
- I-deploy ang Compactor upang mapabuti ang kahusayan ng query sa mahabang panahon gamit ang compaction at downsampling.
Kung gusto mong malaman ang higit pa, huwag mag-atubiling tingnan ang aming ΠΈ !
Sa limang hakbang lang, ginawa naming maaasahang monitoring system ang Prometheus na may global view, walang limitasyong oras ng storage at potensyal na mataas na availability ng mga sukatan.
Pull request: kailangan ka namin!
ay isang open source na proyekto mula pa sa simula. Ang walang putol na pagsasama sa Prometheus at ang kakayahang gumamit lamang ng isang bahagi ng Thanos ay ginagawa itong isang mahusay na pagpipilian para sa pag-scale ng iyong monitoring system nang walang kahirap-hirap.
Palagi naming tinatanggap ang Mga Kahilingan at Isyu sa GitHub Pull. Pansamantala, huwag mag-atubiling makipag-ugnayan sa amin sa pamamagitan ng Mga Isyu sa Github o slackkung mayroon kang mga tanong o feedback, o gusto mong ibahagi ang iyong karanasan sa paggamit nito! Kung gusto mo ang ginagawa namin sa Improbable, huwag mag-atubiling makipag-ugnayan sa amin - !
Pinagmulan: www.habr.com