VictoriaMetrics er et raskt og skalerbart DBMS for lagring og behandling av data i form av en tidsserie (en post består av tid og et sett med verdier som tilsvarer denne tiden, for eksempel oppnådd gjennom periodisk polling av statusen til sensorer eller samling av beregninger).
Mitt navn er Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alt er som kode - alt handler om oss: om meg og om andre LeroyMerlin-ansatte.
Det er en sky basert på OpenStack. Det er en liten lenke til den tekniske radaren.
Den er bygget på Kubernetes-maskinvaren, så vel som på alle relaterte tjenester for OpenStack og logging.
Dette er opplegget vi hadde under utvikling. Da vi utviklet alt dette, hadde vi en Prometheus-operatør som lagret data inne i selve K8s-klyngen. Han finner automatisk det som skal skrubbes og legger det under føttene, grovt sett.
Vi må flytte alle dataene utenfor Kubernetes-klyngen, for hvis noe skjer, må vi forstå hva og hvor.
Den første løsningen er at vi bruker føderasjon når vi har en tredjeparts Prometheus, når vi går til Kubernetes-klyngen gjennom føderasjonsmekanismen.
Men det er noen små problemer her. I vårt tilfelle startet problemene da vi hadde 250 000 målinger, og da det var 400 000 målinger, innså vi at vi ikke kunne jobbe slik. Vi økte scrape_timeout til 25 sekunder.
Hvorfor måtte vi gjøre dette? Prometheus begynner å telle timeout fra begynnelsen av gjerdet. Det spiller ingen rolle at dataene fortsatt flyter. Hvis dataene ikke er slått sammen i løpet av denne angitte tidsperioden og økten ikke lukkes via http, anses økten å ha mislyktes og dataene kommer ikke inn i selve Prometheus.
Alle er kjent med grafene som vi får når noen av dataene mangler. Timeplanene er revet og vi er ikke fornøyd med dette.
Det neste alternativet er sharding basert på to forskjellige Prometheus gjennom samme føderasjonsmekanisme.
For eksempel, bare ta dem og sønderdele dem ved navn. Dette kan også brukes, men vi bestemte oss for å gå videre.
Vi må nå behandle disse skårene på en eller annen måte. Du kan ta promxy, som går til shard-området og multipliserer dataene. Den fungerer med to skår som ett enkelt inngangspunkt. Dette kan implementeres gjennom promxy, men det er fortsatt for vanskelig.
Det første alternativet er at vi ønsker å forlate føderasjonsmekanismen fordi den er veldig treg.
Prometheus-utviklerne sier tydelig: "Gutter, bruk en annen TimescaleDB fordi vi ikke støtter langsiktig lagring av beregninger." Dette er ikke deres oppgave.
Vi skriver ned på et stykke papir som vi fortsatt trenger å losse utenfor, for ikke å lagre alt på ett sted.
Den andre ulempen er minneforbruk. Ja, jeg forstår at mange vil si at i 2020 koster et par gigabyte minne en krone, men likevel.
Nå har vi et utvikler- og prodmiljø. I dev er det omtrent 9 gigabyte for 350 000 metrikk. I produksjon er det 14 gigabyte og litt over 780 000 metrikk. Samtidig er oppbevaringstiden vår kun 30 minutter. Dette er dårlig. Og nå skal jeg forklare hvorfor.
Vi gjør en beregning, det vil si med halvannen million beregninger, og vi er allerede nær dem, på designstadiet får vi 35-37 gigabyte minne. Men allerede 4 millioner metrikker krever omtrent 90 gigabyte minne. Det vil si at det ble beregnet ved å bruke formelen gitt av Prometheus-utviklerne. Vi så på korrelasjonen og innså at vi ikke ønsket å betale et par millioner for en server bare for overvåking.
Vi vil ikke bare øke antall maskiner, vi overvåker også selve de virtuelle maskinene. Derfor, jo flere virtuelle maskiner, jo flere metrikker av ulike slag osv. Vi vil ha en spesiell vekst av klyngen vår når det gjelder metrikk.
Med diskplass er ikke alt så ille her, men jeg vil gjerne forbedre det. Vi fikk totalt 15 gigabyte på 120 dager, hvorav 100 er komprimerte data, 20 er ukomprimerte data, men vi vil alltid ha mindre.
Følgelig skriver vi ned ett punkt til - dette er et stort ressursforbruk, som vi fortsatt ønsker å spare, fordi vi ikke ønsker at overvåkingsklyngen vår skal forbruke mer ressurser enn klyngen vår, som administrerer OpenStack.
Det er enda en ulempe med Prometheus, som vi har identifisert for oss selv, dette er i det minste en slags minnebegrensning. Med Prometheus er alt mye verre her, fordi det ikke har slike vendinger i det hele tatt. Å bruke en grense i docker er heller ikke et alternativ. Hvis RAF plutselig falt og det er 20-30 gigabyte, vil det ta veldig lang tid å stige.
Dette er en annen grunn til at Prometheus ikke passer for oss, det vil si at vi ikke kan begrense minneforbruket.
Det ville vært mulig å komme med en slik ordning. Vi trenger denne ordningen for å kunne organisere en HA-klynge. Vi vil at våre beregninger skal være tilgjengelige alltid og overalt, selv om serveren som lagrer disse beregningene krasjer. Og dermed blir vi nødt til å bygge en slik ordning.
Denne ordningen sier at vi vil ha duplisering av skår, og følgelig duplisering av kostnadene for forbrukte ressurser. Den kan skaleres nesten horisontalt, men likevel blir ressursforbruket helvete.
Ulemper i rekkefølge i den formen vi skrev dem ned for oss selv:
- Krever opplasting av beregninger eksternt.
- Høyt ressursforbruk.
- Det er ingen måte å begrense minneforbruket på.
- Kompleks og ressurskrevende implementering av HA.
For oss selv bestemte vi at vi skulle flytte bort fra Prometheus som et lager.
Vi har identifisert ytterligere krav til oss selv som vi trenger. Dette:
- Dette er promql-støtte, fordi mange ting allerede er skrevet for Prometheus: spørringer, varsler.
- Og så har vi Grafana, som allerede er skrevet på nøyaktig samme måte for Prometheus som backend. Jeg vil ikke skrive om dashboards.
- Vi ønsker å bygge en vanlig HA-arkitektur.
- Vi ønsker å redusere forbruket av eventuelle ressurser.
- Det er en annen liten nyanse. Vi kan ikke bruke ulike typer innsamlingssystemer for skyberegninger. Vi vet ikke hva som faller inn i disse beregningene ennå. Og siden alt kan fly dit, må vi begrense oss til lokal plassering.
Det var lite valg. Vi samlet alt vi hadde erfaring med. Vi så på Prometheus-siden i integrasjonsdelen, leste en haug med artikler og så hva som var der ute. Og for oss selv valgte vi VictoriaMetrics som erstatning for Prometheus.
Hvorfor? Fordi:
- Kan gjøre promql.
- Det er en modulær arkitektur.
- Krever ikke endringer i Grafana.
- Og viktigst av alt, vi vil sannsynligvis gi metrikklagringen i selskapet vårt som en tjeneste, så vi ser på forhånd mot restriksjoner av ulike slag slik at brukere kan bruke alle ressursene i klyngen på en begrenset måte, fordi det er en sjanse at det vil flerhushold.
La oss gjøre den første sammenligningen. Vi tar den samme Prometheus inne i klyngen, ekstern Prometheus går til den. Legg til via remoteWrite VictoriaMetrics.
Jeg tar umiddelbart forbehold om at her fanget vi en liten økning i CPU-forbruk fra VictoriaMetrics. VictoriaMetrics-wikien forteller deg hvilke parametere som er best. Vi sjekket dem. De har redusert CPU-forbruket veldig bra.
I vårt tilfelle økte ikke minneforbruket til Prometheus, som ligger i Kubernetes-klyngen, nevneverdig.
Vi sammenligner to datakilder med samme data. I Prometheus ser vi de samme manglende dataene. Alt er bra hos VictoriaMetrics.
Diskplass testresultater. Vi i Prometheus fikk 120 gigabyte totalt. Hos VictoriaMetrics mottar vi allerede 4 gigabyte per dag. Det er en litt annen mekanisme enn det vi er vant til å se i Prometheus. Det vil si at dataene allerede er komprimert ganske godt på en dag, på en halvtime. De er allerede høstet godt på et døgn, på en halvtime, til tross for at dataene fortsatt vil gå tapt senere. Som et resultat sparte vi diskplass.
Vi sparer også på minneressursforbruk. På tidspunktet for testingen hadde vi Prometheus utplassert på en virtuell maskin - 8 kjerner, 24 gigabyte. Prometheus spiser nesten alt. Han falt på OOM Killer. På samme tid ble bare 900 000 aktive beregninger strømmet inn i den. Dette er omtrent 25 000-27 000 metrikk per sekund.
Vi kjørte VictoriaMetrics på en dual-core virtuell maskin med 8 gigabyte RAM. Vi klarte å få VictoriaMetrics til å fungere godt ved å fikle med et par ting på en 8GB-maskin. Til slutt holdt vi det til 7 gigabyte. Samtidig var hastigheten på levering av innhold, dvs. beregninger, enda høyere enn Prometheus.
CPU-en har blitt mye bedre sammenlignet med Prometheus. Her bruker Prometheus 2,5 kjerner, og VictoriaMetrics bruker bare 0,25 kjerner. Ved starten - 0,5 kjerner. Når den smelter sammen, når den én kjerne, men dette er ekstremt, ekstremt sjeldent.
I vårt tilfelle falt valget på VictoriaMetrics av åpenbare grunner; vi ønsket å spare penger og det gjorde vi.
La oss stryke ut to punkter med en gang – opplasting av beregninger og det høye ressursforbruket. Og vi må bare avgjøre to punkter som vi fortsatt har igjen for oss selv.
Her tar jeg en reservasjon med en gang, vi anser VictoriaMetrics som en lagring av metrikk. Men siden vi mest sannsynlig vil gi VictoriaMetrics som lagring for hele Leroy, må vi begrense de som skal bruke denne klyngen slik at de ikke gir den til oss.
Det er en fantastisk parameter som lar deg begrense etter tid, volum av data og utførelsestid.
Det er også et utmerket alternativ som lar oss begrense minneforbruket, og dermed kan vi finne selve balansen som vil tillate oss å få normal driftshastighet og tilstrekkelig ressursforbruk.
Minus ett punkt til, dvs. kryss ut punktet - du kan ikke begrense minneforbruket.
I de første iterasjonene testet vi VictoriaMetrics Single Node. Deretter går vi videre til VictoriaMetrics Cluster Version.
Her har vi frie hender til å skille ulike tjenester i VictoriaMetrics avhengig av hva de skal kjøre på og hvilke ressurser de vil forbruke. Dette er en veldig fleksibel og praktisk løsning. Vi brukte dette på oss selv.
Hovedkomponentene i VictoriaMetrics Cluster Version er vmstsorage. Det kan være N antall av dem. I vårt tilfelle er det 2 av dem så langt.
Og det er vminsert. Dette er en proxy-server som lar oss: ordne sharding mellom alle lagringene vi fortalte den om, og den tillater også en replika, det vil si at du vil ha både sharding og en replika.
Vminsert støtter OpenTSDB, Graphite, InfluxDB og remoteWrite-protokoller fra Prometheus.
Det er også vmselect. Hovedoppgaven er å gå til vmstorage, motta data fra dem, deduplisere disse dataene og gi dem til klienten.
Det er en fantastisk ting som heter vmagent. Vi liker henne veldig godt. Den lar deg konfigurere akkurat som Prometheus og fortsatt gjøre alt akkurat som Prometheus. Det vil si at den samler inn beregninger fra forskjellige enheter og tjenester og sender dem til vminsert. Da avhenger alt av deg.
En annen flott tjeneste er vmalert, som lar deg bruke VictoriaMetrics som backend, motta behandlet data fra vminsert og sende det til vmselect. Den behandler selve varslene, så vel som reglene. Ved varsler mottar vi varselet gjennom alertmanager.
Det er en wmauth-komponent. Vi kan eller ikke kan (vi har ikke bestemt oss for dette ennå) bruke det som et autorisasjonssystem for multitenancyversjonen av klynger. Den støtter remoteWrite for Prometheus og kan autorisere basert på url, eller rettere sagt den andre delen av den, hvor du kan eller ikke kan skrive.
Det er også vmbackup, vmrestore. Dette er i hovedsak gjenoppretting og sikkerhetskopiering av alle data. Kan gjøre S3, GCS, fil.
Den første gjentakelsen av klyngen vår ble gjort under karantene. På den tiden var det ingen replika, så iterasjonen vår besto av to forskjellige og uavhengige klynger som vi mottok data i via remoteWrite.
Her tar jeg forbehold om at da vi byttet fra VictoriaMetrics Single Node til VictoriaMetrics Cluster Version, forble vi fortsatt med de samme forbrukte ressursene, dvs. den viktigste er minnet. Dette er omtrent hvordan våre data, det vil si ressursforbruk, ble fordelt.
En replika er allerede lagt til her. Vi kombinerte alt dette til en relativt stor klynge. Alle våre data er både sønderdelt og replikert.
Hele klyngen har N inngangspunkter, noe som betyr at Prometheus kan legge til data via HAPROXY. Her har vi dette inngangspunktet. Og gjennom dette inngangspunktet kan du logge inn fra Grafana.
I vårt tilfelle er HAPROXY den eneste porten som proxyer velger, setter inn og andre tjenester inne i denne klyngen. I vårt tilfelle var det umulig å lage én adresse; vi måtte gjøre flere inngangspunkter, fordi selve de virtuelle maskinene som VictoriaMetrics-klyngen kjører på er plassert i forskjellige soner hos samme skyleverandør, dvs. ikke inne i skyen vår, men utenfor skyen vår. .
Vi har varsling. Vi bruker det. Vi bruker alertmanager fra Prometheus. Vi bruker Opsgenie og Telegram som en varslingsleveringskanal. I Telegram strømmer de inn fra dev, kanskje noe fra prod, men mest noe statistisk, som trengs av ingeniører. Og Opsgenie er kritisk. Dette er samtaler, hendelseshåndtering.
Det evige spørsmålet: "Hvem overvåker overvåkingen?" I vårt tilfelle overvåker overvåking overvåking av seg selv, fordi vi bruker vmagent på hver node. Og siden våre noder er fordelt på ulike datasentre hos samme leverandør, har hvert datasenter sin egen kanal, de er uavhengige, og selv om en splittet hjerne kommer, vil vi fortsatt motta varsler. Ja, det vil bli flere av dem, men det er bedre å motta flere varsler enn ingen.
Vi avslutter listen med en HA-implementering.
Og videre vil jeg legge merke til opplevelsen av å kommunisere med VictoriaMetrics-fellesskapet. Det viste seg veldig positivt. Gutta er lydhøre. De prøver å fordype seg i hver sak som tilbys.
Jeg startet problemer på GitHub. De ble løst veldig raskt. Det er et par flere problemer som ikke er helt lukket, men jeg kan allerede se fra koden at arbeidet i denne retningen er i gang.
Den største smerten for meg under iterasjoner var at hvis jeg stengte en node, så kunne ikke vminsert forstå at det ikke var noen backend i de første 30 sekundene. Dette er nå avgjort. Og bokstavelig talt i løpet av et sekund eller to blir dataene tatt fra alle de gjenværende nodene, og forespørselen slutter å vente på den manglende noden.
På et tidspunkt ønsket vi at VictoriaMetrics skulle være en VictoriaMetrics-operatør. Vi ventet på ham. Vi bygger nå aktivt et rammeverk for at VictoriaMetrics-operatøren skal ta alle forhåndsberegningsregler osv. Prometheus, fordi vi bruker ganske aktivt reglene som følger med Prometheus-operatøren.
Det er forslag for å forbedre klyngeimplementeringen. Jeg skisserte dem ovenfor.
Og jeg vil virkelig nedsample. I vårt tilfelle er nedsampling utelukkende nødvendig for å se trender. Grovt sett er én beregning nok for meg i løpet av dagen. Disse trendene er nødvendige i et år, tre, fem, ti år. Og én metrisk verdi er nok.
- Vi har kjent smerte, i likhet med noen av våre kolleger, ved bruk av Prometheus.
- Vi valgte VictoriaMetrics for oss selv.
- Den skalerer ganske bra både vertikalt og horisontalt.
- Vi kan distribuere forskjellige komponenter til forskjellige antall noder i klyngen, begrense dem med minne, legge til minne, etc.
Vi kommer til å bruke VictoriaMetrics hjemme fordi vi virkelig likte det. Dette er det som var og det som har blitt.
Et par QR-koder for VictoriaMetrics chat, mine kontakter, LeroyMerlin teknisk radar.
Kilde: www.habr.com