VictoriaMetrics je brz i skalabilan DBMS za pohranjivanje i obradu podataka u obliku vremenske serije (zapis formira vrijeme i skup vrijednosti koje odgovaraju ovom vremenu, na primjer, dobivene periodičnim ispitivanjem statusa senzora ili prikupljanje metrike).
Moje ime je Pavel Kolobaev. DevOps, SRE, LeroyMerlin, sve je kao kod - sve je o nama: o meni i drugim zaposlenima LeroyMerlina.
Postoji oblak baziran na OpenStack-u. Postoji mala veza sa tehničkim radarom.
Izgrađen je na bazi Kubernetes gvožđa, kao i na svim povezanim servisima za OpenStack i logovanje.
Ovo je šema koju smo imali u razvoju. Kada smo sve ovo razvili, imali smo Prometheus operator, koji je čuvao podatke unutar samog klastera K8s. On automatski pronalazi šta treba da se izriba i stavlja pod noge, grubo rečeno.
Moraćemo da premestimo sve podatke van Kubernetes klastera, jer ako se nešto desi, onda moramo razumeti šta i gde.
Prvo rješenje je da koristimo federaciju kada imamo treće strane Prometheus kada idemo na Kubernetes klaster kroz mehanizam federacije.
Ali ovdje postoje neki manji problemi. U našem slučaju, problemi su počeli kada smo imali 250 metrika, a kada je postalo 000 metrika, shvatili smo da ne možemo tako raditi. Povećali smo scrape_timeout na 400 sekundi.
Zašto smo to morali da uradimo? Prometej počinje da računa vremensko ograničenje od početka trenutka preuzimanja. Nema veze što podaci i dalje pristižu. Ako se u ovom navedenom vremenskom periodu podaci nisu spojili i sesija nije zatvorena putem http, onda se smatra da je sesija neuspjela i podaci ne dolaze u sam Prometheus.
Svima su poznati grafikoni koje dobijamo kada dio podataka nedostaje. Grafika je pocepana i nismo zadovoljni njome.
Sljedeća opcija je dijeljenje zasnovano na dva različita Prometheusa putem istog mehanizma federacije.
Na primjer, samo ih uzmite i podijelite po imenu. Ovo se takođe može iskoristiti, ali odlučili smo da idemo dalje.
Sada ćemo morati nekako obraditi ove krhotine. Možete uzeti promxy, koji se spušta u područje krhotine, množi podatke. Radi sa dva komada kao jedna ulazna tačka. Ovo se može implementirati kroz promxy, ali je za sada previše komplikovano.
Prva opcija - želimo da napustimo mehanizam federacije, jer je veoma spor.
Programeri Prometheusa izričito kažu: "Momci, koristite drugi TimescaleDB, jer nećemo podržavati dugoročno skladištenje metrike." To nije njihov zadatak.
Zapisujemo na komad papira koji još treba da istovarimo napolje, kako ne bismo sve čuvali na jednom mestu.
Drugi nedostatak je potrošnja memorije. Da, razumijem da će mnogi reći da 2020. par gigabajta memorije vrijedi peni, ali ipak.
Sada imamo dev i prod okruženje. U dev-u, ovo je oko 9 gigabajta na 350 metrika. U produkciji, ovo je 000 gigabajta sa malim 14 metrika. Istovremeno, imamo samo 780 minuta vremena zadržavanja. Ovo je loše. A sada ću objasniti zašto.
Napravimo proračun, odnosno sa milion i po metrika, i već smo blizu njih, u fazi projektovanja dobijamo 35-37 gigabajta memorije. Ali već za 4 miliona metrika, već je potrebno oko 90 gigabajta memorije. To jest, izračunato je prema formuli koju su dali programeri Prometheusa. Pogledali smo korelaciju i shvatili da ne želimo da platimo par miliona za server samo za nadgledanje.
Ne samo da ćemo povećati broj mašina, već ćemo pratiti i same virtuelne mašine. Dakle, što je više virtuelnih mašina, to je više metrika raznih vrsta itd. Imaćemo poseban rast našeg klastera u pogledu metrike.
Sa prostorom na disku, ovdje nije sve tako tužno, ali bih to želio poboljšati. Dobili smo ukupno 15 gigabajta za 120 dana, od čega 100 komprimiranih podataka, 20 nekomprimiranih podataka, ali uvijek želite manje.
Shodno tome, zapisujemo još jednu tačku - ovo je velika potrošnja resursa koju i dalje želimo uštedjeti, jer ne želimo da naš klaster za praćenje pojede više resursa od našeg klastera koji upravlja OpenStack-om.
Postoji još jedan nedostatak Prometeja, koji smo sami identificirali, to je barem neka vrsta ograničenja pamćenja. Kod Prometeja je ovde sve mnogo gore, jer on uopšte nema takvih obrta. Upotreba docker limita također nije opcija. Ako je iznenada vaš RAF pao i ima 20-30 gigabajta, onda će trebati jako dugo da se podigne.
Ovo je još jedan razlog zašto Prometheus nije prikladan za nas, odnosno ne možemo ograničiti potrošnju memorije.
Bilo bi moguće smisliti takvu šemu. Ova šema nam je potrebna kako bismo organizirali HA klaster. Želimo da naša metrika bude dostupna bilo kada i bilo gdje, čak i ako se server koji pohranjuje ove metrike sruši. I stoga moramo izgraditi takvu šemu.
Ova šema kaže da ćemo imati dupliranje krhotina, a samim tim i dupliranje troškova utrošenih resursa. Može se skoro horizontalno skalirati, ali će ipak potrošnja resursa biti paklena.
Nedostaci redom, u obliku u kojem smo ih sami napisali:
- Zahtijeva otpremanje metrike na van.
- Velika potrošnja resursa.
- Ne možete ograničiti potrošnju memorije.
- Komplikovana i resursno intenzivna implementacija HA.
Za sebe smo odlučili da se udaljavamo od Prometeja kao repozitorija.
Identificirali smo dodatne zahtjeve za sebe koji su nam potrebni. Ovo:
- Ovo je podrška za promql, jer je već dosta toga napisano za Prometheus: upiti, upozorenja.
- I onda imamo Grafanu, koja je već na isti način napisana pod Prometheusom kao backend. Ne želim da prepravljam kontrolne table.
- Želimo da izgradimo normalnu HA arhitekturu.
- Želimo smanjiti potrošnju svih resursa.
- Postoji još jedna mala nijansa. Ne možemo koristiti razne vrste cloud sistema za prikupljanje metrike. Za sada ne znamo šta će ući u ove metrike. A pošto tamo sve može letjeti, moramo se ograničiti na lokalni plasman.
Izbor je bio mali. Prikupili smo sve na čemu smo imali iskustva. Pogledali smo stranicu Prometheus u odjeljku integracije, pročitali gomilu članaka, pogledali šta je općenito dostupno. A za sebe smo odabrali VictoriaMetrics kao zamjenu za Prometheus.
Zašto? jer:
- U stanju da promql.
- Postoji modularna arhitektura.
- Ne zahtijeva promjene u Grafani.
- I što je najvažnije, vjerovatno ćemo obezbijediti skladište metrike unutar naše kompanije kao uslugu, tako da unaprijed gledamo na razne vrste ograničenja kako bi korisnici mogli na ograničen način koristiti sve resurse klastera, jer postoji šansa da će to biti višestanarstvo.
Pravimo prvo poređenje. Uzimamo istog Prometeja unutar klastera, vanjski Prometej ide do njega. Dodajemo putem remoteWrite VictoriaMetrics.
Odmah ću rezervirati da smo ovdje uhvatili blagi porast potrošnje CPU-a od VictoriaMetrics-a. VictoriaMetrics wiki kaže koji su parametri najprikladniji. Provjerili smo ih. Vrlo dobro su 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 sve iste podatke koji nedostaju. Sve je dobro u VictoriaMetrics.
Rezultati testova sa prostorom na disku. Mi u Prometeju imamo ukupno 120 gigabajta. U VictoriaMetrics-u već dobijamo 4 gigabajta dnevno. Postoji malo drugačiji mehanizam od onoga što ste navikli da vidite u Prometeju. Odnosno, podaci su već prilično dobro komprimirani za jedan dan, za pola sata. Oni su već dobro požnjeni za jedan dan, za pola sata, uprkos tome što će kasnije podaci biti spojeni. Kao rezultat toga, uštedjeli smo na disku.
Također štedimo na potrošnji memorijskih resursa. U vrijeme testiranja, Prometheus je bio raspoređen na virtuelnoj mašini - 8 jezgara, 24 gigabajta. Prometej jede skoro sve. Pao je na OOM Killera. Istovremeno, u njega je uliveno samo 900 aktivnih metrika. Ovo je oko 000-25 metrika u sekundi.
VictoriaMetrics je radio na dual-core virtuelnoj mašini sa 8 gigabajta RAM-a. Uspjeli smo natjerati VictoriaMetrics da dobro radi tako što smo podesili neke stvari na mašini od 8 GB. Kao rezultat toga, zadržali smo se unutar 7 gigabajta. Istovremeno, dobili smo brzinu isporuke sadržaja, odnosno metriku, čak i veću od Prometejeve.
CPU je mnogo bolji od Prometheusa. Ovdje Prometheus troši 2,5 jezgara, a VictoriaMetrics samo 0,25 jezgara. Na početku - 0,5 jezgara. Kako se spaja, dolazi do jednog jezgra, ali to je izuzetno, izuzetno rijetko.
U našem slučaju, izbor je pao na VictoriaMetrics iz očiglednih razloga, htjeli smo uštedjeti novac i uštedjeti.
Odmah precrtavamo dvije točke - ovo je rasterećenje metrike i velika potrošnja resursa. A ostaje nam da odlučimo dva boda koja smo ipak ostavili za sebe.
Ovdje ću odmah napraviti rezervaciju, VictoriaMetrics smatramo repozitorijumom metrike. Ali pošto ćemo najvjerovatnije obezbijediti VictoriaMetrics kao skladište za sve Leroy, moramo ograničiti one koji će koristiti ovaj klaster kako nam ga ne bi dali.
Postoji divan parametar koji vam omogućava da ograničite po vremenu, količini podataka i vremenu izvršenja.
A tu je i odlična opcija koja vam omogućava da ograničite potrošnju memorije, tako da možemo pronaći balans koji će nam omogućiti normalnu brzinu i adekvatnu potrošnju resursa.
Minus još jedan bod, odnosno precrtavamo točku - ne možete ograničiti potrošnju memorije.
U prvim iteracijama testirali smo VictoriaMetrics Single Node. Zatim prelazimo na VictoriaMetrics Cluster verziju.
Ovdje imamo odriješene ruke po pitanju razdvajanja različitih usluga u VictoriaMetrics, ovisno o tome na čemu će se okretati i koje će resurse trošiti. Ovo je vrlo fleksibilno i praktično rješenje. I sami smo ga koristili.
Glavne komponente VictoriaMetrics Cluster Verzije su vmstsorage. Može postojati N broj. U našem slučaju ima ih 2.
A tu je i vminsert. Ovo je proxy server koji nam omogućava da: organiziramo dijeljenje između svih skladišta o kojima smo mu rekli i dozvoljava drugu repliku, tj. imat ćete i šardiranje i repliku.
Vminsert podržava OpenTSDB, Graphite, InfluxDB i remoteWrite protokole iz Prometheusa.
Tu je i vmselect. Njegov glavni zadatak je otići na vmstorage, dobiti podatke od njih, dedupirati te podatke i dati ih klijentu.
Postoji divna stvar kao što je vmagent. Zaista nam se sviđa. Omogućava vam da konfigurišete baš kao Prometheus i još uvijek radite sve kao Prometheus. To jest, prikuplja metrike od različitih entiteta i usluga i šalje ih vminsert. Onda sve zavisi od vas.
Još jedna odlična usluga je vmalert, koja vam omogućava da koristite VictoriaMetrics kao pozadinu, primate obrađene podatke iz vminsert-a i šaljete obrađene podatke vmselect. Obrađuje sama upozorenja, kao i pravila. U slučaju upozorenja, dobijamo upozorenje preko alertmanagera.
Postoji wmauth komponenta. Vjerovatno ćemo ga koristiti, a možda i ne (još nismo odlučili za ovo) kao sistem autorizacije za višestanarske verzije klastera. Podržava daljinsko pisanje za Prometheus i može autorizirati na osnovu url-a, odnosno drugog dijela, gdje možete ili ne možete pisati.
Tu je i vmbackup, vmrestore. Ovo je, u stvari, restauracija i backup svih podataka. Može S3, GCS, fajl.
Prva iteracija našeg klastera napravljena je tokom karantina. U to vrijeme nije bilo replike, tako da se naša iteracija sastojala od dva različita i nezavisna klastera u koje smo primali podatke putem remoteWrite-a.
Ovdje ću napraviti rezervaciju da kada smo prešli sa VictoriaMetrics Single Node na VictoriaMetrics Cluster Version, i dalje smo ostali na istim potrošenim resursima, odnosno glavni je memorija. Otprilike na ovaj način su distribuirani naši podaci, odnosno potrošnja resursa.
Replika je već dodana ovdje. Sve smo ovo spojili u jedan relativno veliki klaster. Svi podaci se dijele i repliciraju.
Cijeli klaster ima N ulaznih tačaka, tj. Prometheus može dodavati podatke preko HAPROXY-a. Evo naše ulazne tačke. I preko ove ulazne tačke, možete se prijaviti sa Grafanom.
U našem slučaju, HAPROXY je jedini port koji proxy bira, umeće i druge usluge u ovaj klaster. U našem slučaju bilo je nemoguće napraviti jednu adresu, morali smo napraviti nekoliko ulaznih tačaka, jer se same virtuelne mašine, na kojima radi VictoriaMetrics klaster, nalaze u različitim zonama istog provajdera oblaka, odnosno ne unutar našeg oblaka , ali napolju.
Imamo upozorenje. Koristimo ga. Koristimo alertmanager iz Prometheusa. Koristimo Opsgenie i Telegram kao kanal za isporuku upozorenja. U Telegramu sipaju od dev-a, možda nešto iz prod-a, ali više kao nešto statističko što je potrebno inženjerima. A Opsgenie je kritičan. Ovo su pozivi, upravljanje incidentima.
Prastaro pitanje: "Ko nadgleda praćenje?". U našem slučaju, monitoring prati sam monitoring, jer koristimo vmagent na svakom čvoru. A budući da se naši čvorovi nalaze u različitim podatkovnim centrima istog provajdera, svaki podatkovni centar ima svoj kanal, neovisni su, pa čak i ako dođe do podijeljenog mozga, i dalje ćemo primati upozorenja. Da, biće ih više, ali bolje je dobiti više upozorenja nego nijednog.
Našu listu završavamo implementacijom HA.
I dalje bih želio napomenuti iskustvo komunikacije sa VictoriaMetrics zajednicom. Ispostavilo se da je to vrlo pozitivno. Momci su odgovorni. Trude se da proniknu u svaki slučaj koji se nudi.
Napravio sam probleme na GitHubu. Vrlo brzo su riješeni. Ima još par pitanja koja nisu u potpunosti zatvorena, ali već iz koda vidim da se radi u tom pravcu.
Glavni bol tokom iteracija za mene je bio to što ako sam isekao čvor, tada prvih 30 sekundi vminsert nije mogao da shvati da nema pozadinskog dela. Sada je već odlučeno. I bukvalno za sekundu ili dvije, podaci se uzimaju iz svih preostalih čvorova i zahtjev prestaje čekati taj nedostajući čvor.
U nekom trenutku smo željeli da VictoriaMetrics bude VictoriaMetrics operater. Čekali smo ga. Sada aktivno gradimo vezivanje preko VictoriaMetrics operatora da preuzmemo sva pravila prethodnog izračunavanja, itd. Prometheus, jer prilično aktivno koristimo pravila koja dolaze sa Prometheus operatorom.
Postoje prijedlozi za poboljšanje implementacije klastera. Gore sam ih naveo.
I zaista želim smanjenje uzorkovanja. U našem slučaju, downsampling je potreban isključivo za gledanje trendova. Ugrubo govoreći, jedna metrika mi je dovoljna tokom dana. Ovi trendovi su potrebni za godinu, tri, pet, deset godina. I jedna metrička vrijednost je dovoljna.
- Poznavali smo bol, kao i neke naše kolege, dok smo koristili Prometheus.
- Za sebe smo odabrali VictoriaMetrics.
- Prilično dobro skalira i vertikalno i horizontalno.
- Možemo distribuirati različite komponente na različit broj čvorova u klasteru, ograničiti ih u smislu memorije, dodati memoriju itd.
Kod kuće ćemo koristiti VictoriaMetrics, jer nam se jako svidio. Evo šta se dogodilo i šta se dogodilo.
Par qr kodova za VictoriaMetrics chat, moji kontakti, LeroyMerlin tehnički radar.
izvor: www.habr.com