Artikkelin käännös on tehty erityisesti kurssin opiskelijoille .
on ohjelmistokehittäjä, fanaatikko ja ongelmanratkaisija. Hän on myös Prometheus-ylläpitäjä ja Kubernetes SIG -instrumentoinnin perustaja. Aiemmin hän oli tuotantoinsinööri SoundCloudissa ja johti CoreOS:n valvontatiimiä. Työskentelee tällä hetkellä Googlella.
- Infrastruktuuri-insinööri yrityksessä Improbable. Hän on kiinnostunut uusista teknologioista ja hajautettujen järjestelmien ongelmista. Hänellä on matalan tason ohjelmointikokemus Intelistä, avustajakokemus Mesoksesta ja maailmanluokan SRE-tuotantokokemus Improbablesta. Omistettu mikropalvelujen maailman parantamiselle. Hänen kolme rakkauttaan: Golang, avoin lähdekoodi ja lentopallo.
Tarkasteltaessa lippulaivatuotteemme SpatialOS, voit arvata, että Improbable vaatii erittäin dynaamisen, maailmanlaajuisen pilviinfrastruktuurin, jossa on kymmeniä Kubernetes-klustereita. Olimme ensimmäisten joukossa, jotka käyttivät valvontajärjestelmää . Prometheus pystyy seuraamaan miljoonia mittareita reaaliajassa, ja sen mukana tulee tehokas kyselykieli, jonka avulla voit poimia tarvitsemasi tiedot.
Prometheuksen yksinkertaisuus ja luotettavuus on yksi sen tärkeimmistä eduista. Kuitenkin, kun ylitimme tietyn asteikon, kohtasimme useita haittoja. Näiden ongelmien ratkaisemiseksi olemme kehittäneet on Improbablen luoma avoimen lähdekoodin projekti, joka muuttaa olemassa olevat Prometheus-klusterit saumattomasti yhdeksi valvontajärjestelmäksi, jossa on rajoittamaton historiatietojen tallennus. Thanos on saatavilla Githubissa .
Tavoitteemme Thanoksen kanssa
Tietyssä mittakaavassa syntyy ongelmia, jotka ylittävät vanilja Prometheuksen kyvyt. Kuinka tallentaa petabyyttiä historiallista tietoa luotettavasti ja taloudellisesti? Voidaanko tämä tehdä tinkimättä vasteajasta? Onko mahdollista päästä kaikkiin eri Prometheus-palvelimilla sijaitseviin mittareihin yhdellä API-pyynnöllä? Onko mahdollista yhdistää Prometheus HA:lla kerättyä replikoitua dataa?
Näiden ongelmien ratkaisemiseksi loimme Thanosin. Seuraavissa osissa kuvataan, kuinka lähestyimme näitä kysymyksiä, ja selitetään tavoitteemme.
Tietojen kysely useista Prometheus-esiintymistä (yleinen kysely)
Prometheus tarjoaa toiminnallisen lähestymistavan sirpalointiin. Jopa yksi Prometheus-palvelin tarjoaa riittävän skaalautuvuuden vapauttaakseen käyttäjät vaakasuuntaisen sirpaloinnin monimutkaisuudesta lähes kaikissa käyttötapauksissa.
Vaikka tämä on loistava käyttöönottomalli, on usein tarpeen päästä käsiksi eri Prometheus-palvelimien tietoihin yhden API- tai käyttöliittymän kautta - globaalin näkymän kautta. Tietenkin on mahdollista näyttää useita kyselyjä yhdessä Grafana-paneelissa, mutta jokainen kysely voidaan suorittaa vain yhdellä Prometheus-palvelimella. Toisaalta Thanosilla voit tiedustella ja koota tietoja useilta Prometheus-palvelimilta, koska ne ovat kaikki käytettävissä yhdestä päätepisteestä.
Aiemmin järjestimme Prometheus-esiintymämme monitasoiseksi saadaksemme yleiskuvan Improbablesta. . Tämä tarkoitti yhden Prometheus-metapalvelimen luomista, joka kerää osan mittareista jokaiselta lehtipalvelimelta.
Tämä lähestymistapa osoittautui ongelmalliseksi. Tämä on johtanut monimutkaisempiin kokoonpanoihin, lisättyyn mahdolliseen vikakohtaan ja monimutkaisten sääntöjen soveltamiseen sen varmistamiseksi, että yhdistetty päätepiste vastaanottaa vain tarvitsemansa tiedot. Lisäksi tällainen liittäminen ei mahdollista todellisen globaalin näkemyksen saamista, koska kaikki tiedot eivät ole saatavilla yhdestä API-pyynnöstä.
Tähän liittyy läheisesti yhtenäinen näkymä korkean käytettävyyden (HA) Prometheus-palvelimille kerätyistä tiedoista. Prometheuksen HA-malli kerää itsenäisesti dataa kahdesti, mikä on niin yksinkertaista, ettei se voisi olla yksinkertaisempaa. Molempien virtojen yhdistetyn ja kaksoiskappaleen poistamisen käyttäminen olisi kuitenkin paljon kätevämpää.
Tietenkin tarvitaan erittäin saatavilla olevia Prometheus-palvelimia. Suhtaudumme Improbablessa minuutti minuutilta tapahtuvaan tiedonseurantaan todella vakavasti, mutta yhden Prometheus-esiintymän saaminen klusteria kohden on yksi vikakohta. Mikä tahansa asetusvirhe tai laitteistovika voi mahdollisesti johtaa tärkeiden tietojen menetykseen. Yksinkertainenkin käyttöönotto voi aiheuttaa pieniä häiriöitä mittareiden keräämisessä, koska uudelleenkäynnistykset voivat olla huomattavasti pidempiä kuin kaavinväli.
Luotettava historiatietojen tallennus
Halpa, nopea ja pitkäaikainen mittaustietojen tallennus on unelmamme (useimmat Prometheus-käyttäjät jakavat). Improbableissa jouduimme määrittämään mittareiden säilytysajan yhdeksään päivään (Prometheus 1.8:lle). Tämä lisää ilmeisiä rajoja sille, kuinka kauas taaksepäin voimme katsoa.
Prometheus 2.0 on parantunut tässä suhteessa, koska aikasarjojen määrä ei enää vaikuta palvelimen yleiseen suorituskykyyn (katso. ). Prometheus kuitenkin tallentaa tiedot paikalliselle levylle. Vaikka tehokas tiedonpakkaus voi vähentää merkittävästi paikallisen SSD:n käyttöä, tallennettavien historiallisten tietojen määrällä on viime kädessä edelleen raja.
Lisäksi me Improbablella välitämme luotettavuudesta, yksinkertaisuudesta ja kustannuksista. Suuria paikallisia levyjä on vaikeampi käyttää ja varmuuskopioida. Ne maksavat enemmän ja vaativat enemmän varmuuskopiointityökaluja, mikä johtaa tarpeettomaan monimutkaisuuteen.
Alasnäyte
Kun aloimme työskennellä historiallisten tietojen kanssa, huomasimme, että big-O:ssa on perustavanlaatuisia vaikeuksia, jotka hidastavat kyselyitä, kun työskentelemme viikkojen, kuukausien ja vuosien tietojen kanssa.
Normaali ratkaisu tähän ongelmaan olisi (alinäytteistys) - signaalin näytteenottotaajuuden vähentäminen. Alasnäytteenoton avulla voimme "skaalata" laajemmalle aikavälille ja säilyttää saman määrän näytteitä pitäen kyselyt responsiivisina.
Vanhojen tietojen näytteenotto on väistämätön edellytys kaikille pitkäaikaisille tallennusratkaisuille, ja se ei kuulu vanilja-Prometheuksen piiriin.
Lisätavoitteet
Yksi Thanos-projektin alkuperäisistä tavoitteista oli integroida saumattomasti olemassa oleviin Prometheus-asennuksiin. Toinen tavoite oli toiminnan helppous minimaalisilla pääsyn esteillä. Mahdolliset riippuvuudet tulee tyydyttää helposti sekä pienille että suurille käyttäjille, mikä tarkoittaa myös alhaisia peruskustannuksia.
Thanos-arkkitehtuuri
Kun tavoitteemme on lueteltu edellisessä osiossa, käydään ne läpi ja katsotaan kuinka Thanos ratkaisee nämä ongelmat.
Globaali näkymä
Saadaksemme yleiskuvan olemassa olevista Prometheus-esiintymistä, meidän on linkitettävä yksi pyynnön tulopiste kaikkiin palvelimiin. Juuri tätä Thanos-komponentti tekee. . Se on asennettu jokaisen Prometheus-palvelimen viereen ja toimii välityspalvelimena, joka palvelee paikallista Prometheus-dataa gRPC Storen API:n kautta, jolloin aikasarjatiedot voidaan noutaa tunnisteen ja aikavälin mukaan.
Toisella puolella on skaalattava, tilaton Querier-komponentti, joka ei tee muuta kuin vain vastaa PromQL-kyselyihin tavallisen Prometheus HTTP API:n kautta. Querier, Sidecar ja muut Thanos-komponentit kommunikoivat kautta .
- Pyynnön saatuaan Querier muodostaa yhteyden vastaavaan Store API -palvelimeen eli sivuvaunuihimme ja vastaanottaa aikasarjadataa vastaavilta Prometheus-palvelimilta.
- Sen jälkeen se yhdistää vastaukset ja suorittaa PromQL-kyselyn niille. Querier voi yhdistää sekä erillisiä tietoja että päällekkäisiä tietoja Prometheus HA -palvelimista.
Tämä ratkaisee tärkeän palapelimme - yhdistämällä tiedot yksittäisistä Prometheus-palvelimista yhdeksi näkymäksi. Itse asiassa Thanosta voidaan käyttää vain tähän ominaisuuteen. Olemassa oleviin Prometheus-palvelimiin ei tarvitse tehdä muutoksia!
Rajoittamaton säilyvyys!
Kuitenkin ennemmin tai myöhemmin haluamme tallentaa tietoja normaalin Prometheuksen säilytysajan jälkeen. Valitsimme objektitallennustilan historiatietojen tallentamiseen. Se on laajalti saatavilla missä tahansa pilvessä sekä paikallisissa datakeskuksissa ja on erittäin kustannustehokas. Lisäksi lähes mikä tahansa objektitallennus on saatavilla tunnetun S3 API:n kautta.
Prometheus kirjoittaa tiedot RAM-muistista levylle noin kahden tunnin välein. Tallennetussa datalohkossa on kaikki tiedot määrätyn ajan ja se on muuttumaton. Tämä on erittäin kätevää, koska Thanos Sidecar voi yksinkertaisesti katsoa Prometheus-tietohakemistoa ja ladata niitä objektien tallennusämpäriin, kun uusia lohkoja tulee saataville.
Lataamalla objektimuistiin heti levylle kirjoittamisen jälkeen voit myös säilyttää kaavin yksinkertaisuuden (Prometheus ja Thanos Sidecar). Mikä yksinkertaistaa tukea, kustannuksia ja järjestelmän suunnittelua.
Kuten näet, tietojen varmuuskopiointi on hyvin yksinkertaista. Mutta entä tietojen kysely objektivarastosta?
Thanos Store -komponentti toimii välityspalvelimena tietojen noutamiseksi objektien tallennustilasta. Kuten Thanos Sidecar, se osallistuu juoruklusteriin ja toteuttaa Store API:n. Tällä tavalla olemassa oleva Querier voi käsitellä sitä sivuvaununa toisena aikasarjadatan lähteenä - mitään erityisiä määrityksiä ei tarvita.
Aikasarjatietolohkot koostuvat useista suurista tiedostoista. Niiden lataaminen pyynnöstä olisi melko tehotonta, ja niiden välimuistiin tallentaminen paikallisesti vaatisi valtavan määrän muistia ja levytilaa.
Sen sijaan Store Gateway osaa käsitellä Prometheus-tallennusmuotoa. Älykkään kyselyn ajastimen ja vain tarvittavien lohkojen indeksiosien välimuistin ansiosta on mahdollista vähentää monimutkaiset kyselyt mahdollisimman pieneen HTTP-pyyntöjen määrään objektien tallennustiedostoihin. Tällä tavalla voit vähentää pyyntöjen määrää neljästä kuuteen suuruusluokkaa ja saavuttaa vastausaikoja, joita on yleensä vaikea erottaa paikallisella SSD-levyllä olevista tietopyynnöistä.
Kuten yllä olevasta kaaviosta näkyy, Thanos Querier vähentää merkittävästi objektitallennustietojen kyselykohtaisia kustannuksia hyödyntämällä Prometheus-tallennusmuotoa ja sijoittamalla siihen liittyvät tiedot vierekkäin. Tätä lähestymistapaa käyttämällä voimme yhdistää useita yksittäisiä pyyntöjä vähimmäismääräksi joukkotoimintoja.
Tiivistys ja näytteenotto
Kun uusi aikasarjatietojen lohko on ladattu onnistuneesti objektivarastoon, käsittelemme sitä "historiallisena" datana, joka on heti saatavilla Store Gatewayn kautta.
Kuitenkin jonkin ajan kuluttua lohkot yhdestä lähteestä (Prometheus with Sidecar) kerääntyvät eivätkä enää käytä täyttä indeksointipotentiaalia. Tämän ongelman ratkaisemiseksi otimme käyttöön toisen komponentin nimeltä Compactor. Se yksinkertaisesti soveltaa Prometheuksen paikallista tiivistysmoottoria historiallisiin tietoihin objektitallennustilassa, ja sitä voidaan käyttää yksinkertaisena jaksollisena erätyönä.
Tehokkaan pakkauksen ansiosta tallennustilan kysely pitkällä aikavälillä ei aiheuta ongelmaa tietokoon suhteen. Miljardin arvon purkamisesta ja kyselyprosessorin kautta ajosta aiheutuvat kustannukset johtavat kuitenkin väistämättä kyselyn suoritusajan dramaattiseen pidentymiseen. Toisaalta, koska näytöllä on satoja datapisteitä pikseliä kohden, on mahdotonta edes visualisoida tietoja täydellä resoluutiolla. Näin ollen näytteenotto ei ole vain mahdollista, vaan se ei myöskään johda havaittavaan tarkkuuden heikkenemiseen.
Datan otoksen pienentämiseksi Compactor kokoaa tietoja jatkuvasti viiden minuutin ja tunnin tarkkuudella. Jokaiselle TSDB XOR -pakkauksella koodatulle raakapalalle tallennetaan erityyppisiä aggregoituja tietoja, kuten min, max tai summa yhdelle lohkolle. Tämä antaa Querierille mahdollisuuden valita automaattisesti tietylle PromQL-kyselylle sopivan koosteen.
Käyttäjä ei vaadi erityisiä määrityksiä voidakseen käyttää alennettua tarkkuutta. Querier vaihtaa automaattisesti eri resoluutioiden ja raakatietojen välillä, kun käyttäjä lähentää ja loitontaa. Halutessaan käyttäjä voi ohjata tätä suoraan pyynnön "step"-parametrin kautta.
Koska yhden gigatavun tallennuskustannukset ovat alhaiset, Thanos tallentaa oletusarvoisesti raakadataa, viiden minuutin ja tunnin resoluutiodataa. Alkuperäisiä tietoja ei tarvitse poistaa.
Tallennussäännöt
Myös Thanosissa tallennussäännöt ovat olennainen osa valvontapinoa. Ne vähentävät kyselyiden monimutkaisuutta, viivettä ja kustannuksia. Ne ovat myös hyödyllisiä käyttäjille, kun he hankkivat koottuja tietoja mittareittain. Thanos perustuu vaniljaisiin Prometheus-instanssiin, joten tallennussääntöjen ja hälytyssääntöjen tallentaminen olemassa olevalle Prometheus-palvelimelle on täysin hyväksyttävää. Joissakin tapauksissa tämä ei kuitenkaan välttämättä riitä:
- Yleinen hälytys ja sääntö (esimerkiksi hälytys, kun palvelu ei toimi useammassa kuin kahdessa kolmesta klusterista).
- Sääntö datalle paikallisen tallennustilan ulkopuolella.
- Halu tallentaa kaikki säännöt ja hälytykset yhteen paikkaan.
Kaikissa näissä tapauksissa Thanos sisältää erillisen komponentin nimeltä Ruler, joka laskee säännön ja hälytyksen Thanos Queriesin kautta. Tarjoamalla tunnetun StoreAPI:n kyselysolmu voi käyttää juuri laskettuja mittareita. Myöhemmin ne tallennetaan myös esinevarastoihin ja asetetaan saataville Store Gatewayn kautta.
Thanoksen voima
Thanos on tarpeeksi joustava, jotta se voidaan räätälöidä tarpeidesi mukaan. Tämä on erityisen hyödyllistä siirryttäessä tavallisesta Prometheuksesta. Kerrataanpa nopeasti, mitä olemme oppineet Thanos-komponenteista nopealla esimerkillä. Näin saat vanilja-Prometheuksen "rajattoman mittaustilan" maailmaan:
- Lisää Thanos Sidecar Prometheus-palvelimillesi – esimerkiksi sivuvaunukontti Kubernetes-koteloon.
- Ota käyttöön useita Thanos Querier -kopioita, jotta voit tarkastella tietoja. Tässä vaiheessa on helppo luoda juoruja Scraperin ja Querierin välille. Voit tarkistaa komponenttien vuorovaikutuksen käyttämällä thanos_cluster_members-mittaria.
Pelkästään nämä kaksi vaihetta riittävät tarjoamaan yleisnäkymän ja saumattoman tietojen duplikoinnin mahdollisista Prometheus HA -kopioista! Yhdistä vain kojelautasi Querier HTTP -päätepisteeseen tai käytä suoraan Thanos-käyttöliittymää.
Jos kuitenkin tarvitset mittareiden varmuuskopion ja pitkäaikaista tallennusta, sinun on suoritettava vielä kolme vaihetta:
- Luo AWS S3- tai GCS-ämpäri. Määritä Sidecar kopioimaan tiedot näihin ryhmiin. Paikallinen tiedon tallennus voidaan nyt minimoida.
- Ota Store Gateway käyttöön ja yhdistä se olemassa olevaan juoruklusteriisi. Nyt voit tiedustella varmuuskopioituja tietoja!
- Ota Compactor käyttöön parantaaksesi kyselyn tehokkuutta pitkiä aikoja käyttämällä tiivistämistä ja alennusnäytteistystä.
Jos haluat tietää lisää, älä epäröi katsoa meidän и !
Teimme Prometheuksesta vain viidessä vaiheessa luotettavan valvontajärjestelmän, jolla on globaali näkymä, rajoittamaton tallennusaika ja mahdollinen korkea mittarien saatavuus.
Vetopyyntö: tarvitsemme sinua!
on ollut avoimen lähdekoodin projekti alusta alkaen. Saumaton integrointi Prometheuksen kanssa ja mahdollisuus käyttää vain osaa Thanosista tekevät siitä erinomaisen vaihtoehdon valvontajärjestelmän skaalaamiseen vaivattomasti.
Olemme aina tervetulleita GitHub Pull -pyyntöihin ja -ongelmiin. Sillä välin voit ottaa meihin yhteyttä Github Issuesin tai slackin kauttajos sinulla on kysyttävää tai palautetta tai haluat jakaa kokemuksiasi sen käytöstä! Jos pidät siitä, mitä teemme Improbablella, älä epäröi ottaa meihin yhteyttä - !
Lähde: will.com