VictoriaMetrics on nopea ja skaalautuva DBMS, joka tallentaa ja käsittelee dataa aikasarjan muodossa (tietue muodostaa ajan ja tätä aikaa vastaavan arvojoukon, joka saadaan esimerkiksi antureiden tilan säännöllisestä kyselystä tai mittareiden kerääminen).
Nimeni on Pavel Kolobaev. DevOps, SRE, LeroyMerlin, kaikki on kuin koodia - kaikki on meistä: minusta ja muista LeroyMerlinin työntekijöistä.
Siellä on OpenStackiin perustuva pilvi. Siellä on pieni linkki tekniseen tutkaan.
Se on rakennettu Kubernetes-raudan pohjalle sekä kaikkiin OpenStackiin ja kirjaukseen liittyviin palveluihin.
Tämä on suunnitelma, jota kehitimme. Kun kehitimme kaiken tämän, meillä oli Prometheus-operaattori, joka tallensi tiedot itse K8s-klusterin sisään. Hän löytää automaattisesti hankattavan ja laittaa sen karkeasti sanottuna jalkojensa alle.
Meidän on siirrettävä kaikki tiedot Kubernetes-klusterin ulkopuolelle, koska jos jotain tapahtuu, meidän on ymmärrettävä mitä ja missä.
Ensimmäinen ratkaisu on, että käytämme liittämistä, kun meillä on kolmas osapuoli Prometheus, kun menemme Kubernetes-klusteriin liittoutumismekanismin kautta.
Mutta tässä on pieniä ongelmia. Meidän tapauksessamme ongelmat alkoivat, kun meillä oli 250 000 mittaria, ja kun niitä oli 400 000, tajusimme, että emme voi toimia niin. Olemme pidentäneet scrape_timeout-aikaa 25 sekuntiin.
Miksi meidän piti tehdä tämä? Prometheus alkaa laskea aikakatkaisua noutohetken alusta. Sillä ei ole väliä, että dataa tulee edelleen. Jos tiedot eivät ole tämän määritellyn ajanjakson aikana sulautuneet yhteen eikä istuntoa suljeta http:n kautta, katsotaan istunnon epäonnistuneen ja tiedot eivät pääse itse Prometheukseen.
Kaikki tietävät kaaviot, jotka saamme, kun osa tiedoista puuttuu. Grafiikka on repeytynyt, emmekä ole tyytyväisiä siihen.
Seuraava vaihtoehto on jakaminen, joka perustuu kahteen eri Prometheukseen saman liittoutumismekanismin kautta.
Esimerkiksi, ota ja sirpaloi ne nimeltä. Tätä voidaan myös käyttää, mutta päätimme jatkaa.
Meidän on nyt käsiteltävä nämä sirpaleet jotenkin. Voit ottaa promxyn, joka laskeutuu sirpalealueelle, moninkertaistaa tiedot. Se toimii kahden sirpaleen kanssa yhtenä sisääntulopisteenä. Tämä voidaan toteuttaa promxyn kautta, mutta se on toistaiseksi liian monimutkaista.
Ensimmäinen vaihtoehto - haluamme luopua liittoutumismekanismista, koska se on hyvin hidas.
Prometheus-kehittäjät sanovat nimenomaisesti: "Kaverit, käytä muuta TimescaleDB:tä, koska emme tue mittareiden pitkäaikaista tallennusta." Tämä ei ole heidän tehtävänsä.
Kirjoitamme paperille, että meidän on vielä purettava ulkona, jotta kaikkea ei säilytetä yhdessä paikassa.
Toinen haittapuoli on muistin kulutus. Kyllä, ymmärrän, että monet sanovat, että vuonna 2020 pari gigatavua muistia on pennin arvoinen, mutta siitä huolimatta.
Nyt meillä on kehittäjä- ja tuoteympäristö. Kehittäjässä tämä on noin 9 gigatavua 350 000 metriikkaa kohden. Tuotantoversiossa tämä on 14 gigatavua ja pieni 780 000 metriikka. Samaan aikaan meillä on vain 30 minuutin säilytysaika. Tämä on huono. Ja nyt selitän miksi.
Teemme laskelman, eli puolentoista miljoonan metriikan kanssa, ja olemme jo lähellä niitä, suunnitteluvaiheessa saamme 35-37 gigatavua muistia. Mutta jo 4 miljoonalla mittarilla tarvitaan jo noin 90 gigatavua muistia. Eli se laskettiin Prometheus-kehittäjien toimittaman kaavan mukaan. Katselimme korrelaatiota ja totesimme, että emme halua maksaa paria miljoonaa palvelimesta vain valvonnasta.
Emme vain lisää koneiden määrää, vaan valvomme myös itse virtuaalikoneita. Siksi mitä enemmän virtuaalikoneita, sitä enemmän erilaisia mittareita jne. Meillä tulee olemaan klusterimme erityinen kasvu mittareiden suhteen.
Levytilan kanssa kaikki ei ole niin surullista, mutta haluaisin parantaa sitä. Saimme yhteensä 15 gigatavua 120 päivässä, josta 100 on pakattua dataa, 20 on pakkaamatonta dataa, mutta aina haluat vähemmän.
Tämän mukaisesti kirjoitamme vielä yhden pisteen - tämä on suuri resurssien kulutus, jonka haluamme silti säästää, koska emme halua valvontaklusterimme syövän enemmän resursseja kuin OpenStackia hallitseva klusterimme.
Prometheuksessa on vielä yksi haitta, jonka olemme tunnistaneet itsellemme, tämä on ainakin jonkinlainen muistin rajoitus. Prometheuksen kanssa kaikki on paljon pahempaa, koska hänellä ei ole sellaisia käänteitä ollenkaan. Docker-rajan käyttö ei myöskään ole vaihtoehto. Jos RAF on yhtäkkiä pudonnut ja siellä on 20-30 gigatavua, sen nousu kestää hyvin kauan.
Tämä on toinen syy, miksi Prometheus ei sovellu meille, eli emme voi rajoittaa muistin kulutusta.
Tällainen kaava olisi mahdollista keksiä. Tarvitsemme tätä järjestelmää HA-klusterin järjestämiseksi. Haluamme, että mittarimme ovat saatavilla milloin tahansa ja missä tahansa, vaikka nämä tiedot tallentava palvelin kaatuisi. Ja siksi meidän on rakennettava tällainen järjestelmä.
Tämä järjestelmä sanoo, että meillä on päällekkäisiä sirpaleita ja vastaavasti kulutettujen resurssien kustannuksia. Se voidaan skaalata melkein vaakasuoraan, mutta siitä huolimatta resurssien kulutus tulee olemaan helvetillistä.
Haitat järjestyksessä siinä muodossa, jossa kirjoitimme ne itsellemme:
- Edellyttää mittareiden lataamista ulkopuolelle.
- Suuri resurssien kulutus.
- Et voi rajoittaa muistin kulutusta.
- HA:n monimutkainen ja resurssiintensiivinen toteutus.
Päätimme itsellemme, että olemme siirtymässä pois Prometheuksesta arkistona.
Olemme tunnistaneet itsellemme tarvitsemamme lisävaatimukset. Tämä:
- Tämä on promql-tuki, koska Prometheukselle on jo kirjoitettu paljon: kyselyitä, hälytyksiä.
- Ja sitten meillä on Grafana, joka on jo kirjoitettu samalla tavalla Prometheuksen taustaohjelmaksi. En halua kirjoittaa kojetauluja uudelleen.
- Haluamme rakentaa normaalin HA-arkkitehtuurin.
- Haluamme vähentää resurssien kulutusta.
- On toinen pieni vivahde. Emme voi käyttää erilaisia pilvijärjestelmiä mittareiden keräämiseen. Emme toistaiseksi tiedä, mikä näihin mittareihin tulee. Ja koska sinne voi lentää mitä tahansa, meidän on rajoituttava paikalliseen sijoitukseen.
Valinta oli pieni. Olemme keränneet kaiken, mistä meillä on kokemusta. Katsoimme Prometheus-sivua integrointiosiossa, luimme joukon artikkeleita, katsoimme, mitä on yleisesti saatavilla. Ja itsellemme valitsimme VictoriaMetricsin Prometheuksen tilalle.
Miksi? Koska:
- Pystyy promql.
- On modulaarinen arkkitehtuuri.
- Ei vaadi muutoksia Grafanaan.
- Ja mikä tärkeintä, tulemme todennäköisesti tarjoamaan mittareiden tallennuksen yrityksemme sisällä palveluna, joten katsomme etukäteen erilaisia rajoituksia, jotta käyttäjät voivat käyttää kaikkia klusterin resursseja jollain rajoitetulla tavalla, koska siellä on mahdollisuus, että se on monivuokraus.
Teemme ensimmäisen vertailun. Otamme saman Prometheuksen klusterin sisään, ulkoinen Prometheus menee siihen. Lisäämme remoteWrite VictoriaMetricsin kautta.
Teen heti varauksen, että tässä saimme pienen lisäyksen prosessorin kulutuksessa VictoriaMetricsiltä. VictoriaMetrics-wiki kertoo, mitkä parametrit sopivat parhaiten. Tarkistimme ne. Ne vähensivät hyvin prosessorin kulutusta.
Meidän tapauksessamme Kubernetes-klusterissa sijaitsevan Prometheuksen muistinkulutus ei kasvanut merkittävästi.
Vertaamme kahta saman datan tietolähdettä. Prometheuksessa näemme kaikki samat puuttuvat tiedot. VictoriaMetricsissä kaikki on hyvin.
Testien tulokset levytilalla. Me Prometheuksella saimme yhteensä 120 gigatavua. VictoriaMetricsillä saamme jo 4 gigatavua päivässä. Siinä on hieman erilainen mekanismi kuin mitä olet tottunut näkemään Prometheuksessa. Eli data on jo melko hyvin pakattu päiväksi, puoleksi tunniksi. Niitä korjataan jo hyvin päivässä, puolessa tunnissa, huolimatta siitä, että myöhemmin tiedot yhdistetään. Tämän seurauksena säästimme levytilaa.
Säästämme myös muistiresurssien kulutuksessa. Testien aikana meillä oli Prometheus asennettuna virtuaalikoneeseen - 8 ydintä, 24 gigatavua. Prometheus syö melkein kaiken. Hän putosi OOM Killerin päälle. Samaan aikaan siihen kaadettiin vain 900 000 aktiivista mittaria. Tämä on noin 25 000-27 000 metriikkaa sekunnissa.
VictoriaMetrics toimi kahden ytimen virtuaalikoneessa, jossa oli 8 gigatavua RAM-muistia. Saimme VictoriaMetricsin toimimaan hyvin säätämällä joitain asioita 8 Gt:n koneessa. Tuloksena pysyimme 7 gigatavun sisällä. Samalla saimme sisällön toimitusnopeuden eli metriikan jopa Prometheuksen nopeutta korkeammaksi.
Prosessori on paljon parempi kuin Prometheus. Täällä Prometheus kuluttaa 2,5 ydintä ja VictoriaMetrics vain 0,25 ydintä. Alussa - 0,5 ydintä. Kun se sulautuu, se saavuttaa yhden ytimen, mutta tämä on erittäin, erittäin harvinaista.
Meidän tapauksessamme valinta osui VictoriaMetricsiin ilmeisistä syistä, halusimme säästää rahaa ja säästää.
Yliviivaamme heti kaksi kohtaa - tämä on mittareiden purkaminen ja suuri resurssien kulutus. Ja meidän on päätettävä kaksi asiaa, jotka jätimme vielä itsellemme.
Täällä teen varauksen heti, pidämme VictoriaMetricsiä mittareiden arkistona. Mutta koska tarjoamme todennäköisesti VictoriaMetricsin tallennustilaksi kaikille Leroyille, meidän on rajoitettava tämän klusterin käyttäjiä, jotta he eivät laita sitä meille.
On upea parametri, jonka avulla voit rajoittaa ajan, tiedon määrän ja suoritusajan mukaan.
Ja on myös erinomainen vaihtoehto, jonka avulla voit rajoittaa muistin kulutusta, jolloin voimme löytää juuri tasapainon, jonka avulla voimme saada normaalin nopeuden ja riittävän resurssien kulutuksen.
Miinus vielä yksi piste, eli yliviivaamme pisteen - et voi rajoittaa muistin kulutusta.
Ensimmäisessä iteraatiossa testasimme VictoriaMetrics Single Nodea. Seuraavaksi siirrymme VictoriaMetrics Cluster -versioon.
Täällä meillä on vapaat kädet eri palveluiden erottamisessa VictoriaMetricsissä riippuen siitä, mitä ne pyörittävät ja mitä resursseja ne kuluttavat. Tämä on erittäin joustava ja kätevä ratkaisu. Olemme käyttäneet sitä itse.
VictoriaMetrics Cluster -version pääkomponentit ovat vmstsorage. Numeroita voi olla N. Meidän tapauksessamme niitä on 2.
Ja siellä on vminsert. Tämä on välityspalvelin, jonka avulla voimme: järjestää jakamisen kaikkien tallenteiden välillä, joista kerroimme hänelle, ja se sallii toisen replikan, eli sinulla on sekä sharding että replika.
Vminsert tukee Prometheuksen OpenTSDB-, Graphite-, InfluxDB- ja remoteWrite-protokollia.
Siellä on myös vmselect. Sen päätehtävänä on mennä vmstorageen, hakea heiltä tietoja, poistaa tiedot ja antaa ne asiakkaalle.
On olemassa upea asia, kuten vmagent. Pidämme hänestä todella. Sen avulla voit määrittää kuten Prometheus ja silti tehdä kaiken kuten Prometheus. Eli se kerää mittareita eri entiteeteistä ja palveluista ja lähettää ne vminsertille. Sitten kaikki riippuu sinusta.
Toinen loistava palvelu on vmalert, jonka avulla voit käyttää VictoriaMetricsiä taustajärjestelmänä, vastaanottaa käsiteltyjä tietoja vminsertistä ja lähettää käsitellyt tiedot vmselectille. Se käsittelee itse hälytykset sekä säännöt. Hälytystapauksissa saamme hälytyksen Alertmanagerin kautta.
Siinä on wmauth-komponentti. Tulemme todennäköisesti käyttämään sitä, ja ehkä emme (emme ole vielä päättäneet tästä) valtuutusjärjestelmänä klusterien monivuokraversioille. Se tukee Prometheuksen remoteWrite-toimintoa ja voi valtuuttaa URL-osoitteen tai pikemminkin sen toisen osan perusteella, mihin voit kirjoittaa tai ei.
Siellä on myös vmbackup, vmrestore. Tämä on itse asiassa kaikkien tietojen palauttamista ja varmuuskopiointia. Pystyy S3, GCS, tiedosto.
Ensimmäinen iteraatio klusteristamme tehtiin karanteenin aikana. Tuolloin kopiota ei ollut, joten iteraatiomme koostui kahdesta erillisestä ja itsenäisestä klusterista, joihin saimme dataa remoteWritella.
Teen tässä varauksen, että kun siirryimme VictoriaMetrics Single Nodesta VictoriaMetrics Cluster Version -versioon, pysyimme edelleen samoissa kulutetuissa resursseissa, eli pääasiallinen on muisti. Suunnilleen tällä tavalla tietomme jakautuivat, eli resurssien kulutus.
Replika on jo lisätty tänne. Olemme yhdistäneet kaiken tämän yhdeksi suhteellisen suureksi klusteriksi. Kaikki tiedot on sekä sirpaloitu että replikoitu.
Koko klusterissa on N sisääntulopistettä, eli Prometheus voi lisätä tietoja HAPROXY:n kautta. Tässä on sisääntulopisteemme. Ja tämän sisääntulopisteen kautta voit kirjautua sisään Grafanalla.
Meidän tapauksessamme HAPROXY on ainoa portti, joka välittää valinnan, lisäämisen ja muut palvelut tähän klusteriin. Meidän tapauksessamme yhden osoitteen tekeminen oli mahdotonta, jouduimme tekemään useita sisääntulokohtia, koska itse virtuaalikoneet, joissa VictoriaMetrics-klusteri toimii, sijaitsevat saman pilvipalveluntarjoajan eri vyöhykkeillä, eli eivät pilvessämme. , mutta ulkona.
Meillä on hälytys. Käytämme sitä. Käytämme Prometheuksen alertmanageria. Käytämme Opsgenieta ja Telegramia hälytyksen jakelukanavana. Telegramissa ne kaatuvat kehittäjistä, ehkä jotain prodista, mutta enemmänkin jotain tilastollista, jota insinöörit tarvitsevat. Ja Opsgenie on kriittinen. Nämä ovat puheluita, tapausten hallintaa.
Ikivanha kysymys: "Kuka valvoo seurantaa?". Meidän tapauksessamme valvonta valvoo itse seurantaa, koska käytämme vmagentia jokaisessa solmussa. Ja koska solmumme sijaitsevat saman palveluntarjoajan eri datakeskuksissa, jokaisella palvelinkeskuksella on oma kanavansa, ne ovat itsenäisiä, ja vaikka aivot jakautuvat, saamme silti hälytyksiä. Kyllä, niitä tulee lisää, mutta on parempi saada enemmän hälytyksiä kuin ei yhtään.
Lopetamme luettelomme HA:n toteuttamiseen.
Ja edelleen haluaisin huomauttaa kokemuksesta kommunikoinnista VictoriaMetrics-yhteisön kanssa. Se osoittautui erittäin positiiviseksi. Pojat ovat reagoivia. He yrittävät perehtyä kaikkiin tarjottuihin tapauksiin.
Tein ongelmia GitHubissa. Ne ratkesivat erittäin nopeasti. On vielä pari ongelmaa, joita ei ole täysin suljettu, mutta näen jo koodista, että työ on käynnissä tähän suuntaan.
Suurin kipu iteraatioiden aikana minulle oli se, että jos leikkasin solmun, niin vminsert ei ensimmäisten 30 sekuntien aikana ymmärtänyt, että taustaa ei ole. Nyt se on jo päätetty. Ja kirjaimellisesti sekunnissa tai kahdessa tiedot otetaan kaikista jäljellä olevista solmuista, ja pyyntö lakkaa odottamasta puuttuvaa solmua.
Halusimme jossain vaiheessa VictoriaMetricsistä olla VictoriaMetrics-operaattori. Odotimme häntä. Rakennamme nyt aktiivisesti VictoriaMetrics-operaattorin päälle sidontaa ottaaksemme kaikki esilaskentasäännöt jne. Prometheus, koska käytämme melko aktiivisesti Prometheus-operaattorin mukana tulevia sääntöjä.
Klusterin toteutuksen parantamiseksi on ehdotuksia. Olen hahmotellut niitä edellä.
Ja haluan myös todella alasnäytteenottoa. Meidän tapauksessamme alasnäytteenottoa tarvitaan yksinomaan trendien katseluun. Karkeasti sanottuna yksi mittari riittää minulle päivän aikana. Näitä trendejä tarvitaan vuoden, kolmen, viiden, kymmenen vuoden ajan. Ja yksi metriarvo riittää.
- Olemme tunteneet kipua, kuten jotkut kollegamme, käyttäessämme Prometheusta.
- Valitsimme VictoriaMetricsin itsellemme.
- Se skaalautuu melko hyvin sekä pysty- että vaakasuunnassa.
- Voimme jakaa eri komponentteja eri määrälle klusterin solmuja, rajoittaa niitä muistin suhteen, lisätä muistia jne.
Käytämme VictoriaMetricsiä kotona, koska pidimme siitä todella. Tässä on mitä tapahtui ja mitä tapahtui.
Pari qr-koodia VictoriaMetricsin chattiin, yhteystietoni, LeroyMerlinin tekninen tutka.
Lähde: will.com