VictoriaMetrics ja privaatsete pilvede jälgimine. Pavel Kolobaev

VictoriaMetrics — kiire ja skaleeritav andmebaas ajaseeria andmete salvestamiseks ja töötlemiseks (salvestamine koosneb ajast ja sellele ajale vastavatest väärtustest, näiteks, mis saadakse senzorite oleku perioodilise jälgimise või meetrite kogumise käigus).

Minu nimi on Kolobajev Pavel. DevOps, SRE, LeroyMerlin, kõik nagu kood – see on kõik meie kohta: minu ja teiste LeroyMerlini töötajate kohta.

https://bit.ly/3jf1fIK

Seal on OpenStacki põhine pilv. Seal on väike link tehnilistele radaritele.

See on üles ehitatud Kubernetes'i riistvara põhjal, samuti kõigi OpenStack'i ja logimisega seotud teenuste põhjal.

Kavand oli meil selline arendamisel. Kui me seda arendasime, oli meil Prometheuse operaator, mis salvestas andmeid K8si klastris. See leidis automaatselt, mida tuleb skrabida ja ladustas selle enda alla, nii rääkides.

Kõik andmed peab me tõstma välja Kubernetes'i klastri piiridest, sest kui midagi juhtub, peame saama aru, mis ja kus asub.

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

Aga siin tekivad väiksed probleemid. Meie puhul algasid probleemid, kui meil oli 250 000 mõõdikut, ja kui see kasvas 400 000 mõõdikuni, mõistsime, et niimoodi ei saa töötada. Suurendasime scrape_timeout'i 25 sekundini.

Miks me pidime seda tegema? Prometheus hakkab aegumist loendama alates andmete võtmise algusest. Ja pole vahet, et andmed veel voolavad. Kui selle määratud ajavahemiku jooksul andmed ei ole valatud ja seanss ei ole http kaudu suletud, loetakse seanss ebaõnnestunuks ja andmed ei jõua Prometheusse.

Kõigile on tuttavad graafikud, mida saame, kui osa andmeid puudub. Graafikud on katkised ja see ei sobi meile.

Järgmine variant – see on shardimine kahe erineva Prometheuse põhjal sama federaatsiooni mehhanismi kaudu.

Näiteks, lihtsalt võtta ja jagada neid nime järgi. Seda saab ka kasutada, kuid me otsustasime liikuda edasi.

Me peame nüüd neid sharde kuidagi töötlema. Võime kasutada promxy't, mis läheb shard'i alale ja mitmekordistab andmeid. See töötab kahe shardi puhul nagu ühe sissepääsu punkt. Seda saab rakendada promxy kaudu, kuid praegu on see liiga keeruline.

Esimene variant – me tahame loobuda federaatsiooni mehhanismist, kuna see on väga aeglane.

Prometheuse arendajad ütlevad selgelt: „Poisid, kasutage teisi TimescaleDB-sid, sest me ei hakka pikaajalist metoodika toetama“. See ei ole nende ülesanne.

Me kirjutame endale paperile, et meil on ikkagi vajalik eksport välja, et mitte hoida kõike ühes kohas.

Teine puudus on mälu tarbimine. Jah, ma saan aru, et paljud ütlevad, et 2020. aastal paar gigabaiti mälu on odav, kuid siiski.

Praegu on meil dev- ja prod-keskkond. Dev-is on see umbes 9 gigabaiti 350 000 meetrika kohta. Prod-is on see veidi üle 14 gigabaidi 780 000 meetrika kohta. Samal ajal on meie säilitamise aeg vaid 30 minutit. See on halb. Ja nüüd selgitan, miks.

Teeme arvutusi, st 1,5 miljoni meetrika juures, kuna oleme juba sellele lähedal, saame projekteerimise etapis 35–37 gigabaiti mälu. Kuid 4 miljoni meetrika puhul on vajaminev mälu juba umbes 90 gigabaiti. See on arvutatud Prometheuse arendajate esitatud valemi alusel. Me vaatasime korrelatsiooni ja mõistsime, et me ei soovi maksta paar miljonit serveri eest, mis on mõeldud vaid jälgimiseks.

Meie masinate arv ei suurene mitte ainult, vaid jälgime ka virtuaalseid masinaid. Seega, mida rohkem on virtuaalseid masinaid, seda rohkem on erinevaid meetrikaid jne. Meie klastrite kasv meetrikate osas on eriline.

Kettaruumi osas ei ole olukord üldse nii halb, kuid tahaksime paraneda. Saime 15 päevaga kokku 120 gigabaiti, millest 100 on tihendatud andmed ja 20 on tihendamata andmed, kuid alati tahaks vähem.

