{"id":94153,"date":"2020-09-13T19:42:30","date_gmt":"2020-09-13T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev"},"modified":"2020-09-13T19:42:30","modified_gmt":"2020-09-13T17:42:30","slug":"victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics dhe monitorimi i cloud-eve private. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 nj\u00eb DBMS e shpejt\u00eb dhe e shkall\u00ebzueshme p\u00ebr ruajtjen dhe procesimin e t\u00eb dh\u00ebnave n\u00eb form\u00ebn e serive temporale (nj\u00eb regjistrim krijon nj\u00eb koh\u00eb dhe nj\u00eb grup vlerash t\u00eb lidhura me k\u00ebt\u00eb koh\u00eb, p\u00ebr shembull, t\u00eb marra p\u00ebrmes nj\u00eb vrojtimi periodik t\u00eb gjendjes s\u00eb sensor\u00ebve ose mbledhjes s\u00eb metrikeve).<\/p>\n

<\/a><\/noindex>
\n

\r\n \"Luaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Un\u00eb quhem Kolobaev Pavel. DevOps, SRE, LeroyMerlin, gjith\u00e7ka si kod \u2013 kjo \u00ebsht\u00eb gjith\u00e7ka p\u00ebr ne: p\u00ebr mua dhe p\u00ebr punonj\u00ebsit e tjer\u00eb t\u00eb LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

https:\/\/bit.ly\/3jf1fIK<\/a><\/noindex><\/p>\n

<\/p>\n

Ka nj\u00eb re t\u00eb bazuar n\u00eb OpenStack. Aty ka nj\u00eb lidhje t\u00eb vog\u00ebl p\u00ebr radar teknologjik. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ajo \u00ebsht\u00eb nd\u00ebrtuar mbi harduerin e Kubernetes, si dhe mbi t\u00eb gjitha sh\u00ebrbimet p\u00ebrcjell\u00ebse p\u00ebr OpenStack dhe logimin. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Schemi ishte k\u00ebshtu kur ishim duke zhvilluar. Kur e zhvilluam k\u00ebt\u00eb, kishim nj\u00eb operator Prometheus, i cili ruante t\u00eb dh\u00ebnat brenda vet\u00eb klasterit K8s. Ai e gjen automatikisht at\u00eb q\u00eb nevojitet p\u00ebr t\u00eb zbuluar dhe e vendos at\u00eb posht\u00eb vetes, p\u00ebr ta th\u00ebn\u00eb n\u00eb nj\u00eb far\u00eb m\u00ebnyre. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

T\u00eb gjitha t\u00eb dh\u00ebnat na nevojitet t\u00eb nxirren jasht\u00eb klasterit Kubernetes, sepse n\u00ebse ndodh ndonj\u00eb gj\u00eb, duhet t\u00eb kuptojm\u00eb se \u00e7far\u00eb dhe ku \u00ebsht\u00eb. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Zgjidhja e par\u00eb - ne p\u00ebrdorim federation, kur kemi nj\u00eb Prometheus t\u00eb jasht\u00ebm, kur ne hyjm\u00eb n\u00eb klasterin Kubernetes p\u00ebrmes mekanizmit t\u00eb federation.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Por k\u00ebtu ndodhin disa probleme t\u00eb vogla. N\u00eb rastin ton\u00eb, problemet filluan kur kishim 250,000 metrika, dhe kur arrit\u00ebm n\u00eb 400,000 metrika, kuptuam q\u00eb nuk mund t\u00eb punonim k\u00ebshtu. Ne rrit\u00ebm scrape_timeout n\u00eb 25 sekonda.<\/p>\n

<\/p>\n

