VictoriaMetrics is in rappe en skalberbere DBMS foar it opslaan en ferwurkjen fan gegevens yn 'e foarm fan in tiidsearje (in rekord bestiet út tiid en in set wearden dy't oerienkomme mei dizze tiid, bygelyks, krigen troch periodike polling fan' e status fan sensoren as samling metriken).
Myn namme is Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alles is as koade - it giet allegear oer ús: oer my en oer oare LeroyMerlin-meiwurkers.
D'r is in wolk basearre op OpenStack. Der is in lytse link nei de technyske radar.
It is boud op de Kubernetes-hardware, lykas op alle relatearre tsjinsten foar OpenStack en logging.
Dit is it skema dat wy yn ûntwikkeling hienen. Doe't wy dit alles ûntwikkelen, hienen wy in Prometheus-operator dy't gegevens opslein yn 'e K8s-kluster sels. Hy fynt automatysk wat der skrobe wurde moat en leit it rûchwei ûnder de fuotten.
Wy sille alle gegevens bûten it Kubernetes-kluster moatte ferpleatse, want as der wat bart, moatte wy begripe wat en wêr.
De earste oplossing is dat wy federaasje brûke as wy in Prometheus fan tredden hawwe, as wy nei it Kubernetes-kluster gean fia it federaasjemeganisme.
Mar d'r binne wat lytse problemen hjir. Yn ús gefal begûnen de problemen doe't wy 250 metriken hienen, en doe't d'r 000 metriken wiene, realisearren wy dat wy sa net koenen wurkje. Wy ferhege scrape_timeout nei 400 sekonden.
Wêrom moasten wy dit dwaan? Prometheus begjint de time-out te tellen fanôf it begjin fan it hek. It makket neat út dat de gegevens noch streamt. As yn dizze opjûne perioade de gegevens net gearfoege wurde en de sesje is net sluten fia http, dan wurdt de sesje beskôge as mislearre en komme de gegevens net yn Prometheus sels.
Elkenien is bekend mei de grafiken dy't wy krije as guon fan 'e gegevens ûntbrekke. De skema's binne skuord en wy binne hjir net bliid mei.
De folgjende opsje is sharding basearre op twa ferskillende Prometheus fia deselde federaasjemeganisme.
Nim se bygelyks gewoan en knip se by namme. Dit kin ek brûkt wurde, mar wy hawwe besletten om fierder te gean.
Wy sille no dizze skuorren op ien of oare manier moatte ferwurkje. Jo kinne promxy nimme, dy't nei it shardgebiet giet en de gegevens fermannichfâldigje. It wurket mei twa shards as ien yngongspunt. Dit kin útfierd wurde fia promxy, mar it is noch te dreech.
De earste opsje is dat wy it federaasjemeganisme wolle ferlitte om't it heul stadich is.
De Prometheus-ûntwikkelders sizze dúdlik: "Jongens, brûk in oare TimescaleDB, om't wy gjin lange termyn opslach fan metriken sille stypje." Dit is net harren taak.
Wy skriuwe op in stikje papier dat wy noch bûten laden moatte, om net alles op ien plak te bewarjen.
De twadde nadeel is ûnthâld konsumpsje. Ja, ik begryp dat in protte sille sizze dat yn 2020 in pear gigabytes oan ûnthâld in penny kostje, mar dochs.
No hawwe wy in dev en prod omjouwing. Yn dev giet it oer 9 gigabytes foar 350 metriken. Yn prod is it 000 gigabytes en in bytsje mear as 14 metriken. Tagelyk is ús retinsjetiid mar 780 minuten. Dit is min. En no sil ik útlizze wêrom.
Wy meitsje in berekkening, dat is, mei ien en in heal miljoen metriken, en wy binne al ticht by har, op it ûntwerpstadium krije wy 35-37 gigabytes fan ûnthâld. Mar al 4 miljoen metriken fereaskje sa'n 90 gigabyte oan ûnthâld. Dat is, it waard berekkene mei de formule levere troch de Prometheus-ûntwikkelders. Wy seagen nei de korrelaasje en realisearre dat wy gjin pear miljoen wolle betelje foar in server allinich foar tafersjoch.
Wy sille net allinich it oantal masines ferheegje, wy kontrolearje ek de firtuele masines sels. Dêrom, de mear firtuele masines, de mear metriken fan ferskate soarten, ensfh Wy sille in spesjale groei fan ús kluster hawwe yn termen fan metriken.
Mei skiifromte is hjir net alles sa slim, mar ik soe it graach ferbetterje wolle. Wy krigen yn totaal 15 gigabytes yn 120 dagen, wêrfan 100 komprimearre gegevens, 20 net komprimearre gegevens, mar wy wolle altyd minder.
Dêrtroch skriuwe wy noch ien punt op - dit is in grut konsumpsje fan boarnen, dy't wy noch wolle besparje, om't wy net wolle dat ús tafersjochkluster mear boarnen konsumearret dan ús kluster, dat OpenStack beheart.
D'r is noch ien neidiel fan Prometheus, dy't wy foar ússels hawwe identifisearre, dit is op syn minst in soarte fan ûnthâldbeheining. Mei Prometheus is alles hjir folle slimmer, om't it sokke draaien hielendal net hat. It brûken fan in limyt yn docker is ek gjin opsje. As jo RAF ynienen foel en d'r binne 20-30 gigabytes, dan sil it heul lang duorje om op te kommen.
Dit is in oare reden wêrom't Prometheus is net geskikt foar ús, dat wol sizze wy kinne net beheine ûnthâld konsumpsje.
It soe mooglik wêze om mei sa'n regeling te kommen. Wy hawwe dizze regeling nedich om in HA-kluster te organisearjen. Wy wolle dat ús metriken altyd en oeral beskikber binne, sels as de server dy't dizze metriken opslacht crasht. En dus sille wy sa'n skema bouwe moatte.
Dit skema seit dat wy duplikaasje fan shards sille hawwe, en dus duplikaasje fan 'e kosten fan konsumeare boarnen. It kin hast horizontaal opskaald wurde, mar dochs sil it boarneferbrûk helsk wêze.
Neidielen yn oarder yn 'e foarm wêryn't wy se foar ússels opskreaun hawwe:
- Fereasket it opladen fan metriken ekstern.
- Heech boarne konsumpsje.
- D'r is gjin manier om ûnthâldferbrûk te beheinen.
- Komplekse en boarne-yntinsive ymplemintaasje fan HA.
Foar ússels hawwe wy besletten dat wy fuortgeane fan Prometheus as opslach.
Wy hawwe oanfoljende easken foar ússels identifisearre dy't wy nedich binne. Dit:
- Dit is promql-stipe, om't in protte dingen al skreaun binne foar Prometheus: queries, warskôgings.
- En dan hawwe wy Grafana, dy't foar Prometheus al op krekt deselde wize skreaun is as backend. Ik wol gjin dashboards oerskriuwe.
- Wy wolle in normale HA-arsjitektuer bouwe.
- Wy wolle it konsumpsje fan alle boarnen ferminderje.
- Der is in oare lytse nuânse. Wy kinne ferskate soarten kolleksjesystemen foar wolkmetriken net brûke. Wy witte noch net wat yn dizze metriken falle sil. En om't dêr alles fleane kin, moatte wy ús beheine ta pleatslike pleatsing.
Der wie net folle kar. Wy sammele alles wat wy hiene ûnderfining mei. Wy seagen nei de Prometheus-side yn 'e yntegraasje-seksje, lêze in boskje artikels, en seagen wat der wie. En foar ússels hawwe wy VictoriaMetrics keazen as ferfanging foar Prometheus.
Wêrom? Omdat:
- Kent promql.
- D'r is in modulêre arsjitektuer.
- Fereasket gjin feroarings oan Grafana.
- En it wichtichste, wy sille wierskynlik de metriken opslach binnen ús bedriuw leverje as in tsjinst, dus wy sykje foarôf nei beheiningen fan ferskate soarten, sadat brûkers alle boarnen fan it kluster op ien of oare beheinde manier kinne brûke, om't d'r in kâns is dat it sil multitenancy.
Litte wy de earste ferliking meitsje. Wy nimme deselde Prometheus binnen it kluster, eksterne Prometheus giet nei it. Taheakje fia remoteWrite VictoriaMetrics.
Ik sil fuortendaliks in reservearje meitsje dat wy hjir in lichte ferheging fan CPU-konsumpsje fan VictoriaMetrics hawwe. De VictoriaMetrics wiki fertelt jo hokker parameters it bêste binne. Wy hawwe se kontrolearre. Se hawwe fermindere CPU konsumpsje hiel goed.
Yn ús gefal, it ûnthâld konsumpsje fan Prometheus, dat leit yn de Kubernetes kluster, net tanommen signifikant.
Wy fergelykje twa gegevensboarnen fan deselde gegevens. Yn Prometheus sjogge wy deselde ûntbrekkende gegevens. Alles is goed by VictoriaMetrics.
Disk romte test resultaten. Wy by Prometheus krigen yn totaal 120 gigabyte. By VictoriaMetrics krije wy al 4 gigabyte per dei. D'r is in wat oars meganisme dan wat wy wend binne om te sjen yn Prometheus. Dat is, de gegevens binne al frij goed komprimearre yn in dei, yn in healoere. Se binne yn in dei, yn in healoere, al goed rispje, nettsjinsteande it feit dat de gegevens letter noch ferlern geane. As gefolch hawwe wy op skiifromte bewarre.
Wy besparje ek op ûnthâld boarne konsumpsje. Op it momint fan testen hienen wy Prometheus ynset op in firtuele masine - 8 kearnen, 24 gigabytes. Prometheus yt hast alles. Hy foel op OOM Killer. Tagelyk waarden der mar 900 aktive metriken yn getten. Dit is sawat 000-25 metriken per sekonde.
Wy rûnen VictoriaMetrics op in dual-core firtuele masine mei 8 gigabyte RAM. Wy slaggen deryn VictoriaMetrics te krijen om goed te wurkjen troch te rommeljen mei in pear dingen op in 8GB-masine. Uteinlik hâlde wy it op 7 gigabyte. Tagelyk wie de snelheid fan levering fan ynhâld, dus metriken, noch heger as dy fan Prometheus.
De CPU is folle better wurden yn ferliking mei Prometheus. Hjir konsumearret Prometheus 2,5 kearnen, en VictoriaMetrics allinich 0,25 kearnen. Oan it begjin - 0,5 kearnen. As it fusearret, berikt it ien kearn, mar dit is ekstreem, ekstreem seldsum.
Yn ús gefal foel de kar op VictoriaMetrics om foar de hân lizzende redenen, wy woene jild besparje en wy diene.
Litte wy direkt twa punten trochstreare - metriken uploade en heech konsumpsje fan boarnen. En wy moatte gewoan twa punten beslute dy't wy noch foar ússels hawwe.
Hjir sil ik direkt in reservearje meitsje, wy beskôgje VictoriaMetrics as in opslach fan metriken. Mar om't wy wierskynlik VictoriaMetrics sille leverje as opslach foar alle Leroy, moatte wy dejingen beheine dy't dit kluster sille brûke, sadat se it ús net jouwe.
D'r is in prachtige parameter wêrmei jo kinne beheine troch tiid, troch folume fan gegevens en troch útfieringstiid.
D'r is ek in poerbêste opsje wêrmei wy ûnthâldferbrûk kinne beheine, dêrmei kinne wy it lykwicht fine wêrmei wy normale wurksnelheid en adekwaat boarneferbrûk krije kinne.
Minus noch ien punt, d.w.s. oerstekke it punt - do kinst net beheine ûnthâld konsumpsje.
Yn 'e earste iteraasjes testen wy VictoriaMetrics Single Node. Folgjende geane wy troch nei VictoriaMetrics Cluster Ferzje.
Hjir hawwe wy in frije hân om ferskate tsjinsten yn VictoriaMetrics te skieden ôfhinklik fan wêrop se sille rinne en hokker boarnen se sille konsumearje. Dit is in heul fleksibele en handige oplossing. Wy hawwe dit op ússels brûkt.
De wichtichste komponinten fan VictoriaMetrics Cluster Ferzje binne vmstsorage. Der kin N oantal fan harren. Yn ús gefal binne d'r oant no ta 2.
En der is vminsert. Dit is in proxy-tsjinner wêrmei ús: sharding regelje tusken alle opslach wêr't wy it oer fertelden, en it makket ek in replika mooglik, dus jo sille sawol sharding as in replika hawwe.
Vminsert stipet OpenTSDB, Graphite, InfluxDB en remoteWrite-protokollen fan Prometheus.
Der is ek vmselect. Syn wichtichste taak is om te gean nei vmstorage, ûntfange gegevens fan harren, deduplicate dizze gegevens en jou it oan de klant.
D'r is in prachtich ding neamd vmagent. Wy fine har echt leuk. It lit jo presys konfigurearje lykas Prometheus en dochs alles krekt dwaan lykas Prometheus. Dat is, it sammelet metriken fan ferskate entiteiten en tsjinsten en stjoert se nei vminsert. Dan hinget alles fan dy ôf.
In oare grutte tsjinst is vmalert, dat kinne jo brûke VictoriaMetrics as in backend, ûntfange ferwurke gegevens út vminsert en stjoer it nei vmselect. It ferwurket de warskôgings sels, lykas de regels. Yn it gefal fan warskôgings krije wy de warskôging fia alertmanager.
D'r is in wmauth-komponint. Wy kinne it al of net (wy hawwe dit noch net besletten) brûke as autorisaasjesysteem foar de multitenancyferzje fan klusters. It stipet remoteWrite foar Prometheus en kin autorisearje op basis fan 'e url, of leaver it twadde diel dêrfan, wêr't jo kinne of kinne net skriuwe.
D'r is ek vmbackup, vmrestore. Dit is, yn essinsje, de restauraasje en reservekopy fan alle gegevens. Kin dwaan S3, GCS, triem.
De earste iteraasje fan ús kluster waard makke tidens karantine. Op dat stuit wie d'r gjin replika, dus ús iteraasje bestie út twa ferskillende en ûnôfhinklike klusters wêryn wy gegevens krigen fia remoteWrite.
Hjir sil ik in reservearje meitsje dat doe't wy oerstapten fan VictoriaMetrics Single Node nei VictoriaMetrics Cluster Ferzje, wy noch bleaunen mei deselde konsumeare boarnen, d.w.s. de wichtichste is ûnthâld. Dit is sawat hoe't ús gegevens, dus boarneferbrûk, ferdield binne.
In replika is hjir al tafoege. Wy kombinearre dit alles yn ien relatyf grut kluster. Al ús gegevens binne sawol ferdield as replikearre.
It hiele kluster hat N yngongspunten, d.w.s. Prometheus kin gegevens tafoegje fia HAPROXY. Hjir hawwe wy dit yngongspunt. En fia dit yngongspunt kinne jo ynlogge fan Grafana.
Yn ús gefal is HAPROXY de ienige poarte dy't proxy's selektearje, ynfoegje en oare tsjinsten binnen dit kluster. Yn ús gefal wie it ûnmooglik om ien adres te meitsjen, wy moasten ferskate yngongspunten meitsje, om't de firtuele masines sels dêr't de VictoriaMetrics-kluster rint yn ferskate sônes fan deselde wolkprovider sitte, dus net binnen ús wolk, mar bûten; .
Wy hawwe warskôging. Wy brûke it. Wy brûke alertmanager fan Prometheus. Wy brûke Opsgenie en Telegram as in warskôgingskanaal. Yn Telegram streame se yn fan dev, miskien wat fan prod, mar meast wat statistysk, nedich troch yngenieurs. En Opsgenie is kritysk. Dit binne oproppen, incident management.
De ivige fraach: "Wa kontrolearret de tafersjoch?" Yn ús gefal, tafersjochhâlders tafersjoch op himsels, om't wy brûke vmagent op elke knooppunt. En om't ús knooppunten ferdield binne oer ferskate datasintra fan deselde provider, hat elk datasintrum in eigen kanaal, se binne ûnôfhinklik, en sels as in split harsens komt, sille wy noch warskôgings krije. Ja, se sille mear wêze, mar it is better om mear warskôgings te ûntfangen as gjinien.
Wy einigje ús list mei in HA ymplemintaasje.
En fierder wol ik de ûnderfining fan kommunisearjen mei de VictoriaMetrics-mienskip opmerke. It kaam tige posityf út. De jonges binne responsyf. Se besykje te ferdjipjen yn elke saak dy't oanbean wurdt.
Ik begon problemen op GitHub. Se waarden hiel fluch oplost. D'r binne noch in pear problemen dy't net folslein sluten binne, mar ik kin al sjen fan 'e koade dat it wurk yn dizze rjochting oan 'e gong is.
De wichtichste pine foar my tidens iteraasjes wie dat as ik in knoop ôfslute, dan koe vminsert foar de earste 30 sekonden net begripe dat der gjin efterkant wie. Dêr is no besletten. En letterlik yn in sekonde of twa wurde de gegevens fan alle oerbleaune knooppunten nommen, en it fersyk hâldt op te wachtsjen op dat ûntbrekkende knooppunt.
Op in stuit woene wy dat VictoriaMetrics in VictoriaMetrics-operator soe wêze. Wy wachtsje op him. Wy binne no aktyf bouwe in ramt foar de VictoriaMetrics operator te nimmen alle pre-berekkenjen regels, ensfh Prometheus, omdat wy binne frij aktyf mei help fan de regels dy't komme mei de Prometheus operator.
Der binne foarstellen om de klusterimplementaasje te ferbetterjen. Ik sketste se hjirboppe.
En ik wol echt downsample. Yn ús gefal is downsampling allinich nedich foar it besjen fan trends. Rûchwei is ien metrysk genôch foar my oerdeis. Dizze trends binne nedich foar in jier, trije, fiif, tsien jier. En ien metryske wearde is genôch.
- Wy hawwe pine bekend, lykas guon fan ús kollega's, by it brûken fan Prometheus.
- Wy hawwe VictoriaMetrics foar ússels keazen.
- It skaleart frij goed sawol fertikaal as horizontaal.
- Wy kinne ferskate komponinten fersprieden nei ferskate oantallen knopen yn it kluster, beheine se troch ûnthâld, tafoegje ûnthâld, ensfh.
Wy sille VictoriaMetrics thús brûke, om't wy it echt leuk fûnen. Dit is wat wie en wat wurden is.
In pear QR-koades foar VictoriaMetrics petear, myn kontakten, LeroyMerlin technyske radar.
Boarne: www.habr.com