VictoriaMetrics ass e séieren a skalierbare DBMS fir Daten a Form vun enger Zäitserie ze späicheren an ze veraarbecht (e Rekord besteet aus Zäit an enger Rei vu Wäerter, déi zu dëser Zäit entspriechen, zum Beispill duerch periodesch Ëmfroe vum Status vu Sensoren oder Sammlung vu Metriken).
Mäin Numm ass Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alles ass wéi Code - et ass alles iwwer eis: iwwer mech an iwwer aner LeroyMerlin Mataarbechter.
Et gëtt eng Wollek baséiert op OpenStack. Et gëtt e klenge Link zum technesche Radar.
Et ass op der Kubernetes Hardware gebaut, wéi och op all verbonne Servicer fir OpenStack a Logging.
Dëst ass de Schema dee mir an der Entwécklung haten. Wa mir dëst alles entwéckelt hunn, hu mir e Prometheus Bedreiwer deen Daten am K8s Cluster selwer gespäichert huet. Hie fënnt automatesch dat, wat geschrubbt muss ginn, a leet dat grof geschwat ënnert de Féiss.
Mir mussen all d'Donnéeën ausserhalb vum Kubernetes-Cluster réckelen, well wann eppes geschitt, musse mir verstoen wat a wou.
Déi éischt Léisung ass datt mir d'Federatioun benotzen wa mir en Drëtt-Partei Prometheus hunn, wa mir an de Kubernetes-Cluster duerch de Federatiounsmechanismus goen.
Mee et ginn e puer kleng Problemer hei. An eisem Fall hunn d'Problemer ugefaang wéi mir 250 Metriken haten, a wann et 000 Metriken waren, hu mir gemierkt datt mir net esou kënne schaffen. Mir hunn scrape_timeout op 400 Sekonnen erhéicht.
Firwat hu mir dat misse maachen? De Prometheus fänkt un den Timeout vum Ufank vum Zait ze zielen. Et ass egal datt d'Donnéeën nach ëmmer fléissen. Wann während dëser spezifizéierter Zäit d'Donnéeën net fusionéiert sinn an d'Sessioun net iwwer http zougemaach gëtt, da gëtt d'Sessioun als gescheitert ugesinn an d'Donnéeë kommen net an de Prometheus selwer.
Jiddereen ass vertraut mat de Grafiken déi mir kréien wann e puer vun den Donnéeën feelen. D'Zäitplang ass zerrass a mir sinn net zefridden mat dësem.
Déi nächst Optioun ass Sharding baséiert op zwee verschiddene Prometheus duerch deeselwechte Federatiounsmechanismus.
Zum Beispill, huelt se einfach an zerstéiert se mam Numm. Dëst kann och benotzt ginn, awer mir hu beschloss weider ze goen.
Mir mussen elo dës Schnëtt iergendwéi veraarbechten. Dir kënnt Promxy huelen, déi an d'Shardberäich geet an d'Daten multiplizéiert. Et funktionnéiert mat zwee Schnëtt als eenzegen Entréespunkt. Dëst kann duerch Promxy ëmgesat ginn, awer et ass nach ëmmer ze schwéier.
Déi éischt Optioun ass, datt mir de Federatiounsmechanismus wëllen opginn, well e ganz lues ass.
D'Prometheus Entwéckler soen kloer: "Jungs, benotzt eng aner TimescaleDB well mir laangfristeg Späichere vu Metriken net ënnerstëtzen." Dëst ass net hir Aufgab.
Mir schreiwen op e Stéck Pabeier dat mir nach dobausse mussen ausluede, fir net alles op enger Plaz ze späicheren.
Déi zweet Nodeel ass Erënnerung Konsum. Jo, ech verstinn datt vill wäerte soen datt am Joer 2020 e puer Gigabytes Erënnerung e Penny kascht, awer ëmmer.
Elo hu mir en Dev a Prod Ëmfeld. An Dev ass et ongeféier 9 Gigabytes fir 350 Metriken. Am Prod ass et 000 Gigabytes an e bësse méi wéi 14 Metriken. Zur selwechter Zäit ass eis Retentiounszäit nëmmen 780 Minutten. Dëst ass schlecht. An elo wäert ech erkläre firwat.
Mir maachen eng Berechnung, dat heescht mat enger annerhallef Millioun Metriken, a mir si scho no bei hinnen, an der Designstadium kréien mir 35-37 Gigabytes Erënnerung. Awer scho 4 Millioune Metriken erfuerderen ongeféier 90 Gigabytes Erënnerung. Dat ass, et gouf berechent mat der Formel vun de Prometheus Entwéckler. Mir hunn d'Korrelatioun gekuckt a gemierkt datt mir net e puer Millioune fir e Server just fir d'Iwwerwaachung bezuele wëllen.
Mir wäerten net nëmmen d'Zuel vun de Maschinnen erhéijen, mir iwwerwaachen och déi virtuell Maschinnen selwer. Dofir, wat méi virtuell Maschinnen, méi Metriken vu verschiddenen Aarte, etc. Mir wäerten e spezielle Wuesstum vun eisem Cluster a punkto Metriken hunn.
Mat Disk Space ass net alles esou schlecht hei, mee ech géif et gär verbesseren. Mir hunn am Ganzen 15 Gigabytes an 120 Deeg kritt, vun deenen 100 kompriméiert Donnéeën, 20 onkompriméiert Donnéeën, awer mir wëllen ëmmer manner.
Deementspriechend schreiwen mir nach ee Punkt - dat ass e grousse Konsum vu Ressourcen, dee mir nach ëmmer wëllen spueren, well mir wëllen net datt eise Monitoring-Cluster méi Ressourcen konsuméiere wéi eise Cluster, deen OpenStack geréiert.
Et gëtt e méi Nodeel vum Prometheus, dee mir fir eis selwer identifizéiert hunn, dëst ass op d'mannst eng Zort Erënnerungsbegrenzung. Mam Prometheus ass alles vill méi schlëmm hei, well et guer net esou Twists huet. Eng Limit am Docker benotzen ass och keng Optioun. Wann op eemol Äre RAF gefall ass an et sinn 20-30 Gigabyte, da wäert et ganz laang daueren fir eropzekommen.
Dëst ass en anere Grond firwat de Prometheus net fir eis gëeegent ass, dh mir kënnen d'Erënnerungsverbrauch net limitéieren.
Et wier méiglech mat esou engem Schema ze kommen. Mir brauchen dëse Schema fir en HA Cluster ze organiséieren. Mir wëllen datt eis Metriken ëmmer an iwwerall verfügbar sinn, och wann de Server deen dës Metriken späichert crasht. An domat musse mer esou e Schema bauen.
Dëse Schema seet datt mir Duplikatioun vu Schnëtt wäerten hunn, an deementspriechend Duplikatioun vun de Käschte vun de verbrauchte Ressourcen. Et kann bal horizontal skaléiert ginn, awer trotzdem wäert de Ressourceverbrauch hellesch sinn.
Nodeeler an Uerdnung an der Form an där mir se fir eis selwer geschriwwen:
- Verlaangt Eroplueden Metriken extern.
- Héich Ressource Konsum.
- Et gëtt keng Manéier Erënnerung Konsum ze limitéieren.
- Komplex a ressourceintensiv Ëmsetzung vun HA.
Fir eis selwer hu mir décidéiert, datt mir vum Prometheus als Lageranlag fortgoen.
Mir hunn zousätzlech Ufuerderunge fir eis selwer identifizéiert déi mir brauchen. Dëst:
- Dëst ass promql Support, well vill Saache scho fir Prometheus geschriwwe goufen: Ufroen, Alarmer.
- An dann hu mer Grafana, déi scho genee déiselwecht Manéier fir Prometheus als Backend geschriwwe gëtt. Ech wëll Dashboards net ëmschreiwen.
- Mir wëllen eng normal HA Architektur bauen.
- Mir wëllen de Konsum vun all Ressource reduzéieren.
- Et gëtt eng aner kleng Nuance. Mir kënnen net verschidden Aarte vu Cloud Metrik Sammelsystemer benotzen. Mir wëssen nach net wat an dës Metriken falen. A well do alles fléien kann, musse mir eis op lokal Placement limitéieren.
Et war wéineg Wiel. Mir hunn alles gesammelt mat deem mir Erfahrung haten. Mir hunn d'Prometheus Säit an der Integratiounssektioun gekuckt, eng Rëtsch Artikele gelies a gesinn wat dobaussen war. A fir eis selwer hu mir VictoriaMetrics als Ersatz fir Prometheus gewielt.
Firwat? Well:
- Weess promql.
- Et gëtt eng modulär Architektur.
- Erfuerdert keng Ännerunge fir Grafana.
- A wat wichteg ass, wäerte mir méiglecherweis d'Metrikenlagerung an eiser Firma als Service ubidden, also kucken mir am Viraus no Restriktiounen vu verschiddenen Aarte fir datt d'Benotzer all d'Ressourcen vum Cluster op eng limitéiert Manéier benotze kënnen, well et eng Chance ass datt et Multitenancy wäert.
Loosst eis den éischte Verglach maachen. Mir huelen déi selwecht Prometheus am Stärekoup, externen Prometheus geet et. Füügt iwwer RemoteWrite VictoriaMetrics.
Ech wäert direkt eng Reservatioun maachen, datt hei mir eng liicht Erhéijung vun CPU Konsum vun VictoriaMetrics gefaangen. D'VictoriaMetrics Wiki seet Iech wéi eng Parameteren am Beschten sinn. Mir hunn se iwwerpréift. Si hunn CPU Konsum ganz gutt reduzéiert.
An eisem Fall ass de Gedächtnisverbrauch vum Prometheus, deen am Kubernetes-Cluster läit, net wesentlech eropgaang.
Mir vergläichen zwou Datequellen vun der selwechter Donnéeën. Am Prometheus gesi mir déiselwecht fehlend Donnéeën. Alles ass gutt bei VictoriaMetrics.
Disk Space Test Resultater. Mir um Prometheus kruten am Ganzen 120 Gigabyte. Bei VictoriaMetrics kréie mir schonn 4 Gigabyte pro Dag. Et gëtt e bëssen anere Mechanismus wéi dat wat mir gewinnt sinn am Prometheus ze gesinn. Dat ass, d'Donnéeën sinn schonn zimlech gutt an engem Dag kompriméiert, an eng hallef Stonn. Déi sinn schonn an engem Dag, an enger hallwer Stonn, gutt ernannt ginn, obwuel d'Donnéeë spéider nach verluer sinn. Als Resultat hu mir op Disk Space gespuert.
Mir retten och op Erënnerung Ressource Konsum. Zu der Zäit vum Test hu mir Prometheus op enger virtueller Maschinn ofgesat - 8 Kären, 24 Gigabytes. Prometheus ësst bal alles. Hien ass op OOM Killer gefall. Zur selwechter Zäit goufen nëmmen 900 aktive Metriken an et gegoss. Dëst ass ongeféier 000-25 Metriken pro Sekonn.
Mir hunn VictoriaMetrics op enger Dual-Core virtuell Maschinn mat 8 Gigabyte RAM gelaf. Mir hunn et fäerdeg bruecht VictoriaMetrics gutt ze schaffen andeems mir mat e puer Saachen op enger 8GB Maschinn gefiddert hunn. Um Enn hu mir et op 7 Gigabyte behalen. Zur selwechter Zäit war d'Geschwindegkeet vun der Liwwerung vum Inhalt, dh Metriken, nach méi héich wéi déi vum Prometheus.
D'CPU ass vill besser ginn am Verglach zum Prometheus. Hei verbraucht Prometheus 2,5 Kären, a VictoriaMetrics verbraucht nëmmen 0,25 Kären. Am Ufank - 0,5 Kär. Wéi et fusionéiert, erreecht et ee Kär, awer dëst ass extrem, extrem seelen.
An eisem Fall ass d'Wiel op VictoriaMetrics aus offensichtleche Grënn gefall; mir wollte Sue spueren a mir hunn et gemaach.
Loosst eis direkt zwee Punkten ausstrecken - eropluede Metriken an héije Ressourcenverbrauch. A mir musse just zwee Punkten entscheeden, déi mir nach fir eis selwer hunn.
Hei wäert ech direkt eng Reservatioun maachen, mir betruechten VictoriaMetrics als Späichere vu Metriken. Awer well mir héchstwahrscheinlech VictoriaMetrics als Lagerung fir all Leroy ubidden, musse mir déi limitéieren déi dëse Stärekoup benotze fir datt se et eis net ginn.
Et gëtt e wonnerbare Parameter deen Iech erlaabt Iech duerch Zäit ze limitéieren, duerch Volumen vun Daten an Ausféierungszäit.
Et gëtt och eng exzellent Optioun, déi eis erlaabt Erënnerung Konsum ze limitéieren, doduerch kënne mir déi ganz Gläichgewiicht fannen dass eis normal Betribssystemer Vitesse an adäquate Ressource Konsum ze kréien erlaabt.
Minus e Punkt méi, dh de Punkt ausstrecken - Dir kënnt d'Erënnerungsverbrauch net limitéieren.
An den éischten Iteratiounen hu mir VictoriaMetrics Single Node getest. Als nächst fuere mer op d'VictoriaMetrics Cluster Versioun.
Hei hu mir eng fräi Hand fir verschidde Servicer zu VictoriaMetrics ze trennen ofhängeg vun deem wat se lafen a wéi eng Ressourcen se verbrauchen. Dëst ass eng ganz flexibel a praktesch Léisung. Mir hunn dëst op eis selwer benotzt.
D'Haaptkomponente vun der VictoriaMetrics Cluster Versioun sinn vmstsorage. Et kann N Zuel vun hinnen ginn. An eisem Fall sinn et der bis elo 2.
An et gëtt vminsert. Dëst ass e Proxy Server deen eis erlaabt: Sharding tëscht all de Späicher ze arrangéieren, iwwer déi mir et gesot hunn, an et erlaabt och eng Replika, dh Dir wäert souwuel Sharding wéi och eng Replika hunn.
Vminsert ënnerstëtzt OpenTSDB, Graphite, InfluxDB a RemoteWrite Protokoller vu Prometheus.
Et gëtt och vmselect. Seng Haaptaufgab ass op vmstorage ze goen, Daten vun hinnen ze kréien, dës Donnéeën deduplizéieren an dem Client ze ginn.
Et gëtt eng wonnerbar Saach genannt vmagent. Mir hunn hatt wierklech gär. Et erlaabt Iech genau wéi Prometheus ze konfiguréieren an ëmmer nach alles genau wéi Prometheus ze maachen. Dat ass, et sammelt Metriken aus verschiddenen Entitéiten a Servicer a schéckt se op vminsert. Dann hänkt alles vun Iech of.
En anere grousse Service ass vmalert, wat Iech erlaabt VictoriaMetrics als Backend ze benotzen, veraarbecht Donnéeën vu vminsert ze kréien a se op vmselect schécken. Et veraarbecht d'Alarme selwer, souwéi d'Regele. Am Fall vun Alarmer kréien mir d'Alarm iwwer den Alertmanager.
Et gëtt eng wmauth Komponent. Mir kënnen oder vläicht net (mir hunn nach net iwwer dëst decidéiert) et als Autorisatioun System fir Multitenancy Versioun vu Cluster benotzen. Et ënnerstëtzt RemoteWrite fir Prometheus a kann autoriséieren baséiert op der URL, oder éischter den zweeten Deel dovun, wou Dir kënnt oder net schreiwen.
Et gëtt och vmbackup, vmrestore. Dëst ass am Wesentlechen d'Restauratioun a Backup vun all Daten. Kann S3, GCS, Datei maachen.
Déi éischt Iteratioun vun eisem Stärekoup gouf während der Quarantän gemaach. Zu där Zäit gouf et keng Replika, sou datt eis Iteratioun aus zwee verschiddenen an onofhängege Stärekéip bestoung, an déi mir Daten iwwer RemoteWrite kruten.
Hei wäert ech reservéieren datt wa mir vum VictoriaMetrics Single Node op d'VictoriaMetrics Cluster Versioun gewiesselt sinn, mir nach ëmmer mat de selwechte verbrauchte Ressourcen bliwwe sinn, dat heescht den Haaptgrond ass Erënnerung. Dat ass ongeféier wéi eis Donnéeën, also de Ressourceverbrauch, verdeelt goufen.
Eng Replica gouf hei schonn dobäigesat. Mir hunn dat alles an ee relativ grousse Cluster kombinéiert. All eis Donnéeën sinn zerstéiert a replizéiert.
De ganze Stärekoup huet N Entréespunkten, dat heescht datt Prometheus Daten iwwer HAPROXY ka addéieren. Hei hu mir dësen Entréespunkt. An duerch dësen Entrée kënnt Dir Iech vu Grafana aloggen.
An eisem Fall ass HAPROXY deen eenzegen Hafen deen Proxyen auswielen, setzen an aner Servicer an dësem Cluster. An eisem Fall war et onméiglech eng Adress ze maachen; mir hu missen e puer Entréespunkte maachen, well déi virtuell Maschinnen selwer, op deenen de VictoriaMetrics-Cluster leeft, sinn a verschiddenen Zonen vum selwechte Cloud-Provider, also net an eiser Wollek, mee dobaussen. .
Mir hunn Alarm. Mir benotzen et. Mir benotzen Alertmanager vu Prometheus. Mir benotzen Opsgenie an Telegram als Alarm Liwwerungskanal. Am Telegram gi se vun Dev eran, vläicht eppes vu Prod, awer meeschtens eppes statistesches, gebraucht vun Ingenieuren. An Opsgenie ass kritesch. Dëst sinn Uriff, Incidentmanagement.
Déi éiweg Fro: "Wien iwwerwaacht d'Iwwerwaachung?" An eisem Fall, Iwwerwaachungsmonitore iwwerwaachen sech selwer, well mir vmagent op all Node benotzen. A well eis Noden iwwer verschidden Datenzentere vum selwechte Provider verdeelt sinn, huet all Datenzenter säin eegene Kanal, si sinn onofhängeg, an och wann e gesplécktem Gehir ukomm ass, kréie mir nach ëmmer Alarmer. Jo, et wäerte méi vun hinnen sinn, awer et ass besser méi Alarmer ze kréien wéi keng.
Mir schléissen eis Lëscht mat enger HA-Implementatioun of.
A weider wëll ech d'Erfahrung notéieren fir mat der VictoriaMetrics Gemeinschaft ze kommunizéieren. Et huet sech ganz positiv erausgestallt. D'Kärelen sinn reaktiounsfäeger. Si probéieren all Fall ze verdéiwen, deen ugebuede gëtt.
Ech hunn Themen op GitHub ugefaang. Si goufen ganz séier geléist. Et ginn e puer méi Themen déi net komplett zougemaach sinn, awer ech ka scho vum Code gesinn datt d'Aarbecht an dëser Richtung amgaang ass.
D'Haaptrei Péng fir mech während Iteratiounen war, datt wann ech e Node zougemaach, dann fir déi éischt 30 Sekonnen vminsert konnt net verstoen, datt et kee Backend war. Dat ass elo decidéiert. A wuertwiertlech an enger Sekonn oder zwee ginn d'Donnéeën vun all de verbleiwen Noden geholl, an d'Ufro stoppt op dee fehlenden Node ze waarden.
Irgendwann wollte mir datt VictoriaMetrics e VictoriaMetrics Bedreiwer wier. Mir waarden op hien. Mir bauen elo aktiv e Kader fir de VictoriaMetrics Bedreiwer fir all Pre-Berechnungsregelen ze huelen, etc. Prometheus, well mir ganz aktiv d'Regele benotzen déi mam Prometheus Bedreiwer kommen.
Et gi Virschléi fir d'Ëmsetzung vum Cluster ze verbesseren. Ech hunn se uewen duergestallt.
An ech wëll wierklech downsample. An eisem Fall ass Downsampling exklusiv gebraucht fir Trends ze gesinn. Grof geschwat ass eng Metrik fir mech am Dag genuch. Dës Trends sinn néideg fir ee Joer, dräi, fënnef, zéng Joer. An ee metresche Wäert ass ganz genuch.
- Mir hunn Péng bekannt, wéi e puer vun eise Kollegen, wann Dir Prometheus benotzt.
- Mir hunn VictoriaMetrics fir eis gewielt.
- Et scaléiert ganz gutt souwuel vertikal an horizontal.
- Mir kënne verschidde Komponenten op verschidden Zuelen vun Noden am Stärekoup verdeelen, se duerch Erënnerung limitéieren, Erënnerung addéieren, etc.
Mir wäerten VictoriaMetrics doheem benotzen well mir et wierklech gär hunn. Dëst ass wat war a wat ass ginn.
E puer QR Coden fir VictoriaMetrics Chat, meng Kontakter, LeroyMerlin technesche Radar.
Source: will.com