Thanos - skaleeritav Prometheus

Artikli tõlge on ette valmistatud spetsiaalselt kursuse üliõpilastele «DevOps praktikad ja tööriistad».

Fabian Reinartz — tarkvaraarendaja, Go fänn ja keeruliste probleemide lahendamise entusiast. Ta on ka Prometheuse hooldaja ja Kubernetes SIG instrumentation kaasasutaja. A varem töötas ta production-insenerina SoundCloudis ja juhtis CoreOSis monitooringugruppi. Praegu töötab ta Google'is.

Bartek Plotka — infrastruktuuriinsener Improbables. Huvi uute tehnoloogiate ja jaotatud süsteemide probleemide vastu. Tal on madala taseme programmeerimise kogemus Intelis, on olnud Mesose panustaja ja omab maailmatasemel SRE kogemust Improbables. Tegeleb mikroteenuste maailma täiustamisega. Tema kolm armastust: Golang, avatud lähtekood ja võrkpall.

Vaadates meie lipulaeva toodet SpatialOS, saate aimu, et Improbable vajab suure dünaamilisusega pilve infrastruktuuri, mis on maailmatasemel ja millel on kümneid Kubernetes'e klastreid. Olime ühed esimesed, kes hakkasid kasutama monitooringusüsteemi Prometheus. Prometheus on võimeline jälgima miljoneid mõõdikuid reaalajas ja kaasas on võimas päringukeel, mis võimaldab vajalikku teavet välja tuua.

Prometheuse lihtsus ja usaldusväärsus on üks tema kõige olulisemaid eeliseid. Siiski, teatud skaalal seisame silmitsi mitmete puudustega. Nende probleemide lahendamiseks töötasime välja Thanos — avatud lähtekoodiga projekt, mille loob Improbable, sujuvaks üleminekuks olemasolevatest Prometheuse klastritest ühte monitooringusüsteemi piiramatute ajalooliste andmete salvestamiseks. Thanos on saadaval Githubis siin.

Ole kursis Improbable'i viimaste uudistega.

Meie eesmärgid Thanosega

Teatud skaalal tekivad probleemid, mis ületavad vanilje Prometheuse võimalused. Kuidas salvestada petabaitide ajalugu usaldusväärselt ja tõhusalt? Kas seda saab teha ilma päringu vastuse ajaloo kahjustamata? Kas on võimalik saada juurdepääs kõikidele mõõdikutega, mis asuvad erinevates Prometheuse serverites, ühe API-päringu kaudu? Kas on võimalik kuidagi ühendada replitseeritud andmed, mis on kogutud Prometheuse HA kaudu?

Nende küsimuste lahendamiseks lõime Thanose. Järgmistes lõikudes kirjeldame, kuidas me nendega lähenesime ja selgitame eesmärke, mida me taga ajasime.

Andmete pärimine mitmest Prometheuse eksemplarist (globaalne päring)

Prometheus pakub funktsionaalset lähenemist shardimisele. Isegi üks Prometheuse server tagab piisava skaleeritavuse, et vabastada kasutajad horisontaalse shardimise keerukusest praktiliselt kõikides kasutusvõimalustes.

Kuigi see on suurepärane juurutusmudel, on sageli vajalik ligipääs andmetele erinevates Prometheuse serverites ühe API või kasutajaliidese kaudu — globaalne vaade. Loomulikult on võimalik kuvada mitmeid päringuid ühes Grafana paneelis, kuid iga päringut saab teostada vaid ühe serveri Prometheus suhtes. Teiselt poolt saate Thanos'e abil küsida ja koguda andmeid mitmest Prometheuse serverist, kuna kõik need on kättesaadavad ühe lõpp-punkti kaudu.

Varem, et saada globaalset vaadet Improbable'is, korraldasime oma Prometheuse eksemplarid mitmetasandiliseks Hierarchical Federation. See tähendas ühe metaserveri Prometheus loomist, mis kogub osa metrikatest igast "leht" serverist.

See lähenemine osutus probleemseks. See tõi kaasa konfiguratsiooni keerukuse, potentsiaalselt uue tõrke esindaja lisamise ning keeruliste reeglite rakendamise, et anda liidetud lõpp-punktile ainult vajalikud andmed. Lisaks ei luba selline föderatsioon saada tõelist globaalset vaadet, kuna mitte kõik andmed ei ole kättesaadavad ühe API päringu kaudu.

