Üdvözlet mindenkinek. Az alábbiakban a .
– különféle rendszerek és szolgáltatások monitorozására szolgáló rendszer, amellyel a rendszergazdák információt gyűjthetnek a rendszerek aktuális paramétereiről és értesítéseket állíthatnak be a rendszerek működésében bekövetkező eltérésekről.
Az előadásban összehasonlítás szerepel és — a Prometheus hosszú távú metrikagyűjtő projektjeivel.
Elsőként a Prometheusról beszélek. Ez egy monitorozó rendszer, amely a megadott target-ekről gyűjti a metrikákat és tárolja őket egy helyi tárolóban. A Prometheus képes metrikákat távoli tárolóba is írni, generálni alert-eket és recording rules-okat.
A Prometheus korlátai:
- Nincs globális lekérdezési nézete. Ez akkor valósul meg, amikor több független Prometheus példány van. Ezek gyűjtik a metrikákat. És kérdést szeretne feltenni az összes, különböző Prometheus példányból gyűjtött metrikáról. A Prometheus ezt nem teszi lehetővé.
- A Prometheus teljesítménye csak egy szerverre korlátozódik. A Prometheus automatikusan nem képes skálázódni több szerverre. Csak kézzel tudja felosztani a targetjeit több Prometheus között.
- A Prometheus által gyűjtött metrikák mennyisége is csak egy szerverre korlátozódik, ugyanezen okból, amiért automatikusan nem tud skálázódni több szerverre.
- A Prometheusban nem olyan egyszerű az adatok megőrzésének megszervezése.
Ezek a problémák / feladatok megoldásai?
A megoldások a következők:
Ezek az összes megoldás az adatokat távolról tároló Prometheus számára. Ezek különböző módon oldják meg a távoli tárolás problémáját az előző dián. Ebben a prezentációban csak az első két megoldásról beszélek: és .
Először információ jelent meg a -ban . Itt a struktúrája van leírva és hogy hogyan működik.
A Thanos a Prometheus által a helyi lemezre mentett adatokat átveszi, és másolja őket az S3-ba, a vagy más objektumtárolóba.
Így a Thanos globális lekérdezési nézetet biztosít. Lekérdezhet olyan adatokat, amelyeket az objektumtárolóban tároltak, több Prometheus példánytól.
A Thanos támogatja a PromQL-t és .
A Thanos a Prometheus kódját használja az adatok tárolására.
A Thanos fejlesztői ugyanazok, mint a Prometheus fejlesztői.
A . Itt először beszéltünk a .
VictoriaMetrics a több prometheusból nyer adatokat a amelyet a Prometheus támogat.
A VictoriaMetrics biztosítja a globális lekérdezési nézetet, mivel több Prometheus példány is írhatsz adatokat egyetlen VictoriaMetrics példányba. Ennek megfelelően kérdéseket tehetsz fel ezekre az adatokra.
A VictoriaMetrics támogatja a PromQL-t és a Prometheus lekérdezési API-t, akárcsak a Thanos.
A Thanos-tól eltérően a VictoriaMetrics forráskódját nulláról írták, és a sebesség és az erőforrás-használat optimalizálására koncentráltak.
A VictoriaMetrics, a Thanos-tól eltérően, függőlegesen és vízszintesen is skálázható. Van , amely függőlegesen skálázódik. Elkezdhatsz egy processzorral és 1 GB memóriával, majd fokozatosan növelheted akár száz processzorra és 1 TB memóriára. A VictoriaMetrics képes kiaknázni ezeket az erőforrásokat. Teljesítménye körülbelül 100-szorosára nő a 1 magos rendszerhez képest.
A Thanos története 2017 novemberében kezdődött, amikor megjelent az első nyilvános commit. Ezt megelőzően a Thanos a .
bennünket, 2019 júniusában jelentős 0.5.0 kiadást tettünk közzé, amelyben a protokollt. Ezt eltávolították a Thanos-ból, mert nem működött jól. Gyakran a Thanos klaszter nem működött megfelelően, és a csomópontok hibásan csatlakoztak a gossip protokoll miatt. Ezért döntöttünk az eltávolításáról. Véleményem szerint helyes döntés volt.
Ugyanebben a júniusban benyújtották a pályázatunkat, az be. .
és néhány hónappal később a Thanos-t elfogadták a , amely magában foglalja a Prometheus-t, a Kubernetes-t és más népszerű projekteket.
A VictoriaMetrics fejlesztése 2018 januárjában kezdődött.
2018 szeptemberében először nyilvánosan említettem a VictoriaMetrics-t.
2018 decemberében kiadtuk az egységes példányú verziót.
2019 májusában mind az egységes példányú, mind a klaszter verzió forráskódját.
2019 júniusában, akárcsak a Thanos, pályázatot nyújtottunk be a CNCF alapítványhoz, azonosítóval . Egy nappal korábban nyújtottuk be a pályázatunkat, mint a Thanos.
De sajnos még mindig nem fogadtak el minket. Közösségi segítségre van szükségünk.
Nézzük meg a legfontosabb diákat, amelyek bemutatják a Thanos és a VictoriaMetrics architektúráját.
Kezdjük a Thanos-szal. A sárga komponensek a Prometheus komponensei. Minden más a Thanos komponensei. Kezdjük a legfontosabb komponenssel. A Thanos Sidecar az a komponens, amely minden Prometheus mellett telepítésre kerül. Az a feladata, hogy a Prometheus adatait a helyi tárolóból S3-ba vagy más objektumtárolóba töltse.
Van még egy összetevő, a Thanos Store Gateway, amely képes olvasni ezeket az adatokat az Object Storage-ból a Thanos Query-től érkező lekérdezések során. A Thanos Query implementálja a PromQL-t és a Prometheus API-t. Tehát kívülről úgy néz ki, mint egy Prometheus. Elfogadja a PromQL lekérdezéseket, elküldi azokat a Thanos Store Gateway-nek, amely visszahozza a szükséges adatokat az Object Storage-ból.
De az Object Storage-ban két óra nélküli adatokat tárolunk a Thanos Sidecar implementálásának sajátosságai miatt, amely nem tudja feltölteni az utolsó két órát az Object Storage S3-ba, mert ezekhez a két órához a Prometheus még nem hozott létre fájlokat a helyi tárolóban.
Hogyan sikerült ezt megkerülni? A Thanos Query a Thanos Store Gateway-be érkező lekérdezések mellett párhuzamosan lekérdezéseket küld minden Thanos Sidecar-hoz is, amelyek a Prometheus közelében helyezkednek el.
A Thanos Sidecar viszont továbbítja a lekérdezéseket a Prometheus felé, és lekéri az utolsó két óra adatokat.
Ezeken az összetevőkön kívül van egy opcionális összetevő is, amely nélkül a Thanos nem működik megfelelően. Ez a Thanos Compact, amely a kisebb fájlokat egyesíti az Object Storage-ban, nagyobb fájlokká, amelyeket a Thanos Sidecar-ok töltenek fel. A Thanos Sidecar két órás adatfájlokat tölt fel. Ezeket a fájlokat, ha nem egyesítjük nagyobb fájlokká, akkor a számuk nagyon jelentősen megnőhet. Minél több ilyen fájl van, annál több memória szükséges a Thanos Store Gateway-nek, annál több erőforrás szükséges az adatok hálózaton való továbbításához, metaadatok. A Thanos Store Gateway működése nem hatékony. Ezért feltétlenül el kell indítani a Thanos Compact-ot, amely egyesíti a kisebb fájlokat nagyobbakká, hogy csökkentse a fájlok számát és csökkentse a Thanos Store Gateway-re nehezedő terhet.
Van még egy összetevő, a Thanos Ruler. Ez végrehajtja a Prometheus riasztási szabályokat és képes kiszámítani a Prometheus rögzítési szabályokat, hogy az adatokat újra az Object Storage-ba mentse. De ezt az összetevőt nem ajánlott használni, mivel az .
Így néz ki a Thanos egyszerű séma.
Most összehasonlítjuk a VictoriaMetrics sémájával.
A VictoriaMetrics két verzióval rendelkezik: Single-node és klaszter verzió. A Single-node egy számítógépen működik. A Single-node-ban nincsenek ezek az összetevők, csupán egy bináris fájl. Ez a bináris fájl a dián ezzel a négyzettel néz ki. Minden, ami a négyzeten belül található — az a bináris fájl tartalma a Single-node verzióhoz. Nincs szüksége arra, hogy tudja. Csak indítsa el a bináris fájlt — és minden működik.
A klaszter verziója bonyolultabb. Három különböző komponenst tartalmaz: vmselect, vminsert és vmstorage. A nevükből világosan látszik, hogy mindegyik mivel foglalkozik. Az Insert komponens különböző formátumú adatokat fogad: a Prometheus távoli írási API-jából, az Influx line protokollból, a Graphite protokollból és az OpenTSDB protokollból. Az Insert komponens ezeket fogadja, elemzi és elosztja a meglévő tároló komponensek között, ahol az adatok már mentésre kerülnek. , valamint a Prometheus lekérdező API-t, és használható a Prometheus helyettesítésére a Grafanában vagy más Prometheus API kliensekben. A Select promql lekérdezést fogad, elemzi, és a szükséges adatokat olvassa ki a tároló csomópontokból, feldolgozza ezeket az adatokat, és visszaadja a választ.
Hasonlítsuk össze a Thanos és a VictoriaMetrics telepítésének összetettségét.
Kezdjük a Thanossal. Mielőtt elkezdenénk dolgozni a Thanossal, létre kell hozni egy tárolót az Object Storage-ban, például S3 vagy GCS, hogy a Thanos Sidecar oda tudja írni az adatokat.
Ezután minden Prometheushoz telepíteni kell a Thanos Sidecart. E előtt ne felejtsük el kikapcsolni az adat tömörítést a Prometheusban. Az adat tömörítés időnként tömöríti az adatokat a Prometheus helyi tárolójában, hogy csökkentse az erőforrás-felhasználást.
Amikor Thanos Sidecart telepít a Prometheus-ához, ki kell kapcsolni ezt az adat tömörítést, mert a Thanos Sidecar nem képes megfelelően működni bekapcsolt adat tömörítés mellett. Ez azt jelenti, hogy a Prometheus adatokat kétórás blokkokban kezd el tárolni, és abbahagyja a blokkok nagyobb egységekbe való fúzionálását. Ennek következtében, ha olyan lekérdezéseket végez, amelyek meghaladják az elmúlt két óra időtartamát, nem fognak olyan hatékonyan működni, mint ahogy működhetnének, ha az adat tömörítés be lenne kapcsolva.
Ezért a Thanos azt javasolja, hogy csökkentsék az adatok tárolási idejét a helyi tárolóban 6-8 órára, hogy csökkentsék a sok kis blokk miatt adódó többletköltségeket.
Miután telepítette a Thanos Sidecart, minden Object Storage Buckethez két komponenst kell telepítenie. Ezek a Thanos Compactor és a Thanos Store Gateway.
Ezután telepíteni kell a Thanos Query-t, és be kell állítani, hogy csatlakozni tudjon az összes Thanos Store Gateway-hez, ami rendelkezésre áll, valamint az összes Thanos Sidecar-hoz is.
Itt lehet egy kis probléma.
Meg kell határoznia egy megbízható és biztonságos kapcsolatot a Thanos Query és ezek között az összetevők között. Ha a Prometheusok különböző adatközpontokban vagy különböző VPC-kben találhatók, akkor a külső kapcsolatok meg vannak tiltva. De a Thanos Query működéséhez valamilyen módon be kell állítania a kapcsolatot, és ki kell találnia egy megoldást.
Ha sok ilyen adatközpontja van, akkor csökken az egész rendszer megbízhatósága. Mivel a Thanos Query folyamatosan kapcsolatban kell állnia az összes Thanos Sidecar sebességekkel, amelyek különböző adatközpontokban helyezkednek el. Minden bejövő kérésnél minden Thanos Sidecar felé fogja irányítani az adatokat. Ha a kapcsolat megszakad, akkor vagy nem teljes adatcsomagot kap, vagy a választ «a klaszter nem működik» választ kapja.
A VictoriaMetrics esetén minden kicsit egyszerűbb. Az egycsomópontos verzióhoz elegendő csak egy bináris fájlt elindítani, és minden működik.
A klaszteres verzióhoz csak az összes fent említett három típusú komponenst kell elindítani a kívánt mennyiségben, vagy használni kell az összetevők automatikus indításához a Kubernetesben. Tervezzük, hogy Kubernetes operátort is készítünk. A Helm chart nem fed le bizonyos eseteket, és lehetőséget ad arra, hogy a lábunkba lőjünk. Például lehetővé teszi a tárolócsomópontok számának csökkentését, ami adatvesztéshez vezet.
Miután elindította az egy bináris fájlt vagy a klaszteres verziót, elegendő csak hozzáadni a Prometheus konfigurációjához , hogy párhuzamosan elkezdje az adatokat rögzíteni a helyi tárolóba és a távoli tárolóba. Mint láthatja, ez a konfiguráció sokkal megbízhatóbban kell, hogy működjön a Thanos konfigurációhoz képest. Nincs szükség a VictoriaMetrics és az összes Prometheus közötti kapcsolatra, mert a Prometheusok maguk kapcsolódnak a VictoriaMetricshez és továbbítják az adatokat.
Tekintsük a Thanos és a VictoriaMetrics támogatását.
A Thanos-nak figyelemmel kell kísérnie a Sidecart, hogy azok ne álljanak le az adatok betöltésével az Object Storage-ba. Előfordulhat, hogy leállítják ezt a betöltést a betöltési hibák miatt, például, ha ideiglenesen megszakad a hálózati kapcsolat az Object Storage-dal, vagy ha az Object Storage ideiglenesen elérhetetlenné válik. A Thanos Sidecar ebben a pillanatban észleli ezt, hibát jelez, esetleg leáll, és ezután megáll a működés. Ha nem figyelemmel kíséri, az adatok átadása leáll az Object Storage-ba. Ha eltelt a megőrzési idő (ajánlott 6-8 óra), akkor adatokat fog elveszíteni, amelyek nem kerültek az Object Storage-ba.
A Thanos sűrítők leállhatnak a következők miatt . A sűrítők az Object Storage-ból veszik az adatokat, és nagyobb adatblokkokba egyesítik őket. Mivel a sűrítők nincsenek szinkronizálva a Sidecar-ral, a következő történhet: a Sidecar még nem fejezte be a blokk írását, a Sűrítő úgy dönt, hogy ez a blokk teljesen fel van írva. A Sűrítő elkezdi olvasni, de nem a teljes blokkot olvassa, és leáll. Részletekért lásd: .
A Store Gateway inkonzisztens adatokat adhat vissza a Sűrítő és a Sidecar közötti versenyek miatt. Ugyanez a helyzet, mert a Store Gateway nem szinkronizált a Sűrítőkkel és a Sidecar-ral. Ennek következtében versenyhelyzetek alakulhatnak ki, amikor a Store Gateway nem lát bizonyos adatokat, vagy felesleges adatokat lát.
A Thanos lekérdező komponens alapértelmezés szerint részleges eredményt ad vissza, ha egyes Sidecar-ok vagy a Store Gateway éppen nem elérhetők. Részleges adatokat kap, és még csak nem is tud róla, hogy nem kapott meg mindent. Alapértelmezés szerint így működik. Hasonló helyzetben a VictoriaMetrics jelöli meg az adatokat, mint részlegeseket.
A Thanos-szal ellentétben a VictoriaMetrics ritkán veszít el adatokat. Még akkor is, ha megszakad a kapcsolat a Prometheus és a VictoriaMetrics között, ez nem probléma, mivel a Prometheus továbbra is írja az újonnan beérkező adatokat a Write Ahead Log-ba, amelynek mérete 2 óra. Ha a két óra alatt helyreállítja a kapcsolatot a VictoriaMetrics-szal, az adatok nem vesznek el. A Prometheus .
A Thanos-szal ellentétben, amely az adatokat csak két óra elteltével írja be az object storage-ba, a Prometheus automatikusan replikálja az adatokat a remote write protokollal a remote storage-ba, mint például a VictoriaMetrics. A Prometheus esetében nem kell félnie a helyi tároló elvesztésétől. Ha véletlenül elveszíti a helyi tárolót, akkor a legrosszabb esetben az utolsó másodpercek adatai vesznek el, amelyek nem kerültek be a távoli tárolóba.
A Kubernetes automatikusan kezeli a klasztert, ellentétben a Thanos-szal. A Thanos összes komponensét nehéz egy Kubernetes klaszterbe helyezni, míg a VictoriaMetrics klasztern belüli komponensei könnyebben kezelhetők.
A VictoriaMetrics nagyon egyszerűen frissíthető az új verzióra. Egyszerűen állítsa le a VictoriaMetrics-t, frissítse a binárisokat és indítsa újra. A SIGINT jelzéssel történő leállításkor az összes VictoriaMetrics bináris szép leállítást végez. Helyesen menti a szükséges adatokat, és helyesen zárja le a bejövő kapcsolatokat, hogy semmi se vesszen el. Tehát frissítés során semmit sem veszít.
A VictoriaMetrics esetében nagyon egyszerű a klaszter bővítése. Egyszerűen adja hozzá a szükséges komponenseket, és folytassa a munkát.
A Thanos és a VictoriaMetrics rejtett buktatóiról.
A Thanos esetében a következő buktatók léteznek. A Prometheusnak az elmúlt két órára szüksége van az adatok tárolására. Ha ezek elvesznek, akkor teljesen elveszik, mivel még nem íródtak be az Object Storage-ba, mint például az S3.
A Store Gateway és a compactor komponens sok memóriát igényelhet, ha nagy Object Storage-szal dolgozik, amelyben sok apró fájl található. Minél több fájl és ezek nagysága, annál több RAM-ra van szükség a Store Gateway-nek és a compactornak a metaadatok tárolásához. A Thanos számos problémája van azzal kapcsolatban, hogy .
A Thanos azt hirdeti, hogy végtelenül skálázható a Prometheusok számával. Valójában ez nem igaz. Mivel minden kérés a Query komponensen keresztül zajlik, amelynek párhuzamosan kell lekérdeznie az összes Store Gateway komponenst és az összes Sidecar komponenst, hogy onnan adatokat nyerjen, majd előfeldolgozza azokat. Nyilvánvaló, hogy a lekérdezések sebességét a leglassabb gyenge láncszem korlátozza, ami a leglassabb Store Gateway, vagy a leglassabb Sidecar.
Ezek a komponensek egyenlőtlenül terhelődhetnek. Például van egy Prometheus, amely másodpercenként millió metrikát gyűjt. És van egy Prometheus, amelyben másodpercenként ezrek gyűlnek. Az a Prometheus, amely millió metrikát gyűjt másodpercenként, sokkal jobban megterheli a szervert, amelyen fut. Ennek megfelelően a Sidecar ott lassabban működik. És általában minden lassan működik ott. A Query komponens nagyon lassan fogja az adatokat lehívni onnan. Ezért az egész klaszter teljesítménye azzal a lassú Sidecarra lesz korlátozva.
Alapértelmezés szerint a Thanos részleges adatokat szolgáltat, ha néhány Sidecar vagy Store Gateway nem érhető el. Például, ha a Sidecarok a világ különböző adatközpontjaiban szétszórva vannak, akkor nagyobb a valószínűsége a kapcsolat megszakadásának és a komponensek elérhetetlenségének. Ezért a legtöbb esetben részleges adatokat fog kapni, anélkül, hogy tudna róla.
A VictoriaMetricsnak is vannak rejtett buktatói. Az első buktató egy opció, amely korlátozza a VictoriaMetrics által használt memória mennyiségét. Alapértelmezés szerint ez a memória a gépen, ahol a VictoriaMetrics fut, a RAM 60%-a, vagy a VictoriaMetrics pod RAM-jának 60%-a a Kubernetesben.
Ha rosszul változtatja meg ezt az értéket, akkor tönkreteheti a VictoriaMetrics teljesítményét. Például, ha túl alacsony értéket állít be, akkor az adatok leállhatnak a VictoriaMetrics gyorsítótárában. Emiatt a VictoriaMetricsnek extra munkát kell végeznie, ami leterheli a processzort és a lemezt. Ha ezt az opciót túl magasra állítja, akkor egyrészt nő a valószínűsége, hogy a VictoriaMetrics out of memory hibával leáll, másrészt viszont nagyon kevés memória maradhat a fájlgyorsítótár számára az operációs rendszerben. A VictoriaMetrics a fájlgyorsítóra támaszkodik a teljesítmény szempontjából. Ha nem elegendő, akkor jelentősen megnő a lemez terhelése. Ezért a tanács: ne változtassa meg a paramétert szükségtelenül.
A második opció a retentionPeriod — az időszak, amely alapértelmezés szerint 1 hónapra van állítva. Ez az az időtartam, amely alatt a VictoriaMetrics tárolja az adatokat. Ennek a határidőnek a lejártakor a VictoriaMetrics törli az adatokat.
Sokan indítják el a VictoriaMetrics-ot ezen paraméter nélkül, és egy hónapig gyűjtik az adatokat. Aztán megkérdezik: miért tűntek el az adatok az előző hónapról? Mert a retentionPeriod alapértelmezett értéke 1 hónap. Ezért tudni kell és be kell állítani a helyes retentionPeriod-ot.
Nézzük meg az egyedi lehetőségeket.
A Thanos rendelkezik egy funkcióval, amelyet downsampling-nak hívnak: 5 perces és órás intervallumok, amelyek gyakran . Ha rákeresünk, és megnézzük a GitHub-on a problémáikat, rengeteg olyan ügy van, ami ezzel a downsampling-gal kapcsolatos, hogy néha helytelenül működik, vagy nem úgy, ahogy a felhasználók várják.
A Thanos rendelkezik a Prometheus HA párok adatidők deduplikálásával. Amikor két Prometheus ugyanazokat a metrikákat gyűjti ugyanazoktól a célpontoktól, a Thanos ezeket az Object Storage-ba összegzi. A Thanos helyesen tudja deduplikálni ezeket az adatokat, ellentétben a VictoriaMetrics-szal.
A Thanosnak van egy értesítési komponense, amely a Thanos ábrán látható. De azt .
A Thanos előnye, hogy a Thanos és a Prometheus kódja közös. A Thanos és a Prometheus ugyanazok a fejlesztők készítették. A Thanosban vagy a Prometheusból történő fejlesztésekkel a másik fél nyer.
A VictoriaMetrics fő funkciója a MetricsQL. Ez a VictoriaMetrics bővítménye a PromQL-hez, amelyről a korábbi nagy monitoring meetupon beszéltem.
A VictoriaMetrics támogatja az adatok feltöltését számos különböző protokollon keresztül. A VictoriaMetrics nemcsak a Prometheus-tól képes adatokat fogadni, hanem Influx, OpenTSDB és Graphite protokollokon is.
A VictoriaMetrics adatai általában sokkal kevesebb helyet foglalnak el a Thanoshoz és a Prometheushoz képest.
Ha valós adatokat rögzítenek, a felhasználók a Prometheus és Thanos adataival összehasonlítva 2-5 szörös helymegtakarítást említenek a lemezen.
A VictoriaMetrics egy másik előnye, hogy sebességre optimalizált.
Nézzük át az infrastruktúra költségeit.
A Thanos egyik előnye, hogy az adatokat olcsó objektumtárolóban tárolja.
Amikor adatokat tárol az objektumtárolóban, meg kell fizetnie az adatok írási és olvasási műveleteit ($10 millió műveletért). Amikor adatokat ír az objektumtárolóba, a hosting költségeit is meg kell térítenie az internetre történő adatrábocsátás miatt, ha a klaszter nem az AWS-ben van – ott ingyenes. Amikor adatokat olvas, $10-től $230-ig terjedő összeget kell fizetnie 1 TB-ért. Ez jelentős lehet, ha gyakran kérdezi le a Thanos klaszter történeti adatait.
A Thanos cluster requires paying for servers for the Compact, Store Gateway, and Query components, which demand a lot of memory and CPU for large volumes of data.
For VictoriaMetrics, the costs are as follows. If you store data on GCE HDD disks, it amounts to $40 per 1TB. Regular HDD disks are sufficient for VictoriaMetrics; SSDs, which cost five times more, are not necessary. VictoriaMetrics is optimized for HDD.
For VictoriaMetrics, servers are needed for components: either Single-node or for clustered components, which, unlike Thanos components, require significantly less CPU and RAM — therefore, it will be cheaper.
Implementation examples.
An example of Thanos implementation is Gitlab. Gitlab runs entirely on Thanos. However, it’s not all smooth sailing there. If you look through their , you can see that they constantly face some : there’s not enough memory for the Store Gateway or Query components. They constantly have to increase the memory capacity.
Due to this, the costs for resolving these issues increase.
The second implementation, which may be more successful, is the company Improbable, which started Thanos development. They published the Thanos source code. Improbable is a company that develops game engines.
Public implementation examples for VictoriaMetrics include:
- wix.com website builder
- Adidas is implementing VictoriaMetrics and even gave a presentation at the last PromCon 2019
- TrafficStars — ad network
- Seznam.cz — a popular Czech search engine.
And there are further no-name companies that I cannot name right now. They did not give their consent.
- One large game developer. Larger than Improbable.
- A major graphics software developer.
- A large Russian bank.
- A European wind turbine manufacturer, which successfully tested VictoriaMetrics. This manufacturer implements VictoriaMetrics to monitor data received from wind turbines at a rate of 50 samples per second for each sensor. Each wind turbine has several hundred sensors. They operate several hundred wind turbines.
- Russian airlines that want to implement VictoriaMetrics but have not been able to so far. We are at the contract stage with them.
Következtetések.
VictoriaMetrics and Thanos solve similar tasks, but in different ways:
- Global query view
- horizontal scaling
- arbitrary retention
Köszönöm.
We look forward to seeing you on our .
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
What do you use as long-term storage for Prometheus?
35,3%Thanos6
0,0%Cortex0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%other4
17 felhasználó szavazott. 16 felhasználó tartózkodott.
Forrás: habr.com
