Preklad článku bol pripravený špeciálne pre študentov kurzu .
je vývojár softvéru, fanatik Go a riešiteľ problémov. Je tiež správcom Prometheus a spoluzakladateľom prístrojov Kubernetes SIG. V minulosti bol produkčným inžinierom v SoundCloud a viedol monitorovací tím v CoreOS. V súčasnosti pracuje v Google.
- Infraštruktúrny inžinier v spoločnosti Nepravdepodobné. Zaujíma sa o nové technológie a problémy distribuovaných systémov. Má skúsenosti s programovaním na nízkej úrovni v spoločnosti Intel, skúsenosti s prispievateľom v spoločnosti Mesos a skúsenosti s produkciou SRE svetovej triedy v spoločnosti Improbable. Venuje sa zlepšovaniu sveta mikroslužieb. Jeho tri lásky: Golang, open source a volejbal.
Pri pohľade na náš vlajkový produkt SpatialOS môžete uhádnuť, že Nepravdepodobný vyžaduje vysoko dynamickú, globálnu cloudovú infraštruktúru s desiatkami klastrov Kubernetes. Boli sme jedni z prvých, ktorí použili monitorovací systém . Prometheus je schopný sledovať milióny metrík v reálnom čase a prichádza s výkonným jazykom dotazov, ktorý vám umožňuje extrahovať informácie, ktoré potrebujete.
Jednoduchosť a spoľahlivosť Prometheus je jednou z jeho hlavných výhod. Keď sme však prekročili určitú mierku, narazili sme na niekoľko nedostatkov. Na vyriešenie týchto problémov sme vyvinuli je projekt s otvoreným zdrojovým kódom vytvorený spoločnosťou Improbable na bezproblémovú transformáciu existujúcich klastrov Prometheus na jediný monitorovací systém s neobmedzeným ukladaním historických údajov. Thanos je dostupný na Github .
Naše ciele s Thanosom
V určitom meradle vznikajú problémy, ktoré sú nad možnosti vanilky Prometheus. Ako spoľahlivo a ekonomicky ukladať petabajty historických dát? Dá sa to urobiť bez zníženia času odozvy? Je možné získať prístup ku všetkým metrikám umiestneným na rôznych serveroch Prometheus pomocou jedinej požiadavky API? Existuje nejaký spôsob, ako spojiť replikované údaje zozbierané pomocou Prometheus HA?
Na vyriešenie týchto problémov sme vytvorili Thanosa. Nasledujúce časti popisujú, ako sme k týmto problémom pristupovali, a vysvetľujú naše ciele.
Dopytovanie údajov z viacerých inštancií Prometheus (globálny dotaz)
Prometheus ponúka funkčný prístup k shardingu. Dokonca aj jeden server Prometheus poskytuje dostatočnú škálovateľnosť, aby oslobodil používateľov od zložitosti horizontálneho rozdelenia takmer vo všetkých prípadoch použitia.
Aj keď ide o skvelý model nasadenia, často je potrebné pristupovať k údajom na rôznych serveroch Prometheus cez jediné rozhranie API alebo používateľské rozhranie – globálny pohľad. Samozrejme je možné zobraziť viacero dopytov v jednom paneli Grafana, ale každý dopyt je možné vykonať len na jednom serveri Prometheus. Na druhej strane s Thanosom môžete vyhľadávať a agregovať údaje z viacerých serverov Prometheus, pretože všetky sú prístupné z jedného koncového bodu.
Predtým, aby sme získali globálny pohľad na Nepravdepodobné, organizovali sme naše inštancie Prometheus do viacúrovňových . To znamenalo vytvoriť jeden meta server Prometheus, ktorý zhromažďuje niektoré metriky z každého listového servera.
Tento prístup sa ukázal ako problematický. Výsledkom sú zložitejšie konfigurácie, pridanie ďalšieho potenciálneho bodu zlyhania a uplatňovanie zložitých pravidiel, aby sa zabezpečilo, že federovaný koncový bod dostane iba údaje, ktoré potrebuje. Okrem toho vám tento druh federácie neumožňuje získať skutočný globálny pohľad, pretože nie všetky údaje sú dostupné z jedinej požiadavky API.
S tým úzko súvisí aj jednotný pohľad na dáta zozbierané na vysokodostupných (HA) serveroch Prometheus. Prometheusov HA model nezávisle zbiera údaje dvakrát, čo je také jednoduché, že to už nemôže byť jednoduchšie. Použitie kombinovaného a deduplikovaného zobrazenia oboch prúdov by však bolo oveľa pohodlnejšie.
Samozrejme, sú potrebné vysoko dostupné servery Prometheus. V Improbable berieme monitorovanie údajov z minúty na minútu naozaj vážne, ale mať jednu inštanciu Prometheus na klaster je jediným bodom zlyhania. Akákoľvek chyba konfigurácie alebo zlyhanie hardvéru môže potenciálne viesť k strate dôležitých údajov. Dokonca aj jednoduché nasadenie môže spôsobiť menšie narušenie zberu metrík, pretože reštarty môžu byť výrazne dlhšie ako interval zoškrabovania.
Spoľahlivé ukladanie historických údajov
Lacné, rýchle a dlhodobé ukladanie metrík je náš sen (zdieľaný väčšinou používateľov Prometheus). V Nepravdepodobnom sme boli nútení nakonfigurovať obdobie uchovávania metrík na deväť dní (pre Prometheus 1.8). To pridáva zjavné hranice toho, ako ďaleko späť sa môžeme pozrieť.
Prometheus 2.0 sa v tomto smere zlepšil, keďže počet časových radov už neovplyvňuje celkový výkon servera (pozri. ). Prometheus však ukladá dáta na lokálny disk. Hoci vysokoúčinná kompresia dát môže výrazne znížiť miestne využitie SSD, v konečnom dôsledku stále existuje limit na množstvo historických dát, ktoré je možné uložiť.
V Improbable nám navyše záleží na spoľahlivosti, jednoduchosti a cene. Veľké lokálne disky sú náročnejšie na obsluhu a zálohovanie. Sú drahšie a vyžadujú viac nástrojov na zálohovanie, čo vedie k zbytočnej zložitosti.
Prevzorkovanie
Keď sme začali pracovať s historickými údajmi, uvedomili sme si, že existujú zásadné problémy s big-O, ktoré spôsobujú, že dopyty sú stále pomalšie a pomalšie, keďže pracujeme s údajmi z týždňov, mesiacov a rokov.
Štandardné riešenie tohto problému by bolo (downsampling) - zníženie vzorkovacej frekvencie signálu. Pomocou downsamplingu môžeme „zmenšiť“ na väčší časový rozsah a zachovať rovnaký počet vzoriek, pričom dopyty budú stále citlivé.
Prevzorkovanie starých údajov je nevyhnutnou požiadavkou akéhokoľvek riešenia dlhodobého ukladania a presahuje rámec vanilla Prometheus.
Ďalšie ciele
Jedným z pôvodných cieľov projektu Thanos bola bezproblémová integrácia s akýmikoľvek existujúcimi inštaláciami Prometheus. Druhým cieľom bola jednoduchá obsluha s minimálnymi prekážkami vstupu. Akékoľvek závislosti by mali byť ľahko uspokojené pre malých aj veľkých používateľov, čo tiež znamená nízke základné náklady.
Architektúra Thanos
Po vymenovaní našich cieľov v predchádzajúcej časti sa nimi prepracujme a uvidíme, ako Thanos tieto problémy rieši.
Globálny pohľad
Ak chcete získať globálny pohľad na existujúce inštancie Prometheus, musíme prepojiť jeden vstupný bod žiadosti so všetkými servermi. Presne to robí komponent Thanos. . Je nasadený vedľa každého servera Prometheus a funguje ako proxy, ktorý poskytuje miestne údaje Prometheus prostredníctvom rozhrania gRPC Store API, čo umožňuje získavanie údajov o časových radoch podľa značky a časového rozsahu.
Na druhej strane je škálovateľný, bezstavový komponent Querier, ktorý robí o niečo viac, než len odpovedá na otázky PromQL cez štandardné Prometheus HTTP API. Querier, Sidecar a ďalšie komponenty Thanos komunikujú cez .
- Querier sa po prijatí požiadavky pripojí k príslušnému serveru API obchodu, teda k našim Sidecars a dostane údaje o časových radoch z príslušných serverov Prometheus.
- Potom skombinuje odpovede a vykoná na nich dotaz PromQL. Querier dokáže zlúčiť nesúvislé údaje aj duplicitné údaje zo serverov Prometheus HA.
Toto rieši hlavný kúsok našej skladačky – spojenie údajov z izolovaných serverov Prometheus do jedného zobrazenia. V skutočnosti môže byť Thanos použitý iba pre túto funkciu. Na existujúcich serveroch Prometheus nie je potrebné vykonávať žiadne zmeny!
Neobmedzená trvanlivosť!
Skôr či neskôr však budeme chcieť ukladať údaje nad rámec bežného času uchovávania Prometheus. Na ukladanie historických údajov sme zvolili objektové úložisko. Je široko dostupný v akomkoľvek cloude, ako aj v lokálnych dátových centrách a je veľmi nákladovo efektívny. Okrem toho je takmer akékoľvek úložisko objektov dostupné cez známe S3 API.
Prometheus zapisuje dáta z RAM na disk približne každé dve hodiny. Uložený dátový blok obsahuje všetky dáta na pevne stanovený čas a je nemenný. To je veľmi výhodné, pretože Thanos Sidecar sa môže jednoducho pozrieť do adresára údajov Prometheus a keď budú k dispozícii nové bloky, načítať ich do zásobníkov na ukladanie objektov.
Načítanie do úložiska objektov ihneď po zápise na disk tiež umožňuje zachovať jednoduchosť škrabky (Prometheus a Thanos Sidecar). Čo zjednodušuje podporu, náklady a návrh systému.
Ako vidíte, zálohovanie dát je veľmi jednoduché. Ale čo dopytovanie údajov v objektovom úložisku?
Komponent Thanos Store funguje ako proxy na získavanie údajov z úložiska objektov. Rovnako ako Thanos Sidecar sa podieľa na klastri klebiet a implementuje Store API. Týmto spôsobom s ním môže existujúci Querier zaobchádzať ako so sajdkárom, ako s ďalším zdrojom údajov časových radov – nevyžaduje sa žiadna špeciálna konfigurácia.
Dátové bloky časových radov pozostávajú z niekoľkých veľkých súborov. Ich načítanie na požiadanie by bolo dosť neefektívne a ich lokálne ukladanie do vyrovnávacej pamäte by vyžadovalo obrovské množstvo pamäte a miesta na disku.
Namiesto toho Store Gateway vie, ako zaobchádzať s formátom úložiska Prometheus. Vďaka inteligentnému plánovaču dotazov a cachovaniu iba nevyhnutných indexových častí blokov je možné zredukovať zložité dotazy na minimálny počet HTTP požiadaviek na súbory úložiska objektov. Týmto spôsobom môžete znížiť počet požiadaviek o štyri až šesť rádov a dosiahnuť časy odozvy, ktoré je vo všeobecnosti ťažké rozlíšiť od požiadaviek na údaje na lokálnom SSD.
Ako je znázornené na vyššie uvedenom diagrame, Thanos Querier výrazne znižuje náklady na dotaz na údaje o ukladaní objektov využívaním formátu úložiska Prometheus a umiestnením súvisiacich údajov vedľa seba. Pomocou tohto prístupu môžeme spojiť veľa jednotlivých požiadaviek do minimálneho počtu hromadných operácií.
Zhutňovanie a prevzorkovanie
Akonáhle je nový blok údajov časových radov úspešne načítaný do objektového úložiska, zaobchádzame s ním ako s „historickými“ údajmi, ktoré sú okamžite dostupné cez Store Gateway.
Po určitom čase sa však bloky z jedného zdroja (Prometheus so Sidecar) nahromadia a už nevyužívajú plný potenciál indexovania. Na vyriešenie tohto problému sme predstavili ďalší komponent s názvom Compactor. Jednoducho aplikuje Prometheusov lokálny komprimačný mechanizmus na historické dáta v objektovom úložisku a môže byť spustený ako jednoduchá periodická dávková úloha.
Vďaka efektívnej kompresii nepredstavuje dlhodobé dopytovanie úložiska problém z hľadiska veľkosti dát. Potenciálne náklady na rozbalenie miliardy hodnôt a ich spustenie cez procesor dotazov však nevyhnutne povedie k dramatickému predĺženiu času vykonania dotazu. Na druhej strane, keďže na obrazovke sú stovky údajových bodov na pixel, nie je možné ani vizualizovať údaje v plnom rozlíšení. Prevzorkovanie je teda nielen možné, ale nepovedie ani k výraznej strate presnosti.
Na prevzorkovanie údajov Compactor nepretržite agreguje údaje s rozlíšením päť minút a jednu hodinu. Pre každý nespracovaný kus zakódovaný pomocou kompresie TSDB XOR sa ukladajú rôzne typy súhrnných údajov, ako napríklad minimum, maximum alebo súčet pre jeden blok. To umožňuje Querieru automaticky vybrať agregát, ktorý je vhodný pre daný dotaz PromQL.
Na používanie údajov so zníženou presnosťou nie je potrebná žiadna špeciálna konfigurácia. Querier automaticky prepína medzi rôznymi rozlíšeniami a nespracovanými dátami, keď používateľ približuje a odďaľuje. V prípade potreby to môže používateľ ovládať priamo cez parameter „krok“ v požiadavke.
Keďže náklady na uloženie jedného GB sú nízke, Thanos štandardne ukladá nespracované dáta, päťminútové a jednohodinové rozlíšenie. Nie je potrebné vymazávať pôvodné údaje.
Pravidlá nahrávania
Aj v prípade Thanosa sú pravidlá nahrávania nevyhnutnou súčasťou monitorovacieho zásobníka. Znižujú zložitosť, latenciu a náklady na dopyty. Sú tiež vhodné pre používateľov na získanie agregovaných údajov podľa metrík. Thanos je založený na vanilkových inštanciách Prometheus, takže je úplne prijateľné ukladať pravidlá nahrávania a pravidlá varovania na existujúcom serveri Prometheus. V niektorých prípadoch to však nemusí stačiť:
- Globálne upozornenie a pravidlo (napríklad upozornenie, keď služba nefunguje na viac ako dvoch z troch klastrov).
- Pravidlo pre údaje mimo lokálneho úložiska.
- Túžba uložiť všetky pravidlá a upozornenia na jednom mieste.
Pre všetky tieto prípady Thanos obsahuje samostatný komponent s názvom Ruler, ktorý počíta pravidlá a výstrahy prostredníctvom Thanos Queries. Poskytnutím dobre známeho StoreAPI môže uzol Query pristupovať k čerstvo vypočítaným metrikám. Neskôr sú tiež uložené v objektovom úložisku a sprístupnené cez Store Gateway.
Sila Thanosa
Thanos je dostatočne flexibilný na to, aby bol prispôsobený vašim potrebám. To je užitočné najmä pri migrácii z obyčajného Promethea. Poďme si rýchlo zrekapitulovať, čo sme sa o komponentoch Thanos naučili, na rýchlom príklade. Tu je návod, ako preniesť svoj vanilkový Prometheus do sveta „neobmedzeného ukladania metrík“:
- Pridajte Thanos Sidecar na svoje servery Prometheus – napríklad kontajner postranného vozíka v Kubernetes pod.
- Nasaďte viacero replík Thanos Querier, aby ste mohli prezerať údaje. V tejto fáze je ľahké nastaviť klebety medzi Scraper a Querier. Ak chcete skontrolovať interakciu komponentov, použite metriku „thanos_cluster_members“.
Len tieto dva kroky stačia na poskytnutie globálneho pohľadu a bezproblémovej deduplikácie údajov z potenciálnych replík Prometheus HA! Jednoducho pripojte svoje dashboardy ku koncovému bodu Querier HTTP alebo použite priamo používateľské rozhranie Thanos.
Ak však požadujete zálohovanie metrík a dlhodobé ukladanie, budete musieť vykonať tri ďalšie kroky:
- Vytvorte vedro AWS S3 alebo GCS. Nakonfigurujte Sidecar na kopírovanie údajov do týchto segmentov. Miestne ukladanie dát je teraz možné minimalizovať.
- Nasaďte Store Gateway a pripojte ju k vášmu existujúcemu klastru klebiet. Teraz môžete vyhľadávať zálohované údaje!
- Nasaďte Compactor, aby ste zlepšili efektívnosť dopytov počas dlhých časových období pomocou zhutňovania a prevzorkovania.
Ak chcete vedieť viac, neváhajte a pozrite si naše и !
Len v piatich krokoch sme premenili Prometheus na spoľahlivý monitorovací systém s globálnym prehľadom, neobmedzeným časom ukladania a potenciálnou vysokou dostupnosťou metrík.
Vytiahnite požiadavku: Potrebujeme vás!
je od samého začiatku projektom s otvoreným zdrojovým kódom. Bezproblémová integrácia s Prometheus a schopnosť používať len časť Thanos z neho robí vynikajúcu voľbu pre jednoduché škálovanie vášho monitorovacieho systému.
Vždy vítame požiadavky a problémy GitHub Pull. Medzitým nás neváhajte kontaktovať prostredníctvom Github Issues alebo slackak máte otázky alebo spätnú väzbu alebo sa chcete podeliť o svoje skúsenosti s používaním! Ak sa vám páči, čo robíme v Improbable, neváhajte nás kontaktovať - !
Zdroj: hab.com