🥇Thanos — skaleeritav Prometheus

Artikli tõlge on ette valmistatud spetsiaalselt kursuse üliõpilastele „DevOps praktikas ja tööriistades“.

Fabian Reinartz — tarkvaraarendaja, Go fänn ja keeruliste probleemide lahendamise entusiast. Samuti on ta Prometheuse hooldaja ja Kubernetes SIG instrumentation kaasasüttija. Varem töötas ta SoundCloudis tootmisinsenerina ja juhtis CoreOSis jälgimisrühma. Praegu töötab ta Google'is.

Bartek Plotka — infrastruktuuriinsener Improbable'is. Uurib uusi tehnoloogiaid ja jaotatud süsteemide väljakutseid. Tal on madala taseme programmeerimise kogemus Intelis, Mesos'e kaastöötaja kogemus ja maailmanägline SRE tootmispraktika Improbable'is. Tõukab edasi mikroteenuste maailma. Tema kolm armastust: Golang, avatud lähtekood ja võrkpall.

Vaadates meie lipulaeva toodet SpatialOS, saate hinnata, et Improbable vajab kõrgdünaamilist globaalset pilvetehnoloogiat, millel on kümneid Kubernetes'e klastreid. Me olime üks esimesi, kes hakkas kasutama jälgimissüsteemi Prometheus. Prometheus suudab reaalajas jälgida miljoneid mõõdikuid ja sisaldab võimsat päringu keelt, mis võimaldab vajalikku teavet välja tõmmata.

Prometheuse kasutamise lihtsus ja usaldusväärsus on selle peamised eelised. Ent teatud suurusele jõudes oleme pidanud silmitsi seisma mitmete puudustega. Nende probleemide lahendamiseks oleme välja töötanud Thanos — avatud lähtekoodiga projekti, mille on loonud Improbable, et muuta olemasolevad Prometheuse klastrid sujuvaks ühtseks jälgimissüsteemiks, millel on piiramatu ajalooliste andmete salvestus. Thanos on saadaval Githubis siit.

Olge kursis Improbable'i viimaste uudistega.

Meie eesmärgid Thanosiga

Teatud suurusel tekivad probleemid, mis ületavad vanilli Prometheuse võimalusi. Kuidas usaldusväärselt ja ökonoomselt salvestada petabaitide jagu ajaloolisi andmeid? Kas seda saab teha ilma päringu vastuse aega kahjustamata? Kas saame pääseda kõigile erinevatel Prometheuse serveritel asuvatele mõõdikutel ühe API-päringu kaudu? Kas on võimalik säilitada replitseeritud andmeid, kogutud Prometheuse HA abil?

Nende küsimuste lahendamiseks oleme loonud Thanos. Järgmistes osades kirjeldame, kuidas me nendele küsimustele lähenesime ja selgitame eesmärke, mida soovisime saavutada.

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

Prometheus pakub funktsionaalset lähenemist sharding'ule. Isegi üks Prometheuse server tagab piisava skaleeritavuse, et vabastada kasutajad praktiliselt kõigi kasutusjuhtumite horisontaalse sharding'i keerukustest.

Kuigi see on suurepärane juurutusmudel, on sageli vajalik ligipääs andmetele erinevates Prometheuse serverites läbi ühe API või kasutajaliidese — globaalne vaade. Muidugi on võimalik kuvada mitut päringut ühes Grafana paneelis, kuid iga päringut saab teostada ainult ühes Prometheuse serveris. Teisest küljest võimaldab Thanos pärida ja agregatsiooni andmeid mitmest Prometheuse serverist, kuna kõik need on saadaval ühe lõpp-punkti kaudu.

Varem, et saada globaalset vaadet Improbables, korraldasime oma Prometheuse eksemplarid mitme tasandi Hierarchical Federation. See tähendas ühe meta-serveri Prometheuse loomist, mis kogub osa meetrikaid igalt 'lehe'de' serverilt.

See lähenemine osutus probleemseks. See tõi kaasa konfiguratsiooni keerukuse, lisas täiendava võimaliku rikete punkti ja rakendas keerulisi reegleid, et anda föderaalsete lõpp-punktide kaudu ainult vajalikud andmed. Lisaks ei võimalda selline föderatsioon saada tõelist globaalset ülevaadet, kuna kõik andmed ei ole kergesti kättesaadavad ühe API-päringu kaudu.