Sellega on tihedalt seotud andmete ühtne esitamine, mis on kogutud kõrge kättesaadavusega (high-availability, HA) Prometheuse serverites. Prometheuse HA mudel kogub andmeid sõltumatult kaks korda, mis on nii lihtne, et ei saaks olla lihtsam. Siiski oleks palju mugavam kasutada liidetud ja dedupeeritud suurte voogude esitamist.

Muidugi on kõrge kättesaadavuse serverites Prometheus vajadus. Improbable'is võtame andmete minutipõhise jälgimise tõsiselt, kuid üks Prometheuse eksemplar klastris on ainus tõrke koht. Iga konfiguratsiooniviga või riistvararike võivad potentsiaalselt viia oluliste andmete kadumiseni. Isegi lihtne juurutamine võib põhjustada pisikesi tõrkeid metrikate kogumises, kuna taaskäivitamine võib võtta oluliselt kauem kui kraapimise intervall.

Usaldusväärne ajalooliste andmete säilitamine

Odavaru, kiire ja pikaajaline mõõdikute salvestamine on meie unistus (mida jagavad enamik Prometheuse kasutajaid). Improbables olime sunnitud seadistama mõõdikute säilitamise aja üheks päevaks (Prometheus 1.8 jaoks). See seab ilmsed piirangud sellele, kui kaugele me tagasi vaadata saame.

Prometheus 2.0 on selles osas parem, kuna ajasarjade arv ei mõjuta enam serveri üldist jõudlust (vt. KubeConi ettekannet Prometheuse 2-st). Sellegipoolest salvestab Prometheus andmeid kohalikule kettale. Kuigi tõhus andmete kokkusurumine võib märkimisväärselt vähendada kohaliku SSD kasutamist, on lõpuks ikkagi piirang salvestatavate ajalooliste andmete mahule.

Lisaks hoolime Improbables usaldusväärsusest, lihtsusest ja kuludest. Suured kohalikud kettad on keerulisemad hallata ja varundada. Need maksavad rohkem ja vajavad rohkem tööriistu varundamiseks, mis toob kaasa liigset keerukust.

Allapoole proovimine

Kui me hakkasime töötama ajalooliste andmetega, sai selgeks, et on olemas fundamentaalsed raskused O-suurega, mis muudab päringud aina aeglasemaks, kui töötame andmetega nädalate, kuude ja aastate jooksul.

Selle probleemi standardlahenduseks on allapoole proovimine (downsampling) — signaali sageduse vähendamine. Alandades diskreetimist, saame „skaala alandada“ pikema ajavahemiku jaoks ja säilitada endise valimite arvu, mis tagab päringute vastupidavuse.

Ajalooliste andmete allapoole proovimine on igasuguste pikaajaliste salvestuslahenduste vältimatu nõue ja ületab vanilje Prometheuse raames.

Lisaks eesmärgid

Üks projekti Thanos algseid eesmärke oli sujuv integreerimine olemasolevate Prometheuse installatsioonidega. Teine eesmärk oli lihtne haldamine minimaalsete sissepääsupiirangutega. Kõik sõltuvused peavad olema kergesti rahuldatud nii väikeste kui suurte kasutajate jaoks, mis eeldab ka väikeseid algkulusid.

Thanos arhitektuur

Pärast seda, kui oleme eelnevas jaotises loetletud meie eesmärgid, katsetame neid ja vaatame, kuidas Thanos need probleemid lahendab.

Globaalne vaade

Ette saada global view olemasolevate Prometheuse instantside üle, peame siduma ühtse sisenemispunkti kõigi serveritega. Just sellega tegeleb Thanos komponent. Sidecar. See paigaldatakse iga Prometheuse serveri kõrvale ja töötab kui pöördus, teenindades kohalikke Prometheuse andmeid gRPC-API kaudu, mis võimaldab valida järjendi andmeid siltide ja ajavahemiku põhjal.

Teiselt poolt on horisontaalselt skaleeritav komponent Querier, mis ei säilita olekuandmeid ja tegutseb veidi rohkem kui lihtsalt vastab PromQL päringutele standardse Prometheuse HTTP API kaudu. Komponendid Querier, Sidecar ja teised Thanos suhtlevad läbi gossip protokolli..

1. Querier, kui ta saab päringu, ühendub vastava Store API serveriga, st meie Sidecar'iga, ja saadab ajajärgu andmed vastavatelt Prometheuse serveritelt.
2. Pärast seda ühendab ta vastused ja teostab PromQL päringu nende põhjal. Querier võib ühendada nii mittesobivaid andmeid kui ka dubleeritud andmeid HA-Prometheuse serveritest.

