VictoriaMetrics ja privaatsete pilvede jälgimine. Pavel Kolobajev

VictoriaMetrics — kiire ja skaleeritav andmebaas ajareal põhinevate andmete salvestamiseks ja töötlemiseks (salvestus loob aja ja sellele vastava väärtuste kogumi, näiteks andurite oleku perioodilise küsitluse või meetmete kogumise kaudu).

Mina olen Kolobaev Pavel. DevOps, SRE, LeroyMerlin, kõik nagu kood – see on meie kõigi kohta: minu ja teiste LeroyMerlin töötajate kohta.

https://bit.ly/3jf1fIK

Meil on OpenStacki baasil pilv. Seal on väike link tehnoloogiaradarile.

See on loodud Kubernetes'i riistvara baasil ning kõigi OpenStacki ja logimisega seotud teenuste alusel.

Kava oli meil selline arenduse käigus. Kui me seda kõike arendasime, oli meil Prometheuse operaator, kes salvestas andmeid K8si klastri sees. Ta leiab automaatselt, mida on vaja kraapida, ja kogub need enda alla, nii öelda.

Kõik andmed tuleb meil viia klaasist välja, kuna kui midagi juhtub, peame mõistma, mis ja kus on.

Esimene lahendus – kasutame federatsiooni, kui meil on kolmas osaline Prometheus, kui me pääseme Kubernetes'i klastrisse federatsiooni mehhanismi kaudu.

Kuid siin tekivad väiksed probleemid. Meie puhul algasid probleemid, kui meil oli 250 000 mõõtu, ja kui neid sai 400 000, mõistsime, et me ei saa niimoodi jätkata. Me suurendasime scrape_timeout'i 25 sekundini.

Miks me pidime seda tegema? Prometheus hakkab ajastama timeout'i algusest pärast andmete võtmist. Ja pole tähtis, et andmed endiselt voolavad. Kui antud aja jooksul andmeid ei saadetud ja seanss ei suletud HTTP kaudu, siis loetakse seanss ebaõnnestunuks ning andmed ei jõua Prometheus'e.

Meile on tuttavad graafikud, mida saame, kui osa andmeid puudub. Graafikud on katkendlikud ja see ei rahulda meid.

Järgmine variant on sharding kahe erineva Prometheuse vahel sama föderatsioonimehhanismi kaudu.

Näiteks lihtsalt võtta ja nimetuse järgi nendest shard'id teha. Seda saab samuti kasutada, kuid me otsustasime liikuda edasi.

Nüüd peame kuidagi neid shard'e töötlema. Saame kasutada promxy't, mis läheb shardi piirkonda ja mitmekordistab andmed. Ta töötab kahe shardi puhul nagu ühtse sisenemise punktina. Seda saab teostada promxy kaudu, kuid see on praegu liiga keeruline.

Esimene variant – soovime loobuda federation mehhanismist, kuna see on väga aeglane.

Prometheuse arendajad ütlevad selgelt: «Poisid, kasutage teisi TimescaleDB, kuna me ei kavatse pikaajalist meetrikate salvestamist toetada». See ei ole nende ülesanne.

Me kirjutame endale paberile üles, et me ikkagi vajame andmete väljavõttu, et mitte hoida kõike ühes kohas.

Teine puudus – see on mälutarbimine. Jah, ma saan aru, et paljud ütlevad, et 2020. aastal paar gigabaiti mälu on üsna odav, kuid sellegipoolest.

Praegu on meil dev ja prod keskkond. Devis on see umbes 9 gigabaiti 350 000 meetrika kohta. Prodis on see veidi üle 14 gigabaiti 780 000 meetrika kohta. Sealjuures on meie retention time vaid 30 minutit. See on halb. Ja nüüd selgitan, miks.

Teeme arvutuse, st poolteise miljoni meetrika puhul, millega me juba peaaegu oleme, saame projekteerimise etapis 35-37 gigabaiti mälu. Kuid juba 4 miljoni meetrika puhul on vajalik umbes 90 gigabaiti mälu. See arvutati Prometheuse arendajate antud valemi järgi. Me vaatasime korrelatsiooni ja mõistsime, et me ei soovi maksta paar miljonit serveri eest, mis on lihtsalt jälgimiseks.

Meil ei suurene mitte ainult virtuaalmasinate arv, vaid me jälgime ka ise virtuaalmasinaid. Seetõttu, mida rohkem on virtuaalmasinaid, seda rohkem on erinevaid mõõdikuid jne. Meil on plaanis spetsiaalne kasv meie klastris seoses mõõdikutega.

