VictoriaMetrics on kiire ja skaleeritav DBMS andmete salvestamiseks ja töötlemiseks aegridade kujul (kirje moodustab aja ja sellele ajale vastava väärtuste komplekti, mis saadakse näiteks andurite oleku perioodilise küsitluse kaudu või mõõdikute kogumine).
Minu nimi on Pavel Kolobaev. DevOps, SRE, LeroyMerlin, kõik on nagu kood – see kõik puudutab meid: minus ja teistes LeroyMerlini töötajates.
Seal on OpenStackil põhinev pilv. Seal on väike link tehnilise radari juurde.
See on üles ehitatud Kubernetese raua baasil, aga ka kõigil OpenStacki ja logimisega seotud teenustel.
See on skeem, mis meil väljatöötamisel oli. Kui me seda kõike arendasime, oli meil Prometheuse operaator, mis salvestas andmed K8s klastri enda sees. Ta leiab automaatselt üles, mis vajab nühkimist ja paneb selle jämedalt öeldes jalge alla.
Peame kõik andmed Kubernetese klastrist väljapoole teisaldama, sest kui midagi juhtub, siis peame aru saama, mis ja kus.
Esimene lahendus on föderatsiooni kasutamine, kui meil on kolmas osapool Prometheus, kui läheme föderatsioonimehhanismi kaudu Kubernetese klastrisse.
Kuid siin on mõned väikesed probleemid. Meie puhul algasid probleemid siis, kui meil oli 250 000 mõõdikut ja kui sellest sai 400 000 mõõdikut, mõistsime, et me ei saa niimoodi töötada. Oleme suurendanud scrape_timeout 25 sekundini.
Miks me pidime seda tegema? Prometheus hakkab ajalõpu lugema pealevõtuhetke algusest. Vahet pole, et andmeid ikka kallab. Kui selle kindlaksmääratud aja jooksul ei ole andmed liidetud ja seanssi ei suleta http kaudu, siis loetakse seanss nurjunuks ja andmed Prometheusesse endasse ei satu.
Kõik teavad graafikuid, mille saame, kui osa andmetest on puudu. Graafika on rebenenud ja me ei ole sellega rahul.
Järgmine võimalus on kahe erineva Prometheuse jagamine sama föderatsioonimehhanismi kaudu.
Näiteks võtke need lihtsalt nime järgi. Seda saab ka kasutada, kuid otsustasime edasi liikuda.
Nüüd peame neid kilde kuidagi töötlema. Võite võtta promxy, mis laskub killu piirkonda, korrutab andmed. See töötab kahe killuga ühe sisestuspunktina. Seda saab rakendada promksi kaudu, kuid see on praegu liiga keeruline.
Esimene võimalus – tahame föderatsioonimehhanismist loobuda, kuna see on väga aeglane.
Prometheuse arendajad ütlevad selgesõnaliselt: "Poisid, kasutage muud TimescaleDB-d, sest me ei toeta mõõdikute pikaajalist salvestamist." See pole nende ülesanne.
Kirjutame paberile, et väljas on vaja veel maha laadida, et mitte kõike ühte kohta laduda.
Teine puudus on mälu tarbimine. Jah, ma saan aru, et paljud ütlevad, et aastal 2020 on paar gigabaiti mälu väärt senti, aga sellest hoolimata.
Nüüd on meil arendus- ja tootekeskkond. Arenduses on see umbes 9 gigabaiti 350 000 mõõdiku kohta. Tootmisversioonis on see 14 gigabaiti väikese 780 000 mõõdikuga. Samal ajal on meil ainult 30 minutit säilitusaega. See on halb. Ja nüüd ma selgitan, miks.
Teeme arvutuse ehk pooleteise miljoni mõõdikuga ja oleme neile juba lähedal, projekteerimisetapis saame 35-37 gigabaiti mälu. Kuid juba 4 miljoni meetri võrra on juba vaja umbes 90 gigabaiti mälu. See tähendab, et see arvutati Prometheuse arendajate esitatud valemi järgi. Vaatasime korrelatsiooni ja saime aru, et me ei taha serveri eest paari miljonit maksta ainult jälgimise eest.
Me mitte ainult ei suurenda masinate arvu, vaid jälgime ka virtuaalseid masinaid endid. Seega, mida rohkem virtuaalmasinaid, seda rohkem on erinevat tüüpi mõõdikuid jne. Meil on meie klastri mõõdikute osas eriline kasv.
Kettaruumiga pole siin kõik nii kurb, kuid tahaksin seda parandada. Kokku saime 15 päevaga 120 gigabaiti, millest 100 on tihendatud andmeid, 20 on tihendamata andmeid, aga alati tahad vähem.
Sellest lähtuvalt kirjutame veel ühe punkti - see on suur ressursside tarbimine, mida tahame siiski säästa, sest me ei taha, et meie jälgimisklaster sööks rohkem ressursse kui meie klaster, mis haldab OpenStacki.
Üks Prometheuse miinus on veel, mille oleme enda jaoks tuvastanud, see on vähemalt mingi mälupiirang. Prometheusega on siin kõik palju hullem, sest tal pole selliseid keerdkäike üldse. Dockeri piirangu kasutamine pole samuti võimalik. Kui äkki on teie RAF kukkunud ja seal on 20-30 gigabaiti, siis kulub selle tõusmiseks väga kaua aega.
See on veel üks põhjus, miks Prometheus meile ei sobi, st me ei saa piirata mälutarbimist.
Selline skeem oleks võimalik välja mõelda. Seda skeemi vajame HA klastri korraldamiseks. Soovime, et meie mõõdikud oleksid saadaval igal ajal ja igal pool, isegi kui neid mõõdikuid salvestav server jookseb kokku. Ja seega peame sellise skeemi üles ehitama.
See skeem ütleb, et meil tekivad killud ja vastavalt ka tarbitud ressursside kulud. Seda saab peaaegu horisontaalselt mõõta, kuid sellest hoolimata on ressursside tarbimine põrgulik.
Puudused järjekorras sellisel kujul, nagu me need enda jaoks välja kirjutasime:
- Nõuab mõõdikute üleslaadimist väljapoole.
- Suur ressursside tarbimine.
- Mälu tarbimist ei saa piirata.
- HA keeruline ja ressursimahukas rakendamine.
Enda jaoks otsustasime, et eemaldume Prometheusest kui hoidlast.
Oleme enda jaoks välja selgitanud täiendavad nõuded, mida vajame. See:
- See on promql tugi, sest Prometheuse jaoks on juba palju asju kirjutatud: päringud, märguanded.
- Ja siis on meil Grafana, mis on juba samamoodi Prometheuse all taustaprogrammiks kirjutatud. Ma ei taha armatuurlaudu ümber kirjutada.
- Tahame ehitada normaalse HA arhitektuuri.
- Soovime vähendada igasuguste ressursside tarbimist.
- On veel üks väike nüanss. Me ei saa mõõdikute kogumiseks kasutada mitmesuguseid pilvesüsteeme. Me ei tea praegu, mis nendesse mõõdikutesse lendab. Ja kuna sinna võib lennata kõike, peame piirduma kohaliku paigutusega.
Valik oli väike. Oleme kokku kogunud kõik, mille kohta meil oli kogemusi. Vaatasime Prometheuse lehte integratsiooni rubriigis, lugesime hunnikut artikleid, vaatasime, mis on üldiselt saadaval. Ja enda jaoks valisime Prometheuse asendajaks VictoriaMetricsi.
Miks? Sest:
- Võimeline promql.
- Seal on modulaarne arhitektuur.
- Grafana muutmist ei nõua.
- Ja mis kõige tähtsam, pakume ilmselt teenusena ka mõõdikute salvestamist oma ettevõtte sees, seega vaatame juba ette erinevaid piiranguid, et kasutajad saaksid kasutada kõiki klastri ressursse mingil piiratud viisil, sest seal on võimalus, et tegemist on mitme üürilepinguga.
Teeme esimese võrdluse. Me võtame sama Prometheuse klastri sisse, väline Prometheus läheb sinna. Lisame remoteWrite VictoriaMetricsi kaudu.
Ma teen kohe reservatsiooni, et siin saime VictoriaMetricsilt CPU tarbimise väikese kasvu. VictoriaMetricsi wiki ütleb, millised parameetrid sobivad kõige paremini. Kontrollisime neid. Nad vähendasid väga hästi protsessori tarbimist.
Meie puhul Kubernetese klastris paikneva Prometheuse mälutarbimine oluliselt ei suurenenud.
Võrdleme kahte samade andmete andmeallikat. Prometheuses näeme kõiki samu puuduvaid andmeid. VictoriaMetricsis on kõik hästi.
Kettaruumiga tehtud testide tulemused. Meie Prometheus saime kokku 120 gigabaiti. VictoriaMetricsis saame juba 4 gigabaiti päevas. Seal on veidi teistsugune mehhanism kui see, mida olete harjunud nägema Prometheuses. See tähendab, et andmed on juba päris korralikult kokku surutud päevaks, pooleks tunniks. Neid lõigatakse juba tublisti päevaga, poole tunniga, hoolimata sellest, et hiljem hakatakse andmeid liitma. Selle tulemusena säästsime kettaruumi.
Samuti hoiame kokku mäluressursside tarbimise pealt. Testide ajal oli meil Prometheus kasutusele võetud virtuaalses masinas – 8 tuuma, 24 gigabaiti. Prometheus sööb peaaegu kõike. Ta kukkus OOM Killerile. Samal ajal valati sinna vaid 900 000 aktiivset mõõdikut. See on umbes 25 000–27 000 meetrit sekundis.
VictoriaMetrics töötas kahetuumalises virtuaalmasinas, millel oli 8 gigabaiti muutmälu. Meil õnnestus panna VictoriaMetrics hästi tööle, muutes 8 GB masinas mõnda asja. Selle tulemusel hoidsime 7 gigabaidi piires. Samal ajal saime sisu edastamise kiiruse ehk mõõdikud veelgi suuremaks kui Prometheusel.
CPU on palju parem kui Prometheus. Siin tarbib Prometheus 2,5 tuuma ja VictoriaMetrics ainult 0,25 tuuma. Alguses - 0,5 südamikku. Ühinedes jõuab see ühe tuumani, kuid see on äärmiselt, äärmiselt haruldane.
Meie puhul langes valik arusaadavatel põhjustel VictoriaMetricsile, tahtsime raha säästa ja säästsime.
Kriipsutame kohe maha kaks punkti – see on mõõdikute mahalaadimine ja suur ressursside kulu. Ja meie otsustada jääb kaks punkti, mis me ikkagi endale jätsime.
Siin ma teen kohe broneeringu, me peame VictoriaMetricsi mõõdikute hoidlaks. Kuid kuna suure tõenäosusega pakume VictoriaMetricsi kogu Leroy salvestusruumina, peame piirama neid, kes seda klastrit kasutavad, et nad seda meile ei paneks.
Seal on suurepärane parameeter, mis võimaldab teil piirata aja, andmemahu ja täitmisaja järgi.
Ja seal on ka suurepärane võimalus, mis võimaldab teil piirata mälutarbimist, nii et leiame just selle tasakaalu, mis võimaldab meil saavutada normaalse kiiruse ja piisava ressursikulu.
Miinus veel üks punkt, see tähendab, et kriipsutame punkti läbi - te ei saa mälutarbimist piirata.
Esimestel iteratsioonidel testisime VictoriaMetricsi ühtset sõlme. Järgmisena liigume edasi VictoriaMetricsi klastri versiooni juurde.
Siin on meil vabad käed VictoriaMetricsis erinevate teenuste eraldamise teemal, olenevalt sellest, mida need kasutavad ja milliseid ressursse tarbivad. See on väga paindlik ja mugav lahendus. Oleme seda ise kasutanud.
VictoriaMetricsi klastri versiooni põhikomponendid on vmstsorage. Seal võib olla N number. Meie puhul on neid 2.
Ja seal on vminsert. See on puhverserver, mis võimaldab meil: korraldada jagamist kõigi salvestuste vahel, millest me talle rääkisime, ja see võimaldab teist replikat, st teil on nii jagamine kui ka koopia.
Vminsert toetab Prometheuse OpenTSDB, Graphite, InfluxDB ja remoteWrite protokolle.
Samuti on olemas vmselect. Selle põhiülesanne on minna vmstorage'i, hankida neilt andmed, deduping need andmed ja anda need kliendile.
On olemas selline imeline asi nagu vmagent. Ta meeldib meile väga. See võimaldab teil konfigureerida täpselt nagu Prometheus ja teha kõike nagu Prometheus. See tähendab, et see kogub erinevatelt üksustelt ja teenustelt mõõdikuid ning saadab need vminserti. Siis sõltub kõik teist.
Teine suurepärane teenus on vmalert, mis võimaldab kasutada VictoriaMetricsi taustaprogrammina, saada töödeldud andmeid vminserdist ja saata töödeldud andmeid vmselectile. See töötleb nii hoiatusi kui ka reegleid. Märguannete korral saame hoiatuse häirehalduri kaudu.
Seal on wmauthi komponent. Tõenäoliselt kasutame seda ja võib-olla mitte (me pole seda veel otsustanud) klastrite mitme üürimise versiooni autoriseerimissüsteemina. See toetab Prometheuse jaoks remoteWrite'i ja saab autoriseerida URL-i või õigemini selle teise osa alusel, kuhu saab kirjutada või mitte.
Samuti on olemas vmbackup, vmrestore. See on tegelikult kõigi andmete taastamine ja varundamine. Võimaldab S3, GCS, faili.
Meie klastri esimene iteratsioon tehti karantiini ajal. Sel ajal replikat ei olnud, seega koosnes meie iteratsioon kahest erinevast ja sõltumatust klastrist, millesse saime andmed remoteWrite'i kaudu.
Siinkohal teen reservatsiooni, et VictoriaMetrics Single Node'ilt VictoriaMetrics Cluster Versionile üle minnes jäime ikkagi samasse tarbitud ressurssi, st põhiline on mälu. Ligikaudu sellisel viisil jaotati meie andmed, st ressursitarbimine.
Siia on juba lisatud koopia. Oleme kõik selle ühendanud üheks suhteliselt suureks klastriks. Kõik andmed on nii killustatud kui ka paljundatud.
Kogu klastris on N sisestuspunkti, st Prometheus saab andmeid lisada HAPROXY kaudu. Siin on meie sisenemispunkt. Ja selle sisenemispunkti kaudu saate Grafanaga sisse logida.
Meie puhul on HAPROXY ainus port, mis valib, sisestab ja muud teenused sellesse klastrisse. Meie puhul ei saanud ühte aadressi teha, tuli teha mitu sisenemispunkti, sest virtuaalmasinad ise, millel VictoriaMetricsi klaster töötab, asuvad sama pilveteenuse pakkuja erinevates tsoonides, st mitte meie pilve sees. , aga väljas.
Meil on hoiatus. Me kasutame seda. Kasutame Prometheuse alertmanagerit. Hoiatuste edastamise kanalina kasutame Opsgenie't ja Telegrami. Telegramis valavad need välja arendajast, võib-olla midagi tootest, aga pigem midagi statistikat, mida insenerid vajavad. Ja Opsgenie on kriitiline. Need on kõned, juhtumite juhtimine.
Igivana küsimus: "Kes jälgib seiret?". Meie puhul jälgib monitooring jälgimist ennast, kuna kasutame iga sõlme peal vmagenti. Ja kuna meie sõlmed asuvad sama pakkuja erinevates andmekeskustes, siis on igal andmekeskusel oma kanal, nad on sõltumatud ja isegi kui tuleb lõhenenud aju, saame hoiatusi ikkagi. Jah, neid tuleb rohkem, kuid parem on saada rohkem hoiatusi kui mitte ühtegi.
Lõpetame oma nimekirja HA rakendamisega.
Ja lisaks tahaksin märkida VictoriaMetricsi kogukonnaga suhtlemise kogemust. See osutus väga positiivseks. Poisid on vastutulelikud. Püütakse süveneda igasse pakutavasse juhtumisse.
Tegin GitHubis probleeme. Need lahenesid väga kiiresti. On veel paar probleemi, mis pole päris suletud, aga juba koodist näen, et töö selles suunas käib.
Peamine valu iteratsioonide ajal oli minu jaoks see, et kui ma sõlme maha lõikasin, siis esimesed 30 sekundit ei saanud vminsert aru, et backend puudub. Nüüd on see juba otsustatud. Ja sõna otseses mõttes sekundi või kahe pärast võetakse andmed kõigist ülejäänud sõlmedest ja päring lõpetab selle puuduva sõlme ootamise.
Tahtsime, et VictoriaMetrics oleks mingil hetkel VictoriaMetricsi operaator. Ootasime teda. Nüüd loome aktiivselt VictoriaMetricsi operaatorile sidumist, et võtta kõik eelarvutusreeglid jne. Prometheus, sest kasutame üsna aktiivselt Prometheuse operaatoriga kaasasolevaid reegleid.
On ettepanekuid klastri rakendamise parandamiseks. Olen neid eespool kirjeldanud.
Ja ma tahan väga ka allavõtet. Meie puhul on allavõtmist vaja ainult trendide vaatamiseks. Jämedalt öeldes piisab mulle päevast ühest mõõdikust. Neid trende on vaja aasta, kolm, viis, kümme aastat. Ja ühest mõõdiku väärtusest piisab.
- Oleme Prometheuse kasutamisel valu tundnud, nagu ka mõned meie kolleegid.
- Valisime enda jaoks VictoriaMetricsi.
- See mastaabib üsna hästi nii vertikaalselt kui ka horisontaalselt.
- Saame jaotada erinevaid komponente klastri erinevale arvule sõlmedele, piirata neid mälu osas, lisada mälu jne.
Kodus hakkame kasutama VictoriaMetricsi, sest meile väga meeldis. Siin on, mis juhtus ja mis juhtus.
Paar qr-koodi VictoriaMetricsi vestluse jaoks, minu kontaktid, LeroyMerlini tehniline radar.
Allikas: www.habr.com