{"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\/hu\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics \u00e9s priv\u00e1t felh\u0151k monitoroz\u00e1sa. Kolobaev Pavel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

A VictoriaMetrics egy gyors \u00e9s sk\u00e1l\u00e1zhat\u00f3 DBMS az id\u0151alap\u00fa adatok t\u00e1rol\u00e1s\u00e1ra \u00e9s feldolgoz\u00e1s\u00e1ra (az id\u0151 \u00e9s a megfelel\u0151 \u00e9rt\u00e9kek halmaza alkotja az adatokat, p\u00e9ld\u00e1ul amelyek id\u0151szakos \u00e9rz\u00e9kel\u0151\u00e1llapot-ellen\u0151rz\u00e9s vagy metrikagy\u0171jt\u00e9s r\u00e9v\u00e9n j\u00f6ttek l\u00e9tre).<\/p>\n

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

\r\n \"Vide\u00f3\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A nevem Kolobaev Pavel. DevOps, SRE, LeroyMerlin, mindez k\u00f3d form\u00e1j\u00e1ban \u2013 ez mind r\u00f3lunk sz\u00f3l: r\u00f3lam \u00e9s LeroyMerlin m\u00e1s munkat\u00e1rsair\u00f3l.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

Van egy OpenStack alap\u00fa felh\u0151nk. Ott van egy kis hivatkoz\u00e1s a technikai radarra. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ez Kubernetes hardver\u00e9n alapul, valamint minden kapcsol\u00f3d\u00f3 szolg\u00e1ltat\u00e1s\u00e1n az OpenStackhez \u00e9s a napl\u00f3z\u00e1shoz. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

\u00cdgy n\u00e9zett ki a fejleszt\u00e9si terv\u00fcnk. Amikor mindezt kidolgoztuk, volt egy Prometheus oper\u00e1torunk, aki a K8s klaszter belsej\u00e9ben t\u00e1rolta az adatokat. Automatikusan megtal\u00e1lja, hogy mit kell \u00f6sszeszedni, \u00e9s durv\u00e1n fogalmazva, odahelyezi mag\u00e1nak. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Minden adatot ki kell vinn\u00fcnk a Kubernetes klaszteren k\u00edv\u00fcl, mert ha valami t\u00f6rt\u00e9nik, meg kell \u00e9rten\u00fcnk, hogy mi t\u00f6rt\u00e9nt \u00e9s hol. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Az els\u0151 megold\u00e1s \u2013 federation haszn\u00e1lata, amikor van egy k\u00fcls\u0151 Prometheusunk, \u00e9s a klaszter Kuberneteshez a federation mechanizmus\u00e1n kereszt\u00fcl f\u00e9r\u00fcnk hozz\u00e1.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

De itt kisebb probl\u00e9m\u00e1k jelentkeznek. A mi eset\u00fcnkben a probl\u00e9ma akkor kezd\u0151d\u00f6tt, amikor 250 000 metrik\u00e1nk volt, majd amikor 400 000 metrik\u00e1ra n\u0151tt, r\u00e1j\u00f6tt\u00fcnk, hogy \u00edgy nem tudunk dolgozni. A scrape_timeout-t 25 m\u00e1sodpercre n\u00f6velt\u00fck.<\/p>\n

<\/p>\n

Mi\u00e9rt kellett ezt megtenn\u00fcnk? A Prometheus az id\u0151z\u00edt\u00e9st a lek\u00e9rdez\u00e9s kezdet\u00e9t\u0151l sz\u00e1molja. Nem sz\u00e1m\u00edt, hogy az adatok m\u00e9g mindig \u00e9rkeznek. Ha az adott id\u0151intervallumon bel\u00fcl az adatok nem \u00e1ramlanak, \u00e9s a session http-n nem z\u00e1r\u00f3dik le, akkor a session kudarcnak sz\u00e1m\u00edt, \u00e9s az adatok nem jutnak be mag\u00e1ba a Prometheusba.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mindenki ismeri azokat a grafikonokat, amelyeket akkor kapunk, amikor az adatok egy r\u00e9sze hi\u00e1nyzik. A grafikonok megszakadtak, \u00e9s ez minket nem el\u00e9gedett meg. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A k\u00f6vetkez\u0151 lehet\u0151s\u00e9g \u2013 sharding k\u00e9t k\u00fcl\u00f6nb\u00f6z\u0151 Prometheus alapj\u00e1n ugyanazon federation mechanizmuson kereszt\u00fcl.<\/p>\n

<\/p>\n

P\u00e9ld\u00e1ul, egyszer\u0171en az neveik szerint shardolni \u0151ket. Ezt is lehet haszn\u00e1lni, de \u00fagy d\u00f6nt\u00f6tt\u00fcnk, hogy tov\u00e1bbi l\u00e9p\u00e9sekre van sz\u00fcks\u00e9g. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ezeket a shardokat most valahogy kezelni kell. Haszn\u00e1lhatunk promxy-t, amely elmegy a shard ter\u00fclet\u00e9re, \u00e9s t\u00f6bbsz\u00f6r\u00f6zni az adatokat. K\u00e9t sharddal egyetlen bel\u00e9p\u00e9si pontk\u00e9nt m\u0171k\u00f6dik. Ezt promxy seg\u00edts\u00e9g\u00e9vel meg lehet val\u00f3s\u00edtani, de jelenleg t\u00fal bonyolult. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Az els\u0151 lehet\u0151s\u00e9g, hogy lemondjunk a federation mechanizmusr\u00f3l, mert ez nagyon lass\u00fa. <\/p>\n

<\/p>\n

A Prometheus fejleszt\u0151i egy\u00e9rtelm\u0171en mondj\u00e1k: \u201eH\u00f6lgyeim \u00e9s Uraim, haszn\u00e1ljanak m\u00e1s TimescaleDB-t, mert mi nem fogjuk sok\u00e1ig t\u00e1mogatni a metrik\u00e1k hossz\u00fa t\u00e1rol\u00e1s\u00e1t\u201d. Ez nem az \u0151 feladatuk. \"VictoriaMetrics<\/p>\n

<\/p>\n

Pap\u00edron feljegyezz\u00fck, hogy nek\u00fcnk m\u00e9gis sz\u00fcks\u00e9g\u00fcnk van a k\u00fcls\u0151 export\u00e1l\u00e1sra, hogy ne t\u00e1roljunk mindent egy helyen. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A m\u00e1sodik h\u00e1tr\u00e1ny a mem\u00f3riafogyaszt\u00e1s. Igen, tudom, hogy sokan azt mondj\u00e1k, hogy 2020-ban p\u00e1r gigab\u00e1jt mem\u00f3ria nem nagy p\u00e9nz, de mindenesetre. <\/p>\n

<\/p>\n

Jelenleg van dev \u00e9s prod k\u00f6rnyezet\u00fcnk. A dev k\u00f6rnyezetben k\u00f6r\u00fclbel\u00fcl 9 gigab\u00e1jtunk van 350 000 metrik\u00e1ra. A prod k\u00f6rnyezetben pedig 14 gigab\u00e1jt van 780 000 metrik\u00e1ra. Ezzel egy\u00fctt a retention time csak 30 perc. Ez rossz. Most megmagyar\u00e1zom, mi\u00e9rt.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Megcsin\u00e1ljuk a sz\u00e1m\u00edt\u00e1st, azaz m\u00e1sf\u00e9l milli\u00f3 metrik\u00e1n\u00e1l, ahhoz m\u00e1r el\u00e9g k\u00f6zel \u00e1llunk, a tervez\u00e9si f\u00e1zisban 35-37 gigab\u00e1jt mem\u00f3ria j\u00f6n ki. De m\u00e1r 4 milli\u00f3 metrik\u00e1n\u00e1l k\u00f6r\u00fclbel\u00fcl 90 gigab\u00e1jt mem\u00f3ria sz\u00fcks\u00e9ges. Ez a Prometheus fejleszt\u0151i \u00e1ltal biztos\u00edtott k\u00e9plet alapj\u00e1n lett kisz\u00e1m\u00edtva. Megvizsg\u00e1ltuk a korrel\u00e1ci\u00f3t, \u00e9s r\u00e1j\u00f6tt\u00fcnk, hogy nem akarunk p\u00e1r milli\u00f3t fizetni egy szerver\u00e9rt, amely csak a monitoroz\u00e1sra szolg\u00e1l. <\/p>\n

<\/p>\n

Nemcsak a g\u00e9pek sz\u00e1ma n\u0151ni fog, hanem a virtu\u00e1lis g\u00e9peket is monitorozzuk. Teh\u00e1t min\u00e9l t\u00f6bb virtu\u00e1lis g\u00e9p van, ann\u00e1l t\u00f6bb k\u00fcl\u00f6nb\u00f6z\u0151 metrika van stb. K\u00fcl\u00f6n n\u00f6veked\u00e9s v\u00e1r r\u00e1nk a metrik\u00e1k szempontj\u00e1b\u00f3l a klaszter\u00fcnkben.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A lemezter\u00fclettel kapcsolatban a helyzet nem annyira rossz, de szeretn\u00e9nk jav\u00edtani rajta. 15 nap alatt \u00f6sszesen 120 gigab\u00e1jtunk volt, amib\u0151l 100 t\u00f6m\u00f6r\u00edtett adat, 20 pedig t\u00f6m\u00f6r\u00edtetlen adat, de mindig szeretn\u00e9nk kevesebbet. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ennek megfelel\u0151en feljegyz\u00fcnk egy \u00fajabb pontot \u2013 a nagy er\u0151forr\u00e1sfogyaszt\u00e1st, amit szeretn\u00e9nk t\u00e9nyleg megtakar\u00edtani, mert nem akarjuk, hogy a monitoroz\u00f3 klaszter\u00fcnk t\u00f6bb er\u0151forr\u00e1st egyen, mint az OpenStack kezel\u0151 klaszter\u00fcnk.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Van m\u00e9g egy h\u00e1tr\u00e1ny a Prometheusban, amit \u00e9szlelt\u00fcnk, ez pedig a mem\u00f3ria korl\u00e1toz\u00e1s\u00e1nak hi\u00e1nya. A Prometheus helyzete sokkal rosszabb, mert egy\u00e1ltal\u00e1n nincsenek ilyen kapcsol\u00f3k. A docker mem\u00f3ria korl\u00e1toz\u00e1st haszn\u00e1lni sem lehet opci\u00f3. Ha p\u00e9ld\u00e1ul a RAF lerobban \u00e9s ott 20-30 gigab\u00e1jt van, akkor nagyon hossz\u00fa id\u0151be telik az \u00fajraind\u00edt\u00e1s. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ez egy \u00fajabb ok, ami\u00e9rt a Prometheus nem felel meg nek\u00fcnk, azaz nem lehet korl\u00e1tozni a mem\u00f3riafogyaszt\u00e1st. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Lehets\u00e9ges lenne egy ilyen s\u00e9m\u00e1t megval\u00f3s\u00edtani. Erre a s\u00e9m\u00e1ra van sz\u00fcks\u00e9g\u00fcnk ahhoz, hogy HA klasztert szervezz\u00fcnk. Azt akarjuk, hogy a metrik\u00e1ink mindig \u00e9s mindenhol el\u00e9rhet\u0151k legyenek, m\u00e9g akkor is, ha az a szerver, amely t\u00e1rolja ezeket a metrik\u00e1kat, le\u00e1ll. \u00cdgy ki kell alak\u00edtanunk egy ilyen s\u00e9m\u00e1t. <\/p>\n

<\/p>\n

Ez a s\u00e9ma azt jelzi, hogy a shardok duplik\u00e1l\u00f3dni fognak, \u00edgy a felhaszn\u00e1lt er\u0151forr\u00e1sok is duplik\u00e1l\u00f3dnak. Majdnem v\u00edzszintesen sk\u00e1l\u00e1zhat\u00f3, de ennek ellen\u00e9re az er\u0151forr\u00e1sok fogyaszt\u00e1sa rettent\u0151 lesz. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A h\u00e1tr\u00e1nyokat felsorolva, ahogyan mi azokat megfogalmaztuk:<\/p>\n

<\/p>\n