Ketta mahu osas pole siin kõik sugugi masendav, kuid sooviksime parandada. Saime 15 päeva jooksul kokku 120 gigabaiti, millest 100 on kompressitud andmed ja 20 on kompressimata, kuid alati on soov, et see number oleks väiksem.

Seega lisame veel ühe punkti — see on suur ressursikasutuse tarve, mida soovime ikkagi säästa, kuna me ei taha, et meie jälgimiscluster tarbiks rohkem ressursse kui meie OpenStacki halduskolder.

Prometheusel on veel üks puudus, mille oleme enda jaoks tuvastanud, see on mingisugune mälu piirang. Prometheuse puhul on olukord palju halvem, kuna tal ei ole selliseid seadistusi üldse. Piirangu kasutamine Dockeris pole samuti variant. Kui teil juhtub olema RAF, mis on kukkunud ja seal on 20-30 gigabaiti, siis taastumine võtab väga kaua aega.

See on veel üks põhjus, miks Prometheus meile ei sobi, st mälu tarbimist ei saa piirata.

Me saaksime jõuda sellise skeemini. See skeem on vajalik, et korraldada HA klaster. Soovime, et meie mõõdikud oleksid igal ajal ja igal pool kergesti kättesaadavad, isegi kui server, mis neid mõõdikuid hoiab, peaks ebaõnnestuma. Seetõttu peame sellise skeemi üles ehitama.

See skeem näitab, et meil on shardide dubleerimine, mis toob endaga kaasa ka dubleerimise ressursside tarbimises. Seda on võimalik peaaegu horisontaalselt skaleerida, kuid ressursitarbimine jääb siiski tohutuks.

Puudused, mille oleme järjestanud, nagu oleme need välja kirjutanud:

• Nõutav on mõõdikute eksportimine väljapoole.
• Suur ressursitarbimine.
• Mälu tarbimist ei saa piirata.
• Kompleksne ja ressursimahukas HA rakendamine.

Oleme otsustanud, et lahkume Prometheuse andmehoidlast.

Oleme määratlenud veel mõned täiendavad nõuded, mis meile vajalikud. Need on:

• Promql toe olemasolu, kuna palju on juba kirjutatud Prometheuse põhjal: päringud, hoiatused.
• Ja siis on meil Grafana, mis on samuti kirjutatud Prometheuse tagaosas. Ei soovi juhtpaneele ümber kirjutada.
• Soovime luua korraliku HA arhitektuuri.
• Me tahame vähendada kõigi ressursside tarbimist.
• On veel üks väike nüanss. Me ei saa kasutada erinevaid pilvepõhiseid metoodikate kogumise süsteeme. Me ei tea, mis seal meie metoodikatesse läheb. Ja kuna sinna võib minna absoluutselt mis tahes, peame piirama kohaliku paigalduse kasutamist.

Valik oli väike. Kogusime kõik, milles meil oli kogemusi. Vaatasime Prometheuse integreerimise lehte, lugesime hulga artikleid, uurisime, mis on saadaval. Me valisime VictoriaMetricsi Prometheuse asendamiseks.

Miks? Sest:

• Toetab promql.
• Omab modulaarset arhitektuuri.
• Ei vaja muudatusi Grafanas.
• Ja mis kõige tähtsam – me võib-olla hakkame pakkuma metoodikate hoidlat oma ettevõttes teenusena, seega vaatame ette võimalike piirangute poole, et kasutajad saaksid mingil piiratud viisil kasutada kõiki klastrite ressursse, kuna on võimalus, et see on multitenant.

Teeme esimesed võrdlused. V võtame sama Prometheuse klastris, millele pääseb ligi väline Prometheus. Lisame kaudu remoteWrite VictoriaMetricsi.

Esiteks mainin, et siin märkame väikest tõusu CPU tarbimises VictoriaMetrics'i poolt. VictoriaMetrics'i wikis on kirjas, millised seadistused sobivad kõige paremini. Me kontrollisime need üle. Need vähendasid väga hästi CPU tarbimist.

Meie juhul ei ole Kubernetes'i klastri Prometheuse mälutarve oluliselt suurenenud.

Võrdleme kahte andmeallikat samade andmete jaoks. Prometheuses näeme kõiki samu puuduvaid andmeid. VictoriaMetrics'is on kõik korras.

Testitulemused salvestusruumi osas. Prometheuses saime kokku 120 gigabaiti. VictoriaMetrics'is saame juba 4 gigabaiti päevas. Seal on natuke erinev mehhanism, kui oleme harjunud Prometheuses nägema. See tähendab, et andmed suruvad end juba üsna hästi kokku päevas, poole tunni jooksul. Nad on juba hästi kokku surutud päevas, poole tunni jooksul, hoolimata sellest, et andmeid hakatakse hiljem veel ühendama. Kokkuvõttes säästsime salvestusruumilt.

