VictoriaMetrics estas rapida kaj skalebla DBMS por stoki kaj prilabori datumojn en formo de temposerio (rekordo konsistas el tempo kaj aro de valoroj respondaj al ĉi tiu tempo, ekzemple, akiritaj per perioda sondado de la statuso de sensiloj aŭ kolekto de metrikoj).
Mia nomo estas Kolobaev Pavel. DevOps, SRE, LeroyMerlin, ĉio estas kiel kodo - ĉio temas pri ni: pri mi kaj pri aliaj dungitoj de LeroyMerlin.
Estas nubo bazita sur OpenStack. Estas malgranda ligo al la teknika radaro.
Ĝi estas konstruita sur la aparataro Kubernetes, same kiel sur ĉiuj rilataj servoj por OpenStack kaj protokolado.
Ĉi tiu estas la skemo, kiun ni havis en evoluo. Kiam ni disvolvis ĉion ĉi, ni havis Prometheus-funkciigiston, kiu stokis datumojn ene de la K8s-areto mem. Li aŭtomate trovas tion, kion oni devas froti, kaj metas ĝin sub siajn piedojn, proksimume.
Ni devos movi ĉiujn datumojn ekster la Kubernetes-areo, ĉar se io okazas, ni devas kompreni kio kaj kie.
La unua solvo estas, ke ni uzas federacion kiam ni havas triapartan Prometheus, kiam ni iras al la Kubernetes-grupo per la federacia mekanismo.
Sed estas kelkaj malgrandaj problemoj ĉi tie. En nia kazo, la problemoj komenciĝis kiam ni havis 250 metrikojn, kaj kiam estis 000 metrikoj, ni rimarkis, ke ni ne povus funkcii tiel. Ni pliigis scrape_timeout al 400 sekundoj.
Kial ni devis fari ĉi tion? Prometeo komencas kalkuli la paŭzon de la komenco de la barilo. Ne gravas, ke la datumoj ankoraŭ fluas. Se dum ĉi tiu specifita tempodatumo ne estas kunfanditaj kaj la sesio ne estas fermita per http, tiam la sesio estas konsiderata malsukcesinta kaj la datumoj ne eniras en Prometheus mem.
Ĉiuj konas la grafikaĵojn, kiujn ni ricevas kiam kelkaj el la datumoj mankas. La horaroj estas disŝiritaj kaj ni ne estas feliĉaj pri tio.
La sekva opcio estas sharding bazita sur du malsamaj Prometheus per la sama federacia mekanismo.
Ekzemple, simple prenu ilin kaj dividu ilin laŭnome. Ĉi tio ankaŭ povas esti uzata, sed ni decidis pluiri.
Ni nun devos prilabori ĉi tiujn pecetojn iel. Vi povas preni promxy, kiu iras al la breĉeta areo kaj multobligas la datumojn. Ĝi funkcias kun du pecetoj kiel ununura enirpunkto. Ĉi tio povas esti efektivigita per promxy, sed ĝi estas ankoraŭ tro malfacila.
La unua opcio estas, ke ni volas forlasi la federacian mekanismon ĉar ĝi estas tre malrapida.
La programistoj de Prometheus klare diras, "Knaboj, uzu malsaman TimescaleDB ĉar ni ne subtenos longdaŭran stokadon de metrikoj." Ĉi tio ne estas ilia tasko.
Ni skribas sur papero, kiun ni ankoraŭ bezonas elŝuti ekstere, por ne konservi ĉion en unu loko.
La dua malavantaĝo estas memorkonsumo. Jes, mi komprenas, ke multaj diros, ke en 2020 paro da gigabajtoj da memoro kostas pencon, sed tamen.
Nun ni havas dev- kaj prod-medion. En dev ĝi estas proksimume 9 gigabajtoj por 350 metrikoj. En prod ĝi estas 000 gigabajtoj kaj iom pli ol 14 metrikoj. Samtempe, nia retentempo estas nur 780 minutoj. Ĉi tio estas malbona. Kaj nun mi klarigos kial.
Ni faras kalkulon, tio estas, kun miliono kaj duono da metrikoj, kaj ni jam estas proksimaj al ili, en la desegna stadio ni ricevas 35-37 gigabajtojn da memoro. Sed jam 4 milionoj da metrikoj postulas ĉirkaŭ 90 gigabajtojn da memoro. Tio estas, ĝi estis kalkulita per la formulo provizita de la programistoj de Prometheus. Ni rigardis la korelacion kaj rimarkis, ke ni ne volas pagi kelkajn milionojn por servilo nur por monitorado.
Ni ne nur pliigos la nombron da maŝinoj, ni ankaŭ kontrolas la virtualajn maŝinojn mem. Tial, ju pli da virtualaj maŝinoj, des pli da metrikoj de diversaj specoj, ktp. Ni havos specialan kreskon de nia areto laŭ metriko.
Kun diskspaco, ĉi tie ne ĉio estas tiel malbona, sed mi ŝatus plibonigi ĝin. Ni ricevis entute 15 gigabajtojn en 120 tagoj, el kiuj 100 estas kunpremitaj datumoj, 20 estas nekunpremitaj datumoj, sed ni ĉiam volas malpli.
Sekve, ni notas unu plian punkton - tio estas granda konsumo de rimedoj, kiujn ni ankoraŭ volas ŝpari, ĉar ni ne volas, ke nia monitora areto konsumu pli da rimedoj ol nia areto, kiu administras OpenStack.
Estas unu plia malavantaĝo de Prometeo, kiun ni mem identigis, ĉi tio estas almenaŭ ia memorlimigo. Kun Prometeo, ĉio estas multe pli malbona ĉi tie, ĉar ĝi tute ne havas tiajn tordojn. Uzi limon en docker ankaŭ ne estas opcio. Se subite via RAF falis kaj estas 20-30 gigabajtoj, tiam necesos tre longa tempo por leviĝi.
Ĉi tio estas alia kialo, kial Prometeo ne taŭgas por ni, t.e. ni ne povas limigi memorkonsumon.
Eblus elpensi tian skemon. Ni bezonas ĉi tiun skemon por organizi HA-grupon. Ni volas, ke niaj metrikoj estu disponeblaj ĉiam kaj ĉie, eĉ se la servilo, kiu stokas ĉi tiujn metrikojn, kraŝas. Kaj tiel ni devos konstrui tian skemon.
Ĉi tiu skemo diras, ke ni havos duobligon de fragmentoj, kaj sekve, duobligon de la kostoj de konsumitaj rimedoj. Ĝi povas esti grimpita preskaŭ horizontale, sed tamen la resursa konsumo estos infera.
Malavantaĝoj en ordo en la formo, en kiu ni mem skribis ilin:
- Postulas alŝuti mezurojn ekstere.
- Alta konsumo de rimedoj.
- Ne estas maniero limigi memorkonsumon.
- Kompleksa kaj rimed-intensa efektivigo de HA.
Ni mem decidis, ke ni malproksimiĝas de Prometeo kiel stokejo.
Ni identigis pliajn postulojn por ni mem, kiujn ni bezonas. Ĉi tio:
- Ĉi tio estas promql-subteno, ĉar multaj aferoj jam estis skribitaj por Prometheus: demandoj, atentigoj.
- Kaj tiam ni havas Grafana, kiu jam estas skribita ĝuste en la sama maniero por Prometeo kiel backend. Mi ne volas reverki panelojn.
- Ni volas konstrui normalan HA-arkitekturon.
- Ni volas redukti la konsumon de ajnaj rimedoj.
- Estas alia malgranda nuanco. Ni ne povas uzi diversajn specojn de nubo-metrikaj kolektosistemoj. Ni ankoraŭ ne scias, kio falos en ĉi tiujn metrikojn. Kaj ĉar io ajn povas flugi tien, ni devas limigi nin al loka lokigo.
Estis malmulte da elekto. Ni kolektis ĉion, pri kio ni havis sperton. Ni rigardis la paĝon de Prometheus en la sekcio pri integriĝo, legis amason da artikoloj kaj vidis kio estas tie. Kaj por ni mem, ni elektis VictoriaMetrics kiel anstataŭaĵon de Prometheus.
Kial? Ĉar:
- Povas fari promql.
- Estas modula arkitekturo.
- Ne postulas ŝanĝojn al Grafana.
- Kaj plej grave, ni verŝajne provizos la metrikan stokadon ene de nia kompanio kiel servo, do ni antaŭrigardas al diversaj specoj de limigoj, por ke uzantoj povu uzi ĉiujn rimedojn de la areto en iu limigita maniero, ĉar estas ŝanco. ke ĝi estos plurtenanto.
Ni faru la unuan komparon. Ni prenas la saman Prometeon ene de la areto, ekstera Prometeo iras al ĝi. Aldonu per foraSkribu VictoriaMetrics.
Mi tuj faros rezervon, ke ĉi tie ni kaptis iomete pliiĝon en CPU-konsumo de VictoriaMetrics. La VictoriaMetrics-vikio diras al vi, kiuj parametroj estas plej bonaj. Ni kontrolis ilin. Ili tre bone reduktis CPU-konsumon.
En nia kazo, la memorkonsumo de Prometheus, kiu situas en la Kubernetes-areo, ne signife pliiĝis.
Ni komparas du datumfontojn de la samaj datumoj. En Prometeo ni vidas la samajn mankantajn datumojn. Ĉio estas bona ĉe VictoriaMetrics.
Diskospaco-testrezultoj. Ni ĉe Prometeo ricevis 120 gigabajtojn entute. Ĉe VictoriaMetrics ni jam ricevas 4 gigabajtojn ĉiutage. Estas iomete malsama mekanismo ol tio, kion ni kutimas vidi en Prometeo. Tio estas, la datumoj jam estas sufiĉe bone kunpremitaj en tago, en duonhoro. Ili jam bone rikoltis en tago, en duonhoro, malgraŭ tio, ke la datumoj ankoraŭ poste perdiĝos. Kiel rezulto, ni ŝparis sur diskspaco.
Ni ankaŭ ŝparas je konsumo de memoraj rimedoj. En la tempo de testado, ni havis Prometheus deplojita sur virtuala maŝino - 8 kernoj, 24 gigabajtoj. Prometeo manĝas preskaŭ ĉion. Li falis sur OOM Killer. Samtempe, nur 900 aktivaj metrikoj estis verŝitaj en ĝin. Ĉi tio estas ĉirkaŭ 000-25 metrikoj je sekundo.
Ni kuris VictoriaMetrics sur dukerna virtuala maŝino kun 8 gigabajtoj da RAM. Ni sukcesis bonege funkcii VictoriaMetrics per ludado kun kelkaj aferoj sur 8GB-maŝino. En la fino, ni konservis ĝin al 7 gigabajtoj. Samtempe, la rapideco de livero de enhavo, t.e. metriko, estis eĉ pli alta ol tiu de Prometeo.
La CPU fariĝis multe pli bona kompare kun Prometheus. Ĉi tie Prometheus konsumas 2,5 kernojn, kaj VictoriaMetrics nur konsumas 0,25 kernojn. Komence - 0,5 kernoj. Dum ĝi kunfandiĝas, ĝi atingas unu kernon, sed ĉi tio estas ege, ege malofta.
En nia kazo, la elekto falis sur VictoriaMetrics pro evidentaj kialoj; ni volis ŝpari monon kaj ni faris.
Ni forstreku du punktojn tuj - la alŝuto de metrikoj kaj la alta konsumo de rimedoj. Kaj ni devas nur decidi du punktojn, kiujn ni ankoraŭ lasis al ni.
Ĉi tie mi tuj faros rezervon, ni konsideras VictoriaMetrics kiel stokadon de metrikoj. Sed ĉar ni plej verŝajne provizos VictoriaMetrics kiel stokado por la tuta Leroy, ni devas limigi tiujn, kiuj uzos ĉi tiun areton, por ke ili ne donu ĝin al ni.
Estas mirinda parametro, kiu permesas vin limigi laŭ tempo, laŭ volumo de datumoj kaj laŭ ekzekuttempo.
Ankaŭ ekzistas bonega eblo, kiu ebligas al ni limigi la konsumon de memoro, tiel ni povas trovi la ekvilibron, kiu permesos al ni akiri normalan operacian rapidon kaj taŭgan konsumon de rimedoj.
Minus unu plia punkto, t.e. forstreku la punkton - vi ne povas limigi memorkonsumon.
En la unuaj ripetoj, ni testis VictoriaMetrics Single Node. Poste ni pluiru al VictoriaMetrics Cluster Version.
Ĉi tie ni havas liberan manon por apartigi malsamajn servojn en VictoriaMetrics depende de tio, per kio ili funkcios kaj kiajn rimedojn ili konsumos. Ĉi tio estas tre fleksebla kaj oportuna solvo. Ni uzis ĉi tion sur ni mem.
La ĉefaj komponantoj de VictoriaMetrics Cluster Version estas vmstsorage. Povas esti N nombro da ili. En nia kazo estas 2 el ili ĝis nun.
Kaj estas vminsert. Ĉi tio estas prokura servilo, kiu ebligas al ni: aranĝi sharding inter ĉiuj stokaĵoj pri kiuj ni rakontis ĝin, kaj ĝi ankaŭ permesas kopion, t.e. vi havos kaj sharding kaj kopion.
Vminsert subtenas OpenTSDB, Graphite, InfluxDB kaj remoteWrite protokolojn de Prometheus.
Ekzistas ankaŭ vmselect. Ĝia ĉefa tasko estas iri al vmstorage, ricevi datumojn de ili, dedupliki ĉi tiujn datumojn kaj doni ĝin al la kliento.
Estas mirinda afero nomata vmagent. Ni tre ŝatas ŝin. Ĝi permesas vin agordi ĝuste kiel Prometheus kaj ankoraŭ fari ĉion ekzakte kiel Prometheus. Tio estas, ĝi kolektas metrikojn de malsamaj entoj kaj servoj kaj sendas ilin al vminsert. Tiam ĉio dependas de vi.
Alia bonega servo estas vmalert, kiu permesas vin uzi VictoriaMetrics kiel backend, ricevi prilaboritajn datumojn de vminsert kaj sendi ĝin al vmselect. Ĝi prilaboras la atentigojn mem, same kiel la regulojn. En la kazo de atentigoj, ni ricevas la atentigon per alertmanager.
Estas wmauth-komponento. Ni eble aŭ ne (ni ankoraŭ ne decidis pri tio) uzi ĝin kiel rajtigan sistemon por la plurtenanta versio de aretoj. Ĝi subtenas remoteWrite por Prometheus kaj povas rajtigi surbaze de la url, aŭ pli ĝuste la dua parto de ĝi, kie vi povas aŭ ne povas skribi.
Ekzistas ankaŭ vmbackup, vmrestore. Ĉi tio estas, esence, la restarigo kaj sekurkopio de ĉiuj datumoj. Povas fari S3, GCS, dosieron.
La unua ripeto de nia areto estis farita dum kvaranteno. En tiu tempo, ekzistis neniu kopio, do nia ripeto konsistis el du malsamaj kaj sendependaj aretoj en kiuj ni ricevis datumojn per remoteWrite.
Ĉi tie mi faros rezervon, ke kiam ni ŝanĝis de VictoriaMetrics Single Node al VictoriaMetrics Cluster Version, ni ankoraŭ restis kun la samaj konsumitaj rimedoj, t.e. la ĉefa estas memoro. Ĉi tio estas proksimume kiel niaj datumoj, t.e. konsumo de rimedoj, estis distribuitaj.
Kopio jam estis aldonita ĉi tie. Ni kombinis ĉion ĉi en unu relative grandan areton. Ĉiuj niaj datumoj estas ambaŭ dividitaj kaj reproduktitaj.
La tuta areto havas N enirpunktojn, kio signifas, ke Prometeo povas aldoni datumojn per HAPROXY. Ĉi tie ni havas ĉi tiun enirpunkton. Kaj tra ĉi tiu enirpunkto vi povas ensaluti de Grafana.
En nia kazo, HAPROXY estas la sola haveno, kiun prokuriloj elektas, enigas kaj aliajn servojn ene de ĉi tiu areto. En nia kazo, estis neeble fari unu adreson; ni devis fari plurajn enirpunktojn, ĉar la virtualaj maŝinoj mem, sur kiuj funkcias la cluster VictoriaMetrics, situas en malsamaj zonoj de la sama nuba provizanto, t.e. ne ene de nia nubo, sed ekstere. .
Ni havas atentigon. Ni uzas ĝin. Ni uzas alertmanager de Prometheus. Ni uzas Opsgenie kaj Telegram kiel atentan liveran kanalon. En Telegramo ili enverŝas de dev, eble ion de prod, sed plejparte io statistika, bezonata de inĝenieroj. Kaj Opsgenie estas kritika. Ĉi tiuj estas alvokoj, administrado de incidentoj.
La eterna demando: "Kiu kontrolas la monitoradon?" En nia kazo, monitoroj monitoras sin mem, ĉar ni uzas vmagent sur ĉiu nodo. Kaj ĉar niaj nodoj estas distribuitaj tra malsamaj datumcentroj de la sama provizanto, ĉiu datumcentro havas sian propran kanalon, ili estas sendependaj, kaj eĉ se disigita cerbo alvenos, ni ankoraŭ ricevos atentigojn. Jes, estos pli da ili, sed estas pli bone ricevi pli da atentigoj ol neniu.
Ni finas nian liston per efektivigo de HA.
Kaj plue mi ŝatus noti la sperton de komunikado kun la komunumo VictoriaMetrics. Ĝi rezultis tre pozitiva. La infanoj estas respondemaj. Ili provas enprofundiĝi en ĉiun kazon kiu estas ofertita.
Mi komencis problemojn en GitHub. Ili estis solvitaj tre rapide. Estas kelkaj pliaj aferoj, kiuj ne estas tute fermitaj, sed mi jam povas vidi el la kodo, ke funkcias ĉi-direkte.
La ĉefa doloro por mi dum ripetoj estis, ke se mi fermis nodon, tiam dum la unuaj 30 sekundoj vminsert ne povis kompreni, ke ne ekzistas backend. Ĉi tio nun estas decidita. Kaj laŭvorte en sekundo aŭ du, la datumoj estas prenitaj de ĉiuj ceteraj nodoj, kaj la peto ĉesas atendi tiun mankantan nodon.
Iam ni volis, ke VictoriaMetrics estu VictoriaMetrics-funkciigisto. Ni atendis lin. Ni nun aktive konstruas kadron por la operaciisto VictoriaMetrics por preni ĉiujn antaŭkalkulajn regulojn, ktp. Prometheus, ĉar ni sufiĉe aktive uzas la regulojn, kiuj venas kun la operatoro Prometheus.
Estas proponoj plibonigi la cluster-efektivigon. Mi skizis ilin supre.
Kaj mi vere volas subspecimeni. En nia kazo, subspecimeno necesas ekskluzive por vidi tendencojn. Malglate parolante, unu metriko sufiĉas por mi tage. Ĉi tiuj tendencoj estas bezonataj por jaro, tri, kvin, dek jaroj. Kaj unu metrika valoro sufiĉe sufiĉas.
- Ni konis doloron, kiel iuj el niaj kolegoj, kiam ili uzas Prometeon.
- Ni elektis VictoriaMetrics por ni mem.
- Ĝi skvamas sufiĉe bone kaj vertikale kaj horizontale.
- Ni povas distribui malsamajn komponentojn al malsamaj nombroj da nodoj en la areto, limigi ilin per memoro, aldoni memoron, ktp.
Ni uzos VictoriaMetrics hejme ĉar ni tre ŝatis ĝin. Jen kio estis kaj kio fariĝis.
Paro da QR-kodoj por VictoriaMetrics-babilejo, miaj kontaktoj, teknika radaro de LeroyMerlin.
fonto: www.habr.com