Pse na duhej t\u00eb b\u00ebnim k\u00ebt\u00eb? Prometheus fillon t\u00eb num\u00ebroj\u00eb koh\u00ebn e skadimit nga momenti i fillimit t\u00eb marrjes. Dhe nuk ka r\u00ebnd\u00ebsi q\u00eb t\u00eb dh\u00ebnat akoma rrjedhin. N\u00ebse gjat\u00eb k\u00ebtij intervali t\u00eb caktuar kohor t\u00eb dh\u00ebnat nuk u shkarkuan dhe sesioni nuk do t\u00eb mbyllej n\u00eb http, at\u00ebher\u00eb merret si nj\u00eb sesion d\u00ebshtak dhe t\u00eb dh\u00ebnat nuk arrijn\u00eb n\u00eb Prometheus vet\u00eb.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Grafikat q\u00eb na jan\u00eb t\u00eb njohura, kur pjesa e t\u00eb dh\u00ebnave mungon. Grafikat jan\u00eb t\u00eb prishura dhe kjo nuk na k\u00ebnaq. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Zgjedhja tjet\u00ebr \u2013 \u00ebsht\u00eb shardimi mbi baz\u00ebn e dy Prometheus t\u00eb ndrysh\u00ebm p\u00ebrmes t\u00eb nj\u00ebjtit mekaniz\u00ebm t\u00eb federation.<\/p>\n

<\/p>\n

P\u00ebr shembull, thjesht t\u00eb marrim dhe t'i shardojm\u00eb sipas emrit. Kjo mund t\u00eb p\u00ebrdoret gjithashtu, por ne vendos\u00ebm t\u00eb shkonim m\u00eb tutje. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Do t\u00eb na duhet tani t'i trajtojm\u00eb k\u00ebto shard-e si\u00e7 duhet. Mund t\u00eb marrim promxy, i cili shkon n\u00eb fush\u00ebn e shard-it dhe mblidhet t\u00eb dh\u00ebnat. Ai punon me dy shard-e si me nj\u00eb pik\u00eb hyr\u00ebse t\u00eb vetme. Kjo \u00ebsht\u00eb e mundur t\u00eb realizohet p\u00ebrmes promxy, por akoma \u00ebsht\u00eb shum\u00eb e komplikuar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Zgjedhja e par\u00eb - ne duam t\u00eb heqim dor\u00eb nga mekanizmi i federation, sepse ai \u00ebsht\u00eb shum\u00eb i ngadalsh\u00ebm. <\/p>\n

<\/p>\n

Zhvilluesit e Prometheus jan\u00eb t\u00eb qart\u00eb: \u201cDjem, p\u00ebrdorni TimescaleDB t\u00eb tjera, sepse ne nuk do t\u00eb mb\u00ebshtesim ruajtjen e gjat\u00eb t\u00eb metric\u00ebve.\u201d Kjo nuk \u00ebsht\u00eb detyra e tyre. \"VictoriaMetrics<\/p>\n

<\/p>\n

Ne e shkruajm\u00eb n\u00eb let\u00ebr se na nevojitet dalja p\u00ebrjashta, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos ruajm\u00eb gjith\u00e7ka n\u00eb nj\u00eb vend. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Disavantazhi i dyt\u00eb \u00ebsht\u00eb konsumimi i memorjes. Po, e kuptoj q\u00eb shum\u00eb do t\u00eb thon\u00eb se n\u00eb vitin 2020 disa gigabajt memorje jan\u00eb shum\u00eb pak, por mir\u00ebpo. <\/p>\n

<\/p>\n

Tani kemi ambient dev dhe prodhimi. N\u00eb dev \u00ebsht\u00eb rreth 9 gigabajt p\u00ebr 350,000 metrika. N\u00eb prodhim \u2013 rreth 14 gigabajt p\u00ebr 780,000 metrika. Nd\u00ebrkoh\u00eb, koha e ruajtjes \u00ebsht\u00eb vet\u00ebm 30 minuta. Kjo \u00ebsht\u00eb keq. Dhe tani do ta shpjegoj pse.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ne b\u00ebjm\u00eb llogaritjen, pra me nj\u00eb milion e gjysm\u00eb metrikash, dhe ne jemi af\u00ebr k\u00ebsaj shifre, n\u00eb faz\u00ebn e projektimit, ne po marrim 35-37 gigabajt memorje. Por me 4 milion metrika ne na duhen tashm\u00eb rreth 90 gigabajt memorje. Pra, kjo \u00ebsht\u00eb llogaritur sipas formules q\u00eb ofrojn\u00eb zhvilluesit e Prometheus. Ne pat\u00ebm nj\u00eb v\u00ebshtrim n\u00eb korelacion dhe kuptuam se nuk duam t\u00eb paguajm\u00eb disa milion\u00eb p\u00ebr nj\u00eb server vet\u00ebm p\u00ebr monitorim. <\/p>\n

