ĂversĂ€ttningen av artikeln Ă€r sĂ€rskilt utarbetad för studenter i kursen .
Àr mjukvaruutvecklare, Go-entusiast och Àlskar att lösa komplexa problem. Han Àr ocksÄ underhÄllare av Prometheus och medgrundare av Kubernetes SIG instrumentation. Tidigare var han produktionsingenjör pÄ SoundCloud och ledde ett övervakningsteam pÄ CoreOS. För nÀrvarande arbetar han pÄ Google.
Àr infrastrukturingenjör pÄ Improbable. Han Àr intresserad av ny teknik och utmaningar inom distribuerade system. Han har erfarenhet av lÄgnivÄprogrammering pÄ Intel, har bidragit till Mesos och har produktionsvana som SRE pÄ global nivÄ inom Improbable. Han arbetar med att förbÀttra vÀrlden av mikrotjÀnster. Hans tre passioner: Golang, open source och volleyboll.
Genom att titta pÄ vÄr flaggskeppsprodukt SpatialOS kan du gissa att Improbable behöver en högdynamisk molninfrastruktur pÄ global nivÄ med dussintals Kubernetes-kluster. Vi var bland de första som började anvÀnda ett övervakningssystem . Prometheus kan spÄra miljontals metrik i realtid och kommer med ett kraftfullt frÄgesprÄk som gör det möjligt att hÀmta den information som behövs.
Enkelheten och tillförlitligheten hos Prometheus Ă€r en av dess frĂ€msta fördelar. Men nĂ€r vi nĂ„tt en viss skala har vi stött pĂ„ nĂ„gra nackdelar. För att lösa dessa problem utvecklade vi â ett projekt med öppen kĂ€llkod, skapat av Improbable, för sömlös transformation av befintliga Prometheus-kluster till ett enhetligt övervakningssystem med obegrĂ€nsat lagringsutrymme för historiska data. Thanos finns tillgĂ€ngligt pĂ„ Github .
VÄra mÄl med Thanos
Vid en viss skala uppstĂ„r problem som gĂ„r bortom vad vanliga Prometheus kan hantera. Hur kan vi pĂ„ ett tillförlitligt och kostnadseffektivt sĂ€tt lagra petabyte av historiska data? Ăr det möjligt utan att kompromissa med svarstiden pĂ„ förfrĂ„gningar? Kan vi fĂ„ tillgĂ„ng till alla metrik som finns pĂ„ olika Prometheus-servrar med ett enda API-anrop? Kan vi pĂ„ nĂ„got sĂ€tt kombinera replikerade data som samlats med hjĂ€lp av Prometheus HA?
För att lösa dessa frÄgor skapade vi Thanos. I de kommande avsnitten beskriver vi hur vi angrep dessa frÄgor och förklarar mÄlen vi hade.
FörfrÄgan av data frÄn flera instanser av Prometheus (global query)
Prometheus erbjuder en funktionell strategi för sharding. Ăven en enda Prometheus-server ger tillrĂ€cklig skalbarhet för att frigöra anvĂ€ndare frĂ„n komplexiteten med horisontell sharding i praktiskt taget alla anvĂ€ndningsfall.
Ăven om detta Ă€r en utmĂ€rkt distributionsmodell, krĂ€vs det ofta Ă„tkomst till data frĂ„n olika Prometheus-servrar via ett enda API eller UI â global view. Naturligtvis finns det en möjlighet att visa flera frĂ„gor pĂ„ ett enda Grafana-panel, men varje frĂ„ga kan endast utföras pĂ„ en enda Prometheus-server. Ă andra sidan kan du med Thanos begĂ€ra och aggregera data frĂ„n flera Prometheus-servrar, eftersom alla Ă€r tillgĂ€ngliga frĂ„n en enda slutpunkt.
Tidigare, för att fÄ global view i Improbable, organiserade vi vÄra Prometheus-instanser i en flerlagers . Detta innebar att skapa en meta-server för Prometheus som samlar in vissa mÀtvÀrden frÄn varje "blad"-server.
Denna strategi visade sig vara problematisk. Det ledde till en mer komplicerad konfiguration, en extra potentiell felpunkt och anvÀndning av komplexa regler för att sÀkerstÀlla att den federerade slutpunkten endast tillhandahöll nödvÀndiga data. Dessutom tillÄter federation av detta slag inte en verklig global view, eftersom inte alla data Àr tillgÀngliga frÄn en enda API-begÀran.
Detta Àr nÀra relaterat till en enhetlig vy av data som samlats in pÄ hög tillgÀngliga (high-availability, HA) Prometheus-servrar. HA-modellen för Prometheus samlar oberoende in data tvÄ gÄnger, vilket Àr sÄ enkelt att det knappt kan bli enklare. Men att anvÀnda en sammanslagen och deduplicerad vy av bÄda flödena skulle vara mycket mer praktiskt.
SjĂ€lvklart finns det ett behov av hög tillgĂ€nglighet för Prometheus-servrar. Vi pĂ„ Improbable tar faktiskt minutlig övervakning av data pĂ„ allvar, men att ha en enda instans av Prometheus i klustret utgör en enskild felpunkt. Varje konfigurationsfel eller maskinvarufel kan potentiellt leda till förlust av viktiga data. Ăven en enkel distribution kan leda till smĂ„ avbrott i insamlingen av mĂ€tvĂ€rden, eftersom omstart kan ta betydligt lĂ€ngre tid Ă€n skrapningsintervallet.
PĂ„litlig lagring av historiska data
Billigt, snabbt och lÄngsiktigt lagring av metrik Àr vÄr dröm (delad av de flesta anvÀndare av Prometheus). PÄ Improbable var vi tvungna att stÀlla in lagringsperioden för metrik till nio dagar (för Prometheus 1.8). Detta lÀgger uppenbara begrÀnsningar pÄ hur lÄngt tillbaka vi kan titta.
Prometheus 2.0 har blivit bĂ€ttre pĂ„ det hĂ€r omrĂ„det eftersom antalet tidsserier inte lĂ€ngre pĂ„verkar den totala prestandan pĂ„ servern (se ). Trots det lagrar Prometheus data pĂ„ lokala diskar. Ăven om högpresterande datakompression kan minska anvĂ€ndningen av lokala SSD:er avsevĂ€rt, finns det Ă€ndĂ„ en grĂ€ns för mĂ€ngden historiska data som kan lagras.
Dessutom bryr vi oss pÄ Improbable om tillförlitlighet, enkelhet och kostnad. Stora lokala diskar Àr svÄrare att hantera och sÀkerhetskopiera. De Àr dyrare och krÀver fler verktyg för sÀkerhetskopiering, vilket leder till onödig komplexitet.
Nedprovning
NÀr vi började arbeta med historiska data insÄg vi att det finns fundamentala svÄrigheter med O-storlek, vilket gör förfrÄgningar lÄngsammare och lÄngsammare nÀr vi arbetar med data över veckor, mÄnader och Är.
En standardlösning pĂ„ detta problem Ă€r â att minska samplingfrekvensen av signalen. Genom att sĂ€nka samplingfrekvensen kan vi "skala ner" till ett lĂ€ngre tidsintervall och behĂ„lla samma antal prover, vilket gör att förfrĂ„gningarna förblir responsiva.
Nedprovning av gamla data Àr ett oundvikligt krav för alla lösningar för lÄngsiktig lagring och gÄr bortom vanilj-Prometheus.
Ytterligare mÄl
Ett av de ursprungliga mÄlen för Thanos-projektet var sömlös integration med alla befintliga installationer av Prometheus. Det andra mÄlet var enkel drift med minimala intrÀdesbarriÀrer. Alla beroenden bör enkelt tillfredsstÀllas bÄde för smÄ och stora anvÀndare, vilket ocksÄ innebÀr en lÄg grundkostnad.
Thanos-arkitektur
Efter att ha listat vÄra mÄl i det föregÄende avsnittet, lÄt oss arbeta med dem och se hur Thanos löser dessa problem.
Global vy
För att fÄ en global vy över befintliga Prometheus-instanser mÄste vi koppla en enhetlig ingÄngspunkt för förfrÄgningar med alla servrar. Det Àr just detta som komponenten Thanos gör. . Den distribueras bredvid varje Prometheus-server och fungerar som en proxy, som betjÀnar lokala Prometheus-data via gRPC-grÀnssnittet Store API, vilket möjliggör val av tidsseriedata baserat pÄ etiketter och tidsintervall.
à andra sidan finns en horisontellt skalbar komponent Querier utan tillstÄnd, som gör lite mer Àn att helt enkelt svara pÄ PromQL-förfrÄgningar via standard Prometheus HTTP API. Komponenterna Querier, Sidecar och andra Thanos interagerar via .
- Querier, nÀr den tar emot en förfrÄgan, ansluter till motsvarande Store API-server, det vill sÀga till vÄra Sidecar och hÀmtar tidsseriedata frÄn motsvarande Prometheus-servrar.
- DÀrefter kombinerar den svaren och utför PromQL-förfrÄgan. Querier kan kombinera bÄde icke-överlappande data och duplicerade data frÄn HA-Prometheus-servrar.
Detta löser huvuddelen av vĂ„rt pussel â att kombinera data frĂ„n isolerade Prometheus-servrar till en enhetlig vy. Faktum Ă€r att Thanos kan anvĂ€ndas enbart för denna funktion. Inga Ă€ndringar krĂ€vs pĂ„ befintliga Prometheus-servrar!
Ingen begrÀnsad lagringstid!
Men förr eller senare kommer vi att vilja spara data som gÄr utöver den normala lagringstiden för Prometheus. För lagring av historiska data valde vi objektlagring. Det Àr allmÀnt tillgÀngligt i alla moln och Àven i lokala datacenter och Àr mycket kostnadseffektivt. Dessutom Àr nÀstan all objektlagring tillgÀnglig via det vÀlkÀnda S3 API:et.
Prometheus skriver data frÄn RAM till disk ungefÀr varje tvÄ timmar. En block med sparad data innehÄller all information för en bestÀmd tidsperiod och Àr oförÀnderlig. Detta Àr vÀldigt praktiskt, eftersom Thanos Sidecar enkelt kan övervaka datakatalogen för Prometheus och, nÀr nya block dyker upp, ladda dem till objektlagringsbehÄllare.
Laddning till objektlagring omedelbart efter att de skrivits till disk gör det ocksÄ möjligt att bevara enkelheten av "skraparen" (Prometheus och Thanos Sidecar). Det förenklar underhÄll, kostnader och systemdesign.
Som ni ser Àr backup av data mycket enkelt att genomföra. Men hur Àr det med förfrÄgan om data i objektlagring?
Thanos Store-komponenten fungerar som en proxy för att hĂ€mta data frĂ„n objektlagringen. Precis som Thanos Sidecar deltar den i gossip-klustret och implementerar Store API. DĂ€rför kan befintliga Querier se den som Sidecar, som en ytterligare kĂ€lla för tidsseriedata â ingen speciel konfiguration krĂ€vs.
Tidsseriedata block bestÄr av flera stora filer. Att hÀmta dem vid behov skulle vara ganska ineffektivt, och lokalt cachelagring skulle krÀva enormt mycket minne och diskutrymme.
IstÀllet vet Store Gateway hur man hanterar Prometheus lagringsformat. Med en smart frÄgeplanerare och cachelagring av endast de nödvÀndiga indexdelarna av blocken har det blivit möjligt att minska komplexa förfrÄgningar till ett minimum av HTTP-förfrÄgningar till filer i objektlagring. PÄ sÄ sÀtt kan antalet förfrÄgningar minskas med fyra till sex ordningar och uppnÄ svarstider som överlag Àr svÄra att sÀrskilja frÄn förfrÄgningar om data pÄ lokal SSD.
Som visas i diagrammet ovan minskar Thanos Querier kostnaderna för en förfrÄgan om data i objektlagring avsevÀrt genom att anvÀnda Prometheus lagringsformat och placera relaterade data nÀra varandra. Genom att anvÀnda denna metod kan vi kombinera mÄnga separata förfrÄgningar till ett minimalt antal bulk-operationer.
Kompaktering och nedprovning
NÀr en ny tidsseriedatablock framgÄngsrikt har laddats upp till objektlagringen betraktar vi det som "historiska" data, som genast blir tillgÀngliga via Store Gateway.
Men efter en tid samlas block frÄn samma kÀlla (Prometheus med Sidecar) och utnyttjar inte lÀngre hela potentialen för indexering. För att lösa detta problem införde vi ytterligare en komponent som kallas Compactor. Den tillÀmpar helt enkelt den lokala kompakteringsmekanismen för Prometheus pÄ historiska data i objektlagringen och kan köras som ett enkelt periodiskt batchjobb.
Genom effektiv komprimering innebĂ€r en lagringsförfrĂ„gan under en lĂ€ngre tid inga problem med avseende pĂ„ datastorlek. Men de potentiella kostnaderna för att packa upp en miljard vĂ€rden och köra dem genom en förfrĂ„gningsbehandlare kommer oundvikligen att leda till en kraftig ökning av förfrĂ„gningsutförandetiden. Ă
andra sidan, eftersom varje pixel pÄ skÀrmen motsvarar hundratals datapunkter, blir det omöjligt att ens visualisera data i full upplösning. DÀrför Àr nedsampling inte bara möjlig, utan det kommer inte att leda till mÀrkbar förlust av noggrannhet.
För nedsampling av data aggregerar Compactor kontinuerligt data med upplösning om fem minuter och en timme. För varje obearbetat fragment, kodad med TSDB XOR-komprimering, lagras olika typer av aggregerade data, sÄsom min, max eller sum för en block. Detta gör det möjligt för Querier att automatiskt vÀlja aggregeringen som Àr lÀmplig för den aktuella PromQL-förfrÄgan.
För att anvÀnda data med reducerad noggrannhet krÀvs ingen sÀrskild konfiguration av anvÀndaren. Querier vÀxlar automatiskt mellan olika upplösningar och obearbetade data nÀr anvÀndaren zoomar in och ut. Om sÄ önskas kan anvÀndaren hantera detta direkt via parameter "step" i förfrÄgan.
Eftersom kostnaden för att lagra en GB Àr lÄg, sÄ sparar Thanos som standard originaldata, data med upplösning om fem minuter och en timme. Det finns ingen anledning att ta bort originaldata.
Recording rules
Ăven med Thanos Ă€r recording rules en vĂ€sentlig del av övervakningsstacken. De minskar komplexiteten, fördröjningen och kostnaderna för förfrĂ„gningar. De Ă€r ocksĂ„ bekvĂ€ma för anvĂ€ndarna att fĂ„ aggregerade data om mĂ€tvĂ€rden. Thanos bygger pĂ„ vanliga Prometheus-instans, sĂ„ det Ă€r fullt acceptabelt att lagra recording rules och alerting rules pĂ„ den befintliga Prometheus-servern. Men i vissa fall kanske detta inte Ă€r tillrĂ€ckligt:
- Globala alert och regel (till exempel, ett meddelande nÀr en tjÀnst Àr nere pÄ mer Àn tvÄ av tre kluster).
- Regeln för data utanför den lokala lagringen.
- StrÀvan att lagra alla regler och alert i ett och samma stÀlle.
För alla dessa fall inkluderar Thanos en separat komponent som kallas Ruler, som berÀknar regler och larm genom Thanos Queries. Genom att tillhandahÄlla det vÀlkÀnda StoreAPI kan Query-noden fÄ tillgÄng till nyligen berÀknade metrikvÀrden. Senare lagras dessa ocksÄ i en objektlagring och blir tillgÀngliga genom Store Gateway.
Thanos kraft
Thanos Àr tillrÀckligt flexibelt för att anpassas efter dina krav. Detta Àr sÀrskilt anvÀndbart vid migrering frÄn en enkel Prometheus. LÄt oss snabbt gÄ igenom komponenterna i Thanos med ett litet exempel. SÄ hÀr kan du överföra din vanliga Prometheus till vÀrlden av "obegrÀnsad metriklagring":
- LĂ€gg till Thanos Sidecar till dina Prometheus-servrar â till exempel, som en intilliggande container i en Kubernetes-pod.
- Distribuera flera repliker av Thanos Querier för att möjliggöra datavisning. Vid detta skede Àr det lÀtt att stÀlla in gossip mellan Scraper och Querier. AnvÀnd metrikvÀrdet 'thanos_cluster_members' för att kontrollera komponenternas interaktion.
Bara dessa tvÄ steg Àr tillrÀckliga för att sÀkerstÀlla en global vy och sömlös deduplicering av data frÄn potentiella HA-repliker av Prometheus! Anslut bara dina instrumentpaneler till HTTP-endpointen för Querier eller anvÀnd Thanos UI direkt.
Men om du behöver sÀkerhetskopiera metrik och lÄngsiktig lagring, krÀvs ytterligare tre steg:
- Skapa en AWS S3- eller GCS-bucket. StÀll in Sidecar för att kopiera data till dessa buckets. Nu kan du minimera lokal datalagring.
- Distribuera Store Gateway och anslut den till den befintliga gossip-klustret. Nu kan du skicka förfrÄgningar till data i sÀkerhetskopiorna!
- Distribuera Compactor för att öka effektiviteten för förfrÄgningar över lÀngre tidsperioder genom att anvÀnda komprimering och nedprovering.
Om du vill veta mer, tveka inte att titta pÄ vÄra och !
PÄ bara fem steg har vi omvandlat Prometheus till ett pÄlitligt övervakningssystem med global vy, obegrÀnsad lagringstid och potentiell hög tillgÀnglighet för metrik.
Pull request: vi behöver dig!
har varit ett projekt med öppen kÀllkod frÄn början. Den sömlösa integrationen med Prometheus och möjligheten att anvÀnda bara en del av Thanos gör det till ett utmÀrkt val för att skala övervakningssystemet utan onödig anstrÀngning.
Vi Ă€r alltid glada över GitHub Pull Requests och Issues. Tveka inte att kontakta oss via GitHub Issues eller Slack., om du har frĂ„gor eller feedback, eller om du vill dela din erfarenhet! Om du gillar det vi gör pĂ„ Improbable, tveka inte att höra av dig â !
KĂ€lla: habr.com