Seega kirjutame veel ühe punkti – see on suur ressursi tarbimine, mida tahaksime siiski säästa, sest me ei soovi, et meie jälgimisklastri ressursid ületaksid meie OpenStacki halduskeskkonna ressursse.

Prometheuse puhul oleme avastanud veel ühe puuduse, mis on mingi mälu piiramise puudumine. Prometheuse puhul on olukord palju halvem, kuna tal ei ole selliseid reguleerimisi üldse. Piirangu seadmine Dockeris ei ole samuti variant. Kui teie RAF kukub ja seal on 20–30 gigabaiti, siis taastumine kestab väga kaua.

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

Me võiksime välja töötada sellise skeemi. See skeem on vajalik, et organiseerida HA klastrit. Soovime, et meie mõõdikud oleksid alati ja kõikjal kergesti kätte saadavad, isegi kui server, mis neid mõõdikuid hoiab, kukub alla. Seega peame ehitama just sellise skeemi.

See skeem näitab, et meil on shardide dubleerimine ja seega ka dubleerimine kasutatavate ressursside kuludes. Seda on võimalik peaaegu horisontaalselt skaleerida, kuid ressursside tarbimine jääb siiski väga kõrgeks.

Puudused, nagu me neid endale kirja panime:

• On vajalik mõõdikute eksportimine välja.
• Suure tarbimisega ressursid.
• Mälu tarbimist ei saa piirata.
• Kompaktne ja ressursohutu HA rakendamine.

Oleme otsustanud, et loobume Prometheusest andmehoidjana.

Meil on veel täiendavad nõudmised, mis on vajalikud. Need on:

• Toetust promql, kuna palju on juba kirjutatud Prometheuse alla: päringud, hoiatused.
• Ja meil on Grafana, mis on samuti kirjutatud Prometheuse tagaplaanina. Me ei taha armatuurlaudu ümber kirjutada.
• Soovime üles ehitada korraliku HA arhitektuuri.
• Soovime vähendada igasuguste ressursside tarbimist.
• On veel üks väike nüanss. Me ei saa kasutada mitmesuguseid pilvesüsteeme mõõdikute kogumiseks. Me ei tea, mis meie mõõdikutesse satub. Kuna sinna võib sattuda mis tahes, peame piirduma kohalikuga.

Valik oli üsna väike. Me kogusime kõik, millel meil oli kogemus. Vaatasime Prometheuse integratsiooni lehte, lugesime palju artikleid ja uurisime, mis kõik on olemas. Valisime VictoriaMetrics'i Prometheuse asendajana.

Miks? Sest:

• Toetab promql.
• On modulaarne arhitektuur.
• Ei vaja muudatusi Grafanas.
• Ja kõige tähtsam - me võime pakkuda mõõdikute hoidlat oma ettevõtte sees teenusena, seega vaatame ette, et piirame eri viisil, et kasutajad saaksid mingis piiratud mahus kasutada kõiki klastrite ressursse, kuna on tõenäosus, et see on multitenant.

Teeme esimesi võrdlusi. Võtame sama Prometheuse klastris, millele pääseb juurde väline Prometheus. Lisame remoteWrite'i kaudu VictoriaMetrics'i.

Koheselt ütlen, et siin jälgime väikest tõusu CPU kasutuses VictoriaMetrics'i poolt. VictoriaMetrics'i wikis on kirjas, millised parameetrid sobivad paremini. Me oleme need üle kontrollinud. Nad vähendasid CPU kasutust väga tõhusalt.

Meie puhul ei tõusnud Kuberneteses töötava Prometheuse mälu kasutus märkimisväärselt.

Võrdleme kahte andmeallikat samadele andmetele. Prometheuses näeme endiselt kõiki samu puudulikke andmeid. VictoriaMetrics'is on kõik korras.

Testide tulemused ketasruumi osas. Prometheuses saime kokku 120 gigabaiti. VictoriaMetrics'is saame juba 4 gigabaiti päevas. Seal on veidi erinev mehhanism, kui oleme harjunud nägema Prometheuses. T. e. andmed pressitakse üsna hästi kokku päeva ja poole tunni jooksul. Need on juba hästi kokku pressitud, vaatamata sellele, et hiljem liidetakse andmed kokku. Lõppkokkuvõttes säästsime ketasruumis.