<\/p>\n

Numri i makinave do t\u00eb rritet dhe ne gjithashtu monitorojm\u00eb edhe vet\u00eb makinat virtuale. Prandaj, sa m\u00eb shum\u00eb makina virtuale, aq m\u00eb shum\u00eb metrika t\u00eb ndryshme dhe k\u00ebshtu me radh\u00eb. Do t\u00eb kemi nj\u00eb rritje t\u00eb ve\u00e7ant\u00eb t\u00eb klasit ton\u00eb n\u00eb lidhje me metrikat.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Me hap\u00ebsir\u00ebn diskore, k\u00ebtu nuk \u00ebsht\u00eb gjith\u00e7ka aq e m\u00ebrzitshme, por do t\u00eb d\u00ebshironim t\u00eb p\u00ebrmir\u00ebsojm\u00eb. N\u00eb 15 dit\u00eb ne kemi marr\u00eb gjithsej 120 gigabajt, nga t\u00eb cilat 100 jan\u00eb t\u00eb dh\u00ebna t\u00eb kompresuara, 20 jan\u00eb t\u00eb dh\u00ebna t\u00eb pa kompresuara, por gjithmon\u00eb do t\u00eb d\u00ebshironim m\u00eb pak. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

P\u00ebr rrjedhoj\u00eb, ne po regjistrojm\u00eb nj\u00eb pik\u00eb tjet\u00ebr \u2013 kjo \u00ebsht\u00eb konsumimi i madh i burimeve, t\u00eb cilat duam t'i kursejm\u00eb, sepse nuk duam q\u00eb klasteri yn\u00eb i monitorimit t\u00eb konsumoj\u00eb m\u00eb shum\u00eb burime se klasteri q\u00eb merret me menaxhimin e OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ka nj\u00eb disavantazh tjet\u00ebr tek Prometheus, q\u00eb ne e kemi identifikuar, q\u00eb \u00ebsht\u00eb ndonj\u00eb kufizim mbi memorjen. Me Prometheus situata \u00ebsht\u00eb shum\u00eb m\u00eb e keqe, sepse atje nuk ka asnj\u00eb opsion t\u00eb till\u00eb. P\u00ebrdorimi i kufizimeve n\u00eb docker gjithashtu nuk \u00ebsht\u00eb nj\u00eb mund\u00ebsi. N\u00ebse ndonj\u00ebher\u00eb RAF bie dhe aty ka 20-30 gigabajt, rikthimi do t\u00eb jet\u00eb shum\u00eb i ngadalsh\u00ebm. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Kjo \u00ebsht\u00eb nj\u00eb arsye tjet\u00ebr pse Prometheus nuk na p\u00ebrshtatet, pra nuk \u00ebsht\u00eb e mundur t\u00eb kufizohet konsumimi i memorjes. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mund t\u00eb dalim n\u00eb nj\u00eb skem\u00eb t\u00eb till\u00eb. Kjo skem\u00eb na nevojitet p\u00ebr t\u00eb organizuar nj\u00eb klaster HA. Ne duam q\u00eb metrike tona t\u00eb jen\u00eb gjithmon\u00eb dhe kudo t\u00eb aksesueshme, madje edhe n\u00eb rast t\u00eb r\u00ebnies s\u00eb serverit q\u00eb i ruan k\u00ebto metrika. K\u00ebshtu na nevojitet t\u00eb nd\u00ebrtojm\u00eb nj\u00eb skem\u00eb t\u00eb till\u00eb. <\/p>\n

<\/p>\n

Kjo skem\u00eb thot\u00eb se do t\u00eb kemi dyfishim t\u00eb shard-\u00ebve, dhe p\u00ebr rrjedhoj\u00eb, edhe dyfishim t\u00eb shpenzimeve t\u00eb burimeve t\u00eb konsumuar. Ajo mund t\u00eb skalohet pothuajse horizontalisht, por megjithat\u00eb, konsumimi i burimeve do t\u00eb jet\u00eb i madh. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Disavantazhet renditur sipas asaj q\u00eb i kemi shkruar vet\u00eb:<\/p>\n

<\/p>\n