🥇VictoriaMetrics dhe monitorimi i mjeteve private. Pavel Kolobaev

VictoriaMetrics — një DBMS e shpejtë dhe e shkallëzuar për ruajtjen dhe përpunimin e të dhënave në formën e serive temporale (një regjistrim krijon kohën dhe një grup vlerash përkatëse për atë kohë, për shembull, të marra nëpërmjet pyetjeve periodike të gjendjeve të sensorëve ose të grumbullimit të metrikave).

Më quajnë Kolobajev Pavel. DevOps, SRE, LeroyMerlin, gjithçka si kod – kjo është gjithçka për ne: për mua dhe për kolegët e tjerë të LeroyMerlin.

https://bit.ly/3jf1fIK

Ka një cloud të bazuar në OpenStack. Atje ka një lidhje të vogël për radarin teknik.

E ndërtuar mbi bazën e harduerit Kubernetes, si dhe mbi të gjitha shërbimet përkatëse të OpenStack dhe regjistrimit.

Skema ishte kështu gjatë zhvillimit. Kur e zhvilluam, kishim një operator Prometheus, i cili ruante të dhënat brenda vetë klasës K8s. Ai automatiksht gjen atë që duhet të shkrapohet dhe e sistemon, thënë ndryshe.

Të gjitha të dhënat duhet t'i transferojmë jashtë klasës Kubernetes, sepse nëse ndodh diçka, ne duhet të kuptojmë se çfarë dhe ku.

Zgjidhja e parë – ne përdorim federation, kur kemi një Prometheus të jashtëm, kur qarkullojmë në klasën Kubernetes përmes mekanizmit federation.

Por këtu dalin disa probleme. Në rastin tonë problemi filloi kur patëm 250,000 metrika, dhe kur arritëm në 400,000 metrika, kuptuam se nuk mund të punojmë kështu. Ne rritëm scrape_timeout në 25 sekonda.

Pse na u desh të bënim këtë? Prometheus fillon të numërojë kohën e skadimit që nga momenti i marrjes së të dhënave. Dhe nuk ka rëndësi se të dhënat ende po lëvizin. Nëse brenda këtij intervali të caktuar kohor të dhënat nuk janë shkarkuar dhe sesioni nuk do të mbyllet përmes http, atëherë sesioni konsiderohet dështim dhe të dhënat nuk arrijnë në Prometheus.

Grafikët që të gjithë i njohim, të cilat marrim kur mungojnë disa të dhëna. Grafikët janë të shqyer dhe kjo nuk na kënaq.

Opcioni tjetër – është sharding bazuar në dy Prometheus të ndryshëm përmes të njëjtit mekanizëm federation.

Për shembull, thjesht të merret dhe të shkarkohet sipas emrit. Kjo mund të përdoret gjithashtu, por ne vendosëm të lëvizim përpara.

Tani do na duhet të përpunojmë këto sharde në njëfarë mënyre. Mund të përdorni promxy, i cili shkon në zonën e shardit, dhe bën shumëfishimin e të dhënave. Ai punon me dy sharde si me një pikë të vetme hyrje. Kjo mund të realizohet përmes promxy, por është ende shumë e komplikuar.

Opcioni i parë – ne duam të heqim dorë nga mekanizmi federation, sepse është shumë i ngadalshëm.

Zhvilluesit e Prometheus thonë qartë: «Djem, përdorni databaza të tjera si TimescaleDB, sepse ne nuk do të mbështesim ruajtjen afatgjatë të metrikave». Kjo nuk është detyra e tyre.

Ne e shkruajmë në letër se na duhet një eksport jashtë, për të mos ruajtur gjithçka në një vend.

Disavantazhi i dytë – është konsumimi i memories. Po, e kuptoj që shumica do të thonë se në vitin 2020 disa gigabajt memorie janë një çmim i vogël, por megjithatë.

