VictoriaMetrics je brz i skalabilan DBMS za pohranjivanje i obradu podataka u obliku vremenske serije (zapis se sastoji od vremena i skupa vrijednosti koje odgovaraju tom vremenu, npr. dobivenih periodičnim ispitivanjem statusa senzora ili zbirka metrike).
Moje ime je Kolobaev Pavel. DevOps, SRE, LeroyMerlin, sve je kao kod - sve je o nama: o meni i o drugim zaposlenicima LeroyMerlina.
Postoji oblak temeljen na OpenStacku. Postoji mala veza s tehničkim radarom.
Izgrađen je na hardveru Kubernetes, kao i na svim povezanim servisima za OpenStack i logiranje.
Ovo je shema koju smo imali u razvoju. Kada smo sve to razvijali, imali smo Prometheus operatora koji je podatke spremao unutar samog K8s klastera. Automatski nađe što treba izribati i stavi pod noge, grubo rečeno.
Morat ćemo premjestiti sve podatke izvan Kubernetes klastera, jer ako se nešto dogodi, moramo razumjeti što i gdje.
Prvo rješenje je da koristimo federaciju kada imamo Prometheus treće strane, kada idemo u Kubernetes klaster kroz mehanizam federacije.
Ali tu postoje neki mali problemi. U našem slučaju problemi su počeli kada smo imali 250 metrika, a kada je bilo 000 metrika, shvatili smo da ne možemo tako raditi. Povećali smo scrape_timeout na 400 sekundi.
Zašto smo to morali učiniti? Prometej počinje brojati timeout od početka ograde. Nije važno što podaci i dalje teku. Ako se tijekom navedenog vremenskog razdoblja podaci ne spoje i sesija ne zatvori putem http-a, tada se sesija smatra neuspješnom i podaci ne ulaze u sam Prometheus.
Svima su poznati grafovi koje dobijemo kada neki podaci nedostaju. Rasporedi su poremećeni i nismo zadovoljni s tim.
Sljedeća opcija je dijeljenje temeljeno na dva različita Prometheusa kroz isti mehanizam federacije.
Na primjer, samo ih uzmite i podijelite po imenu. I ovo se može koristiti, ali mi smo odlučili krenuti dalje.
Sad ćemo te krhotine morati nekako obraditi. Možete uzeti promxy, koji ide u područje krhotina i umnožava podatke. Radi s dva sharda kao jednom ulaznom točkom. Ovo se može implementirati kroz promxy, ali je još uvijek preteško.
Prva opcija je da želimo napustiti mehanizam federacije jer je jako spor.
Programeri Prometheusa jasno poručuju: "Društvo, koristite drugu TimescaleDB jer nećemo podržavati dugoročnu pohranu metrike." To nije njihov zadatak.
Zapisujemo na papirić da još moramo istovariti vani, da ne skladištimo sve na jednom mjestu.
Drugi nedostatak je potrošnja memorije. Da, razumijem da će mnogi reći da u 2020. par gigabajta memorije košta lipe, ali ipak.
Sada imamo razvojno i proizvodno okruženje. U dev-u je oko 9 gigabajta za 350 000 metrika. U proizvodnoj verziji ima 14 gigabajta i nešto više od 780 000 metrika. U isto vrijeme, naše vrijeme zadržavanja je samo 30 minuta. To je loše. A sada ću objasniti zašto.
Izrađujemo izračun, odnosno s milijun i pol metrika, a već smo im blizu, u fazi projektiranja dobivamo 35-37 gigabajta memorije. Ali već 4 milijuna metrika zahtijeva oko 90 gigabajta memorije. Odnosno, izračunato je pomoću formule koju su dali programeri Prometheusa. Pogledali smo korelaciju i shvatili da ne želimo platiti nekoliko milijuna za server samo za nadzor.
Ne samo da ćemo povećati broj strojeva, već pratimo i same virtualne strojeve. Dakle, što više virtualnih strojeva, to više metrika raznih vrsta itd. Imat ćemo poseban rast našeg klastera u metričkom smislu.
S prostorom na disku ovdje nije sve tako loše, ali volio bih ga poboljšati. Dobili smo ukupno 15 gigabajta u 120 dana, od toga 100 komprimiranih podataka, 20 nekomprimiranih podataka, ali uvijek želimo manje.
Sukladno tome, zapisujemo još jednu točku - to je velika potrošnja resursa, koju ipak želimo uštedjeti, jer ne želimo da naš klaster za praćenje troši više resursa od našeg klastera koji upravlja OpenStackom.
Postoji još jedan nedostatak Prometheusa, koji smo sami identificirali, to je barem neka vrsta ograničenja pamćenja. S Prometejem je ovdje sve mnogo gore, jer uopće nema takvih zaokreta. Korištenje ograničenja u dockeru također nije opcija. Ako je vaš RAF iznenada pao i ima 20-30 gigabajta, tada će trebati jako dugo vremena da poraste.
To je još jedan razlog zašto Prometheus nije prikladan za nas, tj. ne možemo ograničiti potrošnju memorije.
Bilo bi moguće smisliti takvu shemu. Ova nam je shema potrebna kako bismo organizirali HA klaster. Želimo da naše metrike budu dostupne uvijek i svugdje, čak i ako se poslužitelj koji pohranjuje te metrike sruši. I stoga ćemo morati izgraditi takvu shemu.
Ova shema kaže da ćemo imati dupliciranje šardova, a time i dupliciranje troškova potrošenih resursa. Može se skalirati gotovo horizontalno, ali svejedno će potrošnja resursa biti paklena.
Mane redom u obliku u kojem smo ih sami zapisali:
- Zahtijeva prijenos mjernih podataka izvana.
- Velika potrošnja resursa.
- Ne postoji način da se ograniči potrošnja memorije.
- Složena i resursno intenzivna implementacija HA.
Za sebe smo odlučili da se maknemo od Prometeja kao skladišta.
Identificirali smo dodatne zahtjeve za sebe koji su nam potrebni. Ovaj:
- Ovo je podrška za promql, jer je puno toga već napisano za Prometheus: upiti, upozorenja.
- A onda imamo Grafanu, koja je već napisana na potpuno isti način za Prometheus kao backend. Ne želim ponovno pisati nadzorne ploče.
- Želimo izgraditi normalnu HA arhitekturu.
- Želimo smanjiti potrošnju svih resursa.
- Postoji još jedna mala nijansa. Ne možemo koristiti različite vrste sustava za prikupljanje podataka u oblaku. Još ne znamo što će ući u ove metrike. A kako tamo sve može letjeti, moramo se ograničiti na lokalni plasman.
Bilo je malo izbora. Prikupili smo sve s čime smo imali iskustva. Pogledali smo Prometheusovu stranicu u odjeljku o integraciji, pročitali hrpu članaka i vidjeli što je vani. A za sebe smo odabrali VictoriaMetrics kao zamjenu za Prometheus.
Zašto? Jer:
- Poznaje promql.
- Postoji modularna arhitektura.
- Ne zahtijeva promjene na Grafanu.
- I što je najvažnije, vjerojatno ćemo osigurati pohranu metrike unutar naše tvrtke kao uslugu, tako da unaprijed gledamo na ograničenja raznih vrsta kako bi korisnici mogli koristiti sve resurse klastera na neki ograničeni način, jer postoji šansa da će višestanarstvo.
Napravimo prvu usporedbu. Uzimamo istog Prometeja unutar klastera, vanjski Prometej ide do njega. Dodajte putem remoteWrite VictoriaMetrics.
Odmah ću reći da smo ovdje uhvatili blagi porast potrošnje CPU-a od VictoriaMetrics. VictoriaMetrics wiki govori vam koji su parametri najbolji. Provjerili smo ih. Vrlo su dobro smanjili potrošnju CPU-a.
U našem slučaju, potrošnja memorije Prometheusa, koji se nalazi u Kubernetes klasteru, nije značajno porasla.
Uspoređujemo dva izvora podataka istih podataka. U Prometeju vidimo iste podatke koji nedostaju. U VictoriaMetricsu je sve u redu.
Rezultati testa prostora na disku. Mi u Prometeju dobili smo ukupno 120 gigabajta. U VictoriaMetricsu već primamo 4 gigabajta dnevno. Postoji nešto drugačiji mehanizam od onoga što smo navikli vidjeti u Prometeju. Odnosno, podaci se već dosta dobro komprimiraju u danu, u pola sata. Već su dobro požnjeveni za dan, za pola sata, unatoč tome što će se podaci kasnije ipak izgubiti. Kao rezultat toga, uštedjeli smo na prostoru na disku.
Također štedimo na potrošnji memorijskih resursa. U vrijeme testiranja imali smo Prometheus postavljen na virtualnom stroju - 8 jezgri, 24 gigabajta. Prometej jede gotovo sve. Pao je na OOM ubojicu. Istovremeno je u njega uliveno samo 900 aktivnih metrika. To je oko 000-25 metrika u sekundi.
Pokrenuli smo VictoriaMetrics na virtualnom stroju s dvije jezgre i 8 gigabajta RAM-a. Uspjeli smo natjerati VictoriaMetrics da dobro radi petljajući oko nekoliko stvari na stroju od 8 GB. Na kraju smo ga zadržali na 7 gigabajta. Pritom je brzina isporuke sadržaja, odnosno metrike, bila čak i veća od one kod Prometheusa.
CPU je postao puno bolji u usporedbi s Prometheusom. Ovdje Prometheus troši 2,5 jezgre, a VictoriaMetrics samo 0,25 jezgri. U početku – 0,5 jezgri. Kako se spaja, dolazi do jedne jezgre, ali to je iznimno, iznimno rijetko.
U našem slučaju, izbor je pao na VictoriaMetrics iz očitih razloga; htjeli smo uštedjeti novac i jesmo.
Odmah prekrižimo dvije točke - učitavanje metrike i veliku potrošnju resursa. A još samo moramo odlučiti o dva boda koja su nam još ostala.
Ovdje ću odmah rezervirati, VictoriaMetrics smatramo skladištem metrike. Ali budući da ćemo najvjerojatnije osigurati VictoriaMetrics kao pohranu za cijeli Leroy, moramo ograničiti one koji će koristiti ovaj klaster kako nam ga ne bi dali.
Postoji prekrasan parametar koji vam omogućuje da ga ograničite vremenom, količinom podataka i vremenom izvršenja.
Postoji i izvrsna opcija koja nam omogućuje da ograničimo potrošnju memorije, čime možemo pronaći ravnotežu koja će nam omogućiti normalnu radnu brzinu i odgovarajuću potrošnju resursa.
Minus još jedan bod, tj. prekriži točku - ne možete ograničiti potrošnju memorije.
U prvim smo iteracijama testirali VictoriaMetrics Single Node. Zatim prelazimo na verziju klastera VictoriaMetrics.
Ovdje imamo odriješene ruke za odvajanje različitih usluga u VictoriaMetrics ovisno o tome na čemu će raditi i koje resurse će trošiti. Ovo je vrlo fleksibilno i praktično rješenje. Koristili smo ovo na sebi.
Glavne komponente VictoriaMetrics Cluster Version su vmstsorage. Može ih biti N broj. U našem slučaju ih je do sada 2.
A tu je i vminsert. Ovo je proxy poslužitelj koji nam omogućuje da: dogovorimo sharding između svih pohrana o kojima smo govorili, a omogućuje i repliku, tj. imat ćete i sharding i repliku.
Vminsert podržava OpenTSDB, Graphite, InfluxDB i protokole remoteWrite iz Prometheusa.
Tu je i vmselect. Njegov glavni zadatak je otići na vmstorage, primiti podatke od njih, deduplicirati te podatke i dati ih klijentu.
Postoji divna stvar koja se zove vmagent. Jako nam se sviđa. Omogućuje vam da konfigurirate točno kao Prometheus, a opet sve radite točno kao Prometheus. Odnosno, prikuplja metrike od različitih entiteta i usluga i šalje ih u vminsert. Onda sve ovisi o vama.
Još jedna sjajna usluga je vmalert, koja vam omogućuje da koristite VictoriaMetrics kao backend, primate obrađene podatke od vminsert i šaljete ih vmselectu. Obrađuje sama upozorenja, kao i pravila. U slučaju upozorenja, primamo upozorenje putem alertmanagera.
Postoji wmauth komponenta. Možemo ili ne (o tome još nismo odlučili) koristiti ga kao autorizacijski sustav za višenamjensku verziju klastera. Podržava remoteWrite za Prometheus i može autorizirati na temelju url-a, odnosno njegovog drugog dijela, gdje možete ili ne možete pisati.
Tu je i vmbackup, vmrestore. To je, u biti, vraćanje i backup svih podataka. Može raditi S3, GCS, datoteku.
Prva iteracija našeg klastera napravljena je tijekom karantene. U to vrijeme nije bilo replike, pa se naša iteracija sastojala od dva različita i neovisna klastera u koje smo primali podatke putem remoteWrite-a.
Ovdje ću reći da smo, kada smo se prebacili s VictoriaMetrics Single Node na VictoriaMetrics Cluster Version, i dalje ostali s istim potrošenim resursima, tj. glavni je memorija. Otprilike tako su raspoređeni naši podaci, odnosno potrošnja resursa.
Ovdje je već dodana replika. Sve smo to spojili u jedan relativno veliki klaster. Svi naši podaci su podijeljeni i replicirani.
Cijeli klaster ima N ulaznih točaka, što znači da Prometheus može dodavati podatke putem HAPROXY-a. Ovdje imamo ovu ulaznu točku. I preko ove ulazne točke možete se prijaviti iz Grafana.
U našem slučaju, HAPROXY je jedini port koji proxy odabire, ubacuje i druge usluge unutar ovog klastera. U našem slučaju bilo je nemoguće napraviti jednu adresu, morali smo napraviti nekoliko ulaznih točaka, jer se same virtualne mašine na kojima radi VictoriaMetrics klaster nalaze u različitim zonama istog cloud providera, tj. ne unutar našeg oblaka, već izvan njega. .
Imamo uzbunu. Mi ga koristimo. Koristimo alertmanager iz Prometheusa. Koristimo Opsgenie i Telegram kao kanal za isporuku upozorenja. U Telegram ulijeću iz dev-a, možda nešto iz prod-a, ali uglavnom nešto statističko, potrebno inženjerima. I Opsgenie je kritičan. To su pozivi, upravljanje incidentima.
Vječno pitanje: “Tko prati monitoring?” U našem slučaju, nadzor nadzire sam nadzor jer koristimo vmagent na svakom čvoru. A budući da su naši čvorovi raspoređeni po različitim podatkovnim centrima istog pružatelja usluga, svaki podatkovni centar ima vlastiti kanal, neovisni su, pa čak i ako dođe podijeljeni mozak, i dalje ćemo primati upozorenja. Da, bit će ih više, ali bolje je primati više upozorenja nego nijedno.
Naš popis završavamo implementacijom HA.
I dalje bih želio napomenuti iskustvo komunikacije sa zajednicom VictoriaMetrics. Ispalo je vrlo pozitivno. Dečki reagiraju. Trude se udubiti u svaki ponuđeni slučaj.
Započeo sam probleme na GitHubu. Vrlo brzo su riješeni. Ima još par problema koji nisu u potpunosti riješeni, ali već po kodu vidim da je rad u tom smjeru u tijeku.
Glavni problem za mene tijekom iteracija bio je taj što, ako isključim čvor, prvih 30 sekundi vminsert nije mogao shvatiti da nema pozadine. Ovo je sada odlučeno. I doslovno u sekundi ili dvije, podaci se uzimaju iz svih preostalih čvorova, a zahtjev prestaje čekati taj čvor koji nedostaje.
U nekom smo trenutku htjeli da VictoriaMetrics bude VictoriaMetrics operater. Čekali smo ga. Sada aktivno gradimo okvir za operator VictoriaMetrics koji preuzima sva pravila predračunanja, itd. Prometheus, jer prilično aktivno koristimo pravila koja dolaze s operatorom Prometheus.
Postoje prijedlozi za poboljšanje implementacije klastera. Naveo sam ih gore.
I stvarno želim smanjiti uzorkovanje. U našem slučaju, downsampling je potreban isključivo za gledanje trendova. Ugrubo rečeno, dovoljna mi je jedna metrika tijekom dana. Ovi trendovi su potrebni za godinu, tri, pet, deset godina. I jedna metrička vrijednost je sasvim dovoljna.
- Poznavali smo bol, kao i neki naši kolege, kada smo koristili Prometheus.
- Za sebe smo odabrali VictoriaMetrics.
- Prilično se skalira i okomito i vodoravno.
- Možemo distribuirati različite komponente na različite brojeve čvorova u klasteru, ograničiti ih memorijom, dodati memoriju itd.
Doma ćemo koristiti VictoriaMetrics jer nam se jako svidio. To je ono što je bilo i što je postalo.
Nekoliko QR kodova za VictoriaMetrics chat, moje kontakte, LeroyMerlin tehnički radar.
Izvor: www.habr.com