Samuti säästame mäluressursside kasutuses. Meie Prometheus oli testide ajal käivitatud virtuaalmasinas – 8 tuuma, 24 gigabaiti. Prometheus kasutab praktiliselt kogu ressursi. See langes OOM Killer'i tõttu. Selle all oli vaid 900 000 aktiivset mõõdikut. See on umbes 25 000-27 000 mõõdikut sekundis.

VictoriaMetrics oli meil käivitatud kahetuumalisel virtuaalmasinal, kus oli 8 gigabaiti RAM-i. Me suutsime VictoriaMetrics'i hästi tööle panna, keerates mõningaid asju 8-gigabaitisel masinal. Lõppkokkuvõttes mahtusime 7 gigabaiti. Seejuures saime sisu edastuskiiruselt, t. e. mõõdikute, isegi kõrgema tulemuse kui Prometheusel.

CPU osas on olukord oluliselt parem võrreldes Prometheusega. Siin kasutab Prometheus 2,5 tuuma, VictoriaMetrics aga vaid 0,25 tuuma. Alguses – 0,5 tuuma. Ühinemise käigus võib see tõusta kuni ühe tuumana, kuid see on äärmiselt haruldane.

Meie puhul langes valik VictoriaMetrics'i kasuks arusaadavatel põhjustel, soovisime säästa ja olime edukad.

Koheselt välistame kaks punkti – see on mõõdikute väljavedu ja suur ressursihulk. Meil jääb lahendada kaks punkti, mille oleme endale veel jätnud.

Siin mainin kohe, et käsitleme VictoriaMetrics'i mõõdikute salvestusruumina. Kuna pakume tõenäoliselt VictoriaMetrics'i salvestusruumina kogu Leroy'le, peame piirama neid, kes seda klastrit kasutavad, et nad seda meile mitte kinni keeraks.

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

Samuti on olemas suurepärane valik, mis võimaldab piirata mälutarbimist, tänu millele saame leida tasakaalu, mis tagab normaalse töö kiirus ja mõistliku ressursikasutuse.

Veel üks miinus, st peale kriipsutame punkti - mälutarbimist ei saa piirata.

Esimestes iteratsioonides katsetasime VictoriaMetrics Single Node'i. Edasi liikume VictoriaMetrics Cluster versiooni juurde.

Siin on meil avatud käed erinevate teenuste hajutamiseks VictoriaMetricsis, sõltuvalt sellest, mis neid käitama hakkab ja milliseid ressursse need kasutavad. See on väga paindlik ja mugav lahendus. Oleme seda ise kasutanud.

VictoriaMetrics Cluster versiooni peamised komponendid on vmstorage. Neid võib olla N arv. Meie korral on neid hetkel kaks.

Ja on olemas vminsert. See on vahe-server, mis võimaldab meil: korraldada shardimist kõigi nende storage'ide vahel, kellest me talle rääkisime, ja see võimaldab ka replikatsiooni, st teil on nii shardimine kui ka replikatsioon.

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

On olemas ka vmselect. Selle peamine ülesanne on külastada vmstorage'i, saada sealt andmed, dedupeerida need andmed ja anda need klientidele.

On olemas suurepärane asi nimelt vmagent. Meile see väga meeldib. See võimaldab konfigureerida täpselt nagu Prometheus ja samas teha kõike täpselt nagu Prometheus. St see kogub erinevatelt objektidelt, teenustelt mõõdikud ja saadab need vminsert'i. Edasi sõltub kõik juba teistest.

Veel üks suurepärane teenus on vmalert, mis võimaldab kasutada taustteenusena VictoriaMetrics'i, saada andmeid vminsert'ilt ja saata neid vmselect'ile töödeldud andmete vormis. See käsitleb nii alarme kui ka reegleid. Alarmide korral saame meie alarmi läbi alertmanager'i.

On olemas komponent wmauth. Meil on see võib-olla kasutusele võtmiseks, aga võib-olla ka mitte (me pole sellega veel kindlaks teinud) multitenancy klastrite versiooni autoriseerimissüsteemina. See toetab remoteWrite'i Prometheuse jaoks ja võib autoriseerida url'i põhjal, täpsemalt selle teise osa põhjal, kuhu teil on lubatud või keelatud kirjutada.

On olemas ka vmbackup, vmrestore. Need on tegelikult kõigi andmete taastamine ja varukoopia tegemine. Toetab S3, GCS, fail.

Meie klastrite esimene iteratsioon toimus karantiini ajal. Sel hetkel ei olnud replikatsiooni, nii et meie iteratsioon koosnes kahest erinevast ja iseseisvast klastrist, kust saime remoteWrite'i kaudu andmeid.

