VictoriaMetrics er et hurtigt og skalerbart DBMS til lagring og behandling af data i form af en tidsserie (en registrering danner en tid og et sæt værdier svarende til denne tid, f.eks. opnået gennem en periodisk polling af sensorers status eller indsamling af metrics).
Mit navn er Pavel Kolobaev. DevOps, SRE, LeroyMerlin, alt er som kode - det handler om os: om mig og om andre LeroyMerlin-medarbejdere.
Der er en sky baseret på OpenStack. Der er et lille link til den tekniske radar.
Det er bygget på basis af Kubernetes jern, samt på alle relaterede tjenester til OpenStack og logning.
Dette er den ordning, vi havde under udvikling. Da vi udviklede alt dette, havde vi Prometheus-operatøren, som lagrede data inde i selve K8s-klyngen. Han finder automatisk det, der skal skrubbes, og lægger det groft sagt under fødderne.
Vi bliver nødt til at flytte alle data uden for Kubernetes-klyngen, for hvis der sker noget, så skal vi forstå hvad og hvor.
Den første løsning er, at vi bruger føderation, når vi har en tredjeparts Prometheus, når vi går til Kubernetes-klyngen gennem føderationsmekanismen.
Men der er nogle mindre problemer her. I vores tilfælde startede problemerne, da vi havde 250 målinger, og da det blev 000 målinger, indså vi, at vi ikke kunne arbejde sådan. Vi har øget scrape_timeout til 400 sekunder.
Hvorfor var vi nødt til at gøre dette? Prometheus begynder at tælle timeout fra starten af afhentningsøjeblikket. Det gør ikke noget, at dataene stadig strømmer ind. Hvis dataene i løbet af denne angivne tidsperiode ikke er flettet, og sessionen ikke er lukket via http, anses det for, at sessionen er mislykket, og dataene kommer ikke ind i selve Prometheus.
Alle kender graferne, som vi får, når en del af dataene mangler. Grafikken er revet i stykker, og vi er ikke tilfredse med den.
Den næste mulighed er sharding baseret på to forskellige Prometheus gennem den samme føderationsmekanisme.
Tag for eksempel bare og skær dem ved navn. Dette kan også bruges, men vi besluttede at gå videre.
Vi bliver nu nødt til at behandle disse skår på en eller anden måde. Du kan tage promxy, som går ned i shard-området, multiplicerer dataene. Det fungerer med to skår som et enkelt indgangspunkt. Dette kan implementeres via promxy, men det er for kompliceret for nu.
Den første mulighed - vi ønsker at opgive føderationsmekanismen, fordi den er meget langsom.
Prometheus-udviklerne siger eksplicit: "Gutter, brug andre TimescaleDB, for vi vil ikke understøtte langtidslagring af metrics." Dette er ikke deres opgave.
Vi skriver ned på et stykke papir, som vi stadig mangler at læsse af udenfor, for ikke at gemme alt ét sted.
Den anden ulempe er hukommelsesforbrug. Ja, jeg forstår, at mange vil sige, at i 2020 er et par gigabyte hukommelse en øre værd, men ikke desto mindre.
Nu har vi et udvikler- og et prod-miljø. I dev er dette omkring 9 gigabyte pr. 350 metrics. I produktion er dette 000 gigabyte med små 14 metrics. Samtidig har vi kun 780 minutters retentionstid. Det her er slemt. Og nu vil jeg forklare hvorfor.
Vi laver en beregning, det vil sige med halvanden million målinger, og vi er allerede tæt på dem, på designstadiet får vi 35-37 gigabyte hukommelse. Men allerede efter 4 millioner målinger kræves der allerede omkring 90 gigabyte hukommelse. Det vil sige, det blev beregnet i henhold til formlen leveret af Prometheus-udviklerne. Vi så på sammenhængen og indså, at vi ikke ønsker at betale et par millioner for en server kun for overvågning.
Vi vil ikke kun øge antallet af maskiner, vi overvåger også selve de virtuelle maskiner. Derfor er det sådan, at jo flere virtuelle maskiner, jo flere metrics af forskellig art osv. Vi vil have en særlig vækst af vores klynge, hvad angår metrics.
Med diskplads er alt ikke så trist her, men jeg vil gerne forbedre det. Vi modtog i alt 15 gigabyte på 120 dage, hvoraf 100 er komprimerede data, 20 er ukomprimerede data, men du vil altid have mindre.
Derfor skriver vi et punkt mere ned - det er et stort forbrug af ressourcer, som vi stadig ønsker at spare, fordi vi ikke ønsker, at vores overvågningsklynge skal æde flere ressourcer end vores klynge, der administrerer OpenStack.
Der er endnu en ulempe ved Prometheus, som vi selv har identificeret, dette er i det mindste en form for hukommelsesbegrænsning. Med Prometheus er alt meget værre her, fordi han slet ikke har sådanne drejninger. Brug af docker limit er heller ikke en mulighed. Hvis din RAF pludselig er faldet, og der er 20-30 gigabyte, så vil det tage meget lang tid at stige.
Dette er endnu en grund til, at Prometheus ikke er egnet til os, dvs. vi kan ikke begrænse hukommelsesforbruget.
Det ville være muligt at komme med en sådan ordning. Vi har brug for denne ordning for at kunne organisere en HA-klynge. Vi ønsker, at vores metrics skal være tilgængelige når som helst og hvor som helst, selvom serveren, der gemmer disse metrics, går ned. Og dermed er vi nødt til at bygge sådan en ordning.
Denne ordning siger, at vi vil have duplikering af skår og følgelig duplikering af omkostningerne ved forbrugte ressourcer. Det kan næsten skaleres vandret, men ikke desto mindre vil ressourceforbruget være infernalsk.
Ulemper i rækkefølge, i den form, som vi skrev dem ud for os selv:
- Kræver upload af metrics til det ydre.
- Højt forbrug af ressourcer.
- Du kan ikke begrænse hukommelsesforbruget.
- Kompliceret og ressourcekrævende implementering af HA.
For os selv besluttede vi, at vi bevæger os væk fra Prometheus som et depot.
Vi har identificeret yderligere krav til os selv, som vi har brug for. Det her:
- Dette er promql-understøttelse, fordi der allerede er skrevet meget til Prometheus: forespørgsler, advarsler.
- Og så har vi Grafana, som allerede er skrevet på samme måde under Prometheus som backend. Jeg ønsker ikke at omskrive dashboards.
- Vi ønsker at bygge en normal HA-arkitektur.
- Vi ønsker at reducere forbruget af eventuelle ressourcer.
- Der er en anden lille nuance. Vi kan ikke bruge forskellige former for cloud-systemer til at indsamle metrics. Vi ved ikke, hvad der vil flyve ind i disse målinger for nu. Og da alt kan flyve dertil, må vi begrænse os til lokal placering.
Valget var lille. Vi har samlet alt, hvad vi havde erfaring med. Vi kiggede på Prometheus-siden i integrationssektionen, læste en masse artikler, så på, hvad der er generelt tilgængeligt. Og for os selv valgte vi VictoriaMetrics som erstatning for Prometheus.
Hvorfor? Fordi:
- Kan promql.
- Der er en modulær arkitektur.
- Kræver ingen ændringer til Grafana.
- Og vigtigst af alt, så vil vi nok levere en metric storage i vores virksomhed som en service, så vi kigger på forhånd mod forskellige former for restriktioner, så brugerne kan bruge alle klyngens ressourcer på en begrænset måde, fordi der er en chance at det vil multilejemål.
Vi laver den første sammenligning. Vi tager den samme Prometheus inde i klyngen, ekstern Prometheus går til den. Vi tilføjer via remoteWrite VictoriaMetrics.
Jeg vil med det samme tage forbehold for, at her fangede vi en lille stigning i CPU-forbruget fra VictoriaMetrics. VictoriaMetrics wiki siger, hvilke parametre der er bedst egnede. Vi tjekkede dem. De reducerede meget godt forbruget af CPU'en.
I vores tilfælde steg hukommelsesforbruget af Prometheus, som er placeret i en Kubernetes-klynge, ikke væsentligt.
Vi sammenligner to datakilder af samme data. I Prometheus ser vi alle de samme manglende data. Alt er godt hos VictoriaMetrics.
Resultater af test med diskplads. Vi hos Prometheus fik 120 gigabyte i alt. Hos VictoriaMetrics får vi allerede 4 gigabyte om dagen. Der er en lidt anden mekanisme, end den du er vant til at se i Prometheus. Det vil sige, at dataene allerede er ret godt komprimeret i en dag, i en halv time. De er allerede godt høstet på en dag, på en halv time, på trods af at dataene senere vil blive flettet sammen. Som et resultat sparede vi på diskplads.
Vi sparer også på forbruget af hukommelsesressourcer. På tidspunktet for testene havde vi Prometheus installeret på en virtuel maskine - 8 kerner, 24 gigabyte. Prometheus spiser næsten alt. Han faldt på OOM Killer. Samtidig blev der kun hældt 900 aktive metrics i det. Dette er omkring 000-25 metrics per sekund.
VictoriaMetrics kørte på en virtuel dual-core maskine med 8 gigabyte RAM. Det lykkedes at få VictoriaMetrics til at fungere godt ved at justere nogle ting på en 8GB-maskine. Som et resultat holdt vi os inden for 7 gigabyte. Samtidig fik vi hastigheden på indholdslevering, det vil sige målinger, endnu højere end Prometheus.
CPU'en er meget bedre end Prometheus. Her forbruger Prometheus 2,5 kerner, og VictoriaMetrics forbruger kun 0,25 kerner. I starten - 0,5 kerner. Når den smelter sammen, når den én kerne, men dette er ekstremt, ekstremt sjældent.
I vores tilfælde faldt valget på VictoriaMetrics af indlysende årsager, vi ville spare penge og sparede.
Vi krydser to punkter ud lige fra hånden - dette er aflæsning af metrikker og et stort forbrug af ressourcer. Og det er op til os at afgøre to punkter, som vi stadig overlod til os selv.
Her vil jeg tage en reservation med det samme, vi betragter VictoriaMetrics som et repository af metrics. Men da vi højst sandsynligt vil levere VictoriaMetrics som opbevaring til alle Leroy, er vi nødt til at begrænse dem, der vil bruge denne klynge, så de ikke lægger den til os.
Der er en vidunderlig parameter, der giver dig mulighed for at begrænse efter tid, af mængden af data og af eksekveringstid.
Og der er også en glimrende mulighed, der giver dig mulighed for at begrænse hukommelsesforbruget, så vi kan finde netop den balance, der vil tillade os at få normal hastighed og tilstrækkeligt ressourceforbrug.
Minus et punkt mere, det vil sige, vi overstreger punktet - du kan ikke begrænse hukommelsesforbruget.
I de første iterationer testede vi VictoriaMetrics Single Node. Dernæst går vi videre til VictoriaMetrics Cluster-versionen.
Her har vi frie hænder til emnet adskillelse af forskellige tjenester i VictoriaMetrics, alt efter hvad de vil spinde på, og hvilke ressourcer de vil forbruge. Dette er en meget fleksibel og praktisk løsning. Vi har selv brugt det.
Hovedkomponenterne i VictoriaMetrics Cluster Version er vmstsorage. Der kan være N-nummer. I vores tilfælde er der 2 af dem.
Og der er vminsert. Dette er en proxy-server, der giver os mulighed for at: arrangere sharding mellem alle de storages, som vi fortalte ham om, og den tillader en anden replika, dvs. du vil både have sharding og en replika.
Vminsert understøtter OpenTSDB, Graphite, InfluxDB og remoteWrite-protokollerne fra Prometheus.
Der er også vmselect. Dens hovedopgave er at gå til vmstorage, hente data fra dem, dedupere disse data og give dem til klienten.
Der er en vidunderlig ting som vmagent. Vi kan virkelig godt lide hende. Det giver dig mulighed for at konfigurere ligesom Prometheus og stadig gøre alt ligesom Prometheus. Det vil sige, at den indsamler metrics fra forskellige enheder og tjenester og sender dem til vminsert. Så afhænger alt af dig.
En anden god service er vmalert, som giver dig mulighed for at bruge VictoriaMetrics som backend, modtage behandlede data fra vminsert og sende behandlede data til vmselect. Den behandler selve advarslerne samt reglerne. I tilfælde af alarmer får vi en alarm gennem alertmanager.
Der er en wmauth-komponent. Vi vil sandsynligvis bruge det, og måske ikke (vi har ikke besluttet os for dette endnu) som et autorisationssystem for multitenancy-versioner af klynger. Den understøtter remoteWrite til Prometheus og kan godkende baseret på url'en, eller rettere den anden del af den, hvor du kan eller ikke kan skrive.
Der er også vmbackup, vmrestore. Dette er faktisk gendannelse og backup af alle data. Kan S3, GCS, fil.
Den første gentagelse af vores klynge blev lavet under karantæne. På det tidspunkt var der ingen replika, så vores iteration bestod af to forskellige og uafhængige klynger, som vi modtog data i via remoteWrite.
Her vil jeg tage forbehold for, at da vi skiftede fra VictoriaMetrics Single Node til VictoriaMetrics Cluster Version, forblev vi stadig i de samme forbrugte ressourcer, dvs. den vigtigste er hukommelsen. Omtrent på denne måde blev vores data fordelt, det vil sige ressourceforbrug.
En replika er allerede blevet tilføjet her. Vi har samlet alt dette i en forholdsvis stor klynge. Alle data er både sønderdelt og replikeret.
Hele klyngen har N indgangspunkter, dvs. Prometheus kan tilføje data via HAPROXY. Her er vores indgangspunkt. Og gennem dette indgangspunkt kan du logge ind med Grafana.
I vores tilfælde er HAPROXY den eneste port, som proxyer vælger, indsætter og andre tjenester i denne klynge. I vores tilfælde var det umuligt at lave én adresse, vi var nødt til at lave flere indgangspunkter, fordi selve de virtuelle maskiner, som VictoriaMetrics-klyngen kører på, er placeret i forskellige zoner hos den samme cloud-udbyder, altså ikke inde i vores sky. , men udenfor.
Vi har en alarm. Vi bruger det. Vi bruger alertmanager fra Prometheus. Vi bruger Opsgenie og Telegram som en alarmleveringskanal. I Telegram hælder de fra dev, måske noget fra prod, men mere som noget statistisk, som ingeniører har brug for. Og Opsgenie er kritisk. Det er opkald, hændelseshåndtering.
Det ældgamle spørgsmål: "Hvem overvåger overvågningen?". I vores tilfælde overvåger overvågning selve overvågningen, fordi vi bruger vmagent på hver node. Og da vores noder er placeret i forskellige datacentre hos samme udbyder, har hvert datacenter sin egen kanal, de er uafhængige, og selvom der kommer en splittet hjerne, vil vi stadig modtage advarsler. Ja, der vil være flere af dem, men det er bedre at få flere advarsler end ingen.
Vi slutter vores liste med implementeringen af HA.
Og yderligere vil jeg gerne bemærke oplevelsen af at kommunikere med VictoriaMetrics-fællesskabet. Det viste sig at være meget positivt. Fyre er lydhøre. De forsøger at dykke ned i hver eneste sag, der tilbydes.
Jeg lavede problemer på GitHub. De blev løst meget hurtigt. Der er et par problemer mere, som ikke er helt lukkede, men jeg kan allerede se på koden, at der arbejdes i denne retning.
Den største smerte under iterationerne for mig var, at hvis jeg skar knudepunktet ned, så kunne vminsert i de første 30 sekunder ikke forstå, at der ikke var nogen backend. Nu er det allerede besluttet. Og bogstaveligt talt på et sekund eller to bliver dataene taget fra alle de resterende noder, og anmodningen holder op med at vente på den manglende node.
Vi ønskede på et tidspunkt fra VictoriaMetrics at være VictoriaMetrics-operatøren. Vi ventede på ham. Vi er nu aktivt ved at opbygge en binding over VictoriaMetrics-operatøren til at tage alle forudberegningsreglerne osv. Prometheus, fordi vi ret aktivt bruger de regler, der følger med Prometheus-operatøren.
Der er forslag til forbedring af klyngeimplementeringen. Jeg har skitseret dem ovenfor.
Og jeg vil også rigtig gerne have downsampling. I vores tilfælde er downsampling udelukkende nødvendig for at se tendenser. Groft sagt er én metrik nok for mig i løbet af dagen. Disse tendenser er nødvendige i et år, tre, fem, ti år. Og én metrisk værdi er nok.
- Vi har kendt smerte, ligesom nogle af vores kolleger, mens vi har brugt Prometheus.
- Vi valgte VictoriaMetrics for os selv.
- Den skalerer ret godt både lodret og vandret.
- Vi kan distribuere forskellige komponenter til et forskelligt antal noder i klyngen, begrænse dem med hensyn til hukommelse, tilføje hukommelse osv.
Vi vil bruge VictoriaMetrics derhjemme, for vi kunne virkelig godt lide det. Her er hvad der skete og hvad der skete.
Et par qr-koder til VictoriaMetrics chat, mine kontakter, LeroyMerlin teknisk radar.
Kilde: www.habr.com