See lahendab suure osa meie mõistatustest — andmete ühendamine isoleeritud Prometheuse serveritest ühtsesse vaatesse. Tegelikult võib Thanost kasutada ainult selle võimaluse tõttu. Olemasolevatesse Prometheuse serveritesse ei pea tegema mingeid muudatusi!

Piiramatu säilitusaeg!

Kuid varem või hiljem tahame säilitada andmeid, mis ületavad tavalise Prometheuse säilituse aega. Ajalooliste andmete säilitamiseks valisime objektse salvestuse. See on laialdaselt saadaval igas pilves ning ka kohalikus andmekeskustes ja on väga ökonoomne. Lisaks on praktiliselt iga objektne salvestus saadaval läbi hästi tuntud S3 API.

Prometheus salvestab andmeid mälust kettale umbes iga kahe tunni järel. Salvestatava andmete plokk sisaldab kõiki andmeid kindlaksmääratud ajavahemiku jooksul ja on muutumatud. See on väga mugav, kuna Thanos Sidecar saab lihtsalt vaadata Prometheuse andme katalooge ja uute plokkide ilmumisel laadida need objektse salvestuse anumatesse.

Laadimine objektse salvestusse kohe pärast ketasessimist hoiab ka “scraperi” (Prometheus ja Thanos Sidecar) lihtsana. Mis lihtsustab süsteemi hooldust, kulusid ja kujundust.

Nagu näete, toimub andmete varundamine väga lihtsalt. Kuid mis saab andmete päringust objektihoidlas?

Thanos Store komponent toimib vaheproses andmete saamiseks objektihoidlast. Nagu Thanos Sidecar, osaleb see gossip-klusteris ja rakendab Store API-d. Seega võivad olemasolevad Querierid seda käsitleda kui Sidecar'i, kui veel ühte ajasari andmete allikat – spetsiaalset seadistamist ei ole vaja.

Aja seeria andmeplokid koosnevad mitmest suurest failist. Nende nõudmisel allalaadimine oleks üsna ebaefektiivne ja kohalik vahemälu vajaks tohutult mälu ja kettaruumi.

Selle asemel teab Store Gateway, kuidas käsitleda Promethee hoidmisvormingut. Tänu nutikale päringu planeerijale ja ainult vajalike indeksiosade plokkide vahemällu salvestamisele on võimalik keerulisi päringuid vähendada minimaalsete HTTP-päringute arvu objektihoidla failidele. Niisiis, saame vähendada päringute arvu neli kuni kuus korda ja saavutada reageerimisaega, mida on üldiselt raske eristada kohalike SSD-de andmete päringutest.

Nagu on näidatud ülaltoodud diagrammil, vähendab Thanos Querier objektihoidlas andmete päringute kulu oluliselt, kasutades Promethee hoidmisvormingut ja paigutades seotud andmed lähedale. Kasutades seda lähenemist, saame koondada palju üksikpäringute minimaalsete hulgi-operatsioonideni.

Kompaktsioon ja allasampleerimine

Pärast seda, kui uus aja seeria andmeplokk on edukalt üles laaditud objektihoidlasse, käsitleme seda kui "ajaloolisi" andmeid, mis on kohe kergesti kättevõetavad Store Gateway kaudu.

Kuid mõne aja pärast koguneb sama allika (Prometheus koos Sidecar'iga) plokke ja nad ei kasuta enam kogu indekseerimise potentsiaali. Selle probleemi lahendamiseks tutvustasime veel ühte komponenti nimega Compactor. See rakendab lihtsalt kohalikke Promethee kompaktsiooni mehhanisme ajalooliste andmete objektihoidlas ja seda saab käivitada nagu lihtsat perioodilist paketitööd.

Tänu efektiivsele kokkusurumisele ei tekita andmehoidla päring suures andmemahus probleeme. Siiski võib miljoni väärtuse väljapakkimise ja nende töötlusse suunamise hind viia päringuaegade järsu suurenemiseni. Teisest küljest, kuna iga ekraani pikseli kohta on sadu andmepunkte, ei ole isegi kogu määratlemine andmete visuaaliseerimine enam võimalik. Seega ei ole allahindlus mitte ainult võimalik, vaid see ei too kaasa märkimisväärset täpsuse kaotust.

Andmete allahindlemiseks kogub Compactor pidevalt andmeid viie minuti ja ühe tunni resolutsiooniga. Iga toorandmefragment, mis on kodeeritud TSDB XOR-kompressiooniga, salvestab erinevat tüüpi kogumande, nagu min, max või sum ühe bloki kohta. See võimaldab Querieril automaatselt valida selle PromQL-päringu jaoks sobiva kogumi.

Kasutajalt ei ole andmete madalama täpsuse kasutamiseks vajalik mingeid erilisi seadistusi. Querier vahetab automaatselt eri resolutsioonide ja toorandmete vahel kasutaja suumimise ja kärpimise korral. Soovi korral saab kasutaja seda kasutada otse päringu 'step' parameeter kaudu.

Kuna ühe GB salvestamise kulud on väikesed, salvestab Thanos vaikimisi toorandmed, andmed viie minuti ja ühe tunni resolutsiooniga. Toorandmete kustutamine ei ole vajalik.

Salvestamise reeglid

Isegi Thanosel on salvestamise reeglid olulised osad jälgimise virnast. Need vähendavad päringute keerukust, viivitust ja kulusid. Need on ka kasutajatele mugavad, et saada kokkuvõtteid meetmete kohta. Thanos põhineb puhaste Prometheuse instantsidel, seega on võimalik salvestada salvestamise reegleid ja häire reegleid olemasoleval Prometheuse serveril. Siiski võib mõnel juhul sellest jääda väheks:

• Globaalne häire ja reegel (näiteks teavitamine, kui teenus ei tööta enam kui kahel kolmest klastrist).
• Reegel andmete kohta, mis ei ole kohalikus ladustamises.
• Soov hoida kõik reeglid ja häired ühes kohas.

Käesolevate olukordade jaoks sisaldab Thanos eraldi komponenti nimega Ruler, mis arvutab rule ja alert Thanos Queries abil. Andes hästi tuntud StoreAPI, saavad Query-sõlmed juurdepääsu värskelt arvutatud mõõdikutele. Hiljem salvestatakse need ka objektide salvestusse ja need on kergesti kättesaadavad Store Gateway kaudu.

Thanos jõud

Thanos on piisavalt paindlik, et seda saaks kohandada vastavalt teie nõudmistele. See on eriti kasulik, kui migreerida lihtsast Prometheusest. Korraks meenutame väikese näite abil, mida oleme Thanos komponentide kohta õppinud. Nii saate oma tavalise Prometheuse viia "piiramatu mõõdiku salvestamise" maailma:

1. Lisage Thanos Sidecar oma Prometheuse serveritele — näiteks naaber konteiner Kubernetes podis.
2. Käitage mitmeid Thanos Querier koopiaid, et andmeid vaadata. Sel hetkel on lihtne seadistada gossip Scraperi ja Querier vahel. Komponentide omavahelise suhtluse kontrollimiseks kasutage mõõdikut 'thanos_cluster_members'.

Nendest kahest sammust piisab, et tagada globaalne ülevaade ja sujuv andmete dedupe potentsiaalsetest HA-replikatest Prometheuses! Lihtsalt ühendage oma armatuurlaud HTTP Querier lõpp-punktiga või kasutage Thanos UI otse.

Kui aga vajate mõõdikute varundamist ja pikaajalist salvestamist, peate täitma veel kolm sammu:

1. Looge AWS S3 või GCS konteiner. Seadistage Sidecar, et kopeerida andmeid nendesse konteineritesse. Nüüd saate minimeerida kohalikku andmete salvestamist.
2. Käitage Store Gateway ja ühendage see olemasoleva gossip-klastriga. Nüüd saab andmevarunduse järele päringute tegemiseks saata!
3. Käitage Compactor, et suurendada päringute efektiivsust pikaajaliste ajavahemike jooksul, kasutades tihendamist ja allasamaltingut.

Kui soovite rohkem teada saada, tutvuge meiega. kubernetes manifesteeri näidised ja alustamiseks!

Kõigest viie sammuga muutisime Prometheuse usaldusväärseks jälgimissüsteemiks globaalsete vaatamisvõimalustega, piiramatute salvestusajaga ja potentsiaalselt kõrgema saadavuse mõõdikute osas.

Pull request: te olete meile vajalik!

Thanos oli algusest peale avatud lähtekoodiga projekt. Sujuv integratsioon Prometheusega ja võimalus kasutada ainult osa Thanost teeb sellest suurepärase valiku jälgimissüsteemi skaleerimiseks ilma liigsete pingutusteta.

Me oleme alati rõõmsad GitHubi Pull Requestide ja Issueside üle. Samuti ärge kartke meiega ühendust võtta läbi Github Issues või slacki. Improbable-eng #thanos, kui teil on küsimusi või tagasisidet, või soovite jagada oma kogemusi! Kui teile meeldib, mida me Improbable'is teeme, ärge kartke meiega ühendust võtta — meil on alati avatud ametikohti!

Tutvu kursusega lähemalt.

Allikas: habr.com