VictoriaMetrics ni DBMS ya haraka na yenye hatari ya kuhifadhi na kusindika data katika mfumo wa safu ya wakati (rekodi ina wakati na seti ya maadili yanayolingana na wakati huu, kwa mfano, inayopatikana kupitia upigaji kura wa mara kwa mara wa hali ya sensorer au ukusanyaji wa vipimo).
Jina langu ni Kolobaev Pavel. DevOps, SRE, LeroyMerlin, kila kitu ni kama msimbo - yote yanatuhusu: kunihusu na kuhusu wafanyakazi wengine wa LeroyMerlin.
Kuna wingu kulingana na OpenStack. Kuna kiunga kidogo cha rada ya kiufundi.
Imejengwa kwenye vifaa vya Kubernetes, na vile vile kwenye huduma zote zinazohusiana na OpenStack na ukataji miti.
Huu ndio mpango tuliokuwa nao katika maendeleo. Tulipokuwa tukitengeneza haya yote, tulikuwa na mwendeshaji wa Prometheus ambaye alihifadhi data ndani ya nguzo ya K8s yenyewe. Yeye hupata moja kwa moja kile kinachohitaji kusuguliwa na kuiweka chini ya miguu yake, kwa kusema.
Tutahitaji kuhamisha data zote nje ya kikundi cha Kubernetes, kwa sababu ikiwa kitu kitatokea, tunahitaji kuelewa nini na wapi.
Suluhisho la kwanza ni kwamba tunatumia shirikisho tunapokuwa na Prometheus ya mtu wa tatu, tunapoenda kwenye nguzo ya Kubernetes kupitia utaratibu wa shirikisho.
Lakini kuna shida ndogo hapa. Kwa upande wetu, matatizo yalianza tulipokuwa na vipimo 250, na kulipokuwa na vipimo 000, tuligundua kuwa hatukuweza kufanya kazi hivyo. Tuliongeza scrape_timeout hadi sekunde 400.
Kwa nini tulilazimika kufanya hivi? Prometheus anaanza kuhesabu muda kutoka mwanzo wa uzio. Haijalishi kwamba data bado inapita. Ikiwa katika kipindi hiki maalum data haijaunganishwa na kipindi hakijafungwa kupitia http, basi kipindi kinachukuliwa kuwa kimeshindwa na data haiingii kwenye Prometheus yenyewe.
Kila mtu anafahamu grafu ambazo tunapata wakati baadhi ya data inakosekana. Ratiba zimechanika na hatujafurahishwa na hili.
Chaguo linalofuata ni kugawanyika kulingana na Prometheus mbili tofauti kupitia utaratibu huo wa shirikisho.
Kwa mfano, zichukue tu na uzigawanye kwa majina. Hii pia inaweza kutumika, lakini tuliamua kuendelea.
Sasa tutalazimika kushughulikia shards hizi kwa njia fulani. Unaweza kuchukua promksi, ambayo huenda kwenye eneo la shard na kuzidisha data. Inafanya kazi na shards mbili kama sehemu moja ya kuingia. Hii inaweza kutekelezwa kupitia promksi, lakini bado ni ngumu sana.
Chaguo la kwanza ni kwamba tunataka kuachana na utaratibu wa shirikisho kwa sababu ni polepole sana.
Wasanidi wa Prometheus wanasema kwa uwazi, "Jamani, tumieni TimescaleDB tofauti kwa sababu hatutaauni uhifadhi wa muda mrefu wa vipimo." Hii sio kazi yao.
Tunaandika kwenye karatasi ambayo bado tunahitaji kupakua nje, ili tusihifadhi kila kitu mahali pamoja.
Drawback ya pili ni matumizi ya kumbukumbu. Ndio, ninaelewa kuwa wengi watasema kuwa mnamo 2020 gigabytes kadhaa za kumbukumbu hugharimu senti, lakini bado.
Sasa tuna mazingira ya uboreshaji na uzalishaji. Katika dev ni takriban gigabaiti 9 kwa metriki 350. Katika prod ni gigabaiti 000 na zaidi ya metrics 14 kidogo. Wakati huo huo, wakati wetu wa kubaki ni dakika 780 tu. Hii ni mbaya. Na sasa nitaelezea kwa nini.
Tunafanya hesabu, yaani, na metrics milioni moja na nusu, na tayari tuko karibu nao, katika hatua ya kubuni tunapata gigabytes 35-37 za kumbukumbu. Lakini tayari metrics milioni 4 zinahitaji kuhusu gigabytes 90 za kumbukumbu. Hiyo ni, ilihesabiwa kwa kutumia fomula iliyotolewa na watengenezaji wa Prometheus. Tuliangalia uwiano na tukagundua kuwa hatukutaka kulipa milioni kadhaa kwa seva kwa ufuatiliaji tu.
Hatutaongeza tu idadi ya mashine, pia tunafuatilia mashine zenyewe. Kwa hivyo, kadiri mashine za mtandaoni zinavyoongezeka, ndivyo vipimo vingi vya aina mbalimbali, n.k. Tutakuwa na ukuaji maalum wa kundi letu kulingana na vipimo.
Kwa nafasi ya diski, sio kila kitu ni mbaya sana hapa, lakini ningependa kuiboresha. Tulipokea jumla ya gigabaiti 15 katika siku 120, ambazo 100 ni data iliyobanwa, 20 ni data isiyobanwa, lakini tunataka kila wakati kidogo.
Ipasavyo, tunaandika jambo moja zaidi - hii ni matumizi makubwa ya rasilimali, ambayo bado tunataka kuokoa, kwa sababu hatutaki kundi letu la ufuatiliaji kutumia rasilimali zaidi kuliko nguzo yetu, ambayo inasimamia OpenStack.
Kuna drawback moja zaidi ya Prometheus, ambayo tumejitambulisha wenyewe, hii ni angalau aina fulani ya kizuizi cha kumbukumbu. Na Prometheus, kila kitu ni mbaya zaidi hapa, kwa sababu haina twists kama hiyo hata kidogo. Kutumia kikomo kwenye docker pia sio chaguo. Ikiwa ghafla RAF yako ilianguka na kuna gigabytes 20-30, basi itachukua muda mrefu sana kuinuka.
Hii ni sababu nyingine kwa nini Prometheus haifai kwetu, i.e. hatuwezi kupunguza utumiaji wa kumbukumbu.
Inawezekana kuja na mpango kama huo. Tunahitaji mpango huu ili kuandaa nguzo ya HA. Tunataka vipimo vyetu vipatikane kila mara na kila mahali, hata kama seva inayohifadhi vipimo hivi itaacha kufanya kazi. Na kwa hivyo tutalazimika kuunda mpango kama huo.
Mpango huu unasema kwamba tutakuwa na kurudia kwa shards, na, ipasavyo, kurudia kwa gharama za rasilimali zinazotumiwa. Inaweza kupunguzwa karibu kwa usawa, lakini hata hivyo matumizi ya rasilimali yatakuwa ya kuzimu.
Hasara kwa utaratibu katika fomu ambayo tulijiandikia wenyewe:
- Inahitaji kupakia vipimo nje.
- Matumizi ya juu ya rasilimali.
- Hakuna njia ya kupunguza matumizi ya kumbukumbu.
- Utekelezaji tata na unaotumia rasilimali nyingi wa HA.
Kwa sisi wenyewe, tuliamua kwamba tunahama kutoka Prometheus kama kituo cha kuhifadhi.
Tumetambua mahitaji ya ziada kwa ajili yetu sisi wenyewe tunayohitaji. Hii:
- Huu ni usaidizi wa promql, kwa sababu mambo mengi tayari yameandikwa kwa Prometheus: maswali, arifa.
- Na kisha tuna Grafana, ambayo tayari imeandikwa kwa njia sawa kwa Prometheus kama backend. Sitaki kuandika upya dashibodi.
- Tunataka kujenga usanifu wa kawaida wa HA.
- Tunataka kupunguza matumizi ya rasilimali yoyote.
- Kuna nuance nyingine ndogo. Hatuwezi kutumia aina mbalimbali za mifumo ya ukusanyaji wa vipimo vya wingu. Bado hatujui ni nini kitakachoangukia katika vipimo hivi. Na kwa kuwa chochote kinaweza kuruka huko, tunapaswa kujizuia kwa uwekaji wa ndani.
Kulikuwa na chaguo kidogo. Tulikusanya kila kitu ambacho tulikuwa na uzoefu nacho. Tuliangalia ukurasa wa Prometheus katika sehemu ya ujumuishaji, tukasoma rundo la vifungu, na tukaona ni nini kilikuwa huko. Na sisi wenyewe, tulichagua VictoriaMetrics kama mbadala wa Prometheus.
Kwa nini? Kwa sababu:
- Anajua promql.
- Kuna usanifu wa kawaida.
- Haihitaji mabadiliko kwa Grafana.
- Na muhimu zaidi, labda tutatoa hifadhi ya vipimo ndani ya kampuni yetu kama huduma, kwa hivyo tunatazamia mapema vikwazo vya aina mbalimbali ili watumiaji waweze kutumia rasilimali zote za nguzo kwa njia fulani, kwa sababu kuna nafasi. kwamba itakuwa multitenancy.
Hebu tufanye ulinganisho wa kwanza. Tunachukua Prometheus sawa ndani ya nguzo, Prometheus ya nje huenda kwake. Ongeza kupitia remoteWrite VictoriaMetrics.
Mara moja nitahifadhi kuwa hapa tulipata ongezeko kidogo la matumizi ya CPU kutoka VictoriaMetrics. Wiki ya VictoriaMetrics inakuambia ni vigezo gani ni bora zaidi. Tuliziangalia. Wamepunguza matumizi ya CPU vizuri sana.
Kwa upande wetu, matumizi ya kumbukumbu ya Prometheus, ambayo iko katika nguzo ya Kubernetes, haikuongezeka sana.
Tunalinganisha vyanzo viwili vya data vya data sawa. Katika Prometheus tunaona data sawa inayokosekana. Kila kitu kiko sawa katika VictoriaMetrics.
Matokeo ya mtihani wa nafasi ya diski. Sisi katika Prometheus tulipokea gigabytes 120 kwa jumla. Katika VictoriaMetrics tayari tunapokea gigabaiti 4 kwa siku. Kuna utaratibu tofauti kidogo kuliko ule ambao tumezoea kuona katika Prometheus. Hiyo ni, data tayari imesisitizwa vizuri kwa siku, katika nusu saa. Tayari wamevuna vizuri kwa siku, katika nusu saa, licha ya ukweli kwamba data bado itapotea baadaye. Matokeo yake, tulihifadhi kwenye nafasi ya disk.
Pia tunaokoa kwenye matumizi ya rasilimali ya kumbukumbu. Wakati wa majaribio, tulikuwa na Prometheus iliyotumwa kwenye mashine ya kawaida - cores 8, gigabytes 24. Prometheus anakula karibu kila kitu. Alianguka kwa OOM Killer. Wakati huo huo, ni metrics 900 tu zinazofanya kazi zilimwagwa ndani yake. Hii ni takriban vipimo 000-25 kwa sekunde.
Tuliendesha VictoriaMetrics kwenye mashine pepe ya dual-core yenye gigabytes 8 za RAM. Tulifanikiwa kupata VictoriaMetrics kufanya kazi vizuri kwa kuhangaika na mambo machache kwenye mashine ya 8GB. Mwishowe, tuliiweka kwa gigabytes 7. Wakati huo huo, kasi ya utoaji wa yaliyomo, i.e. metrics, ilikuwa kubwa zaidi kuliko ile ya Prometheus.
CPU imekuwa bora zaidi ikilinganishwa na Prometheus. Hapa Prometheus hutumia cores 2,5, na VictoriaMetrics hutumia cores 0,25 tu. Mwanzoni - cores 0,5. Inapounganishwa, hufikia msingi mmoja, lakini hii ni nadra sana.
Kwa upande wetu, chaguo liliangukia VictoriaMetrics kwa sababu dhahiri; tulitaka kuokoa pesa na tulifanya hivyo.
Hebu tuchunguze pointi mbili mara moja - upakiaji wa vipimo na matumizi makubwa ya rasilimali. Na inabidi tuamue pointi mbili ambazo bado tumebaki nazo wenyewe.
Hapa nitaweka nafasi mara moja, tunazingatia VictoriaMetrics kama hifadhi ya vipimo. Lakini kwa kuwa tuna uwezekano mkubwa wa kutoa VictoriaMetrics kama hifadhi kwa Leroy yote, tunahitaji kuwawekea kikomo wale ambao watatumia nguzo hii ili wasitupe.
Kuna parameta nzuri ambayo hukuruhusu kuweka kikomo kwa wakati, kwa kiasi cha data na kwa wakati wa utekelezaji.
Pia kuna chaguo bora ambayo inaruhusu sisi kupunguza matumizi ya kumbukumbu, kwa hivyo tunaweza kupata usawa ambao utaturuhusu kupata kasi ya kawaida ya kufanya kazi na matumizi ya kutosha ya rasilimali.
Ondoa nukta moja zaidi, i.e. ondoa hoja - huwezi kupunguza matumizi ya kumbukumbu.
Katika marudio ya kwanza, tulijaribu Njia Moja ya VictoriaMetrics. Ifuatayo tunakwenda kwenye Toleo la Nguzo la VictoriaMetrics.
Hapa tuna mkono wa bure wa kutenganisha huduma tofauti katika VictoriaMetrics kulingana na watatumia nini na watatumia rasilimali gani. Hii ni suluhisho rahisi sana na rahisi. Tulitumia hii juu yetu wenyewe.
Vipengee vikuu vya Toleo la Nguzo la VictoriaMetrics ni vmstsorage. Kunaweza kuwa na N nambari yao. Kwa upande wetu kuna 2 kati yao hadi sasa.
Na kuna vminsert. Hii ni seva ya proksi inayoturuhusu: kupanga sharding kati ya hifadhi zote ambazo tuliiambia kuzihusu, na pia inaruhusu nakala, yaani, utakuwa na sharding na nakala.
Vminsert inasaidia OpenTSDB, Graphite, InfluxDB na itifaki za RemoteWrite kutoka Prometheus.
Kuna pia vmselect. Kazi yake kuu ni kwenda kwa vmstorage, kupokea data kutoka kwao, kutoa data hii na kumpa mteja.
Kuna kitu cha ajabu kinaitwa vmagent. Tunampenda sana. Inakuruhusu kusanidi haswa kama Prometheus na bado ufanye kila kitu kama Prometheus. Hiyo ni, inakusanya metriki kutoka kwa vyombo na huduma tofauti na kuzituma kwa vminsert. Kisha kila kitu kinategemea wewe.
Huduma nyingine nzuri ni vmalert, ambayo hukuruhusu kutumia VictoriaMetrics kama sehemu ya nyuma, kupokea data iliyochakatwa kutoka kwa vminsert na kuituma kwa vmselect. Inachakata arifa zenyewe, pamoja na sheria. Katika hali ya arifa, tunapokea arifa kupitia msimamizi wa arifa.
Kuna sehemu ya wmauth. Tunaweza au hatuwezi (hatujaamua juu ya hili bado) kuitumia kama mfumo wa uidhinishaji wa toleo la multitenancy la vikundi. Inaauni RemoteWrite kwa Prometheus na inaweza kuidhinisha kulingana na url, au tuseme sehemu yake ya pili, ambapo unaweza au huwezi kuandika.
Pia kuna vmbackup, vmrestore. Hii ni, kimsingi, urejeshaji na chelezo ya data zote. Inaweza kufanya S3, GCS, faili.
Marudio ya kwanza ya nguzo yetu yalifanywa wakati wa karantini. Wakati huo, hapakuwa na nakala, kwa hivyo marudio yetu yalikuwa na makundi mawili tofauti na huru ambayo tulipokea data kupitia remoteWrite.
Hapa nitaweka uhifadhi kwamba tulipohama kutoka kwa Njia Moja ya VictoriaMetrics hadi Toleo la Nguzo la VictoriaMetrics, bado tulibaki na rasilimali zinazotumiwa, yaani, kumbukumbu kuu. Hii ni takriban jinsi data yetu, yaani matumizi ya rasilimali, ilivyosambazwa.
Nakala tayari imeongezwa hapa. Tuliunganisha haya yote katika nguzo moja kubwa kiasi. Data yetu yote imegawanywa na kuigwa.
Kundi zima lina alama za N, kumaanisha kwamba Prometheus inaweza kuongeza data kupitia HAPROXY. Hapa tuna sehemu hii ya kuingilia. Na kupitia hatua hii ya kuingia unaweza kuingia kutoka Grafana.
Kwa upande wetu, HAPROXY ndio mlango pekee ambao proksi huchagua, kuingiza na huduma zingine ndani ya nguzo hii. Kwa upande wetu, haikuwezekana kutengeneza anwani moja; ilibidi tutengeneze viingilio kadhaa, kwa sababu mashine zenyewe ambazo nguzo ya VictoriaMetrics huendesha ziko katika maeneo tofauti ya mtoaji wa wingu sawa, i.e. sio ndani ya wingu letu, lakini nje. .
Tunayo tahadhari. Tunaitumia. Tunatumia alertmanager kutoka Prometheus. Tunatumia Opsgenie na Telegraph kama njia ya uwasilishaji ya tahadhari. Kwenye Telegramu wanamimina kutoka kwa dev, labda kitu kutoka kwa prod, lakini haswa kitu cha takwimu, kinachohitajika na wahandisi. Na Opsgenie ni muhimu. Hizi ni simu, usimamizi wa matukio.
Swali la milele: "Ni nani anayesimamia ufuatiliaji?" Kwa upande wetu, wachunguzi wa ufuatiliaji wanajiangalia yenyewe, kwa sababu tunatumia vmagent kwenye kila node. Na kwa kuwa nodi zetu zinasambazwa katika vituo tofauti vya data vya mtoa huduma yuleyule, kila kituo cha data kina mkondo wake, vinajitegemea, na hata ubongo uliogawanyika ukifika, bado tutapokea arifa. Ndio, kutakuwa na zaidi yao, lakini ni bora kupokea arifu zaidi kuliko hakuna.
Tunamaliza orodha yetu na utekelezaji wa HA.
Na zaidi ningependa kutambua uzoefu wa kuwasiliana na jumuiya ya VictoriaMetrics. Ilibadilika kuwa chanya sana. Vijana ni msikivu. Wanajaribu kupekua katika kila kesi inayotolewa.
Nilianza masuala kwenye GitHub. Walitatuliwa haraka sana. Kuna maswala kadhaa zaidi ambayo hayajafungwa kabisa, lakini tayari ninaweza kuona kutoka kwa nambari ambayo inafanya kazi katika mwelekeo huu.
Maumivu makuu kwangu wakati wa kurudia ni kwamba ikiwa nilifunga node, basi kwa sekunde 30 za kwanza vminsert haikuweza kuelewa kuwa hakuna backend. Hii sasa imeamuliwa. Na kwa kweli katika sekunde moja au mbili, data inachukuliwa kutoka kwa nodi zote zilizobaki, na ombi huacha kungojea node hiyo iliyokosa.
Wakati fulani tulitaka VictoriaMetrics iwe opereta wa VictoriaMetrics. Tulimngoja. Sasa tunaunda mfumo kwa opereta wa VictoriaMetrics kuchukua sheria zote za kukokotoa mapema, n.k. Prometheus, kwa sababu tunatumia kikamilifu sheria zinazokuja na opereta wa Prometheus.
Kuna mapendekezo ya kuboresha utekelezaji wa nguzo. Nimezitaja hapo juu.
Na kwa kweli nataka kupunguza sampuli. Kwa upande wetu, sampuli za chini zinahitajika kwa mitindo ya kutazama tu. Kwa kusema, kipimo kimoja kinanitosha wakati wa mchana. Mwelekeo huu unahitajika kwa mwaka, tatu, tano, miaka kumi. Na thamani moja ya metri inatosha kabisa.
- Tumejua maumivu, kama walivyofanya wenzetu wengine, wakati wa kutumia Prometheus.
- Tulijichagulia VictoriaMetrics.
- Ni mizani vizuri kabisa wima na usawa.
- Tunaweza kusambaza vipengele tofauti kwa nambari tofauti za nodi kwenye nguzo, ziweke kikomo kwa kumbukumbu, kuongeza kumbukumbu, nk.
Tutatumia VictoriaMetrics nyumbani kwa sababu tuliipenda sana. Hivi ndivyo ilivyokuwa na imekuwa.
Misimbo kadhaa ya QR ya gumzo la VictoriaMetrics, anwani zangu, rada ya kiufundi ya LeroyMerlin.
Chanzo: mapenzi.com