Sellega seostatakse tihedalt andmete ühtne esitus, mis on kogutud kõrge saadavusega (high-availability, HA) Prometheuse serverites. HA-mudel kogub Prometheuse andmeid iseseisvalt kaks korda, mis on nii lihtne, et pole lihtsalt võimalik lihtsamat. Siiski oleks palju mugavam kasutada ühendavat ja dubleeritud esitusviisi mõlema voogude jaoks.

Muidugi on Prometheuse kõrgelt kergendatud serverites selline vajadus. Improbable'is suhtume tõsiselt andmete iga minutise jälgimise vajadusse, kuid ühe Prometheuse koha olemasolu klastris on ainus rikkevoht. Ükski konfiguratsiooniviga või riistvara rike ei saa potentsiaalselt kaotada olulisi andmeid. Isegi lihtne juurutamine võib põhjustada lühikesi vigu mõõtmete kogumises, kuna käivitamine võib võtta tunduvalt kauem kui kraapimise intervall.

Usaldusväärne ajalooliste andmete salvestamine

Odav, kiire ja pikaajaline mõõtmete salvestamine on meie unistus (mida jagab enamik Prometheuse kasutajaid). Improbable'is pidime määrama mõõtmete säilivusaja üheks päevaks (Prometheus 1.8 puhul). See seab ilmsed piirangud sellele, kui kaugele me saame tagasi vaadata.

Prometheus 2.0 on selles osas parem, kuna ajaseeriad ei mõjuta enam serveri üldist tulemuslikkust (vt KubeConi peaesinejat Prometheuse 2 kohta). Kuid Prometheus salvestab andmed kohalikule kettale. Kuigi andmete tõhus kokkupressimine võib märgatavalt vähendada kohalikku SSD kasutust, on lõpuks siiski piirang säilitatavate ajalooliste andmete mahule.

Lisaks hoolitseme Improbables usaldusväärsuse, lihtsuse ja kulude pärast. Suured kohalikud kettad on keerukamad haldamise ja varundamise osas. Need on kallimad ja vajavad rohkem varundamisvahendeid, mis toob kaasa liigset keerukust.

Alampõhjaline vähendamine

Kui me hakkasime töötama ajalooliste andmetega, saime aru, et O-suure mahtudega on põhilisi keerukusi, mis muudavad päringud järjest aeglasemaks, kui töötame nädalate, kuude ja aastate andmetega.

Selle probleemi standardlahendus on alampõhjaline vähendamine (downsampling) — signaali proovivõtusageduse vähendamine. Proovivõtusageduse vähendamise kaudu saame “suuruse vähendada” pikema ajavahemiku jooksul ja säilitada endise valimi arvu, mis võimaldab päringute vastupidavust pidada.

Vana andmete allasammumine on igasuguste pikaajalise salvestuse lahenduste vältimatu nõue ja see ületab tavalise Prometheuse piire.

Täiendavad eesmärgid

Üks Thanos projekti algseid eesmärke oli sujuv integreerimine olemasolevate Prometheuse installeerimistega. Teine eesmärk oli lihtne kasutamine vähese sissepääsupiiranguga. Kõik sõltuvused peaksid olema kergesti rahuldavad nii väikeste kui ka suurte kasutajate jaoks, mis eeldab samuti väikest alghinda.

Thanos arhitektuur

Pärast meie eesmärkide loetlemist eelmises jaotises, töötame koos nende nimel ja vaatame, kuidas Thanos neid probleeme lahendab.

Globaalne vaade

Globaalsete vaadete saamiseks olemasolevate Prometheuse eksemplaride peal, peame ühendama ühtse päringute sisenemispunkti kõigi serveritega. Just sellega tegeleb Thanos komponent. Sidecar. See paigaldatakse igasuguste Prometheuse serverite kõrvale ja töötab nagu vahendaja, teenindades kohalikke Prometheuse andmeid gRPC-API Store abil, mis võimaldab valida ajaserveri andmeid siltide ja ajavahemiku järgi.

Teiselt poolt on horisontaalselt skaleeritav Querier, millel ei ole olekukuud, mis teeb veidi rohkem kui lihtsalt vastab PromQL päringutele standardse Prometheuse HTTP API kaudu. Querier, Sidecar ja muud Thanos komponendid suhtlevad gossip protokolli kaudu..

Querier, kui ta saab päringu, ühendub vastava serveriga Store API, milleks on meie Sidecar'id, ja saab ajajoonte andmed vastavatelt Prometheuse serveritelt.
Seejärel liidab ta vastused ja täidab nende põhjal PromQL päringu. Querier suudab liita nii mitteühtivad kui ka dubleeritud andmed HA Prometheuse serveritest.

See lahendab suure osa meie mõistatust — andmete liitmine isoleeritud Prometheuse serveritest ühtseks vaateks. Tegelikult saab Thanoset kasutada ainult selle võimaluse tõttu. Olemasolevatele Prometheuse serveritele ei ole vaja mingeid muudatusi teha!

Piiramatu säilitusaeg!

Siiski, varem või hiljem soovime säilitada andmeid, mis ületavad Prometheuse tavalise säilivusaja. Ajalooliste andmete säilitamiseks oleme valinud objektide salvestamise. See on laialdaselt saadaval igas pilves, samuti kohalikes andmekeskustes, ja on väga ökonoomne. Lisaks on praktiliselt iga objektide salvestamine kergesti ligipääsetav hästi tuntud S3 API kaudu.

Prometheus salvestab andmed operatiivmäluvabad diskile umbes iga kahe tunni tagant. Salvestatud andmeblokid sisaldavad kõiki andmeid fikseeritud ajavahemiku jooksul ning on muutmatud. See on väga mugav, kuna Thanos Sidecar saab lihtsalt vaadata Prometheuse andme katalooge ja, uute blokkside ilmumise korral, laadida need objektide salvestamise ämbritesse.

Andmete laadimine objektide salvestamisse otse pärast salvestamist diskile võimaldab samuti säilitada “kraapijate” (Prometheus ja Thanos Sidecar) lihtsuse. See lihtsustab süsteemi hooldust, kulusid ja disaini.

Nagu näete, on andmete varundamine väga lihtne. Aga mis saab objektide salvestamisel andmete päringutest?

Thanos Store komponent toimib vahendajana objektide salvestusruumist andmete hankimiseks. Nagu Thanos Sidecar, osaleb ta gossip-klassis ja rakendab Store API. Seega, olemasolevad Querier'id saavad seda käsitleda kui Sidecar'i, veel ühe allikana ajaseeriate andmete jaoks — mingeid spetsiaalseid seadistusi ei nõuta.

Ajaseeriate andmeplokid koosnevad mitmest suurest failist. Nende nõudmisel laadimine oleks üsna ebaefektiivne ning lokaalne vahemälu nõuaks tohutult mälu ja kettaruumi.

Selle asemel teab Store Gateway, kuidas töötada Prometheuse salvestusformaadi või vorminguga. Tänu täiustatud päringute planeerijale ja ainult vajalike indeksiosade vahemälule on keerukate päringute lihtsustamine vähendatud minimaalsete HTTP-päringuteni objektide salvestusruumifailidele. Seega saab küsida neli kuni kuus korda vähem ja saavutada vastusaeg, mida on üldiselt raske eristada lokaalsest SSD-l olevate andmete päringutest.

Nagu diagrammil eespool näidatud, vähendab Thanos Querier andmehõive objektihoidlas ühe päringu kulusid oluliselt, kasutades Prometheuse salvestusvormingut ja paigutades seotud andmed lähedale. Selle lähenemisviisi kasutamine võimaldab meil kombineerida mitmeid üksikpäringuid minimaalsete hulgitöötluste hulka.

Kompaktimine ja allasampeldamine

Pärast seda, kui uus ajaserieandmete plokk on edukalt üles laaditud objektihoidlasse, käsitleme seda kui 'ajaloolisi' andmeid, mis saavad kohe Store Gateway'i kaudu kätte.

Kuid mõne aja pärast kogunevad ühelt allikalt (Prometheus Sidecariga) plokid ja ei kasuta enam kogu indekseerimise potentsiaali. Selle probleemi lahendamiseks tutvustasime veel üht komponenti nimega Compactor. See rakendab kohaliku Prometheuse kompaktimise mehhanismi ajaloolistele andmetele objektihoidlas ning seda saab käivitada lihtsalt perioodilise hulgitöötlusülesandena.

Tõhusate kokkusurumiste tõttu ei tekita pikaajaline päring salvestusse andmete suuruse osas probleeme. Siiski toob miljardi väärtuse dekompressioon ja nende läbi päringutöötleja ajamine paratamatult kaasa päringu täitmise aja järsu suurenemise. Teisest küljest, kuna iga ekraani pikslile on sada andmepunkti, on andmete täielikus eraldusvõimes visualiseerimine peaaegu võimatu. Seega ei ole allasammutus mitte ainult võimalik, vaid ei too kaasa märkimisväärset täpsuse kadu.