Tani kemi një ambient dev dhe prodhimi. Në dev, ajo ka rreth 9 gigabajt për 350,000 metrika. Në prodhim – rreth 14 gigabajt për 780,000 metrika. Në të njëjtën kohë, koha e ruajtjes është vetëm 30 minuta. Kjo është keq. Dhe tani do ta shpjegoj pse.

Ne bëjmë një llogari, pra, në 1.5 milion metrika, dhe ne jemi tashmë afër, në fazën e projektimit, marrim 35-37 gigabajt memorie. Por tashmë për 4 milion metrika kërkohet rreth 90 gigabajt memorie. Pra, kjo është llogaritur sipas formulës që ofrojnë zhvilluesit e Prometheus. Ne kemi parë korelacionin dhe kuptuam se nuk duam të paguajmë disa miliona për një server thjesht për monitorim.

Numri i makinerive nuk do të rritet vetëm, ne gjithashtu po monitorojmë vetë makinat virtuale. Prandaj, sa më shumë makina virtuale, aq më shumë metrika të ndryshme etj. Do të kemi një rritje të veçantë të klasës sonë në lidhje me metrikat.

Me hapësirën e diskut këtu nuk është aq keq, por do të deshiim të përmirësojmë. Ne kemi marrë për 15 ditë gjithsej 120 gigabajt, nga të cilat 100 janë të dhëna të kompresuara, 20 janë të dhëna të pakompresuara, por gjithmonë dëshirojmë më pak.

Për rrjedhojë, ne shkruajmë një pikë tjetër – është konsumimi i madh i burimeve, të cilat dëshirojmë t'i kursejmë, sepse nuk duam që klasa jonë e monitorimit të konsumojë më shumë burime sesa klasa jonë që merret me menaxhimin e OpenStack.

Ka një tjetër disavantazh të Prometheus, që ne e kemi zbuluar, është ndonjë kufizim në memorie. Me Prometheus këtu është duke u bërë shumë më keq, sepse ai saktësisht nuk ka këto kufizime. Përdorimi i kufizimit në docker gjithashtu nuk është një zgjidhje. Nëse ndonjëherë RAFT bie dhe atje janë 20-30 gigabajt, atëherë do të rifillojë shumë ngadalë.

Kjo është një arsye tjetër pse Prometheus nuk na përshtatet, pra, nuk mund të kufizohet konsumimi i memories.

Mund të krijohet një skemë të tillë. Kjo skemë na nevojitet për të organizuar një cluster HA. Ne duam që metrike tona të jenë të aksesueshme gjithmonë dhe kudo, edhe kur serveri që ruan këto metrika bie. Kështu që do të duhet të ndërtojmë një skemë të tillë.

Kjo skemë thotë se do të kemi dyfishim të shard-ëve, dhe gjithashtu dyfishim të shpenzimeve të resurseve të përdorura. Mund të shkallëzohet pothuajse horizontalisht, por megjithatë, konsumi i burimeve do të jetë i lartë.

Mangësitë sipas rendit siç i kemi shkruar:

Kërkohet eksportimi i metrikave jashtë.
Konsum i madh i burimeve.
Nuk mund të kufizohet konsumi i memories.
Implementim i komplikuar dhe i ngarkuar për HA.

Kemi vendosur që të heqim dorë nga Prometheus si një depo.

Kemi përcaktuar disa kërkesa shtesë që na nevojiten. Këto janë:

Kjo është mbështetje për promql, sepse tashmë është shkruar shumë për Prometheus: kërkesa, alarme.
Dhe më pas kemi Grafana, e cila gjithashtu është e ndërtuar për Prometheus si backend. Nuk duam të rilidhim panellet.
Ne duam të ndërtuam një arkitekturë normale HA.
Ne duam të reduktojmë konsumimin e çdo burimi.
Ka një nuancë të vogël. Nuk mund të përdorim sistemi të ndryshme cloud për mbledhjen e metrikave. Nuk e dimë se çfarë do të shkojë në këto metrika për momentin. Dhe pasi që mund të shkojë gjithçka, jemi të detyruar të kufizohemi në vendosjen lokale.