Samuti säästame mäluressursside kasutuses. Meil oli Prometheus testide ajal käivitatud virtuaalmasinal – 8 tuuma, 24 gigabaiti. Prometheus tarbib praktiliselt kõik ressursid. See langes OOM Killer'i tõttu. Samal ajal tuli sisse vaid 900 000 aktiivset mõõdikut. See on umbes 25 000-27 000 mõõdikut sekundis.

VictoriaMetrics käivitus meil kahe tuuma virtuaalmasinal, millel on 8 gigabaiti RAM-i. Õnnestus VictoriaMetrics hästi tööle panna, kohandades mõningaid seadeid 8- gigabaitises masinas. Lõpptulemusena mahtusime 7 gigabaiti. Samuti saime sisu edastamise kiirus, st mõõdikud, isegi kõrgem kui Prometheusel.

CPU kasutus on võrreldes Prometheus'ega palju parem. Siin tarbib Prometheus 2,5 tuuma, samas kui VictoriaMetrics vaid 0,25 tuuma. Alguses – 0,5 tuuma. Ümberkatsete käigus tõuseb see ühe tuumani, kuid see juhtub äärmiselt harva.

Meie puhul langes valik VictoriaMetrics'ile arusaadavatel põhjustel, soovisime säästa ja ka säästsime.

Kustutame kohe kaks punkti – see on mõõdikutega laadimine ja suur ressursikasutus. Meil jääb otsustada kaks punkti, mille eest oleme endale veel jätnud.

Siin ma ütlen kohe, et me käsitleme VictoriaMetrics'i kui mõõtmete salvestusseadet. Kuid kuna me kavatseme tõenäoliselt VictoriaMetrics'i pakkuda kogu Leroy jaoks, peame piirama neid, kes kasutatakse seda klastrit, et nad meile seda ei rikkuks.

On suurepärane parameeter, mis võimaldab piirata aega, andmemahtu ja täitmise aega.

Samuti on olemas suurepärane valik, mis võimaldab piirata mälukasutust, sellega saame leida selle tasakaalu, mis võimaldab meil saavutada normaalse töökiirus ja mõõdukas ressursikasutus.

Veel üks miinus, st kustutame punkti – ei saa piirata mälukasutust.

Esimese iteratsioonide jooksul testisime VictoriaMetrics Single Node'i. Edasi liigume VictoriaMetrics Cluster Version'i juurde.

Siin avardame oma võimalusi erinevate teenuste jaotamisel VictoriaMetrics'is sõltuvalt sellest, millistel nad töötavad ja milliseid ressursse nad tarbivad. See on väga paindlik ja mugav lahendus. Me oleme seda ise kasutanud.

VictoriaMetrics Cluster Version'i põhikomponendid on vmstorage. Neid võib olla N arvu. Meie puhul on neid hetkel 2.

Ja on olemas vminsert. See on puhverserver, mis võimaldab meil: korraldada shardimist kõigi nende salvestusruumide vahel, mille kohta oleme talle teatanud, ja see võimaldab hõlbustada ka replikatsiooni, st teil on olemas nii shardimine kui ka replikatsioon.

Vminsert toetab protokolle OpenTSDB, Graphite, InfluxDB ja Prometheuse remoteWrite.

On olemas ka vmselect. Selle peamine ülesanne on minna vmstorage'i, saada sealt andmed, deduplitseerida need andmed ja edastada need kliendile.

On olemas suurepärane tööriist vmagent. Meile see väga meeldib. See võimaldab konfigureerida täpselt nagu Prometheus ja samal ajal teha kõike nii nagu Prometheus. St see kogub erinevatelt üksustelt, teenustelt mõõtmeid ja saadab need vminsert'i. Edasi sõltub kõik juba teistest.

Veel üks suurepärane teenus on vmalert, mis võimaldab kasutada tagaplaanina VictoriaMetrics'i, saada andmeid vminsert'ilt ja saata need vmselect'ile töötlemiseks. Ta töötleb alarme ja reegleid. Alarme korraldame me alertmanager'i kaudu.

Meil on olemas wmauth komponent. Me plaanime seda kasutada, aga võib-olla mitte (me pole veel selgusele jõudnud), et kasutada autentimissüsteemina multitenancy versioonides klastritest. See toetab remoteWrite'i Prometheusele ja suudab autoriseerida URL-i alusel, täpsemalt selle teise osa alusel, kuhu saab või ei saa kirjutada.

Seal on veel vmbackup ja vmrestore. See on põhimõtteliselt andmete taastamise ja varundamise süsteem. Toetab S3, GCS ja file.

