Oversettelsen av artikkelen ble utarbeidet spesielt for studentene på kurset .
er en programvareutvikler, Go-fanatisk og problemløser. Han er også Prometheus vedlikeholder og medgründer av Kubernetes SIG instrumentering. Tidligere var han produksjonsingeniør hos SoundCloud og ledet overvåkingsteamet hos CoreOS. Jobber for tiden hos Google.
- Infrastrukturingeniør hos Improbable. Han er interessert i nye teknologier og problemer med distribuerte systemer. Han har programmeringserfaring på lavt nivå hos Intel, bidragsytererfaring hos Mesos og SRE-produksjonserfaring i verdensklasse hos Improbable. Dedikert til å forbedre verden av mikrotjenester. Hans tre kjærligheter: Golang, åpen kildekode og volleyball.
Når du ser på flaggskipproduktet vårt SpatialOS, kan du gjette at Improbable krever en svært dynamisk, global skyinfrastruktur med dusinvis av Kubernetes-klynger. Vi var en av de første som tok i bruk et overvåkingssystem . Prometheus er i stand til å spore millioner av beregninger i sanntid og kommer med et kraftig spørrespråk som lar deg trekke ut informasjonen du trenger.
Enkelheten og påliteligheten til Prometheus er en av hovedfordelene. Men når vi kom forbi en viss skala, møtte vi flere ulemper. For å løse disse problemene har vi utviklet er et åpen kildekode-prosjekt laget av Improbable for å sømløst transformere eksisterende Prometheus-klynger til et enkelt overvåkingssystem med ubegrenset lagring av historiske data. Thanos er tilgjengelig på Github .
Våre mål med Thanos
I en viss skala oppstår det problemer som er utenfor vanilje Prometheus' evner. Hvordan lagre petabyte med historiske data pålitelig og økonomisk? Kan dette gjøres uten at det går ut over responstiden? Er det mulig å få tilgang til alle beregninger som ligger på forskjellige Prometheus-servere med en enkelt API-forespørsel? Er det noen måte å kombinere replikerte data samlet inn ved hjelp av Prometheus HA?
For å løse disse problemene opprettet vi Thanos. De følgende avsnittene beskriver hvordan vi nærmet oss disse problemene og forklarer våre mål.
Spørre data fra flere Prometheus-forekomster (global spørring)
Prometheus tilbyr en funksjonell tilnærming til skjæring. Selv en enkelt Prometheus-server gir nok skalerbarhet til å frigjøre brukere fra kompleksiteten med horisontal skjæring i nesten alle brukstilfeller.
Selv om dette er en flott distribusjonsmodell, er det ofte nødvendig å få tilgang til data på forskjellige Prometheus-servere gjennom et enkelt API eller brukergrensesnitt - en global visning. Selvfølgelig er det mulig å vise flere spørringer i ett Grafana-panel, men hver spørring kan bare utføres på én Prometheus-server. På den annen side, med Thanos kan du spørre etter og samle data fra flere Prometheus-servere siden de alle er tilgjengelige fra ett enkelt endepunkt.
Tidligere, for å få et globalt syn i Improbable, organiserte vi Prometheus-forekomstene våre i et flernivå . Dette betydde å lage én Prometheus-metaserver som samler noen av beregningene fra hver bladserver.
Denne tilnærmingen viste seg å være problematisk. Dette har resultert i mer komplekse konfigurasjoner, tillegg av et ekstra potensielt feilpunkt og bruk av komplekse regler for å sikre at det forente endepunktet bare mottar dataene det trenger. I tillegg tillater ikke denne typen føderering at du får en sann global visning, siden ikke alle data er tilgjengelige fra en enkelt API-forespørsel.
Nært knyttet til dette er en enhetlig visning av dataene som samles inn på Prometheus-servere med høy tilgjengelighet (HA). Prometheus' HA-modell samler uavhengig inn data to ganger, noe som er så enkelt at det ikke kunne vært enklere. Imidlertid ville det være mye mer praktisk å bruke en kombinert og deduplisert visning av begge bekker.
Selvfølgelig er det behov for svært tilgjengelige Prometheus-servere. Hos Improbable tar vi minutt for minutt dataovervåking virkelig seriøst, men å ha én Prometheus-forekomst per klynge er et enkelt feilpunkt. Enhver konfigurasjonsfeil eller maskinvarefeil kan potensielt føre til tap av viktige data. Selv en enkel distribusjon kan forårsake mindre forstyrrelser i innsamlingen av beregninger fordi omstart kan være betydelig lengre enn skrapeintervallet.
Pålitelig lagring av historiske data
Billig, rask, langsiktig lagring av beregninger er vår drøm (delt av de fleste Prometheus-brukere). I Improbable ble vi tvunget til å konfigurere oppbevaringsperioden for beregninger til ni dager (for Prometheus 1.8). Dette legger åpenbare grenser for hvor langt tilbake vi kan se.
Prometheus 2.0 har forbedret seg i denne forbindelse, siden antall tidsserier ikke lenger påvirker den generelle ytelsen til serveren (se. ). Imidlertid lagrer Prometheus data på lokal disk. Selv om høyeffektiv datakomprimering kan redusere lokal SSD-bruk betydelig, er det til syvende og sist fortsatt en grense for mengden historiske data som kan lagres.
I tillegg bryr vi oss om pålitelighet, enkelhet og kostnad hos Improbable. Store lokale disker er vanskeligere å betjene og sikkerhetskopiere. De koster mer og krever flere sikkerhetskopieringsverktøy, noe som resulterer i unødvendig kompleksitet.
Nedsampling
Når vi begynte å jobbe med historiske data, innså vi at det er grunnleggende vanskeligheter med big-O som gjør spørringer tregere og tregere etter hvert som vi jobber med uker, måneder og år med data.
Standardløsningen på dette problemet vil være (nedsampling) - reduserer signalsamplingsfrekvensen. Med nedsampling kan vi "skalere ned" til et større tidsrom og opprettholde samme antall prøver, slik at spørringene holdes responsive.
Nedsampling av gamle data er et uunngåelig krav til enhver langsiktig lagringsløsning og er utenfor vanilje Prometheus.
Ytterligere mål
Et av de opprinnelige målene med Thanos-prosjektet var å integrere sømløst med eksisterende Prometheus-installasjoner. Det andre målet var enkel betjening med minimale adgangsbarrierer. Eventuelle avhengigheter bør enkelt tilfredsstilles for både små og store brukere, noe som også betyr en lav grunnkostnad.
Thanos arkitektur
Etter å ha listet opp målene våre i forrige seksjon, la oss gå gjennom dem og se hvordan Thanos løser disse problemene.
Global visning
For å få en global oversikt over eksisterende Prometheus-forekomster, må vi koble et enkelt forespørsels-inngangspunkt til alle servere. Dette er akkurat hva Thanos-komponenten gjør. . Den er distribuert ved siden av hver Prometheus-server og fungerer som en proxy, og serverer lokale Prometheus-data gjennom gRPC Store API, slik at tidsseriedata kan hentes etter tag og tidsrom.
På den andre siden er den utskalerte, statsløse Querier-komponenten, som gjør lite mer enn bare å svare på PromQL-spørringer via standard Prometheus HTTP API. Querier, Sidecar og andre Thanos-komponenter kommuniserer via .
- Querier, ved å motta en forespørsel, kobler seg til den tilsvarende Store API-serveren, det vil si til sidevognene våre og mottar tidsseriedata fra de tilsvarende Prometheus-serverne.
- Etter det kombinerer den svarene og utfører en PromQL-spørring på dem. Querier kan slå sammen både usammenhengende data og dupliserte data fra Prometheus HA-servere.
Dette løser en viktig del av puslespillet vårt - å kombinere data fra isolerte Prometheus-servere til en enkelt visning. Faktisk kan Thanos bare brukes til denne funksjonen. Ingen endringer trenger å gjøres på eksisterende Prometheus-servere!
Ubegrenset holdbarhet!
Før eller siden vil vi imidlertid ønske å lagre data utover den normale oppbevaringstiden for Prometheus. Vi valgte objektlagring for å lagre historiske data. Det er allment tilgjengelig i alle skyer så vel som lokale datasentre og er svært kostnadseffektivt. I tillegg er nesten hvilken som helst objektlagring tilgjengelig gjennom det velkjente S3 API.
Prometheus skriver data fra RAM til disk omtrent annenhver time. Den lagrede datablokken inneholder alle data for en fast tidsperiode og er uforanderlig. Dette er veldig praktisk fordi Thanos Sidecar ganske enkelt kan se på Prometheus-datakatalogen og, etter hvert som nye blokker blir tilgjengelige, laste dem inn i objektlagringsbøtter.
Ved å laste inn i objektlagring umiddelbart etter skriving til disk kan du også opprettholde enkelheten til skraperen (Prometheus og Thanos Sidecar). Noe som forenkler support, kostnad og systemdesign.
Som du kan se, er sikkerhetskopiering av data veldig enkelt. Men hva med å spørre etter data i objektlagring?
Thanos Store-komponenten fungerer som en proxy for å hente data fra objektlagring. I likhet med Thanos Sidecar, deltar den i sladderklyngen og implementerer Store API. På denne måten kan eksisterende Querier behandle den som en sidevogn, som en annen kilde til tidsseriedata - ingen spesiell konfigurasjon kreves.
Tidsseriedatablokker består av flere store filer. Å laste dem på forespørsel ville være ganske ineffektivt, og å bufre dem lokalt ville kreve en enorm mengde minne og diskplass.
I stedet vet Store Gateway hvordan man håndterer Prometheus-lagringsformatet. Takket være en smart spørringsplanlegger og caching av bare de nødvendige indeksdelene av blokker, er det mulig å redusere komplekse spørringer til et minimum antall HTTP-forespørsler til objektlagringsfiler. På denne måten kan du redusere antall forespørsler med fire til seks størrelsesordener og oppnå responstider som generelt er vanskelige å skille fra forespørsler til data på en lokal SSD.
Som vist i diagrammet ovenfor, reduserer Thanos Querier kostnaden per forespørsel for objektlagringsdata betydelig ved å utnytte Prometheus-lagringsformatet og plassere relaterte data side ved side. Ved å bruke denne tilnærmingen kan vi kombinere mange enkeltforespørsler til et minimum antall bulkoperasjoner.
Komprimering og nedsampling
Når en ny blokk med tidsseriedata er lastet inn i objektlagring, behandler vi den som "historiske" data, som er umiddelbart tilgjengelige gjennom Store Gateway.
Etter en tid akkumuleres imidlertid blokker fra én kilde (Prometheus med sidevogn) og bruker ikke lenger hele indekseringspotensialet. For å løse dette problemet introduserte vi en annen komponent kalt Compactor. Den bruker ganske enkelt Prometheus' lokale komprimeringsmotor til historiske data i objektlagring og kan kjøres som en enkel periodisk batchjobb.
Takket være effektiv komprimering utgjør det ikke noe problem når det gjelder datastørrelse å spørre etter lagringen over lang tid. Imidlertid vil de potensielle kostnadene ved å pakke ut en milliard verdier og kjøre dem gjennom en spørringsprosessor uunngåelig resultere i en dramatisk økning i utføringstiden for spørringen. På den annen side, siden det er hundrevis av datapunkter per piksel på skjermen, blir det umulig å visualisere dataene i full oppløsning. Dermed er nedsampling ikke bare mulig, men vil heller ikke føre til et merkbart tap av nøyaktighet.
For å nedsample data, samler Compactor kontinuerlig data med en oppløsning på fem minutter og én time. For hver råbit som er kodet ved hjelp av TSDB XOR-komprimering, lagres forskjellige typer aggregerte data, for eksempel min, maks eller sum for én blokk. Dette lar Querier automatisk velge et aggregat som er passende for en gitt PromQL-spørring.
Ingen spesiell konfigurasjon er nødvendig for at brukeren skal bruke data med redusert presisjon. Querier bytter automatisk mellom ulike oppløsninger og rådata når brukeren zoomer inn og ut. Om ønskelig kan brukeren styre dette direkte gjennom "step"-parameteren i forespørselen.
Siden kostnaden for å lagre én GB er lav, lagrer Thanos som standard rådata, fem-minutters og én times oppløsningsdata. Det er ikke nødvendig å slette de originale dataene.
Regler for opptak
Selv med Thanos er opptaksregler en viktig del av overvåkingsstakken. De reduserer kompleksiteten, ventetiden og kostnadene for spørringer. De er også praktiske for brukere å skaffe aggregerte data etter beregninger. Thanos er basert på vanilje Prometheus-forekomster, så det er helt akseptabelt å lagre opptaksregler og varslingsregler på en eksisterende Prometheus-server. Imidlertid kan dette i noen tilfeller ikke være nok:
- Globalt varsel og regel (for eksempel et varsel når en tjeneste ikke fungerer på mer enn to av tre klynger).
- Regel for data utenfor lokal lagring.
- Ønsket om å lagre alle regler og varsler på ett sted.
For alle disse tilfellene inkluderer Thanos en egen komponent kalt Ruler, som beregner regel og varsling via Thanos Queries. Ved å tilby et velkjent StoreAPI, kan spørringsnoden få tilgang til ferske beregninger. Senere blir de også lagret i objektlager og gjort tilgjengelig gjennom Store Gateway.
Kraften til Thanos
Thanos er fleksibel nok til å tilpasses dine behov. Dette er spesielt nyttig når du migrerer fra vanlig Prometheus. La oss raskt oppsummere det vi har lært om Thanos-komponenter med et raskt eksempel. Slik tar du vanilje Prometheus inn i en verden av "ubegrenset metrikklagring":
- Legg Thanos Sidecar til Prometheus-serverne dine - for eksempel en sidevognbeholder i en Kubernetes-pod.
- Distribuer flere Thanos Querier-replikaer for å kunne se data. På dette stadiet er det enkelt å sette opp sladder mellom Scraper og Querier. For å sjekke samspillet mellom komponentene, bruk 'thanos_cluster_members'-beregningen.
Bare disse to trinnene er nok til å gi global oversikt og sømløs datadeduplisering fra potensielle Prometheus HA-replikaer! Koble ganske enkelt dashbordene til Querier HTTP-endepunktet eller bruk Thanos-grensesnittet direkte.
Men hvis du trenger sikkerhetskopiering av beregninger og langtidslagring, må du fullføre tre trinn til:
- Lag en AWS S3- eller GCS-bøtte. Konfigurer Sidecar for å kopiere data til disse bøttene. Lokal datalagring kan nå minimeres.
- Distribuer Store Gateway og koble den til din eksisterende sladderklynge. Nå kan du spørre etter sikkerhetskopierte data!
- Implementer Compactor for å forbedre spørringseffektiviteten over lange tidsperioder ved å bruke komprimering og nedsampling.
Hvis du vil vite mer, ikke nøl med å ta en titt på vår и !
På bare fem trinn gjorde vi Prometheus til et pålitelig overvåkingssystem med global visning, ubegrenset lagringstid og potensiell høy tilgjengelighet av beregninger.
Trekk forespørsel: vi trenger deg!
har vært et åpen kildekode-prosjekt helt fra starten. Sømløs integrasjon med Prometheus og muligheten til å bruke bare en del av Thanos gjør det til et utmerket valg for å skalere overvåkingssystemet uten problemer.
Vi tar alltid imot GitHub Pull-forespørsler og problemer. I mellomtiden kan du gjerne kontakte oss via Github Issues eller slackhvis du har spørsmål eller tilbakemeldinger, eller ønsker å dele din erfaring med å bruke den! Hvis du liker det vi gjør hos Improbable, ikke nøl med å kontakte oss - !
Kilde: www.habr.com