Zgjedhja ishte e vogël. Kemi mbledhur gjithçka për të cilën kemi pasur përvojë. Kemi parë faqen e Prometheus në seksionin e integrimit, kemi lexuar shumë artikuj, kemi parë se çfarë ka në dispozicion. Dhe për ne zgjodhëm VictoriaMetrics si zëvendësim për Prometheus.

Pse? Sepse:

Mbështet promql.
Ka arkitekturë modulare.
Nuk kërkon ndryshime në Grafana.
Dhe më e rëndësishmja – ndoshta do të ofrojmë depo metrikash brenda kompanisë sonë si shërbim, prandaj po shikojmë drejt kufizimeve të ndryshme, në mënyrë që përdoruesit të mund të përdorin burimet e klasterit në një formë të kufizuar, sepse ka mundësi që ai do të jetë multitenancy.

Po bëjmë krahasimin e parë. Marim të njëjtin Prometheus brenda klasterit, dhe një Prometheus të jashtëm që lidhet me të. Shtojmë VictoriaMetrics përmes remoteWrite.

Dua të sqaroj se këtu kemi hasur një rritje të vogël të konsumit të CPU nga VictoriaMetrics. Në wiki-n e VictoriaMetrics thuhet se cilat parametra janë më të përshtatshëm. I kemi verifikuar ato. Ata e zvogëlojnë shumë mirë konsumimin e CPU.

Në rastin tonë, konsumi i memories nga Prometheus, i cili ndodhet në klasterin Kubernetes, ka rritur pak.

Krahasojmë dy burime të dhënash të të njëjtave të dhëna. Në Prometheus shohim të njëjtat të dhëna të munguar. Në VictoriaMetrics gjithçka është në rregull.

Rezultatet e testeve me hapësirën e diskut. Në Prometheus morëm 120 gigabajt gjithsej. Në VictoriaMetrics marrim tashmë 4 gigabajt në ditë. Atje është një mekanizëm pak ndryshe nga ai që jemi mësuar të shohim në Prometheus. Pra, të dhënat janë kompresuar mjaft mirë brenda ditës, brenda gjysmë ore. Ato janë kompresuar mirë brenda ditës, brenda gjysmë ore, megjithatë më pas do të bashkohen të dhënat. Në fund, ne kursyem hapësirën e diskut.

Gjithashtu kursejmë në konsumimin e burimeve të memories. Në momentin e testeve, Prometheus ishte instaluar në një makinë virtuale – 8 bërthama, 24 gigabajt. Prometheus merr pothuajse gjithçka. Ai ra për shkak të OOM Killer. Në të kishte vetëm 900,000 metrika aktive. Kjo është rreth 25,000-27,000 metrika në sekondë.

VictoriaMetrics u aktivizua në një makinë virtuale me dy bërthama dhe 8 gigabajt RAM. Na arriti të bënim që VictoriaMetrics të funksiononte mirë, duke rregulluar disa parametra në makinën e 8-gigabajtë. Në fund, ne arritëm ta mbajmë atë në 7 gigabajt. Në të njëjtën kohë, morëm një shpejtësi të lartë të dhënash, domethënë metrikave, madje më të lartë se ajo e Prometheus.

Në CPU situata u përmirësua ndjeshëm në krahasim me Prometheus. Këtu Prometheus konsumon 2.5 bërthama, ndërsa VictoriaMetrics vetëm 0.25 bërthama. Në fillim – 0.5 bërthama. Ndërsa bashkohet, arrin deri në një bërthamë, por kjo ndodh shumë rrallë.

Në rastin tonë, zgjedhja ra në VictoriaMetrics për arsye të dukshme, ne dëshironim të kursenim dhe vërtetë kursyem.

Heqim menjëherë dy pika – eksportimin e metrikave dhe konsumimin e madh të burimeve. Na mbetet të zgjidhim dy pika që i kemi lënë për vete.

Dua të sqaroj se ne po e shqyrtojmë VictoriaMetrics si një depo metrikash. Por pasi do ta ofrojmë, shumë të mundshëm, VictoriaMetrics si depo për gjithë Leroy, na nevojitet të kufizojmë ata që do ta përdorin këtë klaster, në mënyrë që ata të mos na e prishin.

