A cikk fordítása kifejezetten a kurzus hallgatói számára készült .
szoftverfejlesztő, fanatikus és problémamegoldó. Emellett a Prometheus karbantartója és a Kubernetes SIG műszerezés társalapítója. Korábban a SoundCloud gyártási mérnöke volt, és a CoreOS megfigyelőcsapatát vezette. Jelenleg a Google-nál dolgozik.
- Infrastruktúra mérnök az Improbable cégnél. Érdekli az új technológiák és az elosztott rendszerek problémái. Alacsony szintű programozási tapasztalata van az Intelnél, közreműködői tapasztalata a Mesosnál és világszínvonalú SRE gyártási tapasztalata az Improbable-nél. Elkötelezett a mikroszolgáltatások világának fejlesztése. Három szerelme: Golang, nyílt forráskód és röplabda.
A SpatialOS zászlóshajó termékünket tekintve sejthető, hogy az Improbable rendkívül dinamikus, globális szintű felhő-infrastruktúrát igényel több tucat Kubernetes-fürttel. Mi voltunk az elsők, akik alkalmaztak megfigyelő rendszert . A Prometheus több millió mérőszámot képes valós időben követni, és hatékony lekérdezési nyelvvel rendelkezik, amely lehetővé teszi a szükséges információk kinyerését.
A Prometheus egyszerűsége és megbízhatósága az egyik fő előnye. Amint azonban túljutottunk egy bizonyos mértéken, számos hátránnyal találkoztunk. E problémák megoldására fejlesztettük ki egy nyílt forráskódú projekt, amelyet az Improbable hozott létre, hogy zökkenőmentesen alakítsa át a meglévő Prometheus-fürtöket egyetlen felügyeleti rendszerré korlátlan történelmi adattárolással. A Thanos elérhető a Githubon .
Céljaink Thanosszal
Egy bizonyos léptékben olyan problémák merülnek fel, amelyek meghaladják a vanília Prometheus képességeit. Hogyan tárolhatunk petabájtnyi történelmi adatot megbízhatóan és gazdaságosan? Meg lehet ezt tenni a válaszidő csorbítása nélkül? Elérhető egyetlen API kéréssel a különböző Prometheus szervereken található összes mérőszám? Van-e mód a Prometheus HA segítségével gyűjtött replikált adatok kombinálására?
E problémák megoldására létrehoztuk a Thanos-t. A következő szakaszok leírják, hogyan közelítettük meg ezeket a kérdéseket, és elmagyarázzák céljainkat.
Adatok lekérdezése több Prometheus-példányból (globális lekérdezés)
A Prometheus funkcionális megközelítést kínál a szilánkoláshoz. Még egyetlen Prometheus szerver is elegendő méretezhetőséget biztosít ahhoz, hogy szinte minden felhasználási esetben megszabadítsa a felhasználókat a horizontális felosztás bonyolultságától.
Noha ez egy nagyszerű telepítési modell, gyakran szükséges a különböző Prometheus-kiszolgálókon lévő adatok elérése egyetlen API-n vagy felhasználói felületen keresztül – egy globális nézeten. Természetesen lehetőség van több lekérdezés megjelenítésére egy Grafana panelen, de minden lekérdezés csak egy Prometheus szerveren hajtható végre. Másrészt a Thanos segítségével több Prometheus szerverről is lekérdezhet és összesíthet adatokat, mivel ezek mindegyike egyetlen végpontról elérhető.
Korábban, hogy globális képet kapjunk az Improbable-ban, Prometheus-példányainkat többszintűvé szerveztük. . Ez azt jelentette, hogy létre kell hozni egy Prometheus metaszervert, amely összegyűjti a mérőszámok egy részét minden egyes levélkiszolgálóról.
Ez a megközelítés problémásnak bizonyult. Ez összetettebb konfigurációkat, egy további lehetséges hibapont hozzáadását és összetett szabályok alkalmazását eredményezte annak biztosítására, hogy az egyesített végpont csak a számára szükséges adatokat kapja meg. Ezenkívül ez a fajta összevonás nem teszi lehetővé a valódi globális nézet megszerzését, mivel nem minden adat érhető el egyetlen API-kérésből.
Ehhez szorosan kapcsolódik a magas rendelkezésre állású (HA) Prometheus szervereken gyűjtött adatok egységes nézete. A Prometheus HA modellje egymástól függetlenül kétszer gyűjt adatokat, ami annyira egyszerű, hogy nem is lehetne egyszerűbb. Sokkal kényelmesebb lenne azonban mindkét adatfolyam kombinált és deduplikált nézete.
Természetesen szükség van magas rendelkezésre állású Prometheus szerverekre. Az Improbablenél nagyon komolyan vesszük a percenkénti adatfigyelést, de ha fürtönként egy Prometheus-példány van, az egyetlen hibapont. Bármilyen konfigurációs hiba vagy hardverhiba fontos adatok elvesztéséhez vezethet. Még egy egyszerű üzembe helyezés is okozhat kisebb fennakadásokat a mérőszámok gyűjtésében, mivel az újraindítások jelentősen hosszabbak lehetnek, mint a kaparási időköz.
A történelmi adatok megbízható tárolása
Álmunk az olcsó, gyors, hosszú távú mérőszámok tárolása (amit a legtöbb Prometheus-felhasználó oszt meg). Az Improbable esetén kénytelenek voltunk kilenc napra állítani a mérőszámok megőrzési időszakát (Prometheus 1.8 esetén). Ez nyilvánvaló korlátokat ad annak, hogy meddig tekinthetünk vissza.
A Prometheus 2.0 ebben a tekintetben javult, mivel az idősorok száma már nem befolyásolja a szerver általános teljesítményét (lásd. ). A Prometheus azonban a helyi lemezen tárolja az adatokat. Bár a nagy hatékonyságú adattömörítés jelentősen csökkentheti a helyi SSD-használatot, végső soron még mindig korlátozott a tárolható előzményadatok mennyisége.
Emellett az Improbable-nél a megbízhatóság, az egyszerűség és a költségek is fontosak számunkra. A nagy helyi lemezek kezelése és biztonsági mentése nehezebb. Többe kerülnek, és több biztonsági mentési eszközt igényelnek, ami szükségtelen bonyolultságot eredményez.
Lefelé mintavételezés
Amikor elkezdtünk dolgozni az előzményadatokkal, rájöttünk, hogy a big-O alapvető nehézségei vannak, amelyek egyre lassítják a lekérdezéseket, miközben hetek, hónapok és évek adataival dolgozunk.
A probléma szokásos megoldása az lenne (downsampling) - a jel mintavételezési frekvenciájának csökkentése. A lemintavételezéssel nagyobb időintervallumra tudunk „leskálázni”, és ugyanannyi mintát tarthatunk fenn, így a lekérdezések válaszadók maradnak.
A régi adatok mintavételezése minden hosszú távú tárolási megoldás elkerülhetetlen követelménye, és túlmutat a vanília Prometheus hatókörén.
További célok
A Thanos projekt egyik eredeti célja az volt, hogy zökkenőmentesen integrálódjon a meglévő Prometheus-telepítésekkel. A második cél a könnyű kezelés volt, minimális belépési korlátokkal. Bármilyen függőségnek könnyen kielégíthetőnek kell lennie kis és nagy felhasználók számára egyaránt, ami egyben alacsony alapköltséget is jelent.
Thanos építészet
Miután felsoroltuk céljainkat az előző részben, dolgozzuk át őket, és nézzük meg, hogyan oldja meg a Thanos ezeket a problémákat.
Globális nézet
Ahhoz, hogy átfogó képet kapjunk a meglévő Prometheus-példányokról, egyetlen kérelem belépési pontot kell kapcsolnunk az összes szerverhez. A Thanos komponens pontosan ezt teszi. . Minden Prometheus-kiszolgáló mellett telepítve van, és proxyként működik, a helyi Prometheus-adatokat a gRPC Store API-n keresztül szolgálja ki, lehetővé téve az idősorok adatainak címkénkénti és időtartományonkénti lekérését.
A másik oldalon található a kibővíthető, állapot nélküli Querier komponens, amely nemigen tesz többet, mint a PromQL lekérdezések megválaszolása a szabványos Prometheus HTTP API-n keresztül. A Querier, a Sidecar és a többi Thanos komponens ezen keresztül kommunikál .
- A Querier kérés fogadása után csatlakozik a megfelelő Store API szerverhez, azaz a mi oldalkocsikhoz, és idősoros adatokat kap a megfelelő Prometheus szerverektől.
- Ezt követően egyesíti a válaszokat, és PromQL-lekérdezést hajt végre rajtuk. A Querier képes egyesíteni mind a szétválasztott adatokat, mind a Prometheus HA szerverekről származó duplikált adatokat.
Ez megoldja a rejtvényünk egy jelentős részét – az elszigetelt Prometheus szerverek adatait egyetlen nézetben egyesíti. Valójában a Thanos csak erre a funkcióra használható. A meglévő Prometheus szervereken nem kell változtatásokat végrehajtani!
Korlátlan eltarthatóság!
Előbb-utóbb azonban a normál Prometheus megőrzési időn túl is szeretnénk adatokat tárolni. A történeti adatok tárolására az objektumtárolást választottuk. Széles körben elérhető bármely felhőben, valamint a helyszíni adatközpontokban, és nagyon költséghatékony. Ezen kívül szinte bármilyen objektumtárhely elérhető a jól ismert S3 API-n keresztül.
A Prometheus körülbelül kétóránként ír adatokat a RAM-ból a lemezre. A tárolt adatblokk meghatározott ideig tartalmazza az összes adatot, és megváltoztathatatlan. Ez nagyon kényelmes, mert a Thanos Sidecar egyszerűen meg tudja nézni a Prometheus adatkönyvtárát, és amint új blokkok válnak elérhetővé, betöltheti azokat az objektumtároló vödrökbe.
Az objektumtárolóba való azonnali betöltés a lemezre írás után szintén lehetővé teszi a kaparó egyszerűségének megőrzését (Prometheus és Thanos Sidecar). Ez leegyszerűsíti a támogatást, a költségeket és a rendszertervezést.
Mint látható, az adatok biztonsági mentése nagyon egyszerű. De mi a helyzet az objektumtárolóban lévő adatok lekérdezésével?
A Thanos Store összetevő proxyként működik az adatok lekéréséhez az objektumtárolóból. A Thanos Sidecarhoz hasonlóan részt vesz a pletykafürtben, és megvalósítja a Store API-t. Így a meglévő Querier oldalkocsiként kezelheti, mint egy újabb idősor-adatforrást – nincs szükség speciális konfigurációra.
Az idősor adatblokkok több nagy fájlból állnak. Igény szerint betölteni őket nem lenne hatékony, helyi gyorsítótárazásuk pedig hatalmas mennyiségű memóriát és lemezterületet igényelne.
Ehelyett a Store Gateway tudja, hogyan kell kezelni a Prometheus tárolási formátumot. Az intelligens lekérdezésütemezőnek és a blokkok csak a szükséges indexrészek gyorsítótárazásának köszönhetően lehetséges az összetett lekérdezések minimális számú HTTP-kérelme csökkentése az objektumtároló fájlokhoz. Ily módon négy-hat nagyságrenddel csökkentheti a kérések számát, és olyan válaszidőket érhet el, amelyeket általában nehéz megkülönböztetni a helyi SSD-n lévő adatokra irányuló kérésektől.
Amint a fenti diagramon látható, a Thanos Querier jelentősen csökkenti az objektumtárolási adatok lekérdezésenkénti költségét a Prometheus tárolási formátum kihasználásával és a kapcsolódó adatok egymás mellé helyezésével. Ezzel a megközelítéssel sok egyedi kérést kombinálhatunk minimális számú tömeges művelettel.
Tömörítés és mintavételezés
Ha egy új idősor-adatblokk sikeresen betöltődik az objektumtárba, azt „történelmi” adatként kezeljük, amely azonnal elérhető a Store Gateway-n keresztül.
Egy idő után azonban egy forrásból származó blokkok (Prometheus oldalkocsival) felhalmozódnak, és már nem használják ki a teljes indexelési potenciált. A probléma megoldására bevezettünk egy másik összetevőt, a Compactor nevet. Egyszerűen alkalmazza a Prometheus helyi tömörítő motorját az objektumtárolás történeti adataira, és egyszerű periodikus kötegelt munkaként futtatható.
A hatékony tömörítésnek köszönhetően a tárhely hosszú távú lekérdezése nem okoz gondot az adatméret tekintetében. Azonban az egymilliárd érték kicsomagolásának és lekérdezőprocesszoron keresztüli futtatásának lehetséges költsége elkerülhetetlenül a lekérdezés végrehajtási idejének drámai növekedését eredményezi. Másrészt, mivel pixelenként több száz adatpont található a képernyőn, lehetetlenné válik az adatok teljes felbontású megjelenítése is. Így a mintavételezés nem csak lehetséges, de nem is vezet észrevehető pontosságvesztéshez.
Az adatok csökkentése érdekében a Compactor folyamatosan összesíti az adatokat öt perc és egy órás felbontással. Minden TSDB XOR tömörítéssel kódolt nyers darabhoz különböző típusú összesített adatok kerülnek tárolásra, például egy blokk min, max vagy összege. Ez lehetővé teszi a Querier számára, hogy automatikusan kiválassza az adott PromQL lekérdezéshez megfelelő összesítést.
Nincs szükség speciális konfigurációra ahhoz, hogy a felhasználó csökkentett pontosságú adatokat használjon. A Querier automatikusan vált a különböző felbontások és nyers adatok között, ahogy a felhasználó nagyít és kicsinyít. Kívánt esetben a felhasználó ezt közvetlenül a kérés „step” paraméterével szabályozhatja.
Mivel egy GB tárolási költsége alacsony, a Thanos alapértelmezés szerint nyers adatokat, ötperces és egyórás felbontású adatokat tárol. Az eredeti adatokat nem kell törölni.
Rögzítési szabályok
A rögzítési szabályok még a Thanos esetében is lényeges részét képezik a megfigyelési veremnek. Csökkentik a lekérdezések bonyolultságát, késleltetését és költségét. Ezenkívül kényelmesek a felhasználók számára, hogy metrikák szerint összesített adatokat kapjanak. A Thanos a vanília Prometheus példányokon alapul, így teljesen elfogadható a rögzítési és riasztási szabályok tárolása egy meglévő Prometheus szerveren. Bizonyos esetekben azonban ez nem elég:
- Globális riasztás és szabály (például riasztás, ha egy szolgáltatás három fürt közül kettőnél nem működik).
- A helyi tárhelyen kívüli adatokra vonatkozó szabály.
- Az a vágy, hogy minden szabályt és figyelmeztetést egy helyen tároljunk.
Mindezen esetekben a Thanos tartalmaz egy különálló komponenst, a Ruler-t, amely a Thanos Queries-en keresztül számítja ki a szabályokat és a riasztásokat. Egy jól ismert StoreAPI biztosításával a lekérdezési csomópont hozzáférhet a frissen kiszámított metrikákhoz. Később ezeket az objektumtárolóban is tárolják, és elérhetővé teszik a Store Gateway-n keresztül.
Thanos ereje
A Thanos elég rugalmas ahhoz, hogy az Ön igényei szerint testreszabható legyen. Ez különösen akkor hasznos, ha a sima Prometheusról vándorol. Röviden összefoglaljuk, mit tanultunk a Thanos összetevőiről egy gyors példán keresztül. A következőképpen viheti be vaníliás Prometheus-ját a „korlátlan metrikatárolás” világába:
- Adja hozzá a Thanos Sidecart a Prometheus szervereihez – például egy oldalkocsis konténer egy Kubernetes podban.
- Telepítsen több Thanos Querier replikát az adatok megtekintéséhez. Ebben a szakaszban könnyen beállítható a pletyka a Scraper és a Querier között. Az összetevők kölcsönhatásának ellenőrzéséhez használja a „thanos_cluster_members” mérőszámot.
Csak ez a két lépés elegendő ahhoz, hogy globális nézetet és zökkenőmentes adatduplikációt biztosítson a potenciális Prometheus HA replikákból! Egyszerűen csatlakoztassa irányítópultjait a Querier HTTP-végponthoz, vagy használja közvetlenül a Thanos felhasználói felületet.
Ha azonban biztonsági mentésre és hosszú távú tárolásra van szüksége a mérőszámokról, további három lépést kell végrehajtania:
- Hozzon létre egy AWS S3 vagy GCS tárolót. Állítsa be a Sidecart, hogy adatokat másoljon ezekbe a tárolókba. A helyi adattárolás most minimalizálható.
- Telepítse a Store Gateway-t, és csatlakoztassa meglévő pletykafürtjéhez. Most már lekérdezheti a mentett adatokat!
- Telepítse a Compactort a lekérdezés hatékonyságának növelésére hosszú időn keresztül tömörítéssel és mintavételezéssel.
Ha többet szeretne megtudni, ne habozzon, tekintse meg oldalunkat и !
Mindössze öt lépésben a Prometheust megbízható megfigyelőrendszerré alakítottuk globális nézettel, korlátlan tárolási idővel és a metrikák potenciálisan magas rendelkezésre állásával.
Húzáskérés: szükségünk van rád!
a kezdetektől nyílt forráskódú projekt volt. A Prometheus-szal való zökkenőmentes integráció és a Thanos egy részének használatának lehetősége kiváló választássá teszi a megfigyelőrendszer zökkenőmentes méretezését.
Mindig szívesen fogadjuk a GitHub Pull kéréseket és problémákat. Addig is forduljon hozzánk bizalommal a Github Issues vagy a Slack oldalonha kérdése vagy visszajelzése van, vagy szeretné megosztani tapasztalatait a használatával! Ha tetszik, amit az Improbable-nél csinálunk, ne habozzon kapcsolatba lépni velünk - !
Forrás: will.com