VictoriaMetrics er hraðvirkt og stigstærð DBMS til að geyma og vinna úr gögnum í formi tímaraða (skrá samanstendur af tíma og safni gilda sem samsvara þessum tíma, til dæmis, fengin með reglubundinni könnun á stöðu skynjara eða safn mæligilda).
Ég heiti Kolobaev Pavel. DevOps, SRE, LeroyMerlin, allt er eins og kóða - þetta snýst allt um okkur: um mig og um aðra starfsmenn LeroyMerlin.
Það er ský byggt á OpenStack. Það er lítill hlekkur á tæknilega ratsjána.
Það er byggt á Kubernetes vélbúnaði, sem og á allri tengdri þjónustu fyrir OpenStack og skógarhögg.
Þetta er kerfið sem við vorum með í þróun. Þegar við vorum að þróa þetta allt, vorum við með Prometheus rekstraraðila sem geymdi gögn inni í K8s klasanum sjálfum. Hann finnur sjálfkrafa það sem þarf að skrúbba og setur það undir fætur sér í grófum dráttum.
Við munum þurfa að færa öll gögn út fyrir Kubernetes klasann, því ef eitthvað gerist þurfum við að skilja hvað og hvar.
Fyrsta lausnin er sú að við notum sambandsríki þegar við erum með þriðja aðila Prometheus, þegar við förum í Kubernetes klasann í gegnum sambandskerfið.
En það eru smá vandamál hér. Í okkar tilviki byrjuðu vandamálin þegar við vorum með 250 mælikvarða og þegar það voru 000 mælingar, áttuðum við okkur á því að við gætum ekki unnið svona. Við hækkuðum scrape_timeout í 400 sekúndur.
Af hverju þurftum við að gera þetta? Prometheus byrjar að telja leikhléið frá upphafi girðingarinnar. Það skiptir ekki máli að gögnin flæða enn. Ef gögnin eru ekki sameinuð á þessu tilgreinda tímabili og lotunni er ekki lokað í gegnum http, þá er lotan talin hafa mistekist og gögnin komast ekki inn í Prometheus sjálft.
Allir kannast við línuritin sem við fáum þegar eitthvað af gögnunum vantar. Dagskráin er rifin og við erum ekki ánægð með þetta.
Næsti valkostur er klipping byggð á tveimur mismunandi Prometheus í gegnum sama sambandskerfi.
Til dæmis, taktu þá bara og klipptu þá með nafni. Þetta er líka hægt að nota, en við ákváðum að halda áfram.
Við verðum nú að vinna úr þessum brotum einhvern veginn. Þú getur tekið promxy, sem fer á shard svæðið og margfaldar gögnin. Það virkar með tvö brot sem einn inngangspunkt. Þetta er hægt að útfæra í gegnum promxy, en það er samt of erfitt.
Fyrsti kosturinn er sá að við viljum hætta við sambandskerfið vegna þess að það er mjög hægt.
Prometheus forritararnir segja greinilega: "Krakkar, notaðu annan TimescaleDB vegna þess að við munum ekki styðja langtíma geymslu mæligilda." Þetta er ekki þeirra verkefni.
Við skrifum niður á blað sem við þurfum enn að losa úti, til að geyma ekki allt á einum stað.
Annar gallinn er minnisnotkun. Já, ég skil að margir muni segja að árið 2020 kosti nokkur gígabæt af minni eyri, en samt.
Nú erum við með þróunar- og framleiðsluumhverfi. Í dev er það um 9 gígabæt fyrir 350 mælikvarða. Í framleiðslu er það 000 gígabæt og rúmlega 14 mæligildi. Á sama tíma er varðveislutími okkar aðeins 780 mínútur. Þetta er slæmt. Og nú mun ég útskýra hvers vegna.
Við gerum útreikning, það er, með einni og hálfri milljón mæligildum, og við erum nú þegar nálægt þeim, á hönnunarstigi fáum við 35-37 gígabæta af minni. En nú þegar þurfa 4 milljónir mælikvarða um 90 gígabæta af minni. Það er, það var reiknað út með því að nota formúluna sem Prometheus verktaki gaf upp. Við skoðuðum fylgnina og komumst að því að við vildum ekki borga nokkrar milljónir fyrir netþjón bara fyrir eftirlit.
Við munum ekki bara fjölga vélum, við erum líka að fylgjast með sýndarvélunum sjálfum. Þess vegna, því fleiri sýndarvélar, því fleiri mælikvarðar af ýmsu tagi osfrv. Við munum hafa sérstakan vöxt í klasanum okkar hvað varðar mælikvarða.
Með diskpláss er ekki allt svo slæmt hérna, en ég myndi vilja bæta það. Við fengum alls 15 gígabæt á 120 dögum, þar af 100 þjöppuð gögn, 20 óþjappuð gögn, en við viljum alltaf minna.
Í samræmi við það skrifum við niður einn punkt í viðbót - þetta er mikil neysla á auðlindum, sem við viljum samt spara, því við viljum ekki að vöktunarklasinn okkar eyði meira fjármagni en þyrpingin okkar sem heldur utan um OpenStack.
Það er einn galli í viðbót við Prometheus, sem við höfum greint fyrir okkur, þetta er að minnsta kosti einhvers konar minnistakmörkun. Með Prometheus er allt miklu verra hér, vegna þess að það hefur alls ekki slíka snúning. Að nota takmörk í docker er heldur ekki valkostur. Ef RAF þinn féll skyndilega og það eru 20-30 gígabæt, þá mun það taka mjög langan tíma að hækka.
Þetta er önnur ástæða fyrir því að Prometheus hentar okkur ekki, þ.e.a.s. við getum ekki takmarkað minnisnotkun.
Það væri hægt að koma með slíkt skipulag. Við þurfum þetta kerfi til að skipuleggja HA klasa. Við viljum að mælikvarðar okkar séu alltaf tiltækir og alls staðar, jafnvel þótt þjónninn sem geymir þessar mælingar hrynji. Og því verðum við að byggja upp slíkt kerfi.
Þetta kerfi segir að við munum hafa tvöföldun á brotum og, í samræmi við það, tvöföldun á kostnaði við neytt auðlinda. Það er hægt að skala það nánast lárétt, en engu að síður verður auðlindanotkunin helvítis.
Ókostir í röð í því formi sem við skrifuðum þá niður fyrir okkur:
- Krefst upphleðslu mæligilda utanaðkomandi.
- Mikil auðlindanotkun.
- Það er engin leið til að takmarka minnisnotkun.
- Flókin og auðlindafrek innleiðing HA.
Fyrir okkur sjálf ákváðum við að við værum að flytja frá Prometheus sem geymsluaðstöðu.
Við höfum bent á viðbótarkröfur fyrir okkur sjálf sem við þurfum. Þetta:
- Þetta er promql stuðningur, vegna þess að margt hefur þegar verið skrifað fyrir Prometheus: fyrirspurnir, viðvaranir.
- Og svo höfum við Grafana, sem er þegar skrifað á nákvæmlega sama hátt fyrir Prometheus sem bakenda. Ég vil ekki endurskrifa mælaborð.
- Við viljum byggja venjulegan HA arkitektúr.
- Við viljum draga úr neyslu hvers kyns auðlinda.
- Það er annar lítill blæbrigði. Við getum ekki notað ýmsar gerðir af skýjamælingakerfum. Við vitum ekki hvað mun falla inn í þessar mælingar ennþá. Og þar sem allt getur flogið þangað verðum við að takmarka okkur við staðbundna staðsetningu.
Það var lítið val. Við tókum saman allt sem við höfðum reynslu af. Við skoðuðum Prometheus síðuna í samþættingarhlutanum, lásum fullt af greinum og sáum hvað var þarna úti. Og fyrir okkur sjálf, völdum við VictoriaMetrics í stað Prometheus.
Hvers vegna? Vegna þess að:
- Kann promql.
- Það er mát arkitektúr.
- Þarf ekki breytingar á Grafana.
- Og síðast en ekki síst, við munum líklega veita mæligildi geymslu innan fyrirtækis okkar sem þjónustu, þannig að við erum fyrirfram að horfa til takmarkana af ýmsu tagi svo að notendur geti notað öll auðlindir klasans á einhvern takmarkaðan hátt, því það er möguleiki að það muni fjölbýli.
Við skulum gera fyrsta samanburðinn. Við tökum sama Prometheus inn í þyrpinguna, ytri Prometheus fer að honum. Bættu við með remoteWrite VictoriaMetrics.
Ég mun strax gera fyrirvara um að hér fengum við smá aukningu á örgjörvanotkun frá VictoriaMetrics. VictoriaMetrics wiki segir þér hvaða færibreytur eru bestar. Við skoðuðum þá. Þeir hafa minnkað örgjörvanotkun mjög vel.
Í okkar tilviki jókst minnisnotkun Prometheus, sem er staðsettur í Kubernetes þyrpingunni, ekki verulega.
Við berum saman tvær gagnaheimildir sömu gagna. Í Prometheus sjáum við sömu gögn sem vantar. Allt er í lagi hjá VictoriaMetrics.
Niðurstöður plássprófunar. Við hjá Prometheus fengum 120 gígabæt samtals. Hjá VictoriaMetrics fáum við nú þegar 4 gígabæt á dag. Það er aðeins öðruvísi gangverk en það sem við erum vön að sjá í Prometheus. Það er að segja að gögnin eru þegar þjappuð nokkuð vel á einum degi, á hálftíma. Þeir hafa þegar verið uppskornir vel á einum degi, á hálftíma, þrátt fyrir að gögnin muni enn glatast síðar. Fyrir vikið sparaðum við pláss á disknum.
Við spörum líka minnisnotkun. Á þeim tíma sem prófunin var gerð, vorum við með Prometheus á sýndarvél - 8 kjarna, 24 gígabæt. Prometheus borðar næstum allt. Hann féll á OOM Killer. Á sama tíma var aðeins 900 virkum mælingum hellt í það. Þetta er um 000-25 mælikvarðar á sekúndu.
Við keyrðum VictoriaMetrics á tvíkjarna sýndarvél með 8 gígabæta af vinnsluminni. Okkur tókst að fá VictoriaMetrics til að virka vel með því að fikta í nokkrum hlutum á 8GB vél. Að lokum héldum við því í 7 gígabæta. Á sama tíma var afhendingarhraði efnis, þ.e. mælikvarða, jafnvel meiri en hjá Prometheus.
Örgjörvinn er orðinn miklu betri miðað við Prometheus. Hér eyðir Prometheus 2,5 kjarna, og VictoriaMetrics eyðir aðeins 0,25 kjarna. Í upphafi - 0,5 kjarna. Þegar það sameinast nær það einum kjarna, en þetta er afar, afar sjaldgæft.
Í okkar tilviki féll valið á VictoriaMetrics af augljósum ástæðum; við vildum spara peninga og við gerðum það.
Stráum strax yfir tvo punkta - upphleðslu mæligilda og mikil neysla á auðlindum. Og við verðum bara að ákveða tvö stig sem við eigum enn eftir fyrir okkur.
Hér mun ég panta strax, við lítum á VictoriaMetrics sem geymslu mæligilda. En þar sem við munum líklegast útvega VictoriaMetrics sem geymslu fyrir allt Leroy, þurfum við að takmarka þá sem munu nota þennan klasa svo þeir gefi okkur hann ekki.
Það er dásamleg færibreyta sem gerir þér kleift að takmarka eftir tíma, eftir magni gagna og eftir framkvæmdartíma.
Það er líka frábær valkostur sem gerir okkur kleift að takmarka minnisnotkun, þar með getum við fundið það jafnvægi sem gerir okkur kleift að fá eðlilegan hraða og fullnægjandi auðlindanotkun.
Mínus einn punktur í viðbót, þ.e.a.s. strikaðu út punktinn - þú getur ekki takmarkað minnisnotkun.
Í fyrstu endurtekningunum prófuðum við VictoriaMetrics Single Node. Næst förum við yfir í VictoriaMetrics Cluster Version.
Hér höfum við frjálsar hendur til að aðgreina mismunandi þjónustu í VictoriaMetrics eftir því á hverju þær munu keyra og hvaða auðlindir þær munu neyta. Þetta er mjög sveigjanleg og þægileg lausn. Við notuðum þetta á okkur sjálf.
Helstu þættir VictoriaMetrics Cluster Version eru vmstsorage. Það getur verið N tala af þeim. Í okkar tilviki eru 2 þeirra hingað til.
Og það er vminsert. Þetta er proxy-þjónn sem gerir okkur kleift að: raða sundrun á milli allra geymslunnar sem við sögðum honum frá, og hann leyfir líka eftirmynd, þ.e.a.s. þú munt hafa bæði sundrun og eftirmynd.
Vminsert styður OpenTSDB, Graphite, InfluxDB og remoteWrite samskiptareglur frá Prometheus.
Það er líka vmselect. Aðalverkefni þess er að fara í vmstorage, taka á móti gögnum frá þeim, afrita þessi gögn og gefa viðskiptavininum.
Það er til dásamlegur hlutur sem heitir vmagent. Okkur líkar mjög vel við hana. Það gerir þér kleift að stilla nákvæmlega eins og Prometheus og samt gera allt nákvæmlega eins og Prometheus. Það er, það safnar mælingum frá mismunandi aðilum og þjónustu og sendir þær til vminsert. Þá veltur allt á þér.
Önnur frábær þjónusta er vmalert, sem gerir þér kleift að nota VictoriaMetrics sem bakenda, taka á móti unnin gögn frá vminsert og senda þau til vmselect. Það vinnur úr viðvörunum sjálfum, svo og reglum. Ef um viðvaranir er að ræða fáum við viðvörunina í gegnum alertmanager.
Það er wmauth hluti. Við gætum eða megum ekki (við höfum ekki ákveðið þetta ennþá) notað það sem heimildarkerfi fyrir fjöleignarútgáfu klasa. Það styður remoteWrite fyrir Prometheus og getur heimilað út frá slóðinni, eða öllu heldur seinni hluta hennar, þar sem þú getur eða getur ekki skrifað.
Það er líka vmbackup, vmrestore. Þetta er í raun endurheimt og öryggisafrit af öllum gögnum. Getur gert S3, GCS, skrá.
Fyrsta endurtekningin á klasanum okkar var gerð í sóttkví. Á þeim tíma var engin eftirlíking, svo endurtekningin okkar samanstóð af tveimur mismunandi og sjálfstæðum klösum sem við fengum gögn í gegnum remoteWrite.
Hér ætla ég að gera fyrirvara um að þegar við skiptum úr VictoriaMetrics Single Node yfir í VictoriaMetrics Cluster Version, þá héldum við áfram með sömu neyttu auðlindirnar, þ.e.a.s. það helsta er minni. Þetta er nokkurn veginn hvernig gögnum okkar, þ.e.a.s. auðlindanotkun, var dreift.
Eftirmynd hefur þegar verið bætt við hér. Við sameinuðum þetta allt í einn tiltölulega stóran klasa. Öll gögn okkar eru bæði brotin og endurtekin.
Allur þyrpingin hefur N inngangspunkta, sem þýðir að Prometheus getur bætt við gögnum í gegnum HAPROXY. Hér höfum við þennan inngangspunkt. Og í gegnum þennan aðgangsstað geturðu skráð þig inn frá Grafana.
Í okkar tilviki er HAPROXY eina höfnin sem umboðsmenn velja, setja inn og aðra þjónustu inni í þessum klasa. Í okkar tilviki var ómögulegt að búa til eitt heimilisfang; við þurftum að gera nokkra aðgangsstaði, vegna þess að sýndarvélarnar sjálfar sem VictoriaMetrics þyrpingin keyrir á eru staðsettar á mismunandi svæðum hjá sömu skýjaveitunni, þ.e.a.s. ekki inni í skýinu okkar, heldur utan við .
Við erum með viðvörun. Við notum það. Við notum alertmanager frá Prometheus. Við notum Opsgenie og Telegram sem viðvörunarsendingarrás. Í Telegram streyma þeir inn frá dev, kannski eitthvað frá prod, en aðallega eitthvað tölfræðilegt, sem verkfræðingar þurfa. Og Opsgenie er gagnrýninn. Þetta eru símtöl, atvikastjórnun.
Eilífa spurningin: „Hver fylgist með eftirlitinu? Í okkar tilviki fylgist eftirlit með því að fylgjast með sjálfu sér, vegna þess að við notum vmagent á hverjum hnút. Og þar sem hnútum okkar er dreift á mismunandi gagnaver hjá sömu þjónustuveitunni, þá hefur hver gagnaver sína eigin rás, þeir eru sjálfstæðir og jafnvel þótt klofinn heili berist, munum við samt fá viðvörun. Já, þeir verða fleiri, en það er betra að fá fleiri viðvaranir en engar.
Við endum listann okkar með HA útfærslu.
Og ennfremur vil ég benda á reynsluna af samskiptum við VictoriaMetrics samfélagið. Það reyndist mjög jákvætt. Strákarnir eru móttækilegir. Þeir reyna að kafa ofan í hvert mál sem boðið er upp á.
Ég byrjaði á vandamálum á GitHub. Þau voru leyst mjög fljótt. Það eru nokkur mál í viðbót sem eru ekki alveg lokuð, en ég sé nú þegar af kóðanum að vinna í þessa átt er í gangi.
Helsti sársauki fyrir mig við endurtekningar var að ef ég lokaði á hnút, þá gat vminsert ekki skilið fyrstu 30 sekúndurnar að það væri enginn bakendi. Þetta hefur nú verið ákveðið. Og bókstaflega á einni eða tveimur sekúndum eru gögnin tekin úr öllum hnútunum sem eftir eru og beiðnin hættir að bíða eftir þeim hnút sem vantar.
Á einhverjum tímapunkti vildum við að VictoriaMetrics yrði VictoriaMetrics rekstraraðili. Við biðum eftir honum. Við erum nú virkir að byggja upp ramma fyrir VictoriaMetrics rekstraraðila til að taka allar forútreikningsreglur o.s.frv. Prometheus, vegna þess að við erum frekar virkir að nota reglurnar sem fylgja Prometheus rekstraraðilanum.
Fyrir liggja tillögur um að bæta klasainnleiðinguna. Ég rakti þær hér að ofan.
Og mig langar virkilega að draga úr sýnishorninu. Í okkar tilviki þarf niðursýni eingöngu til að skoða þróun. Í grófum dráttum er einn mælikvarði nóg fyrir mig yfir daginn. Þessar þróunar eru nauðsynlegar í eitt ár, þrjú, fimm, tíu ár. Og eitt mæligildi er alveg nóg.
- Við höfum þekkt sársauka, eins og sumir samstarfsmenn okkar, við notkun Prometheus.
- Við völdum VictoriaMetrics fyrir okkur.
- Hann mælist nokkuð vel bæði lóðrétt og lárétt.
- Við getum dreift mismunandi hlutum á mismunandi fjölda hnúta í þyrpingunni, takmarkað þá með minni, bætt við minni o.s.frv.
Við munum nota VictoriaMetrics heima því okkur líkaði það mjög vel. Þetta er það sem var og það sem er orðið.
Nokkrir QR kóðar fyrir VictoriaMetrics spjallið, tengiliðina mína, tæknilega radar LeroyMerlin.
Heimild: www.habr.com