Siinkohal olgu märgitud, et kui me läksime üle VictoriaMetrics Single Node'ilt VictoriaMetrics Cluster Versionile, jäime me ikkagi samadele tarbimisressurssidele, st peamine on mälu. Umbes selliselt jaotusid meie andmed, st ressursside tarbimine.

Siin oli juba lisatud replika. Koondasime kõik selle ühe suhteliselt suure klastrina. Kõik meie andmed jagunevad ja replikatsioon toimub.

Kogu klastril on N sisenemise punkti, st Prometheus saab andmeid lisada läbi HAPROXY. Siin on meie sisenemise punkt. Ja selle sisenemispunkti kaudu saab siseneda Grafanasse.

Meie puhul on HAPROXY ainus port, mis edastab select, insert ja teised teenused sisse selle klastrisse. Meie puhul ei olnud võimalik luua ühte aadressi, pidime looma mitu sisenemispunkti, kuna VictoriaMetrics klastrit haldavad virtuaalmasinad asuvad erinevates meie pilvepakkuja tsoonides, st mitte meie pilves, vaid väljas.

Meil on häirete süsteem. Me kasutame seda. Kasutame alertmanagerit Prometheuse poolt. Häirete edastuskanalina kasutame Opsgeniet ja Telegrami. Telegrami kaudu tulevad teated arendajatelt, võib-olla ka midagi tootmisest, kuid rohkem on seal statistilisi andmeid, mis on inseneridele vajalikud. Opsgenie puhul on see kriitiline. Need on telefonikõned, juhtimine intsidentide puhul.

Igavene küsimus: "Kwho monitors the monitoring?". Meie puhul jälgib jälgimist monitoring ise, kuna kasutame vmagent'i igas sõlmes. Kuna meie sõlmed on erinevates andmekeskustes ühe pakkuja juures, siis igas andmekeskuses on meil oma kanal ja need on iseseisvad, isegi kui peaks tulema split brain, saame siiski häireid. Jah, neid tuleb rohkem, aga parem saada rohkem häireid kui mitte ühtegi.

Lõpetame meie nimekirja HA rakendamisega.

Ja veel tahaksin rõhutada oma kogemust VictoriaMetrics kogukonnaga. See on olnud väga positiivne. Mehed on abivalmid. Nad püüavad süübida igasse juhtumisse, mis esitatakse.

Olen avanud küsimusi GitHubis. Need lahendati väga kiiresti. On veel mõned küsimused, mis ei ole täielikult suletud, kuid juba koodist näen, et selle suunas töötamine käib.

Peamine valu iteratsioonide ajal minu jaoks oli see, et kui ma node'i välja lülitasin, siis esimese 30 sekundi jooksul ei suutnud vminsert mõista, et backend'i ei ole. See on nüüd juba lahendatud. Ja sõna otseses mõttes ühe või kahe sekundi jooksul saadakse andmed kõikidest ülejäänud node'idest ning päring lõpetab ooteaja selle puuduvate node'i ees.

Me tahtsime mingil hetkel, et see oleks VictoriaMetrics'i operaator. Me ootasime seda. Praegu töötab meil aktiivselt VictoriaMetrics'i operaatori kohalike kohanduste loomine, et võtta kõik eel-arvutamisreeglid jne. Prometheus, kuna me kasutame piisavalt aktiivselt reegleid, mis tulevad koos Prometheuse operaatoriga.

On ettepanekuid klastrite rakenduse parandamiseks. Esitasin need eelnevalt.

Ja väga tahaks downsampling'ut. Meie puhul on downsampling vajalik ainult trendide vaatamiseks. Ütleme nii, et ühe mõõdiku kohta piisab päevaseks kasutamiseks. Need trendid vajavad vaatamist aastaks, kolmeks, viieks, kümneks aastaks. Ja ühe mõõdiku väärtus on täiesti piisav.

• Me olime kogenud valu, nagu ka mõned meie kolleegid, Prometheuse kasutamisel.
• Me valisime endale VictoriaMetrics'i.
• See skaleerub üsna hästi nii vertikaalselt kui ka horisontaalselt.
• Saame erinevad komponendid jagada erinevate node'ide vahel klastris, piirata neid mälumahtude järgi, lisada mälu jne.

Kasutame VictoriaMetrics'i, kuna see meeldis meile väga. Siin on, mis oli ja mis on nüüd.

https://t.me/VictoriaMetrics_ru1

Mõned QR-koodid VictoriaMetrics'i chati jaoks, minu kontaktid, LeroyMerlin'i tehnoloogiaradar.

Allikas: habr.com