Översättningen av artikeln förbereddes speciellt för kursens studenter .
är en mjukvaruutvecklare, Go-fanatiker och problemlösare. Han är också Prometheus-underhållare och medgrundare av Kubernetes SIG-instrumentering. Tidigare var han produktionsingenjör på SoundCloud och ledde övervakningsteamet på CoreOS. Jobbar för närvarande på Google.
- Infrastrukturingenjör på Improbable. Han är intresserad av nya teknologier och problem med distribuerade system. Han har erfarenhet av programmering på låg nivå på Intel, erfarenhet av bidragsgivare på Mesos och erfarenhet av SRE-produktion i världsklass på Improbable. Dedikerad till att förbättra världen av mikrotjänster. Hans tre kärlekar: Golang, öppen källkod och volleyboll.
När du tittar på vår flaggskeppsprodukt SpatialOS kan du gissa att Improbable kräver en mycket dynamisk, global molninfrastruktur med dussintals Kubernetes-kluster. Vi var en av de första som använde ett övervakningssystem . Prometheus kan spåra miljontals mätvärden i realtid och kommer med ett kraftfullt frågespråk som låter dig extrahera den information du behöver.
Enkelheten och tillförlitligheten hos Prometheus är en av dess främsta fördelar. Men när vi väl kom förbi en viss skala stötte vi på flera nackdelar. För att lösa dessa problem har vi utvecklat är ett öppen källkodsprojekt skapat av Improbable för att sömlöst omvandla befintliga Prometheus-kluster till ett enda övervakningssystem med obegränsad historisk datalagring. Thanos är tillgängligt på Github .
Våra mål med Thanos
I en viss skala uppstår problem som ligger utanför vanilj Prometheus förmåga. Hur lagrar man på ett tillförlitligt och ekonomiskt sätt petabyte av historisk data? Kan detta göras utan att kompromissa med svarstiden? Är det möjligt att komma åt alla mätvärden som finns på olika Prometheus-servrar med en enda API-begäran? Finns det något sätt att kombinera replikerad data som samlats in med Prometheus HA?
För att lösa dessa problem skapade vi Thanos. Följande avsnitt beskriver hur vi närmade oss dessa frågor och förklarar våra mål.
Fråga efter data från flera Prometheus-instanser (global fråga)
Prometheus erbjuder ett funktionellt tillvägagångssätt för skärning. Till och med en enda Prometheus-server ger tillräckligt med skalbarhet för att befria användare från komplexiteten med horisontell sönderdelning i nästan alla användningsfall.
Även om detta är en utmärkt implementeringsmodell, är det ofta nödvändigt att komma åt data på olika Prometheus-servrar genom ett enda API eller UI - en global vy. Naturligtvis är det möjligt att visa flera frågor i en Grafana-panel, men varje fråga kan endast köras på en Prometheus-server. Å andra sidan, med Thanos kan du fråga och aggregera data från flera Prometheus-servrar eftersom de alla är tillgängliga från en enda slutpunkt.
Tidigare, för att få en global överblick i Improbable, organiserade vi våra Prometheus-instanser i en multi-level . Detta innebar att skapa en Prometheus-metaserver som samlar in en del av mätvärdena från varje bladserver.
Detta tillvägagångssätt visade sig vara problematiskt. Detta har resulterat i mer komplexa konfigurationer, tillägg av ytterligare en potentiell felpunkt och tillämpning av komplexa regler för att säkerställa att den federerade slutpunkten bara får den data den behöver. Dessutom tillåter den här typen av federation dig inte att få en sann global vy, eftersom inte all data är tillgänglig från en enda API-förfrågan.
Nära relaterat till detta är en enhetlig vy av data som samlas in på Prometheus-servrar med hög tillgänglighet (HA). Prometheus HA-modell samlar in data två gånger oberoende, vilket är så enkelt att det inte kunde vara enklare. Men att använda en kombinerad och deduplicerad vy av båda strömmarna skulle vara mycket bekvämare.
Naturligtvis finns det ett behov av högt tillgängliga Prometheus-servrar. På Improbable tar vi minut för minut dataövervakning på allvar, men att ha en Prometheus-instans per kluster är en enda punkt av misslyckande. Alla konfigurationsfel eller maskinvarufel kan potentiellt leda till förlust av viktig data. Även en enkel implementering kan orsaka mindre störningar i mätinsamlingen eftersom omstarter kan vara betydligt längre än skrapningsintervallet.
Tillförlitlig lagring av historisk data
Billig, snabb, långsiktig lagring av mätvärden är vår dröm (delas av de flesta Prometheus-användare). I Improbable tvingades vi konfigurera lagringsperioden för mätvärden till nio dagar (för Prometheus 1.8). Detta lägger till uppenbara gränser för hur långt tillbaka vi kan titta.
Prometheus 2.0 har förbättrats i detta avseende, eftersom antalet tidsserier inte längre påverkar serverns totala prestanda (se. ). Prometheus lagrar dock data på lokal disk. Även om högeffektiv datakomprimering avsevärt kan minska lokal SSD-användning, finns det i slutändan fortfarande en gräns för mängden historisk data som kan lagras.
Dessutom bryr vi oss på Improbable om tillförlitlighet, enkelhet och kostnad. Stora lokala diskar är svårare att använda och säkerhetskopiera. De kostar mer och kräver fler säkerhetskopieringsverktyg, vilket resulterar i onödig komplexitet.
Nedsampling
När vi väl började arbeta med historisk data insåg vi att det finns grundläggande svårigheter med big-O som gör frågorna långsammare och långsammare när vi arbetar med veckor, månader och år av data.
Standardlösningen på detta problem skulle vara (nedsampling) - minskar signalsamplingsfrekvensen. Med nedsampling kan vi "skala ner" till ett större tidsintervall och behålla samma antal samplingar, vilket gör att frågorna blir responsiva.
Nedsampling av gamla data är ett oundvikligt krav för alla långsiktiga lagringslösningar och ligger utanför vanilj Prometheus.
Ytterligare mål
Ett av de ursprungliga målen med Thanos-projektet var att sömlöst integreras med alla befintliga Prometheus-installationer. Det andra målet var enkel drift med minimala hinder för inträde. Eventuella beroenden ska enkelt kunna tillgodoses för både små och stora användare, vilket också innebär en låg baskostnad.
Thanos arkitektur
Efter att ha listat våra mål i föregående avsnitt, låt oss gå igenom dem och se hur Thanos löser dessa problem.
Global vy
För att få en global översikt över befintliga Prometheus-instanser måste vi länka en enda begärandentrépunkt till alla servrar. Det är precis vad Thanos-komponenten gör. . Den distribueras bredvid varje Prometheus-server och fungerar som en proxy, och serverar lokal Prometheus-data via gRPC Store API, vilket gör att tidsseriedata kan hämtas efter tagg och tidsintervall.
På andra sidan finns den utskalade, tillståndslösa Querier-komponenten, som gör lite mer än att bara svara på PromQL-frågor via Prometheus standard HTTP API. Querier, Sidecar och andra Thanos-komponenter kommunicerar via .
- Querier, vid mottagande av en begäran, ansluter till motsvarande Store API-server, det vill säga till våra Sidecars och tar emot tidsseriedata från motsvarande Prometheus-servrar.
- Efter det kombinerar den svaren och kör en PromQL-fråga på dem. Querier kan slå samman både osammanhängande data och duplicerade data från Prometheus HA-servrar.
Detta löser en stor del av vårt pussel - att kombinera data från isolerade Prometheus-servrar till en enda vy. Faktum är att Thanos bara kan användas för denna funktion. Inga ändringar behöver göras på befintliga Prometheus-servrar!
Obegränsad hållbarhet!
Men förr eller senare kommer vi att vilja lagra data utöver den normala lagringstiden för Prometheus. Vi valde objektlagring för att lagra historisk data. Det är allmänt tillgängligt i alla moln såväl som i lokala datacenter och är mycket kostnadseffektivt. Dessutom är nästan vilken objektlagring som helst tillgänglig genom det välkända S3 API.
Prometheus skriver data från RAM till disk ungefär varannan timme. Det lagrade datablocket innehåller all data under en bestämd tidsperiod och är oföränderlig. Detta är mycket bekvämt eftersom Thanos Sidecar helt enkelt kan titta på Prometheus datakatalog och, när nya block blir tillgängliga, ladda dem i objektlagringshinkar.
Om du laddar in i objektlagring direkt efter att du har skrivit till disk kan du också behålla enkelheten hos skrapan (Prometheus och Thanos Sidecar). Vilket förenklar support, kostnad och systemdesign.
Som du kan se är säkerhetskopiering av data mycket enkel. Men hur är det med att fråga efter data i objektlagring?
Thanos Store-komponenten fungerar som en proxy för att hämta data från objektlagring. Liksom Thanos Sidecar deltar den i skvallerklustret och implementerar Store API. På så sätt kan befintlig Querier behandla den som en sidovagn, som en annan källa för tidsseriedata - ingen speciell konfiguration krävs.
Tidsseriedatablock består av flera stora filer. Att ladda dem på begäran skulle vara ganska ineffektivt, och att cachelagra dem lokalt skulle kräva en enorm mängd minne och diskutrymme.
Istället vet Store Gateway hur man hanterar Prometheus lagringsformat. Tack vare en smart frågeschemaläggare och cachning av endast nödvändiga indexdelar av block, är det möjligt att reducera komplexa frågor till ett minimum av HTTP-förfrågningar till objektlagringsfiler. På så sätt kan du minska antalet förfrågningar med fyra till sex storleksordningar och uppnå svarstider som i allmänhet är svåra att skilja från förfrågningar till data på en lokal SSD.
Som visas i diagrammet ovan, minskar Thanos Querier avsevärt kostnaden per fråga för objektlagringsdata genom att utnyttja Prometheus-lagringsformatet och placera relaterad data sida vid sida. Med detta tillvägagångssätt kan vi kombinera många enstaka förfrågningar till ett minsta antal bulkoperationer.
Packning och nedsampling
När ett nytt block med tidsseriedata väl har laddats in i objektlagring, behandlar vi det som "historiska" data, som är omedelbart tillgängliga via Store Gateway.
Men efter en tid ackumuleras block från en källa (Prometheus med sidovagn) och använder inte längre hela indexeringspotentialen. För att lösa detta problem introducerade vi en annan komponent som heter Compactor. Den tillämpar helt enkelt Prometheus lokala komprimeringsmotor på historisk data i objektlagring och kan köras som ett enkelt periodiskt batchjobb.
Tack vare effektiv komprimering utgör det inte några problem när det gäller datastorlek att efterfråga lagringen under en lång tidsperiod. Den potentiella kostnaden för att packa upp en miljard värden och köra dem genom en frågeprocessor kommer dock oundvikligen att resultera i en dramatisk ökning av exekveringstiden för frågor. Å andra sidan, eftersom det finns hundratals datapunkter per pixel på skärmen, blir det omöjligt att ens visualisera data i full upplösning. Nedsampling är alltså inte bara möjlig, utan kommer inte heller att leda till en märkbar förlust av noggrannhet.
För att nedsampla data aggregerar Compactor kontinuerligt data med en upplösning på fem minuter och en timme. För varje rå chunk som kodas med TSDB XOR-komprimering lagras olika typer av aggregerad data, såsom min, max eller summa för ett block. Detta tillåter Querier att automatiskt välja ett aggregat som är lämpligt för en given PromQL-fråga.
Ingen speciell konfiguration krävs för att användaren ska kunna använda data med reducerad precision. Querier växlar automatiskt mellan olika upplösningar och rådata när användaren zoomar in och ut. Om så önskas kan användaren styra detta direkt genom parametern "steg" i begäran.
Eftersom kostnaden för att lagra en GB är låg lagrar Thanos som standard rådata, fem minuters och en timmes upplösningsdata. Det finns inget behov av att radera originaldata.
Regler för inspelning
Även med Thanos är inspelningsregler en viktig del av övervakningsstacken. De minskar komplexiteten, latensen och kostnaden för frågor. De är också bekväma för användare att få samlad data efter mätvärden. Thanos är baserat på vanilla Prometheus-instanser, så det är helt acceptabelt att lagra inspelningsregler och varningsregler på en befintlig Prometheus-server. Men i vissa fall kanske detta inte räcker:
- Global varning och regel (till exempel en varning när en tjänst inte fungerar på mer än två av tre kluster).
- Regel för data utanför lokal lagring.
- Önskan att lagra alla regler och varningar på ett ställe.
För alla dessa fall inkluderar Thanos en separat komponent som heter Ruler, som beräknar regel och varning via Thanos Queries. Genom att tillhandahålla ett välkänt StoreAPI kan Query-noden komma åt nyberäknade mätvärden. Senare lagras de även i objektlagring och görs tillgängliga via Store Gateway.
Thanos kraft
Thanos är tillräckligt flexibel för att kunna anpassas för att passa dina behov. Detta är särskilt användbart när du migrerar från vanlig Prometheus. Låt oss snabbt sammanfatta vad vi har lärt oss om Thanos-komponenter med ett snabbt exempel. Så här tar du din vanilj Prometheus in i en värld av "obegränsad lagring av mätvärden":
- Lägg till Thanos Sidecar till dina Prometheus-servrar - till exempel en sidovagnsbehållare i en Kubernetes-pod.
- Distribuera flera Thanos Querier-repliker för att kunna se data. I detta skede är det lätt att sätta upp skvaller mellan Scraper och Querier. För att kontrollera interaktionen mellan komponenter, använd måttet 'thanos_cluster_members'.
Bara dessa två steg räcker för att ge global överblick och sömlös datadeduplicering från potentiella Prometheus HA-repliker! Anslut helt enkelt dina instrumentpaneler till Querier HTTP-slutpunkten eller använd Thanos UI direkt.
Men om du behöver säkerhetskopiering av mätvärden och långtidslagring måste du genomföra ytterligare tre steg:
- Skapa en AWS S3 eller GCS hink. Konfigurera Sidecar för att kopiera data till dessa hinkar. Lokal datalagring kan nu minimeras.
- Distribuera Store Gateway och anslut den till ditt befintliga skvallerkluster. Nu kan du fråga efter säkerhetskopierad data!
- Implementera Compactor för att förbättra frågeeffektiviteten under långa tidsperioder med hjälp av komprimering och nedsampling.
Om du vill veta mer, tveka inte att ta en titt på vår и !
På bara fem steg förvandlade vi Prometheus till ett tillförlitligt övervakningssystem med global vy, obegränsad lagringstid och potentiell hög tillgänglighet av mätvärden.
Dra begäran: vi behöver dig!
har varit ett projekt med öppen källkod från första början. Sömlös integration med Prometheus och möjligheten att använda bara en del av Thanos gör det till ett utmärkt val för att enkelt skala ditt övervakningssystem.
Vi välkomnar alltid GitHub Pull-förfrågningar och problem. Under tiden får du gärna kontakta oss via Github Issues eller slackom du har frågor eller feedback, eller vill dela med dig av din erfarenhet av att använda den! Om du gillar det vi gör på Improbable, tveka inte att kontakta oss - !
Källa: will.com