VictoriaMetrics DBMS azkarra eta eskalagarria da datuak gordetzeko eta prozesatzeko denbora-serie moduan (erregistro batek denbora horri dagozkion balio-multzo bat osatzen du, adibidez, sentsoreen egoeraren aldizkako galdeketa baten bidez lortzen da). edo metrikak biltzea).
Nire izena Pavel Kolobaev da. DevOps, SRE, LeroyMerlin, dena kodea bezalakoa da - dena guri buruz da: niri buruz eta LeroyMerlineko beste langileei buruz.
OpenStack-en oinarritutako hodei bat dago. Radar teknikorako lotura txiki bat dago.
Kubernetes burdina oinarri hartuta eraikita dago, baita OpenStack-ekin eta erregistroarekin lotutako zerbitzu guztietan ere.
Hau da garapenean genuen eskema. Hori guztia garatu genuenean, Prometheus operadorea izan genuen, zeinak datuak K8s kluster beraren barruan gordetzen zituen. Automatikoki aurkitu du garbitu beharrekoa eta oinen azpian jartzen du, gutxi gorabehera.
Datu guztiak Kubernetes klusterretik kanpo eraman beharko ditugu, zeren zerbait gertatzen bada, zer eta non ulertu behar dugulako.
Lehenengo irtenbidea federazioa erabiltzen dugu hirugarren Prometheus bat dugunean Kubernetes klusterera federazio mekanismoaren bidez.
Baina hemen arazo txiki batzuk daude. Gure kasuan, arazoak 250 metrika genituenean hasi ziren, eta 000 metrika zeudenean, konturatu ginen ezin genuela horrela funtzionatu. Scrape_timeout 400 segundora igo dugu.
Zergatik egin behar izan dugu hau? Prometheus denbora-muga zenbatzen hasten da bilketa-unearen hasieratik. Ez du axola datuak oraindik isurtzen ari direnik. Zehaztutako denbora-tarte horretan datuak batu ez badira eta saioa http bidez ixten ez bada, saioak huts egin duela eta datuak Prometheus-en bertan sartzen ez badira.
Denek ezagutzen dituzte datuen zati bat falta denean lortzen ditugun grafikoak. Grafikoak urratuta daude eta ez gaude pozik.
Hurrengo aukera bi Prometheus ezberdinetan oinarritutako zatiketa da, federazio mekanismo beraren bidez.
Adibidez, hartu eta zatitu besterik ez dago izenaren arabera. Hau ere erabil daiteke, baina aurrera egitea erabaki dugu.
Orain zati hauek nolabait prozesatu beharko ditugu. Promxy har dezakezu, zatien eremura jaisten dena, datuak biderkatzen ditu. Bi zatirekin funtzionatzen du sarrera-puntu bakar gisa. Hau promxy bidez inplementa daiteke, baina konplikatuegia da oraingoz.
Lehen aukera - federazio mekanismoa alde batera utzi nahi dugu, oso motela delako.
Prometheus-eko garatzaileek esplizituki esaten dute: "Mutilak, erabili beste TimescaleDB, ez baitugu epe luzerako metric biltegiratzea onartuko". Hau ez da euren zeregina. 
Oraindik kanpoan deskargatu behar dugun paper batean idazten dugu, dena leku berean ez gordetzeko.
Bigarren desabantaila memoria kontsumoa da. Bai, ulertzen dut askok esango dutela 2020an memoria gigabyte pare batek zentimo bat balio duela, baina hala ere.
Orain garatzaile eta produkzio ingurune bat dugu. Garapenean, 9 metriko bakoitzeko 350 gigabyte ingurukoa da. Prod, 000 gigabyte da 14 metriko txiki batekin. Aldi berean, 780 minutuko atxikipen-denbora baino ez dugu. Hau txarra da. Eta orain zergatik azalduko dut.
Kalkulu bat egiten dugu, hau da, milioi eta erdi metrikarekin, eta dagoeneko gertu gaude, diseinu fasean 35-37 gigabyteko memoria lortzen dugu. Baina dagoeneko 4 milioi metrikoren arabera, 90 gigabyte inguru memoria behar dira dagoeneko. Hau da, Prometheus garatzaileek emandako formularen arabera kalkulatu zen. Korrelazioa aztertu genuen eta konturatu ginen ez genituela milioi pare bat ordaindu nahi zerbitzari batengatik monitorizazioagatik soilik.
Makina kopurua handitzeaz gain, makina birtualak beraiek kontrolatzen ditugu. Beraz, zenbat eta makina birtual gehiago, hainbat motatako metrika gehiago, etab. Gure klusterraren hazkunde berezia izango dugu metrika aldetik.
Disko espazioarekin, hemen dena ez da hain tristea, baina hobetu nahiko nuke. Guztira 15 gigabyte jaso ditugu 120 egunetan, horietatik 100 datu konprimituak, 20 konprimitu gabeko datuak, baina beti nahi duzu gutxiago.
Horren arabera, puntu bat gehiago idazten dugu: oraindik aurreztu nahi ditugun baliabideen kontsumo handia da, ez baitugu nahi gure monitorizazio-klusterrak OpenStack kudeatzen duen gure klusterrak baino baliabide gehiago jatea.
Prometheus-en desabantaila bat gehiago dago, guk geuk identifikatu duguna, hau memoriaren mugaren bat da behintzat. Prometeorekin dena askoz okerrago dago hemen, ez baitu halako bihurgunerik batere. Docker muga erabiltzea ere ez da aukera bat. Bat-batean zure RAF jaitsi egin bada eta 20-30 gigabyte badaude, oso denbora luzea beharko da igotzeko.
Hau da Prometheus guretzat egokia ez izatearen beste arrazoi bat, hau da, ezin dugu memoria-kontsumoa mugatu.
Posible litzateke horrelako eskema bat egitea. Eskema hau behar dugu HA kluster bat antolatzeko. Gure neurketak edonoiz eta edonon eskuragarri egotea nahi dugu, nahiz eta neurketa horiek gordetzen dituen zerbitzaria huts egin. Eta horrela eraiki behar dugu halako eskema bat.
Eskema honek dio zatien bikoizketa izango dugula, eta, horren arabera, kontsumitutako baliabideen kostuen bikoizketa. Ia horizontalki eskala daiteke, baina, hala ere, baliabideen kontsumoa infernua izango da.
Desabantailak ordenan, guk geuk idatzi ditugun moduan:
- Kanpoaldera neurketak kargatzea eskatzen du.
- Baliabideen kontsumo handia.
- Ezin duzu memoria-kontsumoa mugatu.
- HAren ezarpen konplikatua eta baliabide asko.
Guk, Prometheus-etik biltegi gisa urruntzen ari garela erabaki genuen.
Behar ditugun eskakizun gehigarriak identifikatu ditugu. Hau:
- Hau promql euskarria da, jada asko idatzi baita Prometheusentzat: kontsultak, alertak.
- Eta gero Grafana dugu, dagoeneko Prometheus-en azpian backend gisa modu berean idatzita dagoena. Ez ditut aginte-panelak berridatzi nahi.
- HA arkitektura normal bat eraiki nahi dugu.
- Edozein baliabideren kontsumoa murriztu nahi dugu.
- Bada beste ñabardura txiki bat. Ezin dugu hodei-sistema mota desberdinak erabili metrikak biltzeko. Ez dakigu zer sartuko den metrika hauetan oraingoz. Eta hara edozerk hegan egin dezakeenez, tokiko kokapenera mugatu behar dugu.
Aukera txikia izan zen. Esperientzia izan genuen guztia bildu dugu. Integrazio atalean Prometheus orrialdea begiratu, artikulu mordoa irakurri, orokorrean eskuragarri dagoena aztertu dugu. Eta guretzat, VictoriaMetrics aukeratu genuen Prometheus-en ordezko gisa.
Zergatik? Zeren:
- Promql egiteko gai.
- Arkitektura modularra dago.
- Ez du aldaketarik behar Grafanan.
- Eta garrantzitsuena, ziurrenik gure enpresaren barneko metric biltegiratze bat emango dugu zerbitzu gisa, beraz, aldez aurretik hainbat murrizketari begira ari gara, erabiltzaileek klusterraren baliabide guztiak modu mugatu batean erabil ditzaten, aukera dagoelako. maiztasun anitzekoa izango dela.
Lehenengo konparazioa egiten dugu. Prometeo bera hartzen dugu kluster barruan, kanpoko Prometeo bertara joaten da. VictoriaMetrics remoteWrite bidez gehitzen dugu.
Erreserba bat egingo dut berehala, hemen VictoriaMetrics-en CPUaren kontsumoaren igoera apur bat jaso dugula. VictoriaMetrics wikiak dio zein parametro diren egokienak. Egiaztatu ditugu. Oso ondo murriztu zuten CPUaren kontsumoa.
Gure kasuan, Kubernetes kluster batean dagoen Prometheus-en memoria-kontsumoa ez da nabarmen handitu.
Datu bereko bi datu-iturri konparatzen ditugu. Prometheus-en, falta diren datu berdinak ikusten ditugu. VictoriaMetrics-en dena ona da.
Diskoko espazioa duten proben emaitzak. Prometheus-en 120 gigabyte lortu ditugu guztira. VictoriaMetrics-en, dagoeneko 4 gigabyte jasotzen ari gara egunean. Prometheus-en ikusten ohi duzunarekin alderatuta, mekanismo apur bat desberdina da. Hau da, datuak dagoeneko nahiko ondo konprimituta daude egun batez, ordu erdiz. Dagoeneko egun batean ondo biltzen dira, ordu erdian, gerora datuak batuko diren arren. Ondorioz, diskoan espazioa aurreztu dugu.
Memoria-baliabideen kontsumoan ere aurrezten dugu. Probak egiteko garaian, Prometheus makina birtual batean zabalduta genuen - 8 nukleo, 24 gigabyte. Prometeok ia dena jaten du. OOM Killer-en aurka erori zen. Aldi berean, 900 neurketa aktibo baino ez ziren sartu. Hau segundoko 000-25 metriko inguru da.
VictoriaMetrics 8 gigabyte RAM dituen nukleo bikoitzeko makina birtual batean ari zen exekutatzen. VictoriaMetrics-ek ondo funtzionatzea lortu genuen 8GBko makina batean gauza batzuk doituz. Ondorioz, 7 gigabyteren barruan mantendu ginen. Aldi berean, edukiak bidaltzeko abiadura lortu dugu, hau da, neurketak, Prometheus-ena baino are handiagoa.
CPU Prometheus baino askoz hobea da. Hemen Prometheus-ek 2,5 nukleo kontsumitzen ditu eta VictoriaMetrics-ek 0,25 nukleo baino ez ditu kontsumitzen. Hasieran - 0,5 nukleo. Bat egiten den heinean, muin batera iristen da, baina hau oso, arraroa da.
Gure kasuan, aukera VictoriaMetrics-en erori zen arrazoi bistakoengatik, dirua aurreztu eta aurreztu nahi genuen.
Bi puntu ezabatzen ditugu hasieratik; hau da neurgailuen deskarga eta baliabideen kontsumo handia. Eta oraindik geuretzat utzi ditugun bi puntu erabakitzea geratzen zaigu.
Hemen erreserba bat egingo dut berehala, VictoriaMetrics metrika biltegitzat hartzen dugu. Baina ziurrenik VictoriaMetrics Leroy guztientzako biltegiratze gisa emango dugunez, kluster hau erabiliko dutenak mugatu behar ditugu, guri jarri ez ditzaten.
Parametro zoragarri bat dago, denboraren arabera, datu kopuruaren eta exekuzio denboraren arabera mugatzeko aukera ematen duena.
Eta memoria-kontsumoa mugatzeko aukera ematen duen aukera bikaina ere badago, horrela abiadura normala eta baliabide-kontsumo egokia lortzeko aukera emango digun oreka aurki dezakegu.
Puntu bat gehiago kenduta, hau da, puntua ezabatzen dugu - ezin duzu memoria-kontsumoa mugatu.
Lehenengo iterazioetan, VictoriaMetrics Single Node probatu genuen. Ondoren, VictoriaMetrics Cluster bertsiora pasako gara.
Hemen esku librea dugu VictoriaMetrics-en zerbitzu ezberdinen bereizketaren gaiari buruz, zer bira emango duten eta zer baliabide kontsumituko dituzten arabera. Hau oso irtenbide malgua eta erosoa da. Guk geuk erabili dugu.
VictoriaMetrics Cluster bertsioaren osagai nagusiak vmstsorage dira. N zenbakia egon daiteke. Gure kasuan, 2 dira.
Eta vminsert dago. Hau proxy zerbitzari bat da, hau ahalbidetzen duena: kontatu genion biltegiratze guztien artean zatiketa antolatzea, eta beste erreplika bat ahalbidetzen du, hau da, zatiketa eta erreplika bat izango dituzu.
Vminsert-ek Prometheus-en OpenTSDB, Graphite, InfluxDB eta remoteWrite protokoloak onartzen ditu.
vmselect ere badago. Bere zeregin nagusia da vmstorage-ra joatea, haietatik datuak ateratzea, datu horiek deduplikatzea eta bezeroari ematea.
vmagent bezalako gauza zoragarri bat dago. Asko gustatzen zaigu. Prometheus bezala konfiguratzeko aukera ematen du eta oraindik Prometheus bezala dena egiteko. Hau da, entitate eta zerbitzu ezberdinen metrikak biltzen ditu eta vminsert-era bidaltzen ditu. Orduan dena zure menpe dago.
Beste zerbitzu bikaina vmalert da, VictoriaMetrics backend gisa erabiltzeko, prozesatutako datuak vminsert-etik jaso eta prozesatutako datuak vmselect-era bidaltzeko aukera ematen duena. Alertak berak prozesatzen ditu, baita arauak ere. Alertaren kasuan, alertmanager bidez alerta bat jasotzen dugu.
wmauth osagai bat dago. Ziurrenik erabiliko dugu, eta agian ez (oraindik ez dugu hau erabaki) klusterren maiztasun anitzeko bertsioetarako baimen-sistema gisa. Prometheus-erako remoteWrite onartzen du eta URLan, edo hobeto esanda, haren bigarren zatian oinarrituta baimendu dezake, non idatzi dezakezun edo ezin duzun.
vmbackup, vmrestore ere badago. Hau da, hain zuzen ere, datu guztien leheneratzea eta babeskopia. S3, GCS, fitxategiak egiteko gai da.
Gure klusterraren lehen errepikapena berrogeialdian egin zen. Garai hartan, ez zegoen erreplikarik, beraz, gure iterazioa bi kluster ezberdin eta independentek osatzen zuten, zeinetan datuak remoteWrite bidez jaso genituen.
Hemen erreserba bat egingo dut, VictoriaMetrics Single Nodetik VictoriaMetrics Cluster bertsiora aldatu ginenean, oraindik kontsumitutako baliabide berdinetan geratu ginen, hau da, nagusia memoria da. Gutxi gorabehera horrela banatu ziren gure datuak, hau da, baliabideen kontsumoa.
Erreplika bat gehitu da dagoeneko hemen. Hori guztia kluster handi samarrean konbinatu dugu. Datu guztiak zatikatu eta errepikatu egiten dira.
Kluster osoak N sarrera puntu ditu, hau da, Prometheus-ek datuak gehi ditzake HAPROXY bidez. Hona hemen gure sarrera puntua. Eta sarrera puntu honen bidez, Grafanarekin saioa hasi dezakezu.
Gure kasuan, HAPROXY da kluster honetan proxyak hautatzen, txertatzen eta beste zerbitzu batzuk egiten dituen ataka bakarra. Gure kasuan, ezinezkoa zen helbide bat egitea, hainbat sarrera puntu egin behar izan genituen, VictoriaMetrics cluster-a exekutatzen ari den makina birtualak beraiek hodei-hornitzaile bereko gune ezberdinetan daudelako, hau da, gure hodeiaren barruan ez daudelako. , baina kanpoan.
Alerta bat dugu. Erabiltzen dugu. Prometheus-en alertmanager erabiltzen dugu. Opsgenie eta Telegram erabiltzen ditugu alertak bidaltzeko kanal gisa. Telegram-en garatzailetik isurtzen ari dira, agian produktutik zerbait, baina gehiago ingeniariek behar duten estatistikoa bezalakoa. Eta Opsgenie kritikoa da. Hauek deiak dira, gertakarien kudeaketa.
Aspaldiko galdera: "Nork kontrolatzen du jarraipena?". Gure kasuan, monitorizazioak monitorizazioa bera kontrolatzen du, nodo bakoitzean vmagent erabiltzen dugulako. Eta gure nodoak hornitzaile bereko datu-zentro ezberdinetan daudenez, datu-zentro bakoitzak bere kanala du, independenteak dira, eta garun zatitua etorriko balitz ere, alertak jasoko ditugu. Bai, gehiago izango dira, baina hobe da alerta gehiago jasotzea bat ere ez baino.
Gure zerrenda HAren ezarpenarekin amaitzen dugu.
Eta, gainera, VictoriaMetrics komunitatearekin komunikatzeko esperientzia nabarmendu nahi dut. Oso positiboa izan da. Mutilak erantzuten dira. Eskaintzen diren kasu guztietan sakontzen saiatzen dira.
Arazoak egin ditut GitHub-en. Oso azkar konpondu ziren. Badira beste pare bat arazo guztiz itxita ez daudenak, baina jadanik ikusten dut kodearen arabera lan egiten ari dela norabide horretan.
Niretzat iterazioetan min nagusia izan zen nodoa mozten banu, lehen 30 segundoetan vminsert-ek ezin zuela ulertu backendik ez zegoela. Orain jada erabakita dago. Eta literalki segundo batean edo bitan, datuak gainerako nodo guztietatik hartzen dira, eta eskaera falta den nodo horren zain gelditzen da.
Noizbait VictoriaMetrics-etik VictoriaMetrics operadorea izatea nahi genuen. Haren zain egon ginen. VictoriaMetrics operadorearen gaineko lotura bat eraikitzen ari gara orain, aurrez kalkulatzeko arau guztiak hartzeko, etab. Prometheus, Prometheus operadorearekin batera datozen arauak nahiko aktibo erabiltzen ari garelako.
Klusterren ezarpena hobetzeko iradokizunak daude. Goian adierazi ditut.
Eta oso txikia ere nahi dut. Gure kasuan, beherantz-laginketa beharrezkoa da joerak ikusteko soilik. Gutxi gorabehera, metrika bat nahikoa da niretzat egunean zehar. Joera hauek urtebete, hiru, bost, hamar urterako behar dira. Eta balio metriko bat nahikoa da.
- Mina ezagutu dugu, gure lankide batzuek bezala, Prometheus erabiltzen ari ginen bitartean.
- VictoriaMetrics aukeratu genuen guretzat.
- Nahiko ondo eskalatzen da bai bertikalki bai horizontalki.
- Osagai desberdinak klusterreko nodo kopuru desberdinetan banatu ditzakegu, memoria aldetik mugatu, memoria gehitu, etab.
VictoriaMetrics erabiliko dugu etxean, asko gustatu zaigulako. Hona hemen zer gertatu den eta zer gertatu den.
VictoriaMetrics txaterako qr kode pare bat, nire kontaktuak, LeroyMerlin radar teknikoa.
Iturria: www.habr.com