Meie klastrite esialgne versioon valmis karanteeni ajal. Sellel ajal ei olnud replikatsiooni, seega meie versioon koosnes kahest erinevast ja iseseisvast klastrist, kuhu saime andmeid remoteWrite'i kaudu.

Siinkohal pean mainima, et kui me läksime VictoriaMetrics Single Node'ist VictoriaMetrics Cluster Version'i, siis jäi meie ressursikasutus endiseks, st peamine oli mälu. Umbes niimoodi jagunesid meie andmed, st ressursikasutuse tarbimine.

Siia oli juba lisatud replikatsioon. Koondasime kõik need kokku üheks suhteliselt suureks klastriks. Kõik andmed on meil nii sharditud kui ka replikatsiooniga.

Kogu kluster on varustatud N sissepääsuga, st Prometheus saab andmeid lisada HAPROXY kaudu. See on meie sissepääs. Ja selle kaudu on võimalik siseneda Grafanasse.

Meie juhul on HAPROXY ainus port, mis suunab select, insert ja muud teenused selle klustri sisse. Ühe aadressi loomine ei olnud võimalik, seetõttu pidime tegema mitu sissepääsu, kuna virtuaalmasinad, millel VictoriaMetrics-kluster töötab, asuvad erinevates tsoonides ühe ja sama pilveteenuse pakkuja juures, st mitte meie pilves, vaid väljas.

Meil on häirete haldamine. Me kasutame seda. Me kasutame Prometheuse alertmanagerit. Alerte toimetame läbi Opsgenie ja Telegrami. Telegramis saadavad arendajad, võib-olla midagi tootmisest, aga rohkem on seal statistiline teave, mida insenerid vajavad. Opsgenie puhul on see kriitiline. Need on kõned, juhtimine intsidentide korral.

Igav küsimus: „Kes siis jälgib jälgimist?“. Meie puhul jälgib jälgimist monitor, kuna kasutame vmagent'i igas node'is. Ja kuna meie node'id on erinevates andmekeskustes, kasutame igas andmekeskuses oma kanalit, need on iseseisvad ja isegi kui tekib split brain, saame ikkagi hoiatusteateid. Jah, neid tuleb rohkem, aga parem on saada rohkem hoiatusteateid kui mitte ühtegi.

Kokkuvõttes lõpetame oma nimekirja HA rakendamisega.

Tahaksin veel märkida oma kogemust VictoriaMetrics'i kogukonnaga. See osutus väga positiivseks. Poistel on head pöördumisoskused. Nad püüavad mõista iga juhtumit, mis neile esitatakse.

Olen loonud küsimusi GitHub'is. Need lahendati väga kiiresti. On veel paar küsimust, mis pole täielikult suletud, kuid juba koodi põhjal näen, et see suund on töös.

Peamine valu iteratsioonide ajal oli see, et kui ma lülitasin node'i välja, ei suutnud vminsert esimesed 30 sekundit aru saada, et backend'i ei ole. See on nüüd lahendatud. Ja juba hetkega korjatakse andmed kõigist ülejäänud node'idest ning päring ei pea enam ootama kadunud node'i.

Soovisime mingil hetkel, et see oleks VictoriaMetrics operaator. Me oleme selle saavutanud. Praegu töötame aktiivselt VictoriaMetrics operaatori kohaliku ühenduse ülesehitamise kallal, et viia kõik ettearvutamisreeglid jms Prometheuse, kuna kasutame piisavalt aktiivselt reegleid, mis tulevad koos Prometheuse operaatoriga.

On ettepanekuid klastrite elluviimise parendamiseks. Olen kirjeldanud neid eespool.

Ja me soovime väga downsampling'ut. Meie puhul on downsampling vajalik peamiselt trendide vaatamiseks. Ütleme nii, et ühte mõõdikut päeva jooksul piisab. Need trendid on vajalikud aastaks, kolmeks, viieks, kümneks aastaks. Üks mõõdiku väärtus on täiesti piisav.

• Oleme kogenud valu, nagu ka mõned meie kolleegid, Prometheuse kasutamisel.
• Oleme valinud VictoriaMetricsi.
• See skaleerub piisavalt hästi nii vertikaalselt kui ka horisontaalselt.
• Saame erinevad komponendid hajutada erinevatele sõlmedele klastris, piirata neid mälumahtude järgi, lisada mälu jms.

Kavatseme kasutada VictoriaMetricsi, kuna oleme sellest väga vaimustuses. Nii oli ja nii on nüüd.

https://t.me/VictoriaMetrics_ru1

Mõned qr-koodid VictoriaMetricsi chati jaoks, minu kontaktid, tehnoloogiatõukur LeroyMerlin.

Allikas: habr.com