Ka një parametr të shkëlqyer, i cili lejon kufizimin sipas kohës, volumit të të dhënave dhe kohës së ekzekutimit.

Ka gjithashtu një opsion të shkëlqyer që lejon kufizimin e konsumit të memories, kështu që mund të gjejmë atë balancën që na lejon të kemi një shpejtësi normale pune dhe një konsum të arsyeshëm të burimeve.

Një tjetër pikë negative, dmth. e anulojmë pikën – nuk mund të kufizohet konsumi i memories.

Në iteracionet e para ne testuam VictoriaMetrics Single Node. Pastaj kalojmë në VictoriaMetrics Cluster Version.

Këtu kemi lirinë të shpërndajmë shërbime të ndryshme në VictoriaMetrics në varësi të asaj se si do të punojnë dhe cilat burime do të konsumojnë. Kjo është një zgjidhje shumë fleksibël dhe e përshtatshme. Ne e kemi përdorur atë.

Komponentët kryesorë të VictoriaMetrics Cluster Version janë vmstorage. Mund të ketë një numër N të tillë. Në rastin tonë deri tani kemi 2.

Dhe ka vminsert. Ky është një server proxy që na lejon të: organizojmë shardimin ndërmjet të gjitha storages që i kemi treguar dhe gjithashtu jep një replikë, dmth. do të keni si sharding ashtu edhe replikë.

Vminsert mbështet protokollet OpenTSDB, Graphite, InfluxDB dhe remoteWrite nga Prometheus.

Ka gjithashtu vmselect. Detyra e tij kryesore është të shkojë në vmstorage, të marrë të dhënat nga ata, të deduplichojë këto të dhëna dhe t’ua kthejë klientëve.

Ka një gjë të mrekullueshme si vmagent. Na pëlqen shumë. Ajo mundëson që të konfigurohet njësoj si Prometheus dhe bën gjithçka saktësisht si Prometheus. Kështu, ajo grumbullon metrikat nga entitete dhe shërbime të ndryshme dhe i dërgon ato në vminsert. Më pas gjithçka varet nga ju.

Një shërbim tjetër të mrekullueshëm është vmalert, i cili mundëson si backend përdorimin e VictoriaMetrics, merr të dhëna nga vminsert dhe dërgon në vmselect të dhënat e përpunuara. Ai përpunon alertrat dhe rregullat. Në rastin e alertrave, ne marrim alerte përmes alertmanager.

Ka komponentin wmauth. Ai mund të përdoret, ndoshta, si sistem autorizimi për versionin e multitenancy të grupeve. Ai mbështet remoteWrite për Prometheus dhe mund të autorizojë në bazë të url, më saktësisht pjesës së dytë të saj, ku ju mund të shkruani ose jo.

Ka gjithashtu vmbackup, vmrestore. Këto, në thelb, janë rikuperimi dhe backup i të gjithë të dhënave. Mbështet S3, GCS, file.

Ipari iteracion i grupit tonë u bë gjatë karantinës. Në atë kohë nuk kishte replikë, kështu që iteracioni ynë përbëhej nga dy grupe të ndryshme dhe të pavarura, në të cilat përmes remoteWrite merrnim të dhëna.

Këtu tani mund të them se, kur kaluam nga VictoriaMetrics Single Node në VictoriaMetrics Cluster Version, ne mbetëm ende në të njëjtat burime të konsumit, dmth. kryesore është memoria. Kështu, për këtë arsye, të dhënat tona u shpërndanë, dmth. konsumimi i burimeve.

Tani ishte shtuar një replikë. Ne e bashkuam të gjithë këtë në një grup relativisht të madh. Të gjitha të dhënat tona janë si të sharduar ashtu edhe të replikuar.

I gjithë grupi ka N pika hyrjeje, dmth. Prometheus mund të shtojë të dhëna përmes HAPROXY. Kjo është pika jonë e hyrjes. Dhe përmes kësaj pike hyrje mund të qasemi me Grafana.

