Překlad článku byl připraven speciálně pro studenty kurzu .
je vývojář softwaru, fanatik Go a řešitel problémů. Je také správcem Prometheus a spoluzakladatelem instrumentace Kubernetes SIG. V minulosti byl produkčním inženýrem ve společnosti SoundCloud a vedl monitorovací tým v CoreOS. V současné době pracuje ve společnosti Google.
- Infrastructure Engineer ve společnosti Improbable. Zajímá se o nové technologie a problémy distribuovaných systémů. Má zkušenosti s programováním na nízké úrovni ve společnosti Intel, zkušenosti s přispěvatelem ve společnosti Mesos a zkušenosti s výrobou SRE světové třídy ve společnosti Improbable. Věnuje se zlepšování světa mikroslužeb. Jeho tři lásky: Golang, open source a volejbal.
Když se podíváte na náš vlajkový produkt SpatialOS, můžete uhodnout, že Improbable vyžaduje vysoce dynamickou globální cloudovou infrastrukturu s desítkami clusterů Kubernetes. Jako jedni z prvních jsme použili monitorovací systém . Prometheus je schopen sledovat miliony metrik v reálném čase a přichází s výkonným dotazovacím jazykem, který vám umožňuje extrahovat informace, které potřebujete.
Jednoduchost a spolehlivost Prometheus je jednou z jeho hlavních výhod. Jakmile jsme však překročili určité měřítko, narazili jsme na několik nevýhod. K vyřešení těchto problémů jsme vyvinuli je projekt s otevřeným zdrojovým kódem vytvořený společností Improbable za účelem bezproblémové transformace stávajících clusterů Prometheus do jediného monitorovacího systému s neomezeným ukládáním historických dat. Thanos je k dispozici na Github .
Naše cíle s Thanosem
V určitém měřítku vznikají problémy, které jsou nad možnosti vanilkového Promethea. Jak spolehlivě a ekonomicky ukládat petabajty historických dat? Lze to udělat bez kompromisů v době odezvy? Je možné přistupovat ke všem metrikám umístěným na různých serverech Prometheus pomocí jediného požadavku API? Existuje nějaký způsob, jak zkombinovat replikovaná data shromážděná pomocí Prometheus HA?
Abychom tyto problémy vyřešili, vytvořili jsme Thanos. Následující části popisují, jak jsme k těmto problémům přistupovali, a vysvětlují naše cíle.
Dotazování dat z více instancí Prometheus (globální dotaz)
Prometheus nabízí funkční přístup ke shardingu. Dokonce i jediný server Prometheus poskytuje dostatečnou škálovatelnost, aby uživatele osvobodil od složitosti horizontálního shardingu téměř ve všech případech použití.
I když se jedná o skvělý model nasazení, je často nutné přistupovat k datům na různých serverech Prometheus prostřednictvím jediného rozhraní API nebo uživatelského rozhraní – globální pohled. Samozřejmě je možné zobrazit více dotazů v jednom panelu Grafana, ale každý dotaz lze provést pouze na jednom serveru Prometheus. Na druhou stranu s Thanosem můžete dotazovat a agregovat data z více serverů Prometheus, protože jsou všechny dostupné z jednoho koncového bodu.
Dříve, abychom získali globální pohled na Nepravděpodobné, uspořádali jsme naše instance Prometheus do víceúrovňových . To znamenalo vytvořit jeden meta server Prometheus, který shromažďuje některé metriky z každého listového serveru.
Tento přístup se ukázal jako problematický. To vedlo ke složitějším konfiguracím, přidání dalšího potenciálního bodu selhání a použití složitých pravidel, aby bylo zajištěno, že federovaný koncový bod obdrží pouze data, která potřebuje. Kromě toho vám tento druh federace neumožňuje získat skutečný globální pohled, protože ne všechna data jsou dostupná z jednoho požadavku API.
S tím úzce souvisí jednotný pohled na data shromážděná na high-availability (HA) serverech Prometheus. Model HA společnosti Prometheus nezávisle shromažďuje data dvakrát, což je tak jednoduché, že už to jednodušší být nemůže. Mnohem pohodlnější by však bylo použití kombinovaného a deduplikovaného pohledu na oba proudy.
Samozřejmě jsou potřeba vysoce dostupné servery Prometheus. V Improbable bereme sledování minut po minutě opravdu vážně, ale mít jednu instanci Prometheus na cluster je jediným bodem selhání. Jakákoli chyba konfigurace nebo selhání hardwaru může potenciálně vést ke ztrátě důležitých dat. I jednoduché nasazení může způsobit menší narušení shromažďování metrik, protože restartování může být výrazně delší než interval stírání.
Spolehlivé ukládání historických dat
Levné, rychlé a dlouhodobé ukládání metrik je náš sen (sdílený většinou uživatelů Prometheus). V Nepravděpodobném jsme byli nuceni nakonfigurovat dobu uchování metrik na devět dní (pro Prometheus 1.8). To přidává zjevné limity, jak daleko zpět se můžeme podívat.
Prometheus 2.0 se v tomto ohledu zlepšil, protože počet časových řad již neovlivňuje celkový výkon serveru (viz. ). Prometheus však ukládá data na lokální disk. Přestože vysoce účinná komprese dat může výrazně snížit místní využití SSD, v konečném důsledku stále existuje omezení množství historických dat, která lze uložit.
V Improbable nám navíc záleží na spolehlivosti, jednoduchosti a ceně. Velké lokální disky se obtížněji obsluhují a zálohují. Jsou dražší a vyžadují více zálohovacích nástrojů, což vede ke zbytečné složitosti.
Převzorkování
Jakmile jsme začali pracovat s historickými daty, uvědomili jsme si, že s big-O jsou zásadní potíže, které zpomalují a zpomalují dotazy, když pracujeme s týdny, měsíci a roky dat.
Standardní řešení tohoto problému by bylo (downsampling) - snížení vzorkovací frekvence signálu. S downsamplingem můžeme „zmenšit“ na větší časový rozsah a zachovat stejný počet vzorků, přičemž dotazy budou reagovat.
Převzorkování starých dat je nevyhnutelným požadavkem jakéhokoli řešení dlouhodobého úložiště a je mimo rozsah vanilla Prometheus.
Další cíle
Jedním z původních cílů projektu Thanos byla bezproblémová integrace s jakýmikoli existujícími instalacemi Prometheus. Druhým cílem byla snadná obsluha s minimálními překážkami vstupu. Jakékoli závislosti by měly být snadno uspokojeny pro malé i velké uživatele, což také znamená nízké základní náklady.
Architektura Thanos
Po vyjmenování našich cílů v předchozí části se k nim pojďme propracovat a podívat se, jak Thanos tyto problémy řeší.
Globální pohled
Abychom získali globální pohled na existující instance Prometheus, musíme propojit jeden vstupní bod požadavku se všemi servery. Přesně to dělá komponenta Thanos. . Je nasazen vedle každého serveru Prometheus a funguje jako proxy a obsluhuje místní data Prometheus prostřednictvím rozhraní gRPC Store API, což umožňuje získávat data časových řad podle značky a časového rozsahu.
Na druhé straně je škálovatelná, bezstavová komponenta Querier, která dělá jen málo více než jen odpovídá na dotazy PromQL prostřednictvím standardního Prometheus HTTP API. Querier, Sidecar a další komponenty Thanos komunikují přes .
- Querier se po obdržení požadavku připojí k odpovídajícímu serveru Store API, tedy k našim Sidecars a obdrží data časových řad z odpovídajících serverů Prometheus.
- Poté zkombinuje odpovědi a provede na ně dotaz PromQL. Querier dokáže sloučit jak nesouvislá data, tak duplicitní data ze serverů Prometheus HA.
Tím je vyřešen hlavní kousek naší skládačky – spojení dat z izolovaných serverů Prometheus do jediného pohledu. Ve skutečnosti lze Thanos použít pouze pro tuto funkci. Na stávajících serverech Prometheus není třeba provádět žádné změny!
Neomezená trvanlivost!
Dříve nebo později však budeme chtít ukládat data nad rámec běžné doby uchování Prometheus. Pro ukládání historických dat jsme zvolili objektové úložiště. Je široce dostupný v jakémkoli cloudu i v místních datových centrech a je velmi nákladově efektivní. Kromě toho je téměř jakékoli úložiště objektů dostupné prostřednictvím známého S3 API.
Prometheus zapisuje data z RAM na disk přibližně každé dvě hodiny. Uložený datový blok obsahuje všechna data po pevně stanovenou dobu a je neměnný. To je velmi výhodné, protože Thanos Sidecar se může jednoduše podívat do datového adresáře Prometheus a jakmile budou k dispozici nové bloky, načíst je do zásobníků pro ukládání objektů.
Načítání do objektového úložiště ihned po zápisu na disk také umožňuje zachovat jednoduchost scraperu (Prometheus a Thanos Sidecar). Což zjednodušuje podporu, náklady a návrh systému.
Jak vidíte, zálohování dat je velmi jednoduché. Ale co dotazování na data v úložišti objektů?
Komponenta Thanos Store funguje jako proxy pro načítání dat z úložiště objektů. Stejně jako Thanos Sidecar se účastní klastru drby a implementuje Store API. Tímto způsobem s ním může stávající Querier zacházet jako se sajdkárou, jako s dalším zdrojem dat časových řad – není potřeba žádná speciální konfigurace.
Datové bloky časových řad se skládají z několika velkých souborů. Jejich načítání na vyžádání by bylo značně neefektivní a jejich místní ukládání do mezipaměti by vyžadovalo obrovské množství paměti a místa na disku.
Místo toho Store Gateway ví, jak zacházet s formátem úložiště Prometheus. Díky chytrému plánovači dotazů a cachování pouze nezbytných indexových částí bloků je možné zredukovat složité dotazy na minimální počet HTTP požadavků na soubory úložiště objektů. Tímto způsobem můžete snížit počet požadavků o čtyři až šest řádů a dosáhnout doby odezvy, kterou je obecně obtížné odlišit od požadavků na data na lokálním SSD.
Jak ukazuje výše uvedený diagram, Thanos Querier výrazně snižuje náklady na dotaz na data úložiště objektů tím, že využívá formát úložiště Prometheus a umísťuje související data vedle sebe. Pomocí tohoto přístupu můžeme spojit mnoho jednotlivých požadavků do minimálního počtu hromadných operací.
Zhutňování a převzorkování
Jakmile je nový blok dat časové řady úspěšně načten do objektového úložiště, zacházíme s ním jako s „historickými“ daty, která jsou okamžitě dostupná prostřednictvím brány obchodu.
Po nějaké době se však bloky z jednoho zdroje (Prometheus se Sidecar) hromadí a již nevyužívají plný potenciál indexování. Abychom tento problém vyřešili, představili jsme další komponent s názvem Compactor. Jednoduše aplikuje Prometheusův lokální komprimační stroj na historická data v objektovém úložišti a může být spouštěn jako jednoduchá periodická dávková úloha.
Díky efektivní kompresi nepředstavuje dlouhodobé dotazování úložiště z hlediska velikosti dat problém. Potenciální náklady na rozbalení miliardy hodnot a jejich spuštění prostřednictvím procesoru dotazů však nevyhnutelně povedou k dramatickému prodloužení doby provádění dotazu. Na druhou stranu, protože na obrazovce jsou stovky datových bodů na pixel, je nemožné dokonce vizualizovat data v plném rozlišení. Převzorkování je tedy nejen možné, ale také nepovede ke znatelné ztrátě přesnosti.
Pro převzorkování dat Compactor nepřetržitě agreguje data s rozlišením pěti minut a jedné hodiny. Pro každý nezpracovaný blok zakódovaný pomocí komprese TSDB XOR jsou uloženy různé typy agregovaných dat, jako je min, max nebo součet pro jeden blok. To umožňuje Querieru automaticky vybrat agregát, který je vhodný pro daný dotaz PromQL.
Pro použití dat se sníženou přesností není vyžadována žádná speciální konfigurace. Querier automaticky přepíná mezi různými rozlišeními a nezpracovanými daty, jak uživatel přibližuje a oddaluje. V případě potřeby to může uživatel ovládat přímo pomocí parametru „krok“ v požadavku.
Vzhledem k tomu, že náklady na uložení jednoho GB jsou nízké, ve výchozím nastavení Thanos ukládá nezpracovaná data, pětiminutová a jednohodinová data v rozlišení. Původní data není třeba mazat.
Pravidla nahrávání
I u Thanose jsou pravidla nahrávání nezbytnou součástí monitorovacího zásobníku. Snižují složitost, latenci a náklady na dotazy. Jsou také vhodné pro uživatele k získávání agregovaných dat podle metrik. Thanos je založen na vanilkových instancích Prometheus, takže je naprosto přijatelné ukládat pravidla nahrávání a pravidla upozornění na existující server Prometheus. V některých případech to však nemusí stačit:
- Globální výstraha a pravidlo (například výstraha, když služba nefunguje na více než dvou ze tří clusterů).
- Pravidlo pro data mimo místní úložiště.
- Touha ukládat všechna pravidla a upozornění na jednom místě.
Pro všechny tyto případy Thanos obsahuje samostatnou komponentu nazvanou Ruler, která vypočítává pravidla a výstrahy prostřednictvím Thanos Queries. Poskytnutím dobře známého StoreAPI může uzel Query přistupovat k čerstvě vypočítaným metrikám. Později jsou také uloženy v úložišti objektů a zpřístupněny prostřednictvím brány obchodu.
Síla Thanose
Thanos je dostatečně flexibilní, aby jej bylo možné přizpůsobit vašim potřebám. To je užitečné zejména při migraci z prostého Promethea. Pojďme si rychle zrekapitulovat, co jsme se o komponentách Thanos dozvěděli, na rychlém příkladu. Zde je návod, jak přenést svůj vanilkový Prometheus do světa „neomezeného úložiště metrik“:
- Přidejte Thanos Sidecar na své servery Prometheus – například kontejner postranního vozíku v modulu Kubernetes.
- Nasaďte více replik Thanos Querier, abyste mohli prohlížet data. V této fázi je snadné nastavit drby mezi Scraper a Querier. Chcete-li zkontrolovat interakci komponent, použijte metriku 'thanos_cluster_members'.
Pouze tyto dva kroky stačí k zajištění globálního pohledu a bezproblémové deduplikace dat z potenciálních replik Prometheus HA! Jednoduše připojte své dashboardy ke koncovému bodu Querier HTTP nebo použijte přímo uživatelské rozhraní Thanos.
Pokud však požadujete zálohu metrik a dlouhodobé úložiště, budete muset provést tři další kroky:
- Vytvořte kbelík AWS S3 nebo GCS. Nakonfigurujte Sidecar pro kopírování dat do těchto segmentů. Místní úložiště dat lze nyní minimalizovat.
- Nasaďte Store Gateway a připojte ji ke svému stávajícímu clusteru drby. Nyní se můžete dotazovat na zálohovaná data!
- Nasazením Compactoru zlepšíte efektivitu dotazů po dlouhou dobu pomocí komprimace a downsamplingu.
Pokud se chcete dozvědět více, neváhejte se na nás podívat и !
V pouhých pěti krocích jsme proměnili Prometheus ve spolehlivý monitorovací systém s globálním přehledem, neomezenou dobou ukládání a potenciální vysokou dostupností metrik.
Vytáhněte žádost: potřebujeme vás!
byl od samého počátku projektem s otevřeným zdrojovým kódem. Bezproblémová integrace s Prometheus a možnost používat jen část Thanos z něj činí vynikající volbu pro snadné škálování vašeho monitorovacího systému.
Vždy vítáme požadavky a problémy GitHub Pull. Mezitím nás neváhejte kontaktovat prostřednictvím Github Issues nebo slackpokud máte dotazy nebo zpětnou vazbu nebo se chcete podělit o své zkušenosti s používáním! Pokud se vám líbí, co děláme v Improbable, neváhejte nás kontaktovat - !
Zdroj: www.habr.com