Hei kaikki. Alla on transkriptio .
– eri järjestelmien ja palvelujen valvontajärjestelmä, jonka avulla järjestelmänvalvojat voivat kerätä tietoa järjestelmien ajankohtaisista parametreista ja asettaa hälytyksiä vastaanottamaan ilmoituksia poikkeamista järjestelmien toiminnassa.
Raportti sisältää vertailun и — Prometheus-mittareiden pitkäaikaista säilytystä koskevat hankkeet.
Ensin kerron sinulle Prometheuksesta. Tämä on valvontajärjestelmä, joka kerää mittareita määritetyistä kohteista ja tallentaa ne paikalliseen tallennustilaan. Prometheus voi tallentaa mittareita etämuistiin ja luoda hälytyksiä ja tallennussääntöjä.
Prometheuksen rajoitukset:
- Sillä ei ole yleistä kyselynäkymää. Tämä on silloin, kun sinulla on useita itsenäisiä prometheus-esiintymiä. He keräävät mittareita. Ja haluat tehdä kyselyn kaikkien näiden eri prometheus-esiintymistä kerättyjen mittareiden päälle. Prometheus ei salli tätä.
- Prometheuksen suorituskyky on rajoitettu vain yhteen palvelimeen. Prometheus ei skaalaudu automaattisesti useiden palvelimien kesken. Voit jakaa kohteesi vain manuaalisesti useiden Prometheuksen kesken.
- Prometheuksen mittareiden laajuus on rajoitettu vain yhteen palvelimeen samasta syystä, koska se ei voi skaalata automaattisesti useiden palvelimien kesken.
- Tietoturvan järjestäminen Prometheuksessa ei ole niin helppoa.
Ratkaisuja näihin ongelmiin/haasteisiin?
Ratkaisut ovat:
Kaikki nämä ratkaisut ovat Prometheuksen keräämien tietojen etätallennusta. Ne ratkaisevat etätallennusongelman edellisestä diasta eri tavoin. Tässä esityksessä puhun vain kahdesta ensimmäisestä ratkaisusta: и .
Ensimmäistä kertaa tietoa aiheesta ilmestyi . Arkkitehtuuri on kuvattu siellä ja miten se toimii.
Thanos ottaa Prometheuksen tallentamat tiedot paikalliselle levylle ja kopioi ne S3:lle tai toiseen esinevarastoon.
Siten Thanos tarjoaa globaalin kyselynäkymän. Voit kysyä objektimuistiin tallennettuja tietoja useista Prometheus-esiintymistä.
Thanos tukee PromQL- ja .
Thanos käyttää Prometheus-koodia tietojen tallentamiseen.
Thanosin ovat kehittäneet samat kehittäjät kuin Prometheus.
Про . Täällä , jossa puhuimme ensimmäisen kerran .
VictoriaMetrics saa tietoja useilta prometheuksilta Prometheuksen tukema protokolla.
VictoriaMetrics tarjoaa maailmanlaajuisen kyselynäkymän, koska useat Prometheus-instanssit voivat kirjoittaa tietoja yhteen VictoriaMetricsiin. Näin ollen voit tehdä kyselyitä kaikista näistä tiedoista.
VictoriaMetrics tukee myös, kuten Thanos, PromQL ja Prometheus kyselysovellusliittymää.
Toisin kuin Thanos, VictoriaMetrics-lähdekoodi on kirjoitettu tyhjästä ja on optimoitu nopeutta ja resurssien kulutusta varten.
VictoriaMetrics, toisin kuin Thanos, skaalautuu sekä pysty- että vaakasuunnassa. Syödä , joka skaalautuu pystysuunnassa. Voit aloittaa yhdellä prosessorilla ja 1 Gt muistilla ja kasvaa vähitellen satoihin prosessoreihin ja 1 Tt muistiin. VictoriaMetrics voi käyttää kaikkia näitä resursseja. Sen suorituskyky kasvaa noin 100 kertaa verrattuna 1-ytimiseen järjestelmään.
Thanosin historia alkoi marraskuussa 2017, kun ensimmäinen julkinen sitoumus ilmestyi. Ennen tätä Thanos kehitettiin sisäisesti .
Kesäkuussa 2019 julkaistiin maamerkkijulkaisu 0.5.0, jossa protokollaa. Hänet poistettiin Thanoksesta, koska hän ei esiintynyt hyvin. Usein Thanos-klusteri ei toiminut oikein, solmut liittyivät siihen väärin juoruprotokollan takia. Siksi päätimme poistaa hänet sieltä. Mielestäni tämä on oikea päätös.
Samassa kesäkuussa 2019 he lähettivät hakemusnumeron в .
Ja parin kuukauden kuluttua Thanos hyväksyttiin , joka sisältää Prometheuksen, Kubernetesin ja muita suosittuja projekteja.
Tammikuussa 2018 VictoriaMetricsin kehitys alkoi.
Syyskuussa 2018 mainitsin VictoriaMetricsin julkisesti ensimmäistä kertaa.
Joulukuussa 2018 julkaistiin yhden solmun versio.
Toukokuussa 2019 sekä yhden solmun että klusterin versioiden lähteet.
Kesäkuussa 2019, kuten Thanos, lähetimme hakemuksen CNCF-säätiölle numerolla . Haimme päivää ennen Thanosin hakemista.
Mutta valitettavasti meitä ei ole vieläkään hyväksytty sinne. Yhteisön apua tarvitaan.
Katsotaanpa tärkeimpiä dioja, jotka esittävät Thanosin ja VictoriaMetricsin arkkitehtuuria.
Aloitetaan Thanoksesta. Keltaiset komponentit ovat Prometheus-komponentteja. Kaikki muu on Thanos-komponentteja. Aloitetaan tärkeimmästä komponentista. Thanos Sidecar on komponentti, joka asennetaan jokaisen Prometheuksen viereen. Se lataa Prometheus-tiedot paikallisesta tallennustilasta S3:een tai toiseen objektitallennustilaan.
Siellä on myös Thanos Store Gateway -niminen komponentti, joka voi lukea nämä tiedot Object Storagesta Thanos Queryn saapuvien pyyntöjen yhteydessä. Thanos Query toteuttaa PromQL:n ja Prometheus API:n. Eli ulkopuolelta se näyttää Prometheukselta. Vastaanottaa PromQL-kyselyt, lähettää ne Thanos Store Gatewaylle, Thanos Store Gateway hakee tarvittavat tiedot Object Storagesta ja lähettää ne takaisin.
Mutta tallennamme tietoja Object Storageen ilman viimeisiä kahta tuntia Thanos Sidecar -toteutuksen ominaisuuden vuoksi, joka ei voi ladata kahta viimeistä tuntia Object Storage S3:een, koska Prometheus ei ole vielä luonut tiedostoja näiden kahden tunnin ajalta paikalliseen tallennustilaan.
Miten päätit kiertää tämän? Thanos Query lähettää Thanos Store Gatewayn pyyntöjen lisäksi rinnakkaisia pyyntöjä jokaiseen Thanos Sidecariin, joka sijaitsee Prometheuksen vieressä.
Ja Thanos Sidecar puolestaan välittää pyynnöt edelleen Prometheukselle ja hakee tiedot viimeisen kahden tunnin ajalta.
Näiden komponenttien lisäksi on myös valinnainen komponentti, jota ilman Thanos ei toimi hyvin. Tämä on Thanos Compact, joka vastaa pienten Object Storagen tiedostojen yhdistämisestä suurempiin tiedostoihin, jotka Thanos Sidecars on ladannut tänne. Thanos Sidecar lataa datatiedostot sinne kahdessa tunnissa. Jos näitä tiedostoja ei yhdistetä suurempiin tiedostoihin, niiden määrä voi kasvaa erittäin merkittävästi. Mitä enemmän tällaisia tiedostoja, sitä enemmän muistia Thanos Store Gateway tarvitsee, sitä enemmän resursseja tarvitaan tiedon ja metatietojen siirtämiseen verkon yli. Thanos Store Gateway ei toimi. Siksi on välttämätöntä käyttää Thanos Compactia, joka yhdistää pienet tiedostot suurempiin tiedostoihin, jotta tällaisia tiedostoja on vähemmän ja Thanos Store Gatewayn ylimääräiset kustannukset pienenevät.
On myös sellainen komponentti kuin Thanos Ruler. Se suorittaa Prometheus-hälytyssääntöjä ja voi arvioida Prometheus-tallennussääntöjä kirjoittaakseen tietoja takaisin Object Storage -muistiin. Mutta tätä komponenttia ei suositella käytettäväksi, koska... Hän .
Tämä on Thanoksen yksinkertainen kaava.
Verrataan nyt sitä VictoriaMetrics-järjestelmään.
VictoriaMetricsillä on 2 versiota: yhden solmun ja klusterin versio. Yksisolmu toimii yhdessä tietokoneessa. Yksisolmussa ei ole näitä komponentteja, vain yksi binääri. Tämä dian binaari näyttää tältä neliöltä. Kaikki neliön sisällä oleva on Single-node-version binaaritiedoston sisältöä. Sinun ei tarvitse tietää hänestä. Käytät vain binaaria ja kaikki toimii meille.
Klusteriversio on monimutkaisempi. Sen sisällä on kolme eri komponenttia: vmselect, vminsert ja vmstorage. Heidän nimensä perusteella pitäisi olla selvää, mitä kukin heistä tekee. Insert-komponentti hyväksyy tiedot eri muodoissa: Prometheus-etäkirjoitussovellusliittymästä, Influx-linjaprotokollasta, Graphite-protokollasta ja OpenTSDB-protokollasta. Insert-komponentti hyväksyy ne, jäsentää ja jakaa ne olemassa olevien tallennuskomponenttien kesken, joihin tiedot on jo tallennettu. Select-komponentti puolestaan hyväksyy PromQL-kyselyt. Hän toteuttaa , sekä Prometheus-kyselysovellusliittymää, ja sitä voidaan käyttää Prometheuksen korvaajana Grafanassa tai muissa Prometheus API -asiakasohjelmissa. Select hyväksyy promql-pyynnön, jäsentää sen, lukee tämän pyynnön suorittamiseen tarvittavat tiedot tallennussolmuista, käsittelee nämä tiedot ja palauttaa vastauksen.
Verrataanpa Thanosin ja VictoriaMetricsin asennuksen monimutkaisuutta.
Aloitetaan Thanoksesta. Ennen kuin alat työskennellä Thanosin kanssa, sinun on luotava ämpäri Object Storagessa, kuten S3 tai GCS, jotta Thanos Sidecar voi kirjoittaa siihen tietoja.
Sitten jokaiseen Prometheukseen on asennettava Thanos Sidecar. Ennen tätä sinun täytyy muistaa poistaa Prometheuksen tietojen pakkaaminen käytöstä. Tietojen tiivistäminen pakkaa ajoittain paikallisessa Prometheus-tallennustilassa olevat tiedot resurssien kulutuksen vähentämiseksi.
Kun asennat Thanos Sidecarin Prometheus-laitteeseen, sinun on poistettava tämä tietojen pakkaaminen käytöstä, koska Thanos Sidecar ei toimi kunnolla, kun tietojen pakkaaminen on käytössä. Tämä tarkoittaa, että Prometheus alkaa tallentaa tietoja kahden tunnin lohkoissa ja lopettaa näiden lohkojen yhdistämisen suurempiin lohkoihin. Vastaavasti, jos teet kyselyitä, jotka ylittävät viimeisen kahden tunnin keston, ne eivät toimi yhtä tehokkaasti kuin voisivat toimia, jos tietojen pakkaaminen olisi käytössä.
Siksi Thanos suosittelee lyhentämään tietojen säilytysaikaa paikallisessa tallennustilassa 6-8 tuntiin, jotta voidaan vähentää suuren määrän pienten lohkojen ylimääräisiä kustannuksia.
Kun olet asentanut Thanos Sidecarin, sinun on asennettava kaksi komponenttia jokaista Object Storage Bucket -säilöntä kohden. Nämä ovat Thanos Compactor ja Thanos Store Gateway.
Tämän jälkeen sinun on asennettava Thanos Query ja määritettävä se niin, että se voi muodostaa yhteyden kaikkiin Thanos Store -yhdyskäytävään, jotka sinulla on, ja voi myös muodostaa yhteyden kaikkiin Thanos-sivuvaunuihin.
Tässä voi olla pieni ongelma.
Sinun on määritettävä luotettava ja turvallinen yhteys Thanos Querysta näihin komponentteihin. Ja jos Prometheus sijaitsee eri datakeskuksissa tai eri VPC:issä, yhteydet niihin ulkopuolelta ovat kiellettyjä. Mutta jotta Thanos Query toimisi, sinun on jotenkin määritettävä yhteys siellä ja sinun on keksittävä tapa.
Jos sinulla on monia tällaisia palvelinkeskuksia, koko järjestelmän luotettavuus laskee vastaavasti. Koska Thanos Queryn on jatkuvasti ylläpidettävä yhteyksiä kaikkiin eri datakeskuksissa sijaitseviin Thanos-sivuvaunuihin. Jokaisesta saapuvasta pyynnöstä se reitittää pyynnöt kaikkiin Thanos-sivuvaunuihin. Jos yhteys katkeaa, saat joko epätäydellisen tietojoukon tai saat "klusteri on katkaistu" -vastauksen.
VictoriaMetricsissä kaikki on hieman yksinkertaisempaa. Yhden solmun versiossa sinun tarvitsee vain ajaa yksi binaari ja kaikki toimii.
Klusteriversiossa riittää, että ajetaan kaikkia edellä mainittuja kolmea komponenttityyppiä missä tahansa tarvitsemassasi tai käytössäsi olevassa määrissä automatisoida Kubernetesin komponenttien julkaisu. Suunnittelemme myös Kubernetes-operaattorin tekemistä. Ruorikaavio ei kata kaikkia tapauksia ja antaa sinun ampua itseäsi jalkaan. Sen avulla voit esimerkiksi vähentää tallennussolmujen määrää, mikä johtaa tietojen menetykseen.
Kun olet käynnistänyt yhden binaariversion tai klusteroidun version, sinun tarvitsee vain lisätä Prometheus konfiguraatioon niin, että se alkaa kirjoittaa tietoja rinnakkain paikalliseen tallennustilaan ja etämuistiin. Kuten näet, tämän kokoonpanon pitäisi toimia paljon luotettavammin verrattuna Thanos-kokoonpanoon. Meidän ei tarvitse ylläpitää yhteyttä VictoriaMetricsistä kaikkiin Prometheuksiin, koska Prometheus itse muodostaa yhteyden VictoriaMetricsiin ja lähettää tietoja.
Tarkastellaanpa Thanosin ja VictoriaMetricsin tukea.
Thanosin on valvottava Sidecaria varmistaakseen, että ne eivät lopeta tietojen lataamista Object Storageen. He voivat keskeyttää tämän tietojen lataamisen latausvirheiden vuoksi, esimerkiksi verkkoyhteytesi objektitallennustilaan on tilapäisesti katkennut tai Object Storage ei ole tilapäisesti käytettävissä. Thanos Sidecar huomaa tämän tällä hetkellä, ilmoittaa virheestä, saattaa kaatua ja sitten lakkaa toimimasta. Jos et valvo sitä, lopetat tietojen siirtämisen Object Storageen. Jos säilytysaika kuluu (suositus 6-8 tuntia), menetät tiedot, jotka eivät päätyneet Object Storage -palveluun.
Thanos-puristimet saattavat lakata toimimasta johtuen . Pakkaajat ottavat tietoja Object Storagesta ja yhdistävät ne suuremmiksi tietopaloiksi. Koska tiivistäjiä ei synkronoida sivuvaunujen kanssa, seuraavaa voi tapahtua: Sidecar ei ole vielä ehtinyt viimeistellä lohkoa, Compactor päättää, että tämä lohko on kirjoitettu kokonaan. Compactor alkaa lukea sitä. Se ei lue lohkoa kokonaan ja lakkaa toimimasta. Katso yksityiskohdat .
Store Gateway saattaa palauttaa epäjohdonmukaisia tietoja Compactorin ja Sidecars -kilpailujen vuoksi. Sama tapahtuu täällä, koska Store Gateway ei ole synkronoitu puristimien ja sivuvaunujen kanssa millään tavalla. Vastaavasti kilpailuolosuhteita voi esiintyä, kun Store Gateway ei näe osaa tiedoista tai näkee tarpeettomia tietoja.
Thanoksen kyselykomponentti palauttaa oletuksena osittaisen tuloksen, jos jotkin sivuvaunut tai kauppayhdyskäytävät eivät ole tällä hetkellä saatavilla. Saat osan tiedoista, etkä edes tiedä, ettet saanut kaikkia tietoja. Näin se toimii oletuksena. Samanlaisessa tilanteessa VictoriaMetrics palauttaa merkityt tiedot osittaisina.
Toisin kuin Thanos, VictoriaMetrics menettää harvoin tietoja. Vaikka yhteys Prometheuksesta VictoriaMetricsiin katkeaisi, tämä ei ole ongelma, sillä Prometheus jatkaa saapuvien uusien tietojen tallentamista Write Ahead -lokiin, jonka koko on 2 tuntia. Jos palautat yhteyden VictoriaMetricsiin kahden tunnin kuluessa, tietosi eivät katoa. Prometheus .
Toisin kuin Thanos, joka kirjoittaa tiedot objektimuistiin vasta kahden tunnin kuluttua, Prometheus replikoi tiedot automaattisesti etäkirjoitusprotokollan avulla etämuistiin, kuten VictoriaMetricsiin. Et pelkää menettää Prometheuksen paikallista tallennustilaa. Jos hän yhtäkkiä menetti paikallisen tallennustilan, pahimmassa tapauksessa menetät viimeiset sekunnit tiedoista, joita ei ehtinyt tallentaa etämuistiin.
Kubernetes hallitsee klusteria automaattisesti, toisin kuin Thanos. Kaikkia Thanos-komponentteja on vaikea sijoittaa yhteen Kubernetes-klusteriin, toisin kuin VictoriaMetrics-klusterin komponentit.
VictoriaMetricsillä on hyvin yksinkertainen päivitys uuteen versioon. Pysäytä VictoriaMetrics, päivitä binaarit ja käynnistä se. Kun kaikki VictoriaMetrics-binaarit pysäytetään SIGINT-signaalin kautta, ne sulkeutuvat sulavasti. He tallentavat tarvittavat tiedot oikein, sulkevat saapuvat yhteydet oikein, jotta ne eivät menetä mitään. Et siis menetä mitään päivittäessäsi.
VictoriaMetrics tekee klusterin laajentamisesta erittäin helppoa. Lisää vain tarvittavat komponentit ja jatka työskentelyä.
Tietoja Thanoksen ja VictoriaMetricsin sudenkuopat.
Thanosilla on seuraavat sudenkuopat. Prometheuksen on säilytettävä tiedot viimeisen kahden tunnin ajalta. Jos ne katoavat, menetät ne kokonaan, koska niitä ei ole vielä kirjoitettu Object Storageen, kuten S3.
Store Gateway -komponentti ja tiivistinkomponentti voivat vaatia paljon muistia toimiakseen suuren objektitallennustilan kanssa, jos sinne on tallennettu monia pieniä tiedostoja. Mitä suurempi määrä ja koko tiedostoja on, sitä enemmän Store Gatewayn ja tiivistimen RAM-muistia tarvitaan metatietojen tallentamiseen. Thanosilla on paljon ongelmia sen suhteen .
Thanoksen mainostetaan skaalautuvan loputtomiin Prometheuksen määrään. Tämä ei itse asiassa pidä paikkaansa. Koska kaikki pyynnöt kulkevat Query-komponentin kautta, jonka on samanaikaisesti pohdittava kaikki Store Gateway -komponentit ja kaikki Sidecar-komponentit, noudettava tiedot sieltä ja esikäsiteltävä ne. Ilmeisesti pyyntönopeutta rajoittaa hitain heikko linkki, hitain Store Gateway tai hitain sivuvaunu.
Nämä komponentit voivat olla kuormitettuja epätasaisesti. Sinulla on esimerkiksi Prometheus, joka kerää miljoonia mittareita sekunnissa. Ja on Prometheus, joka kerää tuhansia mittareita sekunnissa. Prometheus, joka kerää miljoonia mittareita sekunnissa, kuormittaa paljon enemmän palvelinta, jolla se toimii. Näin ollen Sidecar toimii siellä hitaammin. Ja yleensä kaikki toimii siellä hitaasti. Ja Kyselykomponentti vetää tietoja sieltä hyvin hitaasti. Näin ollen tämä hidas sivuvaunu rajoittaa koko klusterisi suorituskykyä.
Oletuksena Thanos antaa osittaisia tietoja, jos jotkin sivuvaunut ja joko Store Gateway eivät ole käytettävissä. Esimerkiksi, jos sivuvaunusi ovat hajallaan ympäri maailmaa eri datakeskuksissa, yhteyshäiriön ja komponenttien epäkäytettävyyden todennäköisyys kasvaa huomattavasti. Näin ollen useimmissa tapauksissa saat osittaisia tietoja tietämättäsi.
VictoriaMetricsillä on myös sudenkuoppia. Ensimmäinen sudenkuoppa on vaihtoehto, joka rajoittaa VictoriaMetrics-välimuistin RAM-muistin määrää. Oletusarvoisesti se vastaa 60 % sen koneen RAM-muistista, jossa VictoriaMetrics on käynnissä, tai 60 % Kubernetesin VictoriaMetrics podin RAM-muistista.
Jos muutat tätä arvoa väärin, voit pilata VictoriaMetricsin suorituskyvyn. Jos esimerkiksi asetat arvon liian pieneksi, tiedot eivät ehkä enää mahdu VictoriaMetrics-välimuistiin. Tämän vuoksi hänen on tehtävä ylimääräistä työtä ja ladattava prosessori ja levy. Jos teet tästä vaihtoehdosta liian suuren, se lisää todennäköisyyttä, että VictoriaMetrics kaatuu muistin loppumisesta johtuvasta virheestä, ja toiseksi se johtaa siihen, että käyttöjärjestelmän muistissa on hyvin vähän RAM-muistia jäljellä tiedostovälimuisti. Ja VictoriaMetrics luottaa tiedostovälimuistiin suorituskyvyssä. Jos se ei riitä, levyn kuormitus voi kasvaa huomattavasti. Siksi neuvo: älä muuta parametria, ellei se ole ehdottoman välttämätöntä.
Toinen vaihtoehto. Tämä on retentionPeriod - ajanjakso, joka on oletuksena 1 kuukausi. Tämä on aika, jonka VictoriaMetrics tallentaa tietoja. Tämän ajanjakson jälkeen VictoriaMetrics poistaa tiedot.
Monet ihmiset käyttävät VictoriaMetricsiä ilman tätä parametria ja tallentavat tietoja kuukauden ajan. Ja sitten he kysyvät: miksi edellisen kuukauden tiedot katosivat? Koska oletusarvoinen säilytysaika on 1 kuukausi. Siksi sinun on tiedettävä ja asetettava oikea retentionPeriod.
Katsotaanpa ainutlaatuisia ominaisuuksia.
Thanosilla on ominaisuus nimeltä alasampling: 5 minuutin ja tunnin välein, mikä usein . Jos googletat ja katsot heidän ongelmaansa githubissa, tähän alasnäytteenottoon liittyy paljon ongelmia, että se ei joskus toimi oikein tai ei toimi käyttäjien odottamalla tavalla.
Thanosilla on tietojen duplikointi Prometheus HA -pareille. Kun kaksi Prometheusta kerää samat tiedot samoista kohteista ja Thanos tallentaa ne Object Storageen. Thanos voi poistaa nämä tiedot oikein toisin kuin VictoriaMetrics.
Thanosilla on hälytyskomponentti, joka oli Thanos-kaaviossa. Mutta hän .
Thanosilla on se etu, että Thanos ja Prometheus jakavat saman koodin. Thanos ja Prometheus ovat samat kehittäjät. Thanoksen tai Prometheuksen parannuksilla toinen osapuoli voittaa.
VictoriaMetricsin pääominaisuus on MetricsQL. Nämä ovat VictoriaMetrics-laajennuksia PromQL:lle, joista puhuin edellisessä suuressa valvontametodissa.
VictoriaMetrics tukee tietojen lataamista useilla eri protokollilla. VictoriaMetrics ei voi hyväksyä tietoja vain Prometheuksesta, vaan myös Influx-, OpenTSDB- ja Graphite-protokollien kautta.
VictoriaMetrics-tiedot vievät paljon vähemmän tilaa verrattuna Thanos- ja Prometheus-tietoihin.
Jos tallennat oikeita tietoja, käyttäjät puhuvat 2–5-kertaisesta levyllä olevan datan koon pienenemisestä Prometheukseen ja Thanosiin verrattuna.
Toinen VictoriaMetricsin etu on, että se on optimoitu nopeudelle.
Katsotaanpa infrastruktuurin kustannuksia.
Yksi Thanosin eduista on, että se tallentaa tietoja objektivarastoihin, mikä on suhteellisen halpaa.
Kun tallennat tietoja objektimuistiin, sinun on maksettava tietojen kirjoitus- ja lukutoiminnoista (10 dollaria miljoonaa toimintoa kohden). Kun kirjoitat tietoja objektitallennustilaan, maksat isännöintikulut tiedon lataamisesta Internetiin; jos klusterisi ei ole AWS:ssä, se on siellä ilmainen. Kun luet tietoja, maksat 10–230 dollaria per 1 Tt. Tämä voi olla merkittävää, jos teet usein kyselyitä historiallisista tiedoista Thanos-klusterista.
Thanos-klusterissa sinun on maksettava palvelimista Compact-, Store Gateway-, Query-komponenteista, jotka vaativat paljon muistia, ja suorittimesta suurista tietomääristä.
VictoriaMetricsillä on seuraavat kulut. Jos tallennat tietoja GCE-kiintolevyasemille, sen hinta on 40 dollaria 1 Tt:lta. VictoriaMetricsille tavalliset kiintolevyasemat riittävät, viisi kertaa kalliimpia SSD-levyjä ei tarvita. VictoriaMetrics on optimoitu kiintolevylle.
VictoriaMetrics vaatii palvelimia komponenteille: joko Single-nod- tai klusterikomponenteille, jotka, toisin kuin Thanos-komponentit, vaativat paljon vähemmän suoritinta ja RAM-muistia - ja ovat siten halvempia.
Esimerkkejä toteutuksesta.
Thanosilla on toteutusesimerkki Gitlabissa. Gitlab toimii kokonaan Thanosilla. Mutta kaikki ei ole siellä niin sujuvaa. Jos katsot niitä , voit nähdä, että heillä on jatkuvasti joitakin : Muisti ei riitä Store Gateway- tai Query-komponenteille. Niiden on jatkuvasti lisättävä muistin määrää.
Tästä johtuen näiden ongelmien ratkaisemisen kustannukset kasvavat.
Toinen toteutus, joka saattaa olla menestyneempi, on Improbable-yhtiö, joka aloitti Thanosin kehittämisen. He julkaisivat Thanos-lähdekoodin. Improbable on pelimoottoreita kehittävä yritys.
VictoriaMetricsillä on julkisia toteutusesimerkkejä:
- wix.com-sivuston rakentaja
- Adidas toteuttaa VictoriaMetricsiä ja jopa piti esityksen viimeisessä PromCon 2019 -tapahtumassa
- TrafficStars - mainosverkosto
- Seznam.cz on suosittu tšekkiläinen hakukone.
Ja sitten oli nimettömiä yrityksiä, joita en voi nimetä nyt. He eivät suostuneet.
- Yksi suuri pelinkehittäjä. Isompi kuin im Todennäköistä.
- Suuri grafiikkaohjelmistokehittäjä.
- Suuri venäläinen pankki.
- Eurooppalainen tuuliturbiinien valmistaja, joka on testannut menestyksekkäästi VictoriaMetricsiä. Tämä valmistaja ottaa käyttöön VictoriaMetricsin seuratakseen tuuliturbiineista kerättyä dataa nopeudella 50 näytettä sekunnissa anturia kohti. Jokaisessa tuuliturbiinissa on useita satoja antureita. Heillä on useita satoja tuulivoimaloita.
- Venäläiset lentoyhtiöt, jotka haluavat ottaa VictoriaMetricsin käyttöön, mutta eivät silti pysty. Olemme heidän kanssaan sopimusvaiheessa.
Johtopäätökset.
VictoriaMetrics ja Thanos ratkaisevat samanlaisia ongelmia, mutta eri tavoilla:
- Globaali kyselynäkymä
- vaakasuora skaalaus
- mielivaltainen säilyttäminen
Kiitos.
Odotamme sinua meillä .
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Mitä käytät Prometheuksen pitkäaikaissäilytykseen?
35,3%Thanos 6
0,0%Cortex0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%muut 4
17 käyttäjää äänesti. 16 käyttäjää pidättyi äänestämästä.
Lähde: will.com
