Kamusta kayong lahat. Nasa ibaba ang transcript .
– isang sistema ng pagsubaybay para sa iba't ibang mga sistema at serbisyo, sa tulong kung saan ang mga administrator ng system ay maaaring mangolekta ng impormasyon tungkol sa kasalukuyang mga parameter ng mga system at mag-set up ng mga alerto upang makatanggap ng mga abiso tungkol sa mga paglihis sa pagpapatakbo ng mga system.
Ang ulat ay magsasama ng isang paghahambing и — mga proyekto para sa pangmatagalang imbakan ng mga sukatan ng Prometheus.
Una, sasabihin ko sa iyo ang tungkol sa Prometheus. Ito ay isang monitoring system na nangongolekta ng mga sukatan mula sa mga tinukoy na target at sine-save ang mga ito sa lokal na storage. Maaaring mag-record ang Prometheus ng mga sukatan sa malayong storage at makakabuo ng mga alerto at panuntunan sa pag-record.
Mga Limitasyon ng Prometheus:
- Wala itong pangkalahatang view ng query. Ito ay kapag mayroon kang maraming independiyenteng mga pagkakataon ng prometheus. Nangongolekta sila ng mga sukatan. At gusto mong mag-query sa itaas ng lahat ng mga sukatang ito na nakolekta mula sa iba't ibang mga instance ng prometheus. Hindi ito pinapayagan ng Prometheus.
- Sa prometheus, ang pagganap ay limitado lamang sa isang server. Ang Prometheus ay hindi awtomatikong sumusukat sa maraming server. Maaari mo lamang manual na hatiin ang iyong mga target sa pagitan ng maraming Prometheus.
- Ang saklaw ng mga sukatan sa Prometheus ay limitado sa isang server lamang para sa parehong dahilan na hindi ito awtomatikong mai-scale sa maraming server.
- Hindi napakadali na ayusin ang kaligtasan ng data sa Prometheus.
Mga solusyon sa mga problema/hamong ito?
Ang mga solusyon ay:
Ang lahat ng mga solusyong ito ay para sa malayong pag-iimbak ng data na nakolekta ng Prometheus. Nilulutas nila ang problema sa malayong imbakan mula sa nakaraang slide sa iba't ibang paraan. Sa pagtatanghal na ito ay pag-uusapan ko lamang ang tungkol sa unang dalawang solusyon: и .
Sa unang pagkakataon, impormasyon tungkol sa nagpakita ng . Ang arkitektura ay inilarawan doon at kung paano ito gumagana.
Kinukuha ni Thanos ang data na na-save ni Prometheus sa lokal na disk at kinopya ito sa S3, sa o sa isa pang imbakan ng bagay.
Kaya't ang Thanos ay nagbibigay ng isang pandaigdigang view ng query. Maaari kang mag-query ng data na nakaimbak sa imbakan ng bagay mula sa maraming mga pagkakataon ng Prometheus.
Sinusuportahan ni Thanos ang PromQL at .
Gumagamit si Thanos ng Prometheus code para mag-imbak ng data.
Ang Thanos ay binuo ng parehong mga developer bilang Prometheus.
Tungkol sa . Dito , kung saan tayo unang napag-usapan .
Ang VictoriaMetrics ay tumatanggap ng data mula sa ilang prometheus protocol na sinusuportahan ng Prometheus.
Nagbibigay ang VictoriaMetrics ng pangkalahatang view ng query, dahil maraming instance ng Prometheus ang makakapagsulat ng data sa isang VictoriaMetrics. Alinsunod dito, maaari kang gumawa ng mga query sa lahat ng data na ito.
Sinusuportahan din ng VictoriaMetrics, tulad ng Thanos, PromQL at Prometheus querying API.
Hindi tulad ng Thanos, ang source code ng VictoriaMetrics ay isinulat mula sa simula at na-optimize para sa bilis at pagkonsumo ng mapagkukunan.
Ang VictoriaMetrics, hindi tulad ng Thanos, ay sumusukat nang patayo at pahalang. Kumain , na sumusukat nang patayo. Maaari kang magsimula sa isang processor at 1 GB ng memorya at unti-unting lumaki sa daan-daang mga processor at 1 TB ng memorya. Maaaring gamitin ng VictoriaMetrics ang lahat ng mga mapagkukunang ito. Ang pagganap nito ay tataas ng humigit-kumulang 100 beses kumpara sa isang 1-core system.
Nagsimula ang kasaysayan ng Thanos noong Nobyembre 2017, nang lumitaw ang unang public commit. Bago ito, ang Thanos ay binuo sa loob .
Noong Hunyo 2019 nagkaroon ng landmark release 0.5.0, kung saan protocol. Inalis siya sa Thanos dahil hindi siya gumanap nang maayos. Kadalasan ang kumpol ng Thanos ay hindi gumana nang tama, ang mga node ay konektado dito nang hindi tama dahil sa protocol ng tsismis. Samakatuwid, nagpasya kaming alisin siya mula doon. Sa tingin ko ito ang tamang desisyon.
Sa parehong Hunyo 2019, nagpadala sila ng numero ng aplikasyon в .
At pagkatapos ng ilang buwan ay tinanggap si Thanos , na kinabibilangan ng Prometheus, Kubernetes at iba pang sikat na proyekto.
Noong Enero 2018, nagsimula ang pagbuo ng VictoriaMetrics.
Noong Setyembre 2018, binanggit ko sa publiko ang VictoriaMetrics sa unang pagkakataon.
Noong Disyembre 2018, isang bersyon ng Single-node ang nai-publish.
Sa Mayo 2019 pinagmumulan ng parehong Single-node at cluster na bersyon.
Noong Hunyo 2019, tulad ni Thanos, nagsumite kami ng aplikasyon sa CNCF foundation sa ilalim ng numero . Nag-apply kami isang araw bago nag-apply si Thanos.
Pero, unfortunately, hindi pa rin kami natatanggap doon. Kailangan ng tulong ng komunidad.
Tingnan natin ang pinakamahalagang slide na nagpapakita ng arkitektura ng Thanos at VictoriaMetrics.
Magsimula tayo kay Thanos. Ang mga dilaw na bahagi ay mga bahagi ng Prometheus. Lahat ng iba pa ay mga bahagi ng Thanos. Magsimula tayo sa pinakamahalagang sangkap. Ang Thanos Sidecar ay isang component na naka-install sa tabi ng bawat Prometheus. Naglo-load ito ng data ng Prometheus mula sa lokal na imbakan sa S3 o isa pang Imbakan ng Bagay.
Mayroon ding isang bahagi na tinatawag na Thanos Store Gateway, na maaaring basahin ang data na ito mula sa Object Storage sa mga papasok na kahilingan mula sa Thanos Query. Ipinapatupad ng Thanos Query ang PromQL at Prometheus API. Ibig sabihin, sa labas ay parang si Prometheus. Tumatanggap ng mga query sa PromQL, ipinapadala ang mga ito sa Thanos Store Gateway, kinukuha ng Thanos Store Gateway ang kinakailangang data mula sa Object Storage, ibinabalik ito.
Ngunit nag-iimbak kami ng data sa Object Storage nang wala ang huling dalawang oras dahil sa isang feature ng pagpapatupad ng Thanos Sidecar, na hindi makapag-upload ng huling dalawang oras sa Object Storage S3, dahil hindi pa nakakagawa ang Prometheus ng mga file para sa dalawang oras na ito sa lokal na storage.
Paano ka nagpasya na libutin ito? Ang Thanos Query, bilang karagdagan sa mga kahilingan sa Thanos Store Gateway, ay nagpapadala ng mga parallel na kahilingan sa bawat Thanos Sidecar na matatagpuan sa tabi ng Prometheus.
At si Thanos Sidecar, sa turn, ay humihiling pa ng mga proxy sa Prometheus, at kinukuha ang data sa huling dalawang oras.
Bilang karagdagan sa mga bahaging ito, mayroon ding opsyonal na bahagi kung wala ang Thanos na hindi gagana nang maayos. Ito ang Thanos Compact, na responsable sa pagsasama ng maliliit na file sa Object Storage sa mas malalaking file na na-upload dito ni Thanos Sidecars. Ang Thanos Sidecar ay nag-upload ng mga file ng data doon sa loob ng dalawang oras. Ang mga file na ito, kung hindi sila pinagsama sa mas malalaking file, kung gayon ang kanilang bilang ay maaaring lumaki nang malaki. Kung mas maraming ganoong mga file, mas maraming memory ang kailangan para sa Thanos Store Gateway, mas maraming mapagkukunan ang kinakailangan upang maglipat ng data sa network at metadata. Nagiging hindi epektibo ang Thanos Store Gateway. Samakatuwid, kinakailangang patakbuhin ang Thanos Compact, na pinagsasama ang maliliit na file sa mas malalaking file, para mas kaunti ang mga ganoong file at upang mabawasan ang overhead sa Thanos Store Gateway.
Mayroon ding isang bahagi bilang Thanos Ruler. Isinasagawa nito ang mga panuntunan sa pag-aalerto ng Prometheus at maaaring suriin ang mga panuntunan sa pag-record ng Prometheus upang maisulat ang data pabalik sa Imbakan ng Bagay. Ngunit ang sangkap na ito ay hindi inirerekomenda na gamitin, dahil... Siya .
Ito ang simpleng pamamaraan ni Thanos.
Ngayon, ihambing natin ito sa scheme ng VictoriaMetrics.
Ang VictoriaMetrics ay may 2 bersyon: Single-node at cluster na bersyon. Ang single-node ay tumatakbo sa isang computer. Ang single-node ay walang mga bahaging ito, isang binary lang. Ang binary na ito sa slide ay mukhang parisukat na ito. Ang lahat ng nasa loob ng parisukat ay ang mga nilalaman ng binary file para sa Single-node na bersyon. Hindi mo kailangang malaman ang tungkol sa kanya. Patakbuhin mo lang ang binary at lahat ay gumagana para sa amin.
Ang bersyon ng cluster ay mas kumplikado. Sa loob nito mayroong tatlong magkakaibang sangkap: vmselect, vminsert at vmstorage. Mula sa kanilang pangalan ay dapat na malinaw kung ano ang ginagawa ng bawat isa sa kanila. Ang Insert component ay tumatanggap ng data sa iba't ibang format: mula sa Prometheus remote write API, ang Influx line protocol, ang Graphite protocol at ang OpenTSDB protocol. Ang Insert component ay tinatanggap ang mga ito, pina-parse ang mga ito at ipinamamahagi ang mga ito sa pagitan ng mga kasalukuyang bahagi ng storage, kung saan ang data ay nakaimbak na. Ang Select component, naman, ay tumatanggap ng mga query sa PromQL. Siya ang nagpapatupad , pati na rin ang Prometheus querying API, at maaari itong gamitin bilang kapalit para sa Prometheus sa Grafana o iba pang mga kliyente ng Prometheus API. Tinatanggap ng Select ang isang kahilingan sa promql, i-parse ito, binabasa ang kinakailangang data para sa pagpapatupad ng kahilingang ito mula sa mga storage node, pinoproseso ang data na ito at nagbabalik ng tugon.
Ihambing natin ang pagiging kumplikado ng pag-install ng Thanos at VictoriaMetrics.
Magsimula tayo kay Thanos. Bago ka magsimulang magtrabaho kasama si Thanos, kailangan mong gumawa ng bucket sa Object Storage, gaya ng S3 o GCS, para makapagsulat si Thanos Sidecar ng data dito.
Pagkatapos para sa bawat Prometheus kailangan mong i-install ang Thanos Sidecar. Bago ito, kailangan mong tandaan na huwag paganahin ang data compaction sa Prometheus. Pana-panahong pini-compress ng data compaction ang data sa lokal na storage ng Prometheus upang mabawasan ang pagkonsumo ng mapagkukunan.
Kapag nag-install ka ng Thanos Sidecar sa iyong Prometheus, dapat mong i-disable ang data compaction na ito, dahil hindi gumagana nang maayos ang Thanos Sidecar kapag naka-enable ang data compaction. Nangangahulugan ito na ang iyong Prometheus ay nagsisimulang mag-save ng data sa dalawang oras na bloke at huminto sa pagsasama-sama ng mga bloke na iyon sa mas malalaking bloke. Alinsunod dito, kung gagawa ka ng mga query na lumampas sa tagal ng huling dalawang oras, hindi gagana ang mga ito nang kasinghusay ng magagawa nila kung pinagana ang pag-compact ng data.
Samakatuwid, inirerekomenda ni Thanos na bawasan ang oras ng pagpapanatili ng data sa lokal na imbakan sa 6-8 na oras upang mabawasan ang overhead ng malaking bilang ng maliliit na bloke.
Kapag na-install mo na ang Thanos Sidecar, dapat kang mag-install ng dalawang bahagi para sa bawat Object Storage Bucket. Ito ay ang Thanos Compactor at Thanos Store Gateway.
Pagkatapos nito, kailangan mong i-install ang Thanos Query at i-configure ito para makakonekta ito sa lahat ng Thanos Store Gateways na mayroon ka, at maaari ding kumonekta sa lahat ng Thanos Sidecars.
Maaaring may kaunting problema dito.
Kailangan mong mag-configure ng maaasahan at secure na koneksyon mula sa Thanos Query sa mga bahaging ito. At kung ang iyong Prometheus ay matatagpuan sa iba't ibang data center, o sa iba't ibang VPC, kung gayon ang mga koneksyon sa kanila mula sa labas ay ipinagbabawal. Ngunit para gumana ang Thanos Query, kailangan mong i-configure ang koneksyon doon, at kailangan mong gumawa ng paraan.
Kung mayroon kang maraming tulad na mga sentro ng data, kung gayon, nang naaayon, bumababa ang pagiging maaasahan ng buong system. Dahil dapat patuloy na mapanatili ng Thanos Query ang mga koneksyon sa lahat ng Thanos Sidecars na matatagpuan sa iba't ibang data center. Para sa bawat papasok na kahilingan, iruruta nito ang mga kahilingan sa lahat ng Thanos Sidecar. Kung maabala ang koneksyon, makakatanggap ka ng hindi kumpletong hanay ng data, o makakatanggap ka ng tugon na "pababa ang cluster".
Sa VictoriaMetrics ang lahat ay medyo mas simple. Para sa bersyon ng Single-node, kailangan mo lang magpatakbo ng isang binary at gumagana ang lahat.
Sa bersyon ng kumpol, sapat na upang patakbuhin ang lahat ng nasa itaas na tatlong uri ng mga bahagi sa anumang dami na kailangan mo, o gamitin upang i-automate ang paglulunsad ng mga bahagi sa Kubernetes. Nagpaplano din kaming gumawa ng operator ng Kubernetes. Ang Helm chart ay hindi sumasaklaw sa ilang mga kaso at hinahayaan kang kunan ng larawan ang iyong sarili sa paa. Halimbawa, pinapayagan ka nitong bawasan ang bilang ng mga storage node, na hahantong sa pagkawala ng data.
Pagkatapos mong maglunsad ng isang binary o isang clustered na bersyon, kailangan mo lamang idagdag ang Prometheus sa config upang magsimula itong magsulat ng data na kahanay sa lokal na imbakan at malayong imbakan. Tulad ng nakikita mo, ang pagsasaayos na ito ay dapat gumanap nang mas maaasahan kumpara sa pagsasaayos ng Thanos. Hindi namin kailangang magpanatili ng koneksyon mula sa VictoriaMetrics sa lahat ng Prometheus, dahil ang Prometheus mismo ay kumokonekta sa VictoriaMetrics at nagpapadala ng data.
Isaalang-alang natin ang suporta ng Thanos at VictoriaMetrics.
Kailangang subaybayan ni Thanos ang Sidecar upang matiyak na hindi sila titigil sa paglo-load ng data sa Object Storage. Maaari nilang ihinto ang pag-download ng data na ito dahil sa mga error sa pag-download, halimbawa ang iyong koneksyon sa network sa Object Storage ay pansamantalang naantala, o ang Object Storage ay pansamantalang hindi available. Mapapansin ito ni Thanos Sidecar sa sandaling ito, mag-ulat ng error, maaaring mag-crash at pagkatapos ay tumigil sa paggana. Kung hindi mo ito sinusubaybayan, ititigil mo ang paglilipat ng data sa Object Storage. Kung lumipas ang oras ng pagpapanatili (6-8 oras na inirerekomenda), mawawalan ka ng data na hindi napunta sa Object Storage.
Maaaring huminto sa paggana ang Thanos compactors dahil sa . Kinukuha ng mga Compactor ang data mula sa Object Storage at pinagsama ito sa mas malalaking piraso ng data. Dahil hindi naka-synchronize ang mga compactor sa Sidecars, maaaring mangyari ang mga sumusunod: Wala pang oras ang Sidecar para kumpletuhin ang block, nagpasya si Compactor na ang block na ito ay ganap nang naisulat. Sinimulan itong basahin ng Compactor. Hindi nito binabasa nang buo ang block at huminto sa pagtatrabaho. Tignan ang detalye .
Ang Store Gateway ay maaaring magbalik ng hindi tugmang data dahil sa mga karera sa pagitan ng Compactor at Sidecar. Ang parehong bagay ay nangyayari dito, dahil ang Store Gateway ay hindi naka-synchronize sa Compactors at Sidecars sa anumang paraan. Alinsunod dito, maaaring mangyari ang mga kundisyon ng lahi kapag ang Store Gateway ay hindi nakakita ng bahagi ng data o nakakita ng hindi kinakailangang data.
Ang Query component sa Thanos bilang default ay nagbabalik ng bahagyang resulta kung ang ilang Sidecar o Store Gateway ay hindi available sa ngayon. Makakatanggap ka ng bahagi ng data, at hindi mo malalaman na hindi mo natanggap ang lahat ng data. Ito ay kung paano ito gumagana bilang default. Sa katulad na sitwasyon, ibinabalik ng VictoriaMetrics ang minarkahang data bilang bahagyang.
Hindi tulad ng Thanos, bihirang mawalan ng data ang VictoriaMetrics. Kahit na maputol ang koneksyon mula sa Prometheus sa VictoriaMetrics, hindi ito problema, dahil patuloy na nagtatala ang Prometheus ng mga bagong data sa Write Ahead Log, na ang laki nito ay 2 oras. Kung ibabalik mo ang iyong koneksyon sa VictoriaMetrics sa loob ng dalawang oras, hindi mawawala ang iyong data. Prometheus .
Hindi tulad ng Thanos, na nagsusulat ng data sa object storage pagkalipas lang ng dalawang oras, awtomatikong kinokopya ng Prometheus ang data gamit ang remote write protocol sa remote storage, gaya ng VictoriaMetrics. Hindi ka natatakot na mawala ang lokal na storage sa Prometheus. Kung bigla siyang nawalan ng lokal na imbakan, kung gayon sa pinakamasamang kaso mawawala mo ang mga huling segundo ng data na walang oras upang maitala sa malayong imbakan.
Awtomatikong pinamamahalaan ng Kubernetes ang cluster, hindi tulad ng Thanos. Mahirap ilagay ang lahat ng bahagi ng Thanos sa isang cluster ng Kubernetes, hindi tulad ng mga bahagi ng cluster ng VictoriaMetrics.
Ang VictoriaMetrics ay may napakasimpleng update sa bagong bersyon. Itigil lang ang VictoriaMetrics, i-update ang mga binary at ilunsad ito. Kapag huminto sa pamamagitan ng isang SIGINT signal, lahat ng VictoriaMetrics binary ay nagsasagawa ng magandang pagsara. Tama nilang nai-save ang kinakailangang data, isara nang tama ang mga papasok na koneksyon upang hindi mawalan ng anuman. Kaya wala kang mawawala kapag nag-a-upgrade.
Pinapadali ng VictoriaMetrics ang pagpapalawak ng isang cluster. Idagdag lamang ang mga kinakailangang sangkap at magpatuloy sa pagtatrabaho.
Tungkol sa mga pitfalls sa Thanos at VictoriaMetrics.
May mga sumusunod na pitfalls si Thanos. Dapat mag-imbak ng data ang Prometheus sa huling dalawang oras. Kung mawala sila, tuluyang mawawala sa iyo, dahil wala pa silang oras na sumulat sa Object Storage, gaya ng S3.
Ang bahagi ng Store Gateway at bahagi ng compactor ay maaaring mangailangan ng maraming memory upang gumana sa isang malaking Imbakan ng Bagay kung mayroong maraming maliliit na file na nakaimbak doon. Kung mas malaki ang bilang at laki ng mga file, mas maraming Store Gateway at compactor RAM ang kinakailangan upang mag-imbak ng metainformation. Maraming isyu si Thanos tungkol sa katotohanang iyon .
Ang Thanos ay ina-advertise upang sukatin nang walang katiyakan sa dami ng Prometheus na mayroon ka. Ito ay talagang hindi totoo. Dahil dumaan ang lahat ng kahilingan sa bahagi ng Query, na dapat sabay na i-poll ang lahat ng bahagi ng Store Gateway at lahat ng bahagi ng Sidecar, hilahin ang data mula doon at pagkatapos ay i-preprocess ito. Malinaw, ang bilis ng kahilingan ay nililimitahan ng pinakamabagal na mahinang link, ang pinakamabagal na Store Gateway o ang pinakamabagal na Sidecar.
Ang mga sangkap na ito ay maaaring hindi pantay na na-load. Halimbawa, mayroon kang Prometheus, na nangongolekta ng milyun-milyong sukatan bawat segundo. At mayroong Prometheus, na nangongolekta ng libu-libong sukatan bawat segundo. Ang Prometheus, na nangongolekta ng milyun-milyong sukatan bawat segundo, ay naglalagay ng mas mataas na load sa server na pinapatakbo nito. Alinsunod dito, ang Sidecar ay gumagana nang mas mabagal doon. At sa pangkalahatan ang lahat ay gumagana nang mabagal doon. At ang Query component ay kukuha ng data mula doon nang napakabagal. Alinsunod dito, ang pagganap ng iyong buong cluster ay malilimitahan ng mabagal na Sidecar na ito.
Bilang default, nagbibigay si Thanos ng bahagyang data kung hindi available ang ilang Sidecar at alinman sa Store Gateway. Halimbawa, kung ang iyong mga Sidecar ay nakakalat sa buong mundo sa iba't ibang data center, kung gayon ang posibilidad ng isang pagkabigo ng koneksyon at hindi magagamit ang bahagi ay tumataas nang malaki. Alinsunod dito, sa karamihan ng mga kaso makakatanggap ka ng bahagyang data nang hindi mo ito nalalaman.
Ang VictoriaMetrics ay mayroon ding mga pitfalls. Ang unang pitfall ay ang opsyon na naglilimita sa dami ng RAM na ginamit para sa cache ng VictoriaMetrics. Bilang default, ito ay katumbas ng 60% ng RAM sa machine kung saan tumatakbo ang VictoriaMetrics o 60% ng RAM ng VictoriaMetrics pod sa Kubernetes.
Kung mali mong binago ang value na ito, maaari mong masira ang performance ng VictoriaMetrics. Halimbawa, kung itinakda mo ang halaga nang masyadong mababa, maaaring hindi na magkasya ang data sa cache ng VictoriaMetrics. Dahil dito, kakailanganin niyang gumawa ng karagdagang trabaho at i-load ang processor at disk. Kung gagawin mong masyadong malaki ang pagpipiliang ito, tataas ito, una, ang posibilidad na mag-crash ang VictoriaMetrics nang may error sa memorya, at, pangalawa, hahantong ito sa katotohanan na napakakaunting RAM ang natitira sa memorya ng operating system para sa. cache ng file. At umaasa ang VictoriaMetrics sa isang file cache para sa pagganap. Kung ito ay hindi sapat, ang pag-load sa disk ay maaaring tumaas nang malaki. Samakatuwid, payo: huwag baguhin ang parameter maliban kung talagang kinakailangan.
Pangalawang opsyon. Ito ay retentionPeriod - isang panahon na nakatakda sa 1 buwan bilang default. Ito ang haba ng oras na iniimbak ng VictoriaMetrics ang data. Pagkatapos ng panahong ito, tatanggalin ng VictoriaMetrics ang data.
Maraming tao ang nagpapatakbo ng VictoriaMetrics nang walang parameter na ito at nagtatala ng data sa loob ng isang buwan. At pagkatapos ay itatanong nila: bakit nawala ang data para sa nakaraang buwan? Dahil ang default na retentionPeriod ay 1 buwan. Samakatuwid, kailangan mong malaman at itakda ang tamang retentionPeriod.
Tingnan natin ang mga natatanging tampok.
May feature si Thanos na tinatawag na downsampling: 5 minuto at oras-oras na pagitan, na madalas . Kung mag-google ka at titingnan ang kanilang isyu sa github, mayroong maraming mga isyu na nauugnay sa downsampling na ito, na kung minsan ay hindi ito gumagana nang tama, o hindi gumagana tulad ng inaasahan ng mga gumagamit.
May data deduplication si Thanos para sa mga pares ng Prometheus HA. Kapag nakolekta ng dalawang Prometheus ang parehong mga sukatan mula sa parehong mga target at ini-store ni Thanos ang mga ito sa Object Storage. Maaaring maayos na i-deduplicate ni Thanos ang data na ito, hindi katulad ng VictoriaMetrics.
May alertong bahagi si Thanos na nasa eskematiko ng Thanos. Pero siya .
May kalamangan si Thanos na magkaparehas ang code nina Thanos at Prometheus. Ang Thanos at Prometheus ay binuo ng parehong mga developer. Sa mga pagpapahusay sa Thanos o Prometheus, panalo ang kabilang panig.
Ang pangunahing tampok ng VictoriaMetrics ay MetricsQL. Ito ang mga extension ng VictoriaMetrics para sa PromQL, na napag-usapan ko sa nakaraang malaking monitoring metup.
Sinusuportahan ng VictoriaMetrics ang paglo-load ng data gamit ang maraming iba't ibang protocol. Ang VictoriaMetrics ay hindi lamang maaaring tumanggap ng data mula sa Prometheus, kundi pati na rin sa pamamagitan ng Influx, OpenTSDB at Graphite protocol.
Ang data ng VictoriaMetrics ay tumatagal ng mas kaunting espasyo kumpara sa Thanos at Prometheus.
Kung nagre-record ka ng totoong data, pinag-uusapan ng mga user ang tungkol sa 2-5 beses na pagbawas sa laki ng data sa disk kumpara sa Prometheus at Thanos.
Ang isa pang bentahe ng VictoriaMetrics ay na-optimize ito para sa bilis.
Tingnan natin ang halaga ng imprastraktura.
Ang isa sa mga bentahe ng Thanos ay ang pag-iimbak nito ng data sa imbakan ng bagay, na medyo mura.
Kapag nag-iimbak ng data sa imbakan ng bagay, dapat kang magbayad para sa pagsulat at pagbasa ng data na mga operasyon ($10 bawat milyong operasyon). Kapag sumulat ka ng data sa object storage, babayaran mo ang iyong mga gastos sa pagho-host para sa pag-upload ng data sa Internet kung wala sa AWS ang iyong cluster, libre ito doon. Kapag nagbasa ka ng data, magbabayad ka sa pagitan ng $10 at $230 bawat 1TB. Maaari itong maging makabuluhan kung madalas kang magtatanong ng makasaysayang data mula sa kumpol ng Thanos.
Para sa isang cluster ng Thanos, kailangan mong magbayad para sa mga server para sa Compact, Store Gateway, mga bahagi ng Query na nangangailangan ng maraming memory, at CPU para sa malaking halaga ng data.
Ang VictoriaMetrics ay may mga sumusunod na gastos. Kung mag-iimbak ka ng data sa mga GCE HDD drive, lalabas ito sa $40 para sa 1TB. Para sa VictoriaMetrics, sapat na ang mga ordinaryong HDD drive; Ang VictoriaMetrics ay na-optimize para sa HDD.
Nangangailangan ang VictoriaMetrics ng mga server para sa mga bahagi: alinman sa Single-nod o clustered na mga bahagi, na, hindi katulad ng mga bahagi ng Thanos, ay nangangailangan ng mas kaunting CPU at RAM - at naaayon ay magiging mas mura.
Mga halimbawa ng pagpapatupad.
May halimbawa ng pagpapatupad si Thanos sa Gitlab. Ang Gitlab ay ganap na tumatakbo sa Thanos. Ngunit hindi lahat ay napakakinis doon. Kung titingnan mo sila , pagkatapos ay makikita mo na palagi silang mayroon : Walang sapat na memorya para sa Store Gateway o mga bahagi ng Query. Patuloy nilang kailangang dagdagan ang dami ng memorya.
Dahil dito, tumataas ang mga gastos sa paglutas ng mga problemang ito.
Ang pangalawang pagpapatupad, na maaaring mas matagumpay, ay ang Improbable na kumpanya, na nagsimulang bumuo ng Thanos. Inilathala nila ang source code ng Thanos. Ang Improbable ay isang kumpanyang gumagawa ng mga game engine.
Ang VictoriaMetrics ay may mga halimbawa ng pampublikong pagpapatupad:
- wix.com tagabuo ng website
- Ipinapatupad ng Adidas ang VictoriaMetrics at gumawa pa ng presentasyon sa nakaraang PromCon 2019
- TrafficStars - network ng ad
- Ang Seznam.cz ay isang sikat na Czech search engine.
At pagkatapos ay may mga kumpanyang walang pangalan na hindi ko mabanggit ngayon. Hindi sila pumayag.
- Isang pangunahing developer ng laro. Mas malaki kaysa sa im Improbable.
- Pangunahing graphics software developer.
- Malaking bangko ng Russia.
- European wind turbine manufacturer na matagumpay na nasubok ang VictoriaMetrics. Ang manufacturer na ito ay nagpapatupad ng VictoriaMetrics upang subaybayan ang data na nakolekta mula sa mga wind turbine sa bilis na 50 sample bawat segundo bawat sensor. Ang bawat wind turbine ay may ilang daang sensor. Mayroon silang ilang daang wind turbine.
- Mga airline ng Russia na gustong magpatupad ng VictoriaMetrics, ngunit hindi pa rin magawa. Nasa contract stage na tayo sa kanila.
Mga konklusyon.
Niresolba ng VictoriaMetrics at Thanos ang magkatulad na mga problema, ngunit sa magkaibang paraan:
- Pangkalahatang view ng query
- pahalang scaling
- di-makatwirang pagpapanatili
Salamat sa inyo.
Hinihintay ka namin sa aming .
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Ano ang ginagamit mo bilang pangmatagalang imbakan para sa Prometheus?
35,3%Thanos6
0,0%Cortex0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%iba pa4
17 user ang bumoto. 16 na user ang umiwas.
Pinagmulan: www.habr.com