Në rastin tonë, HAPROXY është porti i vetëm që përshkon selektimin, futjen dhe shërbime të tjera brenda këtij grupi. Në rastin tonë nuk ishte e mundur të krijohej një adresë e vetme, na duhej të krijonim disa pika hyrjeje, sepse vetë virtualet, në të cilat funksionon grupi VictoriaMetrics, ndodhen në zona të ndryshme të një ofruesi cloud, dmth. jashtë oborrit tonë, por jashtë.

Ne kemi alerim. Ne e përdorim atë. Ne përdorim alertmanager nga Prometheus. Si kanal për dërgimin e alertrave ne përdorim Opsgenie dhe Telegram. Në Telegram ndodhin alertrat nga dev, ndoshta diçka nga prodhimi, por më shumë diçka statistike, e nevojshme për inxhinierët. Ndërsa Opsgenie është kritike. Këto janë thirrje, menaxhimi i incidenteve.

Një pyetje e përhershme: «Kush e monitoron monitorimin?». Në rastin tonë, monitorimi e monitoron vetë monitorimin, sepse ne përdorim vmagent në çdo nodë. Dhe pasi nodët tanë janë shpërndarë në data-qendrat e një ofruesi, secila data-qendër ka kanal të vet, ato janë të pavarura dhe madje edhe nëse ndodh një split brain, ne do të marrim ende alerte. Po, do të jenë më shumë, por më mirë të kesh më shumë alerte sesa asnjë.

Ne e përfundojmë listën tonë me realizimin e HA.

Dhe më pas do të doja të theksoja përvojën e komunikimit me komunitetin e VictoriaMetrics. Ishte shumë pozitive. Djemtë janë të gatshëm të ndihmojnë. Ata përpiqen të kuptojnë çdo rast që paraqitet.

Kam hapur probleme në GitHub. Ato u zgjidhën shumë shpejt. Ka edhe disa probleme të tjera që nuk janë mbyllur plotësisht, por tani e shoh që puna në këtë drejtim po shkon.

Gjëja kryesore gjatë iteracioneve për mua ishte që nëse ndaloja nodin, për 30 sekondat e para sistemi vminsert nuk kuptonte që backend-i nuk ishte aty. Tani kjo është zgjidhur. Tani të dhënat merren brenda një sekonde ose dy nga të gjithë nodet e mbetura, dhe kërkesa ndalon së pritur për atë nod që mungon.

Në një moment, ne do të doja që ky të ishte operatori VictoriaMetrics. E pritëm atë. Tani jemi në procesin e ndërtimit të një mbështetjeje për operatorin VictoriaMetrics, për të marrë të gjitha rregullat e parakalkulimit etj. Prometheus, sepse ne e përdorim mjaft aktivisht rregullat që vijnë së bashku me operatorin Prometheus.

Ka propozime për përmirësimin e implementimit në klaster. I kam shprehur ato më sipër.

Dhe duhet shumë downsampling. Në rastin tonë, downsampling është i nevojshëm vetëm për shikimin e trendeve. Në fjalë të tjera, një metrikë për një ditë është e mjaftueshme. Këto trende janë të nevojshme për një vit, për tre, për pesë, për dhjetë vjet. Dhe një vlerë metrikë është plotësisht e mjaftueshme.

Ne e pohojmë dhimbjen, ashtu si disa kolegë tanë, gjatë përdorimit të Prometheus.
Ne zgjodhëm për vete VictoriaMetrics.
Ajo shkallëzohet mjaft mirë si në mënyrë vertikale ashtu edhe horizontale.
Ne mund t'i shpërndajmë komponentët e ndryshëm në një numër të ndryshëm nodash në klaster, t'i limitojmë ato sipas sasisë së memories, t'i shtojmë memory etj.

Ne do të përdorim VictoriaMetrics, sepse na pëlqeu shumë. Këtu është çfarë ishte dhe çfarë u bë.