Ang VictoriaMetrics ay isang mabilis at nasusukat na DBMS para sa pag-iimbak at pagproseso ng data sa anyo ng isang serye ng oras (isang talaan ay binubuo ng oras at isang hanay ng mga halaga na tumutugma sa oras na ito, halimbawa, nakuha sa pamamagitan ng pana-panahong pagboto ng katayuan ng mga sensor o koleksyon ng mga sukatan).
Ang pangalan ko ay Kolobaev Pavel. DevOps, SRE, LeroyMerlin, lahat ay parang code - lahat ito ay tungkol sa atin: tungkol sa akin at tungkol sa iba pang empleyado ng LeroyMerlin.
Mayroong isang ulap batay sa OpenStack. Mayroong maliit na link sa teknikal na radar.
Ito ay binuo sa hardware ng Kubernetes, gayundin sa lahat ng nauugnay na serbisyo para sa OpenStack at pag-log.
Ito ang scheme na mayroon tayo sa pag-unlad. Noong binuo namin ang lahat ng ito, mayroon kaming operator ng Prometheus na nag-imbak ng data sa loob mismo ng K8s cluster. Awtomatiko niyang hinahanap kung ano ang kailangang i-scrub at inilalagay ito sa ilalim ng kanyang mga paa, halos nagsasalita.
Kakailanganin nating ilipat ang lahat ng data sa labas ng Kubernetes cluster, dahil kung may mangyari, kailangan nating maunawaan kung ano at saan.
Ang unang solusyon ay ang paggamit namin ng federation kapag mayroon kaming third-party na Prometheus, kapag pumunta kami sa Kubernetes cluster sa pamamagitan ng federation mechanism.
Ngunit mayroong ilang maliliit na problema dito. Sa aming kaso, nagsimula ang mga problema noong nagkaroon kami ng 250 sukatan, at noong mayroong 000 sukatan, napagtanto namin na hindi kami maaaring gumana nang ganoon. Dinagdagan namin ang scrape_timeout sa 400 segundo.
Bakit kailangan nating gawin ito? Sinimulan ng Prometheus na bilangin ang timeout mula sa simula ng bakod. Hindi mahalaga na ang data ay dumadaloy pa rin. Kung sa loob ng tinukoy na yugto ng panahon ang data ay hindi pinagsama at ang session ay hindi isinara sa pamamagitan ng http, ang session ay itinuturing na nabigo at ang data ay hindi nakapasok sa Prometheus mismo.
Pamilyar ang lahat sa mga graph na nakukuha namin kapag nawawala ang ilan sa data. Ang mga iskedyul ay napunit at hindi kami natutuwa dito.
Ang susunod na opsyon ay sharding batay sa dalawang magkaibang Prometheus sa pamamagitan ng parehong mekanismo ng federation.
Halimbawa, kunin lamang ang mga ito at paghati-hatiin ang mga ito ayon sa pangalan. Maaari rin itong gamitin, ngunit nagpasya kaming magpatuloy.
Kakailanganin na nating iproseso ang mga shards na ito kahit papaano. Maaari kang kumuha ng promxy, na pumupunta sa lugar ng shard at nagpaparami ng data. Gumagana ito sa dalawang shards bilang isang entry point. Maaari itong ipatupad sa pamamagitan ng promxy, ngunit napakahirap pa rin nito.
Ang unang opsyon ay gusto nating talikuran ang mekanismo ng federation dahil napakabagal nito.
Malinaw na sinasabi ng mga developer ng Prometheus, "Guys, gumamit ng ibang TimescaleDB dahil hindi namin susuportahan ang pangmatagalang imbakan ng mga sukatan." Hindi ito ang kanilang gawain.
Isinulat namin sa isang piraso ng papel na kailangan pa naming i-unload sa labas, upang hindi maiimbak ang lahat sa isang lugar.
Ang pangalawang disbentaha ay ang pagkonsumo ng memorya. Oo, naiintindihan ko na marami ang magsasabi na sa 2020 ang isang pares ng gigabytes ng memorya ay nagkakahalaga ng isang sentimos, ngunit gayon pa man.
Ngayon ay mayroon na kaming dev at prod environment. Sa dev ito ay humigit-kumulang 9 gigabytes para sa 350 sukatan. Sa prod ito ay 000 gigabytes at mahigit 14 metrics. At the same time, 780 minutes lang ang retention time namin. Masama ito. At ngayon ipapaliwanag ko kung bakit.
Gumagawa kami ng kalkulasyon, iyon ay, na may isa at kalahating milyong sukatan, at malapit na kami sa kanila, sa yugto ng disenyo nakakakuha kami ng 35-37 gigabytes ng memorya. Ngunit mayroon nang 4 na milyong sukatan ay nangangailangan ng humigit-kumulang 90 gigabytes ng memorya. Ibig sabihin, kinakalkula ito gamit ang formula na ibinigay ng mga developer ng Prometheus. Tiningnan namin ang ugnayan at napagtanto namin na ayaw naming magbayad ng ilang milyon para sa isang server para lang sa pagsubaybay.
Hindi lang namin tataas ang bilang ng mga makina, sinusubaybayan din namin ang mga virtual machine mismo. Samakatuwid, mas maraming virtual machine, mas maraming sukatan ng iba't ibang uri, atbp. Magkakaroon tayo ng espesyal na paglaki ng ating cluster sa mga tuntunin ng mga sukatan.
Sa disk space, hindi lahat ay napakasama dito, ngunit nais kong pagbutihin ito. Nakatanggap kami ng kabuuang 15 gigabytes sa loob ng 120 araw, kung saan 100 ay naka-compress na data, 20 ay hindi naka-compress na data, ngunit palagi naming gusto ang mas kaunti.
Alinsunod dito, nagsusulat kami ng isa pang punto - ito ay isang malaking pagkonsumo ng mga mapagkukunan, na gusto pa rin naming i-save, dahil hindi namin nais na ang aming monitoring cluster ay kumonsumo ng higit pang mga mapagkukunan kaysa sa aming cluster, na namamahala sa OpenStack.
May isa pang disbentaha ng Prometheus, na natukoy natin para sa ating sarili, ito ay hindi bababa sa ilang uri ng limitasyon sa memorya. Sa Prometheus, ang lahat ay mas masahol pa dito, dahil wala itong anumang mga twist. Ang paggamit ng limitasyon sa docker ay hindi rin isang opsyon. Kung biglang bumagsak ang RAF mo at may 20-30 gigabytes, sobrang tagal bago tumaas.
Ito ay isa pang dahilan kung bakit hindi angkop sa atin ang Prometheus, ibig sabihin, hindi natin malilimitahan ang pagkonsumo ng memorya.
Posibleng makabuo ng gayong pamamaraan. Kailangan namin ang pamamaraang ito upang maisaayos ang isang HA cluster. Gusto naming maging available palagi at saanman ang aming mga sukatan, kahit na nag-crash ang server na nag-iimbak ng mga sukatang ito. At sa gayon kailangan nating bumuo ng gayong pamamaraan.
Sinasabi ng scheme na ito na magkakaroon tayo ng pagdoble ng mga shards, at, nang naaayon, pagdoble ng mga gastos ng natupok na mga mapagkukunan. Maaari itong i-scale nang halos pahalang, ngunit gayunpaman ang pagkonsumo ng mapagkukunan ay magiging impiyerno.
Mga kawalan sa pagkakasunud-sunod sa anyo kung saan isinulat namin ang mga ito para sa ating sarili:
- Nangangailangan ng pag-upload ng mga sukatan sa labas.
- Mataas na pagkonsumo ng mapagkukunan.
- Walang paraan upang limitahan ang pagkonsumo ng memorya.
- Kumplikado at resource-intensive na pagpapatupad ng HA.
Para sa aming sarili, nagpasya kaming lumayo kami sa Prometheus bilang isang pasilidad ng imbakan.
Natukoy namin ang mga karagdagang kinakailangan para sa aming sarili na kailangan namin. ito:
- Ito ay suporta sa promql, dahil maraming bagay ang naisulat na para sa Prometheus: mga query, alerto.
- At pagkatapos ay mayroon kaming Grafana, na nakasulat na sa eksaktong parehong paraan para sa Prometheus bilang isang backend. Ayokong isulat muli ang mga dashboard.
- Nais naming bumuo ng isang normal na arkitektura ng HA.
- Nais naming bawasan ang pagkonsumo ng anumang mapagkukunan.
- May isa pang maliit na nuance. Hindi kami maaaring gumamit ng iba't ibang uri ng mga sistema ng koleksyon ng cloud metrics. Hindi pa namin alam kung ano ang mahuhulog sa mga sukatang ito. At dahil kahit ano ay maaaring lumipad doon, kailangan nating limitahan ang ating sarili sa lokal na pagkakalagay.
Nagkaroon ng kaunting pagpipilian. Kinokolekta namin ang lahat ng naranasan namin. Tumingin kami sa pahina ng Prometheus sa seksyon ng pagsasama, nagbasa ng isang grupo ng mga artikulo, at nakita kung ano ang nasa labas. At para sa aming sarili, pinili namin ang VictoriaMetrics bilang kapalit ng Prometheus.
Bakit? dahil:
- Maaaring gumawa ng promql.
- Mayroong isang modular na arkitektura.
- Hindi nangangailangan ng mga pagbabago sa Grafana.
- At higit sa lahat, malamang na ibibigay namin ang imbakan ng mga sukatan sa loob ng aming kumpanya bilang isang serbisyo, kaya't tinitingnan namin nang maaga ang mga paghihigpit sa iba't ibang uri upang magamit ng mga user ang lahat ng mapagkukunan ng cluster sa ilang limitadong paraan, dahil may pagkakataon na ito ay multitenancy.
Gawin natin ang unang paghahambing. Kinukuha namin ang parehong Prometheus sa loob ng cluster, ang panlabas na Prometheus ay napupunta dito. Magdagdag sa pamamagitan ng remoteWrite VictoriaMetrics.
Agad akong magpapareserba na dito ay nakakuha kami ng kaunting pagtaas sa pagkonsumo ng CPU mula sa VictoriaMetrics. Sinasabi sa iyo ng VictoriaMetrics wiki kung aling mga parameter ang pinakamahusay. Sinuri namin sila. Nabawasan nila ang pagkonsumo ng CPU nang napakahusay.
Sa aming kaso, ang pagkonsumo ng memorya ng Prometheus, na matatagpuan sa kumpol ng Kubernetes, ay hindi tumaas nang malaki.
Naghahambing kami ng dalawang data source ng parehong data. Sa Prometheus nakikita natin ang parehong nawawalang data. Maayos ang lahat sa VictoriaMetrics.
Mga resulta ng pagsubok sa espasyo ng disk. Kami sa Prometheus ay nakatanggap ng 120 gigabytes sa kabuuan. Sa VictoriaMetrics nakakatanggap na kami ng 4 gigabytes bawat araw. Mayroong bahagyang naiibang mekanismo kaysa sa nakasanayan nating makita sa Prometheus. Iyon ay, ang data ay na-compress nang maayos sa isang araw, sa kalahating oras. Naani na sila nang maayos sa isang araw, sa kalahating oras, sa kabila ng katotohanang mawawala pa rin ang data mamaya. Bilang resulta, nakatipid kami sa espasyo sa disk.
Nagtitipid din kami sa pagkonsumo ng mapagkukunan ng memorya. Sa oras ng pagsubok, mayroon kaming Prometheus na na-deploy sa isang virtual machine - 8 core, 24 gigabytes. Kinakain ng Prometheus ang halos lahat. Nahulog siya sa OOM Killer. Kasabay nito, 900 aktibong sukatan lamang ang ibinuhos dito. Ito ay humigit-kumulang 000-25 na sukatan bawat segundo.
Pinatakbo namin ang VictoriaMetrics sa isang dual-core virtual machine na may 8 gigabytes ng RAM. Nagawa naming gawing maayos ang VictoriaMetrics sa pamamagitan ng pag-ikot sa ilang bagay sa isang 8GB na makina. Sa huli, pinanatili namin ito sa 7 gigabytes. Kasabay nito, ang bilis ng paghahatid ng nilalaman, ibig sabihin, ang mga sukatan, ay mas mataas pa kaysa sa Prometheus.
Ang CPU ay naging mas mahusay kumpara sa Prometheus. Dito kumukonsumo ang Prometheus ng 2,5 core, at ang VictoriaMetrics ay kumukonsumo lamang ng 0,25 core. Sa simula - 0,5 core. Sa pagsasama nito, umabot ito sa isang core, ngunit ito ay napakabihirang.
Sa aming kaso, ang pagpipilian ay nahulog sa VictoriaMetrics para sa mga malinaw na dahilan; gusto naming makatipid ng pera at ginawa namin.
I-cross out natin kaagad ang dalawang puntos – ang pag-upload ng mga sukatan at ang mataas na pagkonsumo ng mga mapagkukunan. At kailangan lang nating magdesisyon ng dalawang puntos na natitira pa natin para sa ating sarili.
Dito ako magpapareserba kaagad, itinuturing namin ang VictoriaMetrics bilang isang imbakan ng mga sukatan. Ngunit dahil malamang na magbibigay kami ng VictoriaMetrics bilang imbakan para sa lahat ng Leroy, kailangan naming limitahan ang mga gagamit ng cluster na ito para hindi nila ito maibigay sa amin.
Mayroong isang kahanga-hangang parameter na nagbibigay-daan sa iyo upang limitahan sa pamamagitan ng oras, sa dami ng data at sa oras ng pagpapatupad.
Mayroon ding isang mahusay na opsyon na nagpapahintulot sa amin na limitahan ang pagkonsumo ng memorya, sa gayon ay mahahanap namin ang mismong balanse na magbibigay-daan sa amin upang makakuha ng normal na bilis ng pagpapatakbo at sapat na pagkonsumo ng mapagkukunan.
Minus ng isa pang punto, ibig sabihin, i-cross out ang punto - hindi mo malilimitahan ang pagkonsumo ng memorya.
Sa mga unang pag-ulit, sinubukan namin ang VictoriaMetrics Single Node. Susunod, lumipat tayo sa VictoriaMetrics Cluster Version.
Narito mayroon kaming libreng kamay upang paghiwalayin ang iba't ibang mga serbisyo sa VictoriaMetrics depende sa kung ano ang kanilang tatakbo at kung anong mga mapagkukunan ang kanilang kukunin. Ito ay isang napaka-flexible at maginhawang solusyon. Ginamit namin ito sa aming sarili.
Ang mga pangunahing bahagi ng VictoriaMetrics Cluster Version ay vmstsorage. Maaaring mayroong N bilang ng mga ito. Sa aming kaso mayroong 2 sa kanila sa ngayon.
At mayroong vminsert. Isa itong proxy server na nagbibigay-daan sa amin na: ayusin ang sharding sa pagitan ng lahat ng storage na sinabi namin dito, at pinapayagan din nito ang isang replica, ibig sabihin, magkakaroon ka ng sharding at replica.
Sinusuportahan ng Vminsert ang mga protocol ng OpenTSDB, Graphite, InfluxDB at remoteWrite mula sa Prometheus.
Mayroon ding vmselect. Ang pangunahing gawain nito ay pumunta sa vmstorage, tumanggap ng data mula sa kanila, i-deduplicate ang data na ito at ibigay ito sa kliyente.
Mayroong isang kahanga-hangang bagay na tinatawag na vmagent. Talagang gusto namin siya. Pinapayagan ka nitong i-configure nang eksakto tulad ng Prometheus at gawin pa rin ang lahat nang eksakto tulad ng Prometheus. Ibig sabihin, nangongolekta ito ng mga sukatan mula sa iba't ibang entity at serbisyo at ipinapadala ang mga ito sa vminsert. Kung gayon ang lahat ay nakasalalay sa iyo.
Ang isa pang mahusay na serbisyo ay vmalert, na nagbibigay-daan sa iyong gamitin ang VictoriaMetrics bilang backend, tumanggap ng naprosesong data mula sa vminsert at ipadala ito sa vmselect. Pinoproseso nito ang mga alerto mismo, pati na rin ang mga panuntunan. Sa kaso ng mga alerto, natatanggap namin ang alerto sa pamamagitan ng alertmanager.
Mayroong isang bahagi ng wmauth. Maaari naming gamitin o hindi (hindi pa namin ito napagpasyahan) bilang isang authorization system para sa multitenancy na bersyon ng mga cluster. Sinusuportahan nito ang remoteWrite para sa Prometheus at maaaring pahintulutan batay sa url, o sa halip ang pangalawang bahagi nito, kung saan maaari o hindi ka magsulat.
Mayroon ding vmbackup, vmrestore. Ito ay, sa esensya, ang pagpapanumbalik at pag-backup ng lahat ng data. Magagawa ang S3, GCS, file.
Ang unang pag-ulit ng aming cluster ay ginawa sa panahon ng quarantine. Noong panahong iyon, walang replica, kaya ang aming pag-ulit ay binubuo ng dalawang magkaibang at independiyenteng mga kumpol kung saan nakatanggap kami ng data sa pamamagitan ng remoteWrite.
Dito ako magpapareserba na noong lumipat kami mula sa VictoriaMetrics Single Node patungo sa VictoriaMetrics Cluster Version, nanatili pa rin kami sa parehong nagamit na mapagkukunan, ibig sabihin, ang pangunahing isa ay memorya. Ito ay tinatayang kung paano ipinamahagi ang aming data, ibig sabihin, pagkonsumo ng mapagkukunan.
May naidagdag na replica dito. Pinagsama namin ang lahat ng ito sa isang medyo malaking kumpol. Ang lahat ng aming data ay parehong na-shard at ginagaya.
Ang buong cluster ay may N entry point, ibig sabihin ang Prometheus ay maaaring magdagdag ng data sa pamamagitan ng HAPROXY. Narito na ang entry point na ito. At sa pamamagitan ng entry point na ito maaari kang mag-log in mula sa Grafana.
Sa aming kaso, ang HAPROXY ay ang tanging port na pumipili, naglalagay at iba pang mga serbisyo sa loob ng cluster na ito. Sa aming kaso, imposibleng gumawa ng isang address; kailangan naming gumawa ng ilang entry point, dahil ang mga virtual machine mismo kung saan tumatakbo ang VictoriaMetrics cluster ay matatagpuan sa iba't ibang mga zone ng parehong cloud provider, ibig sabihin, hindi sa loob ng aming cloud, ngunit sa labas .
Mayroon kaming alerto. Ginagamit namin ito. Gumagamit kami ng alertmanager mula sa Prometheus. Ginagamit namin ang Opsgenie at Telegram bilang channel ng paghahatid ng alerto. Sa Telegram ay bumubuhos sila mula sa dev, marahil isang bagay mula sa prod, ngunit karamihan ay isang bagay na istatistika, na kailangan ng mga inhinyero. At kritikal si Opsgenie. Ito ay mga tawag, pamamahala ng insidente.
Ang walang hanggang tanong: "Sino ang sumusubaybay sa pagsubaybay?" Sa aming kaso, sinusubaybayan ng pagsubaybay ang pagsubaybay mismo, dahil gumagamit kami ng vmagent sa bawat node. At dahil ang aming mga node ay ipinamahagi sa iba't ibang data center ng parehong provider, ang bawat data center ay may sariling channel, sila ay independyente, at kahit na may dumating na split brain, makakatanggap pa rin kami ng mga alerto. Oo, magkakaroon ng higit pa sa kanila, ngunit mas mahusay na makatanggap ng higit pang mga alerto kaysa wala.
Tinatapos namin ang aming listahan sa isang pagpapatupad ng HA.
At higit pa, gusto kong tandaan ang karanasan ng pakikipag-usap sa komunidad ng VictoriaMetrics. Ito ay naging napaka-positibo. Ang mga lalaki ay tumutugon. Sinusubukan nilang bungkalin ang bawat kaso na inaalok.
Nagsimula ako ng mga isyu sa GitHub. Sila ay nalutas nang napakabilis. Mayroong ilang higit pang mga isyu na hindi ganap na sarado, ngunit nakikita ko na mula sa code na gumagana sa direksyon na ito ay isinasagawa.
Ang pangunahing sakit para sa akin sa panahon ng mga pag-ulit ay na kung isasara ko ang isang node, pagkatapos ay sa unang 30 segundo ay hindi maintindihan ng vminsert na walang backend. Napagpasyahan na ito ngayon. At literal sa isang segundo o dalawa, ang data ay kinuha mula sa lahat ng natitirang mga node, at ang kahilingan ay hihinto sa paghihintay para sa nawawalang node.
Sa ilang mga punto gusto namin ang VictoriaMetrics na maging isang VictoriaMetrics operator. Hinintay namin siya. Aktibo na kaming gumagawa ngayon ng balangkas para sa operator ng VictoriaMetrics na kunin ang lahat ng paunang pagkalkula ng mga panuntunan, atbp. Prometheus, dahil medyo aktibong ginagamit namin ang mga panuntunang kasama ng Prometheus operator.
May mga panukala para mapabuti ang pagpapatupad ng cluster. Binalangkas ko ang mga ito sa itaas.
At gusto ko talagang mag-downsample. Sa aming kaso, ang downsampling ay kailangan lamang para sa pagtingin sa mga uso. Sa madaling salita, sapat na sa akin ang isang sukatan sa araw. Ang mga trend na ito ay kailangan para sa isang taon, tatlo, lima, sampung taon. At sapat na ang isang sukatan na halaga.
- Alam namin ang sakit, tulad ng ilan sa aming mga kasamahan, kapag gumagamit ng Prometheus.
- Pinili namin ang VictoriaMetrics para sa aming sarili.
- Medyo maayos ang sukat nito kapwa patayo at pahalang.
- Maaari naming ipamahagi ang iba't ibang bahagi sa iba't ibang bilang ng mga node sa cluster, limitahan ang mga ito sa pamamagitan ng memorya, magdagdag ng memorya, atbp.
Gagamitin namin ang VictoriaMetrics sa bahay dahil nagustuhan namin ito. Ito ay kung ano ang at kung ano ang naging.
Ilang QR code para sa VictoriaMetrics chat, aking mga contact, LeroyMerlin technical radar.
Pinagmulan: www.habr.com