Artikli tõlge koostati spetsiaalselt kursuse üliõpilastele .
on tarkvaraarendaja, fanaatik ja probleemide lahendaja. Ta on ka Prometheuse hooldaja ja Kubernetes SIG instrumentatsiooni kaasasutaja. Varem oli ta SoundCloudi tootmisinsener ja juhtis CoreOS-i seiremeeskonda. Hetkel töötab Google'is.
- Infrastruktuuriinsener ettevõttes Improbable. Teda huvitavad uued tehnoloogiad ja hajutatud süsteemide probleemid. Tal on madal programmeerimiskogemus Intelis, kaasautori kogemus Mesoses ja maailmatasemel SRE tootmise kogemus ettevõttes Improbable. Pühendatud mikroteenuste maailma täiustamisele. Tema kolm armastust: Golang, avatud lähtekoodiga võrkpall.
Vaadates meie lipulaeva SpatialOS-i, võite arvata, et Improbable nõuab väga dünaamilist globaalset pilveinfrastruktuuri koos kümnete Kubernetese klastritega. Olime ühed esimestest, kes hakkasid jälgimissüsteemi kasutama . Prometheus suudab reaalajas jälgida miljoneid mõõdikuid ja sellel on võimas päringukeel, mis võimaldab teil vajaliku teabe hankida.
Prometheuse lihtsus ja töökindlus on üks selle peamisi eeliseid. Kui aga teatud skaala ületasime, avastasime mitmeid puudusi. Nende probleemide lahendamiseks oleme välja töötanud on avatud lähtekoodiga projekt, mille on loonud firma Improbable, et muuta olemasolevad Prometheuse klastrid sujuvalt üheks seiresüsteemiks, millel on piiramatu ajalooliste andmete salvestusruum. Thanos on saadaval Githubis .
Meie eesmärgid Thanosega
Teatud skaalal tekivad probleemid, mis ületavad vanilje Prometheuse võimalusi. Kuidas usaldusväärselt ja säästlikult salvestada petabaite ajaloolisi andmeid? Kas seda saab teha reageerimisaega kahjustamata? Kas ühe API päringuga on võimalik pääseda juurde kõikidele erinevates Prometheuse serverites asuvatele mõõdikutele? Kas Prometheus HA abil kogutud kopeeritud andmeid on võimalik kuidagi kombineerida?
Nende probleemide lahendamiseks lõime Thanose. Järgmistes jaotistes kirjeldatakse, kuidas me nendele probleemidele lähenesime, ja selgitatakse meie eesmärke.
Andmete päring mitmest Prometheuse eksemplarist (ülemaailmne päring)
Prometheus pakub funktsionaalset lähenemist killustamisele. Isegi üks Prometheuse server pakub piisavalt mastaapsust, et vabastada kasutajad horisontaalse jaotamise keerukusest peaaegu kõigil kasutusjuhtudel.
Kuigi see on suurepärane juurutusmudel, on sageli vaja pääseda juurde Prometheuse erinevate serverite andmetele ühe API või kasutajaliidese kaudu – globaalse vaate kaudu. Loomulikult on ühel Grafana paneelil võimalik kuvada mitut päringut, kuid iga päringut saab täita ainult ühes Prometheuse serveris. Teisest küljest saate Thanose abil päringuid teha ja andmeid koondada mitmelt Prometheuse serverilt, kuna need kõik on juurdepääsetavad ühest lõpp-punktist.
Varem korraldasime rakenduses Improbable globaalse ülevaate saamiseks oma Prometheuse eksemplarid mitmetasandiliseks . See tähendas ühe Prometheuse metaserveri loomist, mis kogub igast leheserverist osa mõõdikuid.
See lähenemine osutus problemaatiliseks. Selle tulemuseks on keerulisemad konfiguratsioonid, täiendava võimaliku tõrkepunkti lisamine ja keerukate reeglite rakendamine tagamaks, et ühendatud lõpp-punkt saab ainult vajalikke andmeid. Lisaks ei võimalda selline liit saada tõelist globaalset vaadet, kuna kõik andmed pole ühest API päringust saadaval.
Sellega on tihedalt seotud ühtne vaade kõrge kättesaadavusega (HA) Prometheuse serverites kogutud andmetele. Prometheuse HA mudel kogub iseseisvalt andmeid kaks korda, mis on nii lihtne, et see ei saaks olla lihtsam. Kuid mõlema voo kombineeritud ja dubleeritud vaate kasutamine oleks palju mugavam.
Loomulikult on vaja väga kättesaadavaid Prometheuse servereid. Ettevõttes Improbable võtame minut-minutite andmete jälgimise väga tõsiselt, kuid ühe Prometheuse eksemplari olemasolu klastri kohta on üks tõrkepunkt. Mis tahes konfiguratsiooniviga või riistvaratõrge võib põhjustada oluliste andmete kadumise. Isegi lihtne juurutamine võib põhjustada mõõdikute kogumisel väiksemaid häireid, kuna taaskäivitused võivad olla märkimisväärselt pikemad kui kraapimise intervall.
Ajalooliste andmete usaldusväärne säilitamine
Odav, kiire ja pikaajaline mõõdikute salvestamine on meie unistus (jagab enamik Prometheuse kasutajaid). Improbable puhul olime sunnitud konfigureerima mõõdikute säilitusperioodiks üheksa päeva (Prometheus 1.8 jaoks). See lisab ilmselged piirid sellele, kui kaugele tahame vaadata.
Prometheus 2.0 on selles osas paranenud, kuna aegridade arv ei mõjuta enam serveri üldist jõudlust (vt. ). Prometheus salvestab andmed aga kohalikule kettale. Kuigi tõhus andmete tihendamine võib oluliselt vähendada kohaliku SSD kasutust, on salvestatavate ajalooliste andmete hulk siiski piiratud.
Lisaks hoolime ettevõttes Improbable töökindlusest, lihtsusest ja kuludest. Suuri kohalikke kettaid on keerulisem kasutada ja varundada. Need maksavad rohkem ja nõuavad rohkem varundustööriistu, mille tulemuseks on tarbetu keerukus.
Alladiskreetmine
Kui hakkasime ajalooliste andmetega töötama, mõistsime, et big-O-ga on põhimõttelisi probleeme, mis muudavad päringute tegemise aeglasemaks, kuna töötame nädalate, kuude ja aastate andmetega.
Selle probleemi standardlahendus oleks (downsampling) - signaali diskreetimissageduse vähendamine. Allaproovimise abil saame „mahandada“ suurema ajavahemikuni ja säilitada sama arvu valimeid, hoides päringud reageerivatena.
Vanade andmete allaproovimine on mis tahes pikaajalise salvestuslahenduse vältimatu nõue ja see ei kuulu vanilje Prometheuse rakendusalasse.
Lisaeesmärgid
Üks Thanose projekti algsetest eesmärkidest oli sujuvalt integreerida olemasolevate Prometheuse installatsioonidega. Teine eesmärk oli toimimise lihtsus minimaalsete sisenemistõketega. Kõik sõltuvused peaksid olema hõlpsasti rahuldatavad nii väikestele kui ka suurtele kasutajatele, mis tähendab ka madalat baaskulu.
Thanose arhitektuur
Pärast meie eesmärkide loetlemist eelmises jaotises töötame need läbi ja vaatame, kuidas Thanos need probleemid lahendab.
Globaalne vaade
Olemasolevate Prometheuse eksemplaride üldise ülevaate saamiseks peame linkima ühe päringu sisenemispunkti kõigi serveritega. Täpselt seda teeb Thanose komponent. . See on juurutatud iga Prometheuse serveri kõrval ja toimib puhverserverina, teenindades kohalikke Prometheuse andmeid gRPC Store API kaudu, võimaldades aegridade andmete hankimist sildi ja ajavahemiku järgi.
Teisel pool on laiendatav olekuta päringukomponent, mis ei tee midagi enamat kui lihtsalt vastab PromQL-i päringutele standardse Prometheuse HTTP API kaudu. Querier, Sidecar ja muud Thanose komponendid suhtlevad .
- Päringu saamisel loob Querier ühenduse vastava Store API serveriga ehk meie külgkorvidega ja saab vastavatelt Prometheuse serveritelt aegridade andmeid.
- Pärast seda ühendab see vastused ja käivitab nende kohta PromQL-päringu. Querier saab ühendada nii Prometheus HA serveritest eraldatud andmeid kui ka dubleeritud andmeid.
See lahendab meie mõistatuse suure osa – eraldatud Prometheuse serverite andmete ühendamine üheks vaateks. Tegelikult saab Thanost kasutada ainult selle funktsiooni jaoks. Olemasolevates Prometheuse serverites pole vaja muudatusi teha!
Piiramatu säilivusaeg!
Siiski tahame varem või hiljem salvestada andmeid kauemaks kui Prometheuse tavapärane säilitusaeg. Ajalooliste andmete salvestamiseks valisime objektide salvestusruumi. See on laialdaselt saadaval nii pilves kui ka kohapealsetes andmekeskustes ning on väga kuluefektiivne. Lisaks on tuntud S3 API kaudu saadaval peaaegu kõik objektide salvestusruumid.
Prometheus kirjutab andmed RAM-ist kettale ligikaudu iga kahe tunni järel. Salvestatud andmeplokk sisaldab kõiki andmeid kindla aja jooksul ja on muutumatu. See on väga mugav, kuna Thanos Sidecar saab lihtsalt vaadata Prometheuse andmekataloogi ja uute plokkide ilmumisel laadida need objektide salvestusämbritesse.
Kohe pärast kettale kirjutamist objektimälu laadimine võimaldab säilitada ka kaabitsa lihtsuse (Prometheus ja Thanos Sidecar). Mis lihtsustab tuge, kulusid ja süsteemi disaini.
Nagu näete, on andmete varundamine väga lihtne. Aga kuidas on lood objektimälus olevate andmete päringutega?
Thanos Store'i komponent toimib puhverserverina andmete toomiseks objektide mälust. Nagu Thanos Sidecar, osaleb see kuulujuttude klastris ja rakendab Store API-t. Nii saab olemasolev päring seda käsitleda nagu külgkorvi, kui teist aegridade andmete allikat – erikonfiguratsiooni pole vaja.
Aegridade andmeplokid koosnevad mitmest suurest failist. Nende nõudmisel laadimine oleks üsna ebaefektiivne ja nende lokaalne vahemällu salvestamine nõuaks tohutult mälu- ja kettaruumi.
Selle asemel teab Store Gateway, kuidas Prometheuse salvestusvormingut käsitleda. Tänu nutikale päringuplaneerijale ja ainult vajalike plokkide indeksiosade vahemällu salvestamisele on võimalik vähendada keerulisi päringuid minimaalse HTTP-päringute arvuni objektide salvestusfailidele. Sel viisil saate päringute arvu vähendada nelja kuni kuue suurusjärgu võrra ja saavutada reageerimisaegu, mida on üldiselt raske eristada kohalikul SSD-l olevate andmete päringutest.
Nagu ülaltoodud diagrammil näidatud, vähendab Thanos Querier märkimisväärselt objektide salvestusandmete päringu hinda, kasutades Prometheuse salvestusvormingut ja asetades seotud andmed kõrvuti. Seda lähenemisviisi kasutades saame kombineerida palju üksikuid taotlusi minimaalseks arvuks hulgitoiminguteks.
Tihendamine ja diskreetimine
Kui uus aegridade andmete plokk on edukalt objektisalvestusse laaditud, käsitleme seda ajalooliste andmetena, mis on Store Gateway kaudu kohe saadaval.
Kuid mõne aja pärast kogunevad ühest allikast (külgkorviga Prometheus) pärinevad plokid ega kasuta enam kogu indekseerimispotentsiaali. Selle probleemi lahendamiseks tutvustasime teist komponenti nimega Compactor. See lihtsalt rakendab Prometheuse kohalikku tihendusmootorit objektide salvestamise ajaloolistele andmetele ja seda saab käivitada lihtsa perioodilise pakktööna.
Tänu tõhusale tihendamisele ei tekita salvestusruumi pikaajaline päringute tegemine andmemahu osas probleeme. Miljardi väärtuse lahtipakkimise ja päringuprotsessori kaudu käivitamise potentsiaalne kulu toob aga paratamatult kaasa päringu täitmisaja järsu pikenemise. Teisest küljest, kuna ekraanil on sadu andmepunkte piksli kohta, muutub täieliku eraldusvõimega andmete visualiseerimine võimatuks. Seega ei ole allavõetud diskreetimine mitte ainult võimalik, vaid see ei too kaasa ka märgatavat täpsuse vähenemist.
Andmete allavõtmiseks koondab Compactor andmeid pidevalt viie minuti ja ühe tunni eraldusvõimega. Iga TSDB XOR-i tihendamisega kodeeritud töötlemata tüki jaoks salvestatakse erinevat tüüpi koondandmed, näiteks min, max või summa ühe ploki kohta. See võimaldab Querieril automaatselt valida antud PromQL-päringu jaoks sobiva koondmaterjali.
Vähendatud täpsusega andmete kasutamiseks pole kasutajal vaja spetsiaalset konfiguratsiooni. Querier lülitub automaatselt erinevate eraldusvõimete ja toorandmete vahel, kui kasutaja sisse ja välja suumib. Soovi korral saab kasutaja seda otse päringu parameetri “step” kaudu juhtida.
Kuna ühe GB salvestamise hind on madal, salvestab Thanos vaikimisi algandmeid, viie minuti ja ühe tunni eraldusvõimega andmeid. Algandmeid pole vaja kustutada.
Salvestusreeglid
Isegi Thanose puhul on salvestusreeglid jälgimispinu oluline osa. Need vähendavad päringute keerukust, latentsust ja maksumust. Samuti on kasutajatel mugav hankida mõõdikute kaupa koondandmeid. Thanos põhineb vanilje Prometheuse eksemplaridel, seega on täiesti vastuvõetav salvestada salvestusreegleid ja hoiatusreegleid olemasolevasse Prometheuse serverisse. Kuid mõnel juhul ei pruugi sellest piisata:
- Globaalne hoiatus ja reegel (näiteks hoiatus, kui teenus ei tööta rohkem kui kahes klastris kolmest).
- Reegel andmetele väljaspool kohalikku salvestusruumi.
- Soov salvestada kõik reeglid ja hoiatused ühte kohta.
Kõigil neil juhtudel sisaldab Thanos eraldi komponenti nimega Ruler, mis arvutab reegli ja hoiatuse Thanose päringute kaudu. Pakkudes tuntud StoreAPI-d, pääseb päringusõlm juurde värskelt arvutatud mõõdikutele. Hiljem salvestatakse need ka objektihoidlasse ja tehakse kättesaadavaks Store Gateway kaudu.
Thanose jõud
Thanos on piisavalt paindlik, et seda vastavalt teie vajadustele kohandada. See on eriti kasulik tavalisest Prometheusest rännates. Kordame Thanose komponentide kohta õpitut kiire näitega kokku. Siit saate teada, kuidas viia oma vanilje Prometheus "piiramatu mõõdikute salvestusruumi" maailma:
- Lisage oma Prometheuse serveritesse Thanos Sidecar – näiteks külgkorvi konteiner Kubernetese kaustas.
- Andmete vaatamiseks juurutage mitu Thanos Querieri koopiat. Selles etapis on Scraperi ja Querieri vaheline kuulujutt lihtne seadistada. Komponentide koostoime kontrollimiseks kasutage mõõdikut „thanos_cluster_members”.
Vaid neist kahest sammust piisab globaalse vaate ja andmete sujuvaks eemaldamiseks potentsiaalsetest Prometheus HA koopiatest! Lihtsalt ühendage oma armatuurlauad Querier HTTP lõpp-punktiga või kasutage otse Thanose kasutajaliidest.
Kui aga vajate mõõdikute varundamist ja pikaajalist talletamist, peate tegema veel kolm sammu.
- Looge AWS S3 või GCS ämber. Konfigureerige külgkorv andmete kopeerimiseks nendesse ämbritesse. Kohalikku andmesalvestust saab nüüd minimeerida.
- Juurutage Store Gateway ja ühendage see oma olemasoleva kuulujuttude klastriga. Nüüd saate varundatud andmete kohta päringuid teha!
- Juurutage Compactor, et parandada päringu tõhusust pikema aja jooksul, kasutades tihendamist ja diskreetimist.
Kui soovite rohkem teada saada, heitke pilk meie lehele и !
Vaid viie sammuga muutsime Prometheuse usaldusväärseks seiresüsteemiks, millel on globaalne vaade, piiramatu salvestusaeg ja mõõdikute võimalik kõrge kättesaadavus.
Tõmbetaotlus: me vajame sind!
on algusest peale olnud avatud lähtekoodiga projekt. Sujuv integreerimine Prometheusega ja võimalus kasutada vaid osa Thanosest muudavad selle suurepäraseks valikuks oma jälgimissüsteemi hõlpsaks skaleerimiseks.
Ootame alati GitHub Pull'i taotlusi ja probleeme. Seni võtke meiega ühendust Githubi probleemide või slack'i kaudukui teil on küsimusi või tagasisidet või soovite jagada oma kogemusi selle kasutamisega! Kui teile meeldib see, mida me Improbable'is teeme, võtke meiega kindlasti ühendust - !
Allikas: www.habr.com