A VictoriaMetrics egy gyors és méretezhető DBMS az adatok idősorok formájában történő tárolására és feldolgozására (a rekord időből és ennek az időnek megfelelő értékkészletből áll, például az érzékelők állapotának időszakos lekérdezésével, ill. mérőszámok gyűjteménye).
A nevem Kolobaev Pavel. DevOps, SRE, LeroyMerlin, minden olyan, mint a kód – minden rólunk szól: rólam és a LeroyMerlin többi alkalmazottjáról.
Van egy OpenStack-alapú felhő. Van egy kis link a műszaki radarhoz.
A Kubernetes hardverre, valamint az összes kapcsolódó OpenStack- és naplózási szolgáltatásra épül.
Ezt a sémát dolgoztuk ki. Amikor mindezt fejlesztettük, volt egy Prometheus operátorunk, amely magában a K8s klaszterben tárolta az adatokat. Automatikusan megkeresi, hogy mit kell súrolni, és durván szólva a lába alá teszi.
Minden adatot át kell helyeznünk a Kubernetes-fürtön kívülre, mert ha valami történik, meg kell értenünk, hogy mit és hol.
Az első megoldás az, hogy az összevonást akkor használjuk, ha harmadik féltől származó Prometheusunk van, amikor az összevonási mechanizmuson keresztül a Kubernetes-fürthöz megyünk.
De van itt néhány apró probléma. A mi esetünkben a problémák akkor kezdődtek, amikor 250 000 mérőszámunk volt, és amikor 400 000 volt, rájöttünk, hogy nem tudunk így dolgozni. A scrape_timeout értéket 25 másodpercre növeltük.
Miért kellett ezt tennünk? A Prometheus a kerítés elejétől kezdi számolni az időtúllépést. Nem számít, hogy az adatok továbbra is áramlanak. Ha a megadott időtartam alatt az adatokat nem egyesítik, és a munkamenetet nem zárják le http-n keresztül, akkor a munkamenet sikertelennek minősül, és az adatok nem kerülnek be magába a Prometheusba.
Mindenki ismeri azokat a grafikonokat, amelyeket akkor kapunk, ha néhány adat hiányzik. A menetrendek szakadtak, és ezzel nem vagyunk elégedettek.
A következő lehetőség a két különböző Prometheuson alapuló felosztás, ugyanazon az összevonási mechanizmuson keresztül.
Például vedd el őket, és vágd szét név szerint. Ezt is lehet használni, de úgy döntöttünk, továbblépünk.
Ezeket a szilánkokat most valahogyan fel kell dolgoznunk. Vedd a promxy-t, ami a shard területre megy és megsokszorozza az adatokat. Két szilánkkal működik egyetlen belépési pontként. Ez megvalósítható a promxy-n keresztül, de még mindig túl nehéz.
Az első lehetőség az, hogy fel akarjuk hagyni az összevonási mechanizmust, mert nagyon lassú.
A Prometheus fejlesztői egyértelműen azt mondják: "Srácok, használjatok egy másik TimescaleDB-t, mert nem támogatjuk a mutatók hosszú távú tárolását." Ez nem az ő feladatuk.
Felírjuk egy papírra, hogy még kint kell kipakolnunk, nehogy mindent egy helyen tároljunk.
A második hátrány a memóriafogyasztás. Igen, megértem, hogy sokan azt mondják majd, hogy 2020-ban néhány gigabájt memória egy fillérbe kerül, de akkor is.
Most már van egy fejlesztői és termékkörnyezetünk. Fejlesztőben ez körülbelül 9 gigabájt 350 000 mérőszámhoz. Prod-ban 14 gigabájt és valamivel több, mint 780 000 metrika. Ugyanakkor a retenciós időnk mindössze 30 perc. Ez rossz. És most elmagyarázom, miért.
Számítást készítünk, vagyis másfél millió mérőszámmal, és már közel járunk hozzájuk, a tervezési szakaszban 35-37 gigabájt memóriát kapunk. De már 4 millió metrika körülbelül 90 gigabájt memóriát igényel. Vagyis a Prometheus fejlesztői által megadott képlet alapján számították ki. Megnéztük az összefüggést, és rájöttünk, hogy nem akarunk pár milliót fizetni egy szerverért csak a monitorozásért.
Nemcsak a gépek számát növeljük, hanem magukat a virtuális gépeket is figyeljük. Ezért minél több a virtuális gép, annál több a különféle mérőszám, stb. A fürtünk a metrikák tekintetében különleges növekedést fog elérni.
A lemezterülettel nem minden olyan rossz itt, de szeretnék javítani rajta. 15 nap alatt összesen 120 gigabájtot kaptunk, ebből 100 tömörített adat, 20 tömörítetlen adat, de mindig kevesebbet akarunk.
Ennek megfelelően még egy pontot írunk le - ez egy nagy erőforrás-felhasználás, amelyet még mindig szeretnénk megtakarítani, mert nem akarjuk, hogy a megfigyelő fürtünk több erőforrást fogyasztson, mint az OpenStack-et kezelő klaszterünk.
A Prometheusnak van még egy hátránya, amit magunk azonosítottunk, ez legalább valamiféle memóriakorlátozás. A Prometheusszal itt sokkal rosszabb minden, mert egyáltalán nincsenek ilyen fordulatai. A korlát használata a dockerben szintén nem választható. Ha hirtelen leesik a RAF-ja, és 20-30 gigabájt van, akkor nagyon sokáig tart, amíg felemelkedik.
Ez egy másik oka annak, hogy a Prometheus nem alkalmas számunkra, vagyis nem tudjuk korlátozni a memóriafelhasználást.
Lehetne egy ilyen sémát kitalálni. Erre a sémára szükségünk van egy HA klaszter megszervezéséhez. Szeretnénk, ha mérőszámaink mindig és mindenhol elérhetőek lennének, még akkor is, ha a mérőszámokat tároló szerver összeomlik. És ezért egy ilyen rendszert kell felépíteni.
Ez a séma azt mondja, hogy a szilánkok megduplázódnak, és ennek megfelelően az elhasznált erőforrások költségei megkettőződnek. Szinte vízszintesen skálázható, de ennek ellenére pokoli lesz az erőforrás-felhasználás.
A hátrányok abban a formában, ahogy magunknak leírtuk:
- A mutatók külső feltöltését igényli.
- Magas erőforrás-felhasználás.
- A memóriafogyasztás korlátozására nincs mód.
- A HA komplex és erőforrás-igényes megvalósítása.
Magunk számára úgy döntöttünk, hogy elköltözünk a Prometheustól, mint raktárról.
További követelményeket határoztunk meg magunknak, amelyekre szükségünk van. Ez:
- Ez a promql támogatás, mert a Prometheushoz már sok mindent megírtak: lekérdezések, figyelmeztetések.
- És akkor ott van a Grafana, ami már pontosan ugyanúgy meg van írva a Prometheushoz háttérként. Nem akarom átírni a műszerfalakat.
- Egy normál HA architektúrát akarunk építeni.
- Csökkenteni akarjuk az erőforrások felhasználását.
- Van még egy apró árnyalat. Nem használhatunk különféle típusú felhőmetrika-gyűjtő rendszereket. Még nem tudjuk, mi fog beletartozni ezekbe a mutatókba. És mivel oda bármi repülhet, a helyi elhelyezésre kell korlátoznunk magunkat.
Kevés volt a választék. Mindent összegyűjtöttünk, amivel tapasztalatunk volt. Megnéztük a Prometheus oldalt az integrációs részben, elolvastunk egy csomó cikket, és megnéztük, mi van ott. Saját magunk számára pedig a VictoriaMetrics-t választottuk a Prometheus helyett.
Miért? Mert:
- Ismeri a promql-t.
- Van egy moduláris felépítés.
- Nem igényel változtatást a Grafana-n.
- És ami a legfontosabb, a mérőszámok tárolását valószínűleg szolgáltatásként fogjuk biztosítani cégünkön belül, ezért előre nézünk a különféle korlátozások felé, hogy a felhasználók a klaszter összes erőforrását korlátozottan tudják használni, mert van rá esély. hogy többbérletes lesz.
Végezzük el az első összehasonlítást. Ugyanazt a Prometheust vesszük a klaszter belsejébe, a külső Prometheus megy hozzá. Hozzáadás távolrólWrite VictoriaMetrics.
Azonnal leszögezem, hogy itt enyhe CPU-fogyasztásnövekedést észleltünk a VictoriaMetrics-től. A VictoriaMetrics wiki megmondja, mely paraméterek a legjobbak. Ellenőriztük őket. Nagyon jól csökkentették a CPU-fogyasztást.
Esetünkben a Kubernetes klaszterben található Prometheus memóriafogyasztása nem nőtt jelentősen.
Két azonos adatforrást hasonlítunk össze. A Prometheusban ugyanezeket a hiányzó adatokat látjuk. A VictoriaMetrics-nél minden rendben van.
Lemezterület-teszt eredményei. Mi a Prometheusnál összesen 120 gigabájtot kaptunk. A VictoriaMetrics-nél már napi 4 gigabájtot kapunk. Van egy kicsit más mechanizmus, mint amit a Prometheusban látni szoktunk. Azaz egy nap alatt, fél óra alatt már egész jól tömörülnek az adatok. Egy nap alatt, fél óra alatt már jól learatták, annak ellenére, hogy később még elvesznek az adatok. Ennek eredményeként lemezterületet takarítottunk meg.
A memória erőforrás-felhasználását is megtakarítjuk. A tesztelés idején a Prometheust egy virtuális gépen telepítettük – 8 mag, 24 gigabájt. Prométheusz szinte mindent megeszik. Az OOM Killerre esett. Ugyanakkor mindössze 900 000 aktív mérőszámot öntöttek bele. Ez körülbelül 25 000-27 000 metrika másodpercenként.
A VictoriaMetrics-t egy kétmagos virtuális gépen futtattuk, 8 gigabájt RAM-mal. Sikerült jól működni a VictoriaMetrics azzal, hogy egy 8 GB-os gépen bíbelődtünk néhány dologgal. Végül 7 gigabájton tartottuk. Ugyanakkor a tartalom, azaz a mérőszámok szállítási sebessége még a Prometheusnál is nagyobb volt.
A CPU sokkal jobb lett a Prometheushoz képest. Itt a Prometheus 2,5 magot fogyaszt, a VictoriaMetrics pedig csak 0,25 magot. Kezdetben - 0,5 mag. Ahogy egyesül, elér egy magot, de ez rendkívül, rendkívül ritka.
Esetünkben nyilvánvaló okokból a VictoriaMetricsre esett a választás: pénzt akartunk spórolni, és meg is tettük.
Azonnal húzzunk át két pontot – a mérőszámok feltöltését és a magas erőforrás-felhasználást. És már csak két pontot kell eldöntenünk, ami még hátra van magunknak.
Itt rögtön lefoglalom, a VictoriaMetrics-t a mérőszámok tárolójának tekintjük. De mivel nagy valószínűséggel a VictoriaMetrics-t biztosítjuk tárhelyként az egész Leroy számára, korlátoznunk kell azokat, akik ezt a klasztert használják, hogy ne adják nekünk.
Van egy csodálatos paraméter, amely lehetővé teszi az idő, az adatmennyiség és a végrehajtási idő szerinti korlátozást.
Van egy kiváló lehetőség is, amellyel korlátozhatjuk a memóriafelhasználást, ezáltal megtalálhatjuk azt az egyensúlyt, amely lehetővé teszi a normál működési sebesség és a megfelelő erőforrás-felhasználás elérését.
Mínusz még egy pont, azaz a pont áthúzása - nem korlátozhatja a memóriafogyasztást.
Az első iterációk során a VictoriaMetrics Single Node-ot teszteltük. Ezután áttérünk a VictoriaMetrics Cluster Versionra.
Itt szabad kezet kapunk, hogy szétválasztjuk a VictoriaMetrics különböző szolgáltatásokat attól függően, hogy miről fognak futni, és milyen erőforrásokat fogyasztanak. Ez egy nagyon rugalmas és kényelmes megoldás. Ezt használtuk magunkon.
A VictoriaMetrics Cluster Version fő összetevői a vmstsorage. N szám lehet belőlük. A mi esetünkben eddig 2 db van.
És van vminsert. Ez egy proxyszerver, amely lehetővé teszi számunkra, hogy: felosztást rendezzünk az összes tároló között, amelyről beszéltünk, és lehetővé teszi a replikát is, azaz lesz sharding és replika is.
A Vminsert támogatja a Prometheus OpenTSDB, Graphite, InfluxDB és remoteWrite protokolljait.
Van vmselect is. Fő feladata, hogy a vmstorage-ra menjen, adatokat fogadjon tőlük, deduplikálja ezeket az adatokat és adja át a kliensnek.
Van egy csodálatos dolog, amit vmagentnek hívnak. Nagyon szeretjük őt. Lehetővé teszi, hogy pontosan úgy konfiguráljon, mint a Prometheus, és mindent pontosan úgy csináljon, mint a Prometheus. Azaz összegyűjti a különböző entitásoktól és szolgáltatásoktól származó metrikákat, és elküldi a vminsert-nek. Akkor minden rajtad múlik.
Egy másik nagyszerű szolgáltatás a vmalert, amely lehetővé teszi a VictoriaMetrics háttérrendszerként való használatát, feldolgozott adatok fogadását a vminserttől és elküldését a vmselect-nek. Magukat a riasztásokat, valamint a szabályokat dolgozza fel. Riasztások esetén a riasztást a riasztáskezelőn keresztül kapjuk meg.
Van egy wmauth összetevő. Használhatjuk vagy nem (erről még nem döntöttünk) a fürtök többbérletes verziójának engedélyezési rendszereként. Támogatja a remoteWrite for Prometheus-t, és az url, vagy inkább annak második része alapján tud engedélyezni, ahova írhatunk vagy nem.
Van még vmbackup, vmrestore. Ez lényegében az összes adat visszaállítása és biztonsági mentése. Képes S3, GCS, fájl.
A klaszterünk első iterációja a karantén idején készült. Ekkor még nem volt replika, így az iterációnk két különböző és független klaszterből állt, amelyekbe remoteWrite segítségével kaptunk adatokat.
Itt teszek egy fenntartást, hogy amikor a VictoriaMetrics Single Node-ról a VictoriaMetrics Cluster Versionra váltottunk, továbbra is ugyanazokkal az erőforrásokkal maradtunk, vagyis a fő a memória. Körülbelül így oszlottak el adataink, vagyis az erőforrás-felhasználás.
Egy replika már felkerült ide. Mindezt egy viszonylag nagy klaszterbe egyesítettük. Minden adatunk szilánkosra és replikálva van.
A teljes klaszter N belépési ponttal rendelkezik, ami azt jelenti, hogy a Prometheus adatokat adhat hozzá a HAPROXY-n keresztül. Itt van ez a belépési pont. Ezen a belépési ponton keresztül pedig bejelentkezhet a Grafanából.
Esetünkben a HAPROXY az egyetlen port, amely a fürtön belül kiválasztja, beilleszti és egyéb szolgáltatásokat proxykál. Esetünkben lehetetlen volt egy címet létrehozni, több belépési pontot kellett létrehoznunk, mert maguk a virtuális gépek, amelyeken a VictoriaMetrics fürt fut, ugyanannak a felhőszolgáltatónak különböző zónáiban találhatók, vagyis nem a mi felhőnkön belül, hanem azon kívül. .
Riasztásunk van. Használjuk. A Prometheus alertmanager-jét használjuk. Az Opsgenie-t és a Telegram-ot használjuk riasztási kézbesítési csatornaként. A Telegramban devből ömlik be, esetleg prod-ból valami, de leginkább valami statisztikai adatot, ami a mérnököknek kell. És Opsgenie kritikus. Ezek hívások, incidenskezelés.
Az örök kérdés: „Ki figyeli a monitorozást?” Esetünkben a monitorozás önmagát figyeli, mert minden csomóponton vmagent használunk. És mivel a csomópontjaink ugyanannak a szolgáltatónak a különböző adatközpontjai között vannak elosztva, ezért minden adatközpontnak megvan a saját csatornája, függetlenek, és még ha meg is érkezik egy megosztott agy, akkor is kapunk riasztásokat. Igen, több lesz belőlük, de jobb, ha több riasztást kap, mint egyet sem.
Listánkat egy HA implementációval zárjuk.
Továbbá szeretném megjegyezni a VictoriaMetrics közösséggel való kommunikáció tapasztalatait. Nagyon pozitív lett. A srácok érzékenyek. Igyekeznek minden felkínált ügyben elmélyülni.
Elindítottam a problémákat a GitHubon. Nagyon gyorsan megoldódtak. Van még pár probléma, ami nincs teljesen lezárva, de a kódból már látom, hogy ez irányú munka folyik.
Az iterációk során az volt a fő fájdalom, hogy ha leállítok egy csomópontot, akkor a vminsert az első 30 másodpercben nem tudta megérteni, hogy nincs háttér. Ez most eldőlt. És szó szerint egy-két másodpercen belül az adatokat az összes többi csomóponttól veszik, és a kérés nem vár a hiányzó csomópontra.
Valamikor azt akartuk, hogy a VictoriaMetrics a VictoriaMetrics operátor legyen. Vártuk őt. Jelenleg aktívan építünk egy keretrendszert a VictoriaMetrics operátor számára, hogy átvegye az összes előszámítási szabályt stb. Prometheus, mert elég aktívan használjuk a Prometheus operátorhoz tartozó szabályokat.
Vannak javaslatok a klaszter megvalósításának javítására. Ezeket fentebb vázoltam.
És nagyon szeretnék lemintázni. Esetünkben a mintavételezésre kizárólag a trendek megtekintéséhez van szükség. Nagyjából egy mérőszám elég nekem napközben. Ezekre a trendekre egy évre, háromra, ötre, tíz évre van szükség. És egy metrikus érték is elég.
- Ismertük a fájdalmat, akárcsak néhány kollégánk a Prometheus használata során.
- A VictoriaMetrics-t választottuk magunknak.
- Függőlegesen és vízszintesen is jól skálázódik.
- Különböző komponenseket oszthatunk szét a fürt különböző számú csomópontjai között, korlátozhatjuk őket memóriával, hozzáadhatunk memóriát stb.
Otthon a VictoriaMetrics-t fogjuk használni, mert nagyon tetszett. Ez volt és ez lett.
Pár QR kód a VictoriaMetrics chathez, az elérhetőségeim, a LeroyMerlin műszaki radar.
Forrás: will.com