Andmete allasammutamiseks kogub Compactor pidevalt andmeid, mille eraldusvõime on viis minutit ja üks tund. Iga toorfragment, mis on kodeeritud kasutades TSDB XOR-kokku tihendamist, sisaldab erinevaid tüüpe kogutud andmeid, nagu min, max või sum ühe ploki kohta. See võimaldab Querier'il automaatselt valida aggregeeritud väärtuse, mis sobib antud PromQL päringuks.

Andmete kasutamiseks madala täpsusega ei nõua kasutajalt mingit erilist konfigureerimist. Querier lülitub automaatselt erinevate resolutsioonide ja töötlemata andmete vahel, kui kasutaja suurendab või vähendab skaalat. Vajadusel saab kasutaja seda otse hallata päringus oleva „step“ parameetri kaudu.

Kuna ühe GB salvestamise hind on väike, siis Thanos salvestab vaikimisi algandmed, viie minuti ja ühe tunni resolutsiooniga andmed. Algandmete kustutamine ei ole vajalik.

Salvestamise reeglid

Isegi Thanos'e puhul on salvestamise reeglid olulised osad jälgimise killust. Need vähendavad päringute keerukust, latentsust ja kulusid. Need on ka kasutajatele mugavad, et saada kogutud andmeid metrite kohta. Thanos põhineb vanilje Prometheuse eksemplaridel, seega on täiesti sobiv salvestada salvestamise reegleid ja häire reegleid olemasolevas Prometheuse serveris. Siiski võib mõnel juhul sellest olla liiga vähe:

Globaalne häire ja reegel (näiteks teavitamine, kui teenus ei tööta rohkem kui kahe kolmest klastrist).
Reegel andmete jaoks, mis asub väljaspool lokaalset salvestust.
Soov hoida kõik reeglid ja häired ühes kohas.

Kuna Thanos sisaldab eraldi komponenti nimega Ruler, mis arvutab reegleid ja häireid Thanos Queries kaudu, on see kõikidele neile juhtudele ideaalne lahendus. Pakudes hästi tuntud StoreAPI-d, saab Query node juurde pääseda värskelt arvutatud mõõdikutele. Hiljem salvestatakse need objektide salvestusse ja need on saadaval Store Gateway kaudu.

Thanose jõud

Thanos on piisavalt paindlik, et seda saaks kohandada vastavalt teie nõuetele. See on eriti kasulik, kui migreerite lihtsast Prometheusest. Vaatame kiiresti, mida me learnti Thanose komponentide kohta. Siin on, kuidas viia teie tavaline Prometheus piiramatute mõõdikute salvestamise maailma:

Lisage Thanose Sidecar oma Prometheuse serveritele — näiteks külgnev konteiner Kubernetes podis.
Käivitage mitu Thanose Querier'i koopiat andmete vaatamiseks. Sellisel etapil on lihtne seadistada gossip Scraperi ja Querier'i vahel. Komponentide vahekorra kontrollimiseks kasutage mõõdikut ‘thanos_cluster_members’.

Need only these two steps to ensure a global view and seamless data deduplication from potential HA replicas of Prometheus! Simply connect your dashboards to the HTTP Querier endpoint or use the Thanos UI directly.

However, if you require metrics backup and long-term storage, you'll need to complete three additional steps:

Create an AWS S3 or GCS bucket. Set up the Sidecar to copy data to these buckets. You can now minimize local data storage.
Deploy the Store Gateway and connect it to the existing gossip cluster. You can now query the data in backups!
Deploy the Compactor to improve query efficiency for long time intervals using compaction and downsampling.

If you want to know more, feel free to check out our kubernetes manifest examples ja getting started!

In just five steps, we transformed Prometheus into a reliable monitoring system with a global view, unlimited storage time, and potential high availability of metrics.

Pull request: we need you!

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

Meie ootame alati GitHubi Pull Requeste ja Issues. Samuti ärge kartke meie poole pöörduda GitHubi Issues või slacki kaudu Improbable-eng #thanos, kui teil on küsimusi või tagasisidet, või soovite jagada oma kogemusi! Kui teile meeldib, mida me Improbables teeme, ärge kartke meiega ühendust võtta — meil on alati vabanevaid töökohti!

Uuri kursuse kohta lähemalt.

Allikas: habr.com