Prevod članka je bil pripravljen posebej za študente tečaja .
je razvijalec programske opreme, Go fanatik in reševalec težav. Je tudi vzdrževalec Prometheusa in soustanovitelj Kubernetes SIG instrumentation. V preteklosti je bil produkcijski inženir pri SoundCloudu in vodil nadzorno skupino pri CoreOS. Trenutno dela pri Googlu.
- infrastrukturni inženir pri Improbable. Zanimajo ga nove tehnologije in problemi porazdeljenih sistemov. Ima nizke izkušnje s programiranjem pri Intelu, izkušnje s sodelavci pri Mesosu in vrhunske izkušnje s proizvodnjo SRE pri Improbable. Predan izboljšanju sveta mikrostoritev. Njegove tri ljubezni: Golang, odprta koda in odbojka.
Če pogledate naš vodilni izdelek SpatialOS, lahko sklepate, da Improbable zahteva zelo dinamično infrastrukturo v oblaku globalnega obsega z več desetimi gručami Kubernetes. Bili smo eni prvih, ki smo začeli uporabljati nadzorni sistem . Prometheus je sposoben slediti milijonom meritev v realnem času in je opremljen z zmogljivim poizvedovalnim jezikom, ki vam omogoča pridobivanje informacij, ki jih potrebujete.
Enostavnost in zanesljivost Prometheusa je ena njegovih glavnih prednosti. Ko pa smo presegli določeno lestvico, smo naleteli na več pomanjkljivosti. Za rešitev teh težav smo razvili je odprtokodni projekt, ki ga je ustvaril Improbable za brezhibno preoblikovanje obstoječih grozdov Prometheus v enoten nadzorni sistem z neomejenim shranjevanjem zgodovinskih podatkov. Thanos je na voljo na Githubu .
Naši cilji s Thanosom
V določenem obsegu se pojavijo težave, ki presegajo zmožnosti vanilijevega Prometeja. Kako zanesljivo in ekonomično shraniti petabajte zgodovinskih podatkov? Ali je to mogoče storiti brez zmanjšanja odzivnega časa? Ali je mogoče z eno samo zahtevo API-ja dostopati do vseh meritev, ki se nahajajo na različnih strežnikih Prometheus? Ali obstaja način za združevanje ponovljenih podatkov, zbranih z uporabo Prometheus HA?
Za reševanje teh težav smo ustvarili Thanosa. Naslednji razdelki opisujejo, kako smo se lotili teh vprašanj, in pojasnjujejo naše cilje.
Poizvedovanje po podatkih iz več primerkov Prometheus (globalna poizvedba)
Prometheus ponuja funkcionalen pristop k razdeljevanju. Celo en strežnik Prometheus zagotavlja dovolj razširljivosti, da uporabnike osvobodi zapletenosti vodoravnega razdeljevanja v skoraj vseh primerih uporabe.
Čeprav je to odličen model uvajanja, je pogosto treba dostopati do podatkov na različnih strežnikih Prometheus prek enega samega API-ja ali uporabniškega vmesnika – globalni pogled. Seveda je možno prikazati več poizvedb v enem panelu Grafana, vendar se lahko vsaka poizvedba izvede samo na enem strežniku Prometheus. Po drugi strani pa lahko s Thanosom poizvedujete in združujete podatke iz več strežnikov Prometheus, saj so vsi dostopni z ene končne točke.
Prej, da bi dobili globalni pogled v Improbable, smo naše primerke Prometheus organizirali v večnivojski . To je pomenilo ustvarjanje enega meta strežnika Prometheus, ki zbira nekatere meritve iz vsakega listnega strežnika.
Ta pristop se je izkazal za problematičnega. Posledica tega so bolj zapletene konfiguracije, dodana dodatna potencialna točka napake in uporaba zapletenih pravil za zagotovitev, da zvezna končna točka prejme samo podatke, ki jih potrebuje. Poleg tega vam ta vrsta združevanja ne omogoča pravega globalnega pogleda, saj vsi podatki niso na voljo iz ene same zahteve API.
S tem je tesno povezan poenoten pogled na podatke, zbrane na strežnikih Prometheus z visoko razpoložljivostjo (HA). Prometheusov HA model neodvisno zbira podatke dvakrat, kar je tako preprosto, da preprostejše ne bi moglo biti. Vendar pa bi bila uporaba kombiniranega in dedupliciranega pogleda obeh tokov veliko bolj priročna.
Seveda obstaja potreba po visoko razpoložljivih strežnikih Prometheus. Pri Improbable spremljanje podatkov iz minute v minuto jemljemo zelo resno, vendar je imeti en primerek Prometheus na gručo ena sama točka napake. Vsaka konfiguracijska napaka ali okvara strojne opreme lahko vodi do izgube pomembnih podatkov. Celo preprosta uvedba lahko povzroči manjše motnje pri zbiranju meritev, ker so ponovni zagoni lahko bistveno daljši od intervala strganja.
Zanesljivo shranjevanje zgodovinskih podatkov
Poceni, hitro in dolgoročno shranjevanje meritev so naše sanje (ki jih deli večina uporabnikov Prometheusa). V Improbable smo bili prisiljeni konfigurirati obdobje hrambe meritev na devet dni (za Prometheus 1.8). To dodaja očitne omejitve glede tega, kako daleč nazaj lahko gledamo.
Prometheus 2.0 se je v tem pogledu izboljšal, saj število časovnih vrst ne vpliva več na splošno zmogljivost strežnika (glejte. ). Vendar Prometheus shranjuje podatke na lokalni disk. Čeprav lahko visokoučinkovito stiskanje podatkov znatno zmanjša uporabo lokalnega SSD-ja, na koncu še vedno obstaja omejitev količine zgodovinskih podatkov, ki jih je mogoče shraniti.
Poleg tega pri Improbable skrbimo za zanesljivost, preprostost in ceno. Velike lokalne diske je težje upravljati in varnostno kopirati. Stanejo več in zahtevajo več orodij za varnostno kopiranje, kar povzroči nepotrebno zapletenost.
Zmanjšanje vzorčenja
Ko smo začeli delati s preteklimi podatki, smo spoznali, da obstajajo temeljne težave z velikim O, zaradi katerih so poizvedbe čedalje počasnejše, ko delamo s tedni, meseci in leti podatkov.
Standardna rešitev tega problema bi bila (downsampling) - zmanjšanje frekvence vzorčenja signala. Z zmanjševanjem vzorčenja lahko »zmanjšamo« na večji časovni razpon in ohranimo enako število vzorcev, s čimer ohranjamo odzivnost poizvedb.
Zmanjšanje vzorčenja starih podatkov je neizogibna zahteva katere koli rešitve za dolgoročno shranjevanje in je izven obsega vanilije Prometheus.
Dodatni cilji
Eden od prvotnih ciljev projekta Thanos je bila brezhibna integracija z vsemi obstoječimi instalacijami Prometheus. Drugi cilj je bila enostavnost delovanja z minimalnimi ovirami za vstop. Vse odvisnosti bi morale biti enostavno zadovoljene tako za male kot velike uporabnike, kar pomeni tudi nizke osnovne stroške.
Thanosova arhitektura
Potem ko smo našteli naše cilje v prejšnjem razdelku, jih obdelajmo in poglejmo, kako Thanos rešuje te težave.
Globalni pogled
Da bi dobili globalni pogled na obstoječe instance Prometheus, moramo povezati eno samo vstopno točko zahteve z vsemi strežniki. Točno to počne komponenta Thanos. . Razmeščen je poleg vsakega strežnika Prometheus in deluje kot proxy, ki streže lokalne podatke Prometheus prek API-ja gRPC Store, kar omogoča pridobivanje podatkov časovne serije po oznaki in časovnem obsegu.
Na drugi strani je razširljiva komponenta Querier brez stanja, ki ne naredi več kot le odgovarja na poizvedbe PromQL prek standardnega API-ja Prometheus HTTP. Querier, Sidecar in druge komponente Thanosa komunicirajo prek .
- Querier se po prejemu zahteve poveže z ustreznim strežnikom Store API, to je z našimi Sidecars in prejme podatke o časovni vrsti od ustreznih strežnikov Prometheus.
- Nato združi odgovore in na njih izvede poizvedbo PromQL. Querier lahko združi tako nepovezane podatke kot podvojene podatke iz strežnikov Prometheus HA.
To reši glavni del naše uganke – združevanje podatkov iz izoliranih strežnikov Prometheus v en sam pogled. Pravzaprav je Thanosa mogoče uporabiti samo za to funkcijo. Obstoječih strežnikov Prometheus ni treba spreminjati!
Neomejen rok trajanja!
Vendar pa bomo prej ali slej želeli shraniti podatke preko običajnega Prometheusovega časa hrambe. Za shranjevanje zgodovinskih podatkov smo izbrali objektno shranjevanje. Široko je na voljo v katerem koli oblaku, pa tudi v podatkovnih centrih na mestu uporabe in je zelo stroškovno učinkovit. Poleg tega je skoraj vsako shranjevanje predmetov na voljo prek znanega API-ja S3.
Prometheus zapiše podatke iz RAM-a na disk približno vsaki dve uri. Shranjeni podatkovni blok vsebuje vse podatke za določeno časovno obdobje in je nespremenljiv. To je zelo priročno, ker lahko Thanos Sidecar preprosto pogleda podatkovni imenik Prometheus in jih, ko so na voljo novi bloki, naloži v vedra za shranjevanje predmetov.
Nalaganje v shrambo objektov takoj po pisanju na disk omogoča tudi ohranjanje preprostosti strgala (Prometheus in Thanos Sidecar). Kar poenostavlja podporo, stroške in načrtovanje sistema.
Kot lahko vidite, je varnostno kopiranje podatkov zelo preprosto. Kaj pa poizvedovanje po podatkih v shrambi objektov?
Komponenta Thanos Store deluje kot proxy za pridobivanje podatkov iz shrambe objektov. Tako kot Thanos Sidecar sodeluje v gossip grozdu in implementira Store API. Na ta način ga lahko obstoječi Querier obravnava kot Sidecar, kot še en vir podatkov o časovni vrsti – posebna konfiguracija ni potrebna.
Podatkovni bloki časovnih vrst so sestavljeni iz več velikih datotek. Njihovo nalaganje na zahtevo bi bilo precej neučinkovito, njihovo lokalno predpomnjenje pa bi zahtevalo ogromno pomnilnika in prostora na disku.
Namesto tega Store Gateway ve, kako ravnati s formatom za shranjevanje Prometheus. Zahvaljujoč pametnemu razporejevalniku poizvedb in predpomnjenju samo potrebnih indeksnih delov blokov je mogoče kompleksne poizvedbe zmanjšati na minimalno število zahtev HTTP za datoteke za shranjevanje objektov. Na ta način lahko zmanjšate število zahtev za štiri do šest velikosti in dosežete odzivne čase, ki jih je na splošno težko razlikovati od zahtev za podatke na lokalnem SSD.
Kot je prikazano v zgornjem diagramu, Thanos Querier znatno zmanjša stroške na poizvedbo podatkov o shranjevanju objektov, tako da izkoristi format shranjevanja Prometheus in postavi sorodne podatke enega ob drugega. S tem pristopom lahko združimo veliko posameznih zahtev v minimalno število množičnih operacij.
Zgoščevanje in zmanjševanje vzorčenja
Ko je nov blok podatkov časovne serije uspešno naložen v shrambo objekta, ga obravnavamo kot "zgodovinske" podatke, ki so takoj na voljo prek prehoda Store.
Vendar pa se čez nekaj časa bloki iz enega vira (Prometheus s Sidecar) kopičijo in ne uporabljajo več celotnega potenciala indeksiranja. Da bi rešili to težavo, smo uvedli drugo komponento, imenovano Compactor. Preprosto uporabi Prometheusov lokalni stroj za zgoščevanje zgodovinskih podatkov v shranjevanju objektov in ga je mogoče izvajati kot preprosto periodično paketno opravilo.
Zahvaljujoč učinkovitemu stiskanju poizvedovanje po pomnilniku v daljšem časovnem obdobju ne predstavlja težave glede velikosti podatkov. Vendar bodo potencialni stroški razpakiranja milijarde vrednosti in njihovega izvajanja skozi procesor poizvedb neizogibno povzročili dramatično povečanje časa izvajanja poizvedbe. Po drugi strani, ker je na zaslonu na stotine podatkovnih točk na slikovno piko, postane nemogoče celo prikazati podatke v polni ločljivosti. Tako znižanje vzorčenja ni samo možno, ampak tudi ne bo povzročilo opazne izgube natančnosti.
Za zmanjšanje vzorčenja podatkov Compactor nenehno združuje podatke z ločljivostjo pet minut in eno uro. Za vsak neobdelani kos, kodiran s kompresijo TSDB XOR, so shranjene različne vrste zbirnih podatkov, kot so min, maks ali vsota za en blok. To omogoča Querierju, da samodejno izbere agregat, ki je primeren za dano poizvedbo PromQL.
Za uporabo podatkov z zmanjšano natančnostjo uporabniku ni potrebna posebna konfiguracija. Querier samodejno preklaplja med različnimi ločljivostmi in neobdelanimi podatki, ko uporabnik poveča in pomanjša. Po želji lahko uporabnik to nadzira neposredno prek parametra »korak« v zahtevi.
Ker so stroški shranjevanja enega GB nizki, Thanos privzeto shranjuje neobdelane podatke, petminutne in enourne podatke. Izvirnih podatkov ni treba izbrisati.
Pravila snemanja
Tudi pri Thanosu so pravila snemanja bistveni del sklada za spremljanje. Zmanjšujejo kompleksnost, zakasnitev in stroške poizvedb. Prav tako so priročni za uporabnike, da pridobijo agregirane podatke po metrikah. Thanos temelji na instancah Prometheus, zato je povsem sprejemljivo, da pravila za snemanje in pravila za opozarjanje shranite na obstoječi strežnik Prometheus. Vendar v nekaterih primerih to morda ne bo dovolj:
- Globalno opozorilo in pravilo (na primer opozorilo, ko storitev ne deluje v več kot dveh od treh gruč).
- Pravilo za podatke zunaj lokalnega pomnilnika.
- Želja po shranjevanju vseh pravil in opozoril na enem mestu.
Za vse te primere Thanos vključuje ločeno komponento, imenovano Ruler, ki izračuna pravilo in opozorilo prek Thanos Queries. Z zagotavljanjem dobro znanega StoreAPI lahko vozlišče Query dostopa do sveže izračunanih meritev. Kasneje so shranjeni tudi v objektni shrambi in so na voljo prek Store Gateway.
Moč Thanosa
Thanos je dovolj prilagodljiv, da ga lahko prilagodite svojim potrebam. To je še posebej uporabno pri selitvi iz navadnega Prometheusa. Na kratko povzamemo, kaj smo se naučili o komponentah Thanos s hitrim primerom. Tukaj je opisano, kako popeljati svojega vanilijevega Prometheusa v svet »neomejenega shranjevanja metrik«:
- Dodajte Thanos Sidecar na svoje strežnike Prometheus – na primer posodo s stransko prikolico v Kubernetes pod.
- Namestite več replik Thanos Querier, da si boste lahko ogledali podatke. Na tej stopnji je enostavno vzpostaviti trač med Scraperjem in Querierjem. Za preverjanje interakcije komponent uporabite metriko 'thanos_cluster_members'.
Samo ta dva koraka sta dovolj, da zagotovite globalni pogled in brezhibno deduplikacijo podatkov iz morebitnih replik Prometheus HA! Preprosto povežite svoje nadzorne plošče s končno točko HTTP Querier ali neposredno uporabite uporabniški vmesnik Thanos.
Če pa potrebujete varnostno kopijo meritev in dolgoročno shranjevanje, boste morali izvesti še tri korake:
- Ustvarite vedro AWS S3 ali GCS. Konfigurirajte Sidecar za kopiranje podatkov v ta vedra. Lokalno shranjevanje podatkov je zdaj mogoče zmanjšati.
- Namestite Store Gateway in ga povežite z vašo obstoječo gossip gručo. Zdaj lahko povprašate po varnostno kopiranih podatkih!
- Razmestite Compactor za izboljšanje učinkovitosti poizvedb v daljših časovnih obdobjih z uporabo stiskanja in zmanjšanja vzorčenja.
Če želite izvedeti več, ne oklevajte in si oglejte naše и !
V samo petih korakih smo Prometheus spremenili v zanesljiv nadzorni sistem z globalnim pogledom, neomejenim časom shranjevanja in potencialno visoko razpoložljivostjo meritev.
Pull request: potrebujemo vas!
je že od vsega začetka odprtokodni projekt. Brezhibna integracija s Prometheusom in možnost uporabe samo dela Thanosa je odlična izbira za enostavno prilagajanje vašega nadzornega sistema.
Vedno pozdravljamo GitHub Pull Requests in Issues. Medtem nas lahko kontaktirate prek Github Issues ali Slackče imate vprašanja ali povratne informacije ali želite deliti svoje izkušnje z uporabo! Če vam je všeč, kar počnemo pri Improbable, ne oklevajte in nas kontaktirajte - !
Vir: www.habr.com