VictoriaMetrics is een snel en schaalbaar DBMS voor het opslaan en verwerken van gegevens in de vorm van een tijdreeks (een record bestaat uit tijd en een reeks waarden die overeenkomen met deze tijd, bijvoorbeeld verkregen door periodieke polling van de status van sensoren of verzameling van meetgegevens).
Mijn naam is Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alles lijkt op code - het draait allemaal om ons: om mij en om andere medewerkers van LeroyMerlin.
Er is een cloud gebaseerd op OpenStack. Er is een kleine link naar de technische radar.
Het is gebouwd op de Kubernetes-hardware, maar ook op alle gerelateerde services voor OpenStack en logging.
Dit is het schema dat we in ontwikkeling hadden. Toen we dit allemaal ontwikkelden, hadden we een Prometheus-operator die gegevens opsloeg in het K8s-cluster zelf. Hij vindt automatisch wat er geschrobd moet worden en legt dat grofweg onder zijn voeten.
We zullen alle data buiten het Kubernetes-cluster moeten verplaatsen, want als er iets gebeurt, moeten we begrijpen wat en waar.
De eerste oplossing is dat we federatie gebruiken als we een Prometheus van derden hebben, wanneer we via het federatiemechanisme naar het Kubernetes-cluster gaan.
Maar er zijn hier enkele kleine problemen. In ons geval begonnen de problemen toen we 250 statistieken hadden, en toen er 000 statistieken waren, realiseerden we ons dat we zo niet konden werken. We hebben scrape_timeout verhoogd naar 400 seconden.
Waarom moesten we dit doen? Prometheus begint de time-out te tellen vanaf het begin van het hek. Het maakt niet uit dat de gegevens nog steeds stromen. Als gedurende deze gespecificeerde periode de gegevens niet worden samengevoegd en de sessie niet via http wordt afgesloten, wordt de sessie als mislukt beschouwd en komen de gegevens niet in Prometheus zelf terecht.
Iedereen kent de grafieken die we krijgen als bepaalde gegevens ontbreken. De schema’s zijn gescheurd en wij zijn hier niet blij mee.
De volgende optie is sharding op basis van twee verschillende Prometheus via hetzelfde federatiemechanisme.
Neem ze bijvoorbeeld gewoon en deel ze op naam. Dit kan ook worden gebruikt, maar we hebben besloten verder te gaan.
We zullen deze scherven nu op de een of andere manier moeten verwerken. U kunt promxy nemen, dat naar het scherfgebied gaat en de gegevens vermenigvuldigt. Het werkt met twee scherven als één toegangspunt. Dit kan via promxy worden geïmplementeerd, maar het is nog steeds te moeilijk.
De eerste optie is dat we het federatiemechanisme willen verlaten, omdat het erg traag is.
De Prometheus-ontwikkelaars zeggen duidelijk: "Jongens, gebruik een andere TimescaleDB omdat we de langetermijnopslag van statistieken niet ondersteunen." Dit is niet hun taak.
We schrijven op een vel papier dat we nog buiten moeten uitladen, om niet alles op één plek op te bergen.
Het tweede nadeel is het geheugengebruik. Ja, ik begrijp dat velen zullen zeggen dat in 2020 een paar gigabytes geheugen een cent kost, maar toch.
Nu hebben we een ontwikkel- en productieomgeving. In dev is het ongeveer 9 gigabyte voor 350 statistieken. In productie is het 000 gigabyte en iets meer dan 14 statistieken. Tegelijkertijd bedraagt onze retentietijd slechts 780 minuten. Dit is slecht. En nu zal ik uitleggen waarom.
We maken een berekening, dat wil zeggen met anderhalf miljoen statistieken, en we zijn er al dichtbij, in de ontwerpfase krijgen we 35-37 gigabyte geheugen. Maar voor 4 miljoen statistieken is al ongeveer 90 gigabyte geheugen nodig. Dat wil zeggen, het werd berekend met behulp van de formule van de Prometheus-ontwikkelaars. We keken naar de correlatie en realiseerden ons dat we niet een paar miljoen wilden betalen voor een server alleen voor monitoring.
We gaan niet alleen het aantal machines vergroten, we monitoren ook de virtuele machines zelf. Daarom geldt: hoe meer virtuele machines, hoe meer verschillende soorten statistieken, enz. We zullen een bijzondere groei van ons cluster doormaken in termen van statistieken.
Met schijfruimte is niet alles hier zo slecht, maar ik zou het graag willen verbeteren. We hebben in 15 dagen in totaal 120 gigabytes ontvangen, waarvan 100 gecomprimeerde gegevens, 20 ongecomprimeerde gegevens, maar we willen altijd minder.
Dienovereenkomstig schrijven we nog een punt op: dit is een groot verbruik van bronnen, dat we nog steeds willen besparen, omdat we niet willen dat ons monitoringcluster meer bronnen verbruikt dan ons cluster, dat OpenStack beheert.
Er is nog een nadeel van Prometheus, dat we voor onszelf hebben geïdentificeerd: dit is op zijn minst een soort geheugenbeperking. Met Prometheus is alles hier veel erger, omdat het helemaal niet zulke wendingen kent. Het gebruik van een limiet in docker is ook geen optie. Als je RAF plotseling valt en er zijn 20-30 gigabytes over, dan zal het heel lang duren om te stijgen.
Dit is nog een reden waarom Prometheus niet geschikt is voor ons, dat wil zeggen dat we het geheugengebruik niet kunnen beperken.
Het zou mogelijk zijn een dergelijk plan te bedenken. Dit schema hebben we nodig om een HA-cluster te kunnen organiseren. We willen dat onze statistieken altijd en overal beschikbaar zijn, zelfs als de server die deze statistieken opslaat crasht. En dus zullen we zo'n schema moeten bouwen.
Dit schema zegt dat we een duplicatie van scherven zullen hebben, en dienovereenkomstig een duplicatie van de kosten van de verbruikte hulpbronnen. Het kan bijna horizontaal worden geschaald, maar desalniettemin zal het verbruik van hulpbronnen hels zijn.
Nadelen op een rij in de vorm waarin we ze voor onszelf opschreven:
- Vereist extern uploaden van statistieken.
- Hoog verbruik van hulpbronnen.
- Er is geen manier om het geheugengebruik te beperken.
- Complexe en resource-intensieve implementatie van HA.
Voor onszelf hebben we besloten dat we weg zouden gaan van Prometheus als opslagfaciliteit.
We hebben voor onszelf aanvullende eisen geïdentificeerd die we nodig hebben. Dit:
- Dit is promql-ondersteuning, omdat er al veel dingen voor Prometheus zijn geschreven: queries, alerts.
- En dan hebben we Grafana, dat al op precies dezelfde manier is geschreven voor Prometheus als backend. Ik wil dashboards niet herschrijven.
- We willen een normale HA-architectuur bouwen.
- We willen het verbruik van alle hulpbronnen verminderen.
- Er is nog een kleine nuance. We kunnen geen verschillende soorten systemen voor het verzamelen van cloudstatistieken gebruiken. We weten nog niet wat er in deze statistieken zal vallen. En aangezien daar alles kan vliegen, moeten we ons beperken tot lokale plaatsing.
Er was weinig keuze. Alles waar we ervaring mee hadden, hebben we verzameld. We keken naar de Prometheus-pagina in de integratiesectie, lazen een aantal artikelen en zagen wat daar te vinden was. En voor onszelf hebben we VictoriaMetrics gekozen als vervanger van Prometheus.
Waarom? Omdat:
- Kan promql doen.
- Er is sprake van een modulaire architectuur.
- Vereist geen wijzigingen aan Grafana.
- En het allerbelangrijkste: we zullen de opslag van metrische gegevens binnen ons bedrijf waarschijnlijk als een service aanbieden, dus we kijken van tevoren naar allerlei soorten beperkingen, zodat gebruikers alle bronnen van het cluster op een beperkte manier kunnen gebruiken, omdat er een kans bestaat dat het multitenancy zal zijn.
Laten we de eerste vergelijking maken. We nemen dezelfde Prometheus binnen het cluster, externe Prometheus gaat er naartoe. Toevoegen via remoteWrite VictoriaMetrics.
Ik maak meteen een voorbehoud dat we hier een lichte stijging in het CPU-verbruik van VictoriaMetrics hebben opgemerkt. De VictoriaMetrics-wiki vertelt u welke parameters het beste zijn. Wij hebben ze gecontroleerd. Ze hebben het CPU-verbruik zeer goed verminderd.
In ons geval is het geheugenverbruik van Prometheus, dat zich in het Kubernetes-cluster bevindt, niet significant toegenomen.
We vergelijken twee gegevensbronnen met dezelfde gegevens. In Prometheus zien we dezelfde ontbrekende gegevens. Bij VictoriaMetrics is alles prima.
Testresultaten schijfruimte. Wij van Prometheus ontvingen in totaal 120 gigabyte. Bij VictoriaMetrics ontvangen we al 4 gigabyte per dag. Er is een iets ander mechanisme dan wat we gewend zijn bij Prometheus. Dat wil zeggen dat de gegevens binnen een dag, binnen een half uur, al behoorlijk goed zijn gecomprimeerd. Op een dag, in een half uur, zijn ze al goed geoogst, ondanks dat de gegevens later alsnog verloren gaan. Als gevolg hiervan hebben we schijfruimte bespaard.
We besparen ook op het verbruik van geheugenbronnen. Op het moment van testen hadden we Prometheus geïmplementeerd op een virtuele machine - 8 cores, 24 gigabytes. Prometheus eet bijna alles. Hij viel op OOM Killer. Tegelijkertijd werden er slechts 900 actieve statistieken in gestopt. Dit zijn ongeveer 000-25 statistieken per seconde.
We hebben VictoriaMetrics uitgevoerd op een dual-core virtuele machine met 8 gigabyte RAM. We zijn erin geslaagd VictoriaMetrics goed werkend te krijgen door met een paar dingen te rommelen op een machine van 8 GB. Uiteindelijk hebben we het op 7 gigabyte gehouden. Tegelijkertijd was de snelheid van levering van inhoud, dat wil zeggen statistieken, zelfs hoger dan die van Prometheus.
De CPU is veel beter geworden vergeleken met Prometheus. Hier verbruikt Prometheus 2,5 cores en VictoriaMetrics slechts 0,25 cores. In het begin - 0,5 kernen. Terwijl het samensmelt, bereikt het één kern, maar dit is uiterst zeldzaam.
In ons geval viel de keuze om voor de hand liggende redenen op VictoriaMetrics; we wilden geld besparen en dat hebben we gedaan.
Laten we meteen twee punten doorstrepen: het uploaden van statistieken en het hoge verbruik van bronnen. En we moeten nog maar twee punten beslissen die we nog voor onszelf hebben.
Hier maak ik meteen een reservering, wij beschouwen VictoriaMetrics als opslag van metrics. Maar aangezien we VictoriaMetrics hoogstwaarschijnlijk zullen leveren als opslag voor heel Leroy, moeten we het aantal gebruikers van dit cluster beperken, zodat ze het niet aan ons geven.
Er is een prachtige parameter waarmee u kunt beperken op tijd, op datavolume en op uitvoeringstijd.
Er is ook een uitstekende optie waarmee we het geheugengebruik kunnen beperken, waardoor we het evenwicht kunnen vinden waarmee we een normale werksnelheid en voldoende hulpbronnenverbruik kunnen krijgen.
Nog één punt min, d.w.z. streep het punt door - u kunt het geheugengebruik niet beperken.
In de eerste iteraties hebben we VictoriaMetrics Single Node getest. Vervolgens gaan we verder met de VictoriaMetrics Clusterversie.
Hier hebben we de vrije hand om verschillende services in VictoriaMetrics te scheiden, afhankelijk van waar ze op zullen draaien en welke bronnen ze zullen verbruiken. Dit is een zeer flexibele en handige oplossing. Wij hebben dit voor onszelf gebruikt.
De belangrijkste componenten van VictoriaMetrics Cluster Version zijn vmstsorage. Er kunnen er N-nummers zijn. In ons geval zijn het er tot nu toe 2.
En er is vminsert. Dit is een proxyserver die ons in staat stelt om: sharding te regelen tussen alle opslagplaatsen waarover we het hebben verteld, en het staat ook een replica toe, dat wil zeggen dat je zowel sharding als een replica hebt.
Vminsert ondersteunt OpenTSDB-, Graphite-, InfluxDB- en remoteWrite-protocollen van Prometheus.
Er is ook vmselect. De belangrijkste taak is om naar vmstorage te gaan, gegevens van hen te ontvangen, deze gegevens te ontdubbelen en aan de klant te geven.
Er is iets geweldigs dat vmagent heet. Wij vinden haar erg leuk. Hiermee kunt u precies zoals Prometheus configureren en toch alles precies zoals Prometheus doen. Dat wil zeggen, het verzamelt statistieken van verschillende entiteiten en services en stuurt deze naar vminsert. Dan hangt alles van jou af.
Een andere geweldige service is vmalert, waarmee u VictoriaMetrics als backend kunt gebruiken, verwerkte gegevens van vminsert kunt ontvangen en naar vmselect kunt sturen. Het verwerkt de waarschuwingen zelf, evenals de regels. Bij alerts ontvangen wij de alert via alertmanager.
Er is een wmauth-component. We kunnen het wel of niet (we hebben hier nog niet over besloten) gebruiken als autorisatiesysteem voor de multitenancy-versie van clusters. Het ondersteunt remoteWrite voor Prometheus en kan autoriseren op basis van de url, of beter gezegd het tweede deel ervan, waar je wel of niet kunt schrijven.
Er is ook vmbackup, vmrestore. Dit is in wezen het herstel en de back-up van alle gegevens. Kan S3, GCS, bestand doen.
De eerste iteratie van ons cluster is gemaakt tijdens quarantaine. Op dat moment was er nog geen replica, dus onze iteratie bestond uit twee verschillende en onafhankelijke clusters waarin we gegevens ontvingen via remoteWrite.
Hier maak ik een voorbehoud dat toen we overstapten van VictoriaMetrics Single Node naar VictoriaMetrics Cluster Version, we nog steeds met dezelfde verbruikte bronnen bleven, d.w.z. de belangrijkste is geheugen. Dit is ongeveer hoe onze gegevens, dat wil zeggen het verbruik van hulpbronnen, werden verspreid.
Hier is al een replica toegevoegd. Dit alles hebben we samengevoegd tot één relatief groot cluster. Al onze gegevens worden zowel gedeeld als gerepliceerd.
Het hele cluster heeft N entrypunten, waardoor Prometheus via HAPROXY data kan toevoegen. Hier hebben we dit toegangspunt. En via dit instappunt kun je inloggen vanuit Grafana.
In ons geval is HAPROXY de enige poort die select-, insert- en andere services binnen dit cluster proxy's. In ons geval was het onmogelijk om één adres aan te maken; we moesten meerdere toegangspunten maken, omdat de virtuele machines zelf waarop het VictoriaMetrics-cluster draait zich in verschillende zones van dezelfde cloudprovider bevinden, dus niet binnen onze cloud, maar daarbuiten. .
We hebben een waarschuwing. Wij gebruiken het. Wij gebruiken alertmanager van Prometheus. We gebruiken Opsgenie en Telegram als kanaal voor het afleveren van waarschuwingen. In Telegram stromen ze binnen van dev, misschien iets van prod, maar vooral iets statistisch, nodig voor ingenieurs. En Opsgenie is kritisch. Dit zijn oproepen, incidentbeheer.
De eeuwige vraag: “Wie controleert de monitoring?” In ons geval monitort monitoring de monitoring zelf, omdat we vmagent op elk knooppunt gebruiken. En omdat onze knooppunten zijn verdeeld over verschillende datacenters van dezelfde provider, heeft elk datacenter zijn eigen kanaal, zijn ze onafhankelijk en zelfs als er een gespleten brein arriveert, krijgen we nog steeds waarschuwingen. Ja, er zullen er meer zijn, maar het is beter om meer waarschuwingen te ontvangen dan geen.
We eindigen onze lijst met een HA-implementatie.
En verder zou ik graag de ervaring willen opmerken van de communicatie met de VictoriaMetrics-gemeenschap. Het pakte heel positief uit. De jongens reageren. Ze proberen zich te verdiepen in elke zaak die wordt aangeboden.
Ik begon problemen op GitHub. Ze werden zeer snel opgelost. Er zijn nog een paar problemen die nog niet volledig zijn opgelost, maar ik kan aan de code al zien dat er in deze richting wordt gewerkt.
De grootste pijn voor mij tijdens iteraties was dat als ik een knooppunt afsluit, vminsert de eerste 30 seconden niet kon begrijpen dat er geen backend was. Dit is nu besloten. En letterlijk binnen een seconde of twee worden de gegevens van alle resterende knooppunten gehaald en stopt het verzoek met wachten op dat ontbrekende knooppunt.
Op een gegeven moment wilden we dat VictoriaMetrics een VictoriaMetrics-operator zou worden. Wij hebben op hem gewacht. We zijn nu actief bezig met het bouwen van een raamwerk voor de VictoriaMetrics-operator om alle voorberekeningsregels, enz., Prometheus te gebruiken, omdat we behoorlijk actief gebruik maken van de regels die bij de Prometheus-operator horen.
Er zijn voorstellen om de clusterimplementatie te verbeteren. Ik heb ze hierboven geschetst.
En ik wil heel graag downsamplen. In ons geval is downsampling uitsluitend nodig om trends te bekijken. Globaal gesproken is één statistiek voor mij voldoende gedurende de dag. Deze trends zijn nodig voor een jaar, drie, vijf, tien jaar. En één metrische waarde is voldoende.
- We hebben, net als sommige van onze collega's, pijn gekend bij het gebruik van Prometheus.
- Wij hebben zelf voor VictoriaMetrics gekozen.
- Het schaalt zowel verticaal als horizontaal vrij goed.
- We kunnen verschillende componenten distribueren naar verschillende aantallen knooppunten in het cluster, ze beperken op geheugen, geheugen toevoegen, enz.
We zullen VictoriaMetrics thuis gebruiken omdat we het erg leuk vonden. Dit is wat was en wat is geworden.
Een paar QR-codes voor VictoriaMetrics-chat, mijn contacten, technische radar van LeroyMerlin.
Bron: www.habr.com