Oversættelsen af artiklen er udarbejdet specifikt til kursets studerende .
— en softwareudvikler, Go-fan og problemknuser. Han er også Prometheus-vedligeholder og medstifter af Kubernetes SIG-instrumentationen. Han var tidligere produktionsingeniør hos SoundCloud og ledede monitoreringsteamet hos CoreOS. Arbejder i øjeblikket hos Google.
— Infrastrukturingeniør hos Improbable. Han er interesseret i nye teknologier og problemer med distribuerede systemer. Han har programmeringserfaring på lavt niveau hos Intel, bidragydererfaring hos Mesos og erfaring med SRE i produktion i verdensklasse hos Improbable. Dedikeret til at forbedre mikroserviceverdenen. Hans tre kærligheder: Golang, open source og volleyball.
Når man ser på vores flagskibsprodukt SpatialOS, kan man gætte på, at Improbable kræver en meget dynamisk, global cloud-infrastruktur med snesevis af Kubernetes-klynger. Vi var blandt de første til at begynde at bruge overvågningssystemet . Prometheus er i stand til at overvåge millioner af målinger i realtid og leveres med et kraftfuldt forespørgselssprog til at udtrække de oplysninger, du har brug for.
Prometheus' enkelhed og pålidelighed er en af dens største fordele. Men efter at have nået ud over en vis skala, stødte vi på flere ulemper. For at løse disse problemer har vi udviklet — et open source-projekt skabt af Improbable til problemfrit at transformere eksisterende Prometheus-klynger til et enkelt overvågningssystem med ubegrænset historisk datalagring. Thanos er tilgængelig på Github .
Vores mål med Thanos
I en vis skala opstår der problemer, der ligger uden for den sædvanlige Prometheus' muligheder. Hvordan lagrer man petabytes af historiske data pålideligt og omkostningseffektivt? Er det muligt at gøre dette uden at gå på kompromis med svartid på anmodningen? Er det muligt at få adgang til alle metrikker, der er placeret på forskellige Prometheus-servere, med en enkelt API-anmodning? Er der nogen måde at flette replikerede data indsamlet af Prometheus HA?
For at løse disse problemer skabte vi Thanos. De følgende afsnit beskriver, hvordan vi har greb disse problemstillinger an, og forklarer de mål, vi har forfulgt.
Forespørgsel på data fra flere Prometheus-instanser (global forespørgsel)
Prometheus tilbyder en funktionel tilgang til sharding. Selv en enkelt Prometheus-server giver tilstrækkelig skalerbarhed til at befri brugerne fra kompleksiteten ved horisontal sharding i næsten alle anvendelsesscenarier.
Selvom dette er en fremragende implementeringsmodel, er der ofte behov for at få adgang til data på tværs af flere Prometheus-servere via en enkelt API eller brugergrænseflade - den globale visning. Det er selvfølgelig muligt at vise flere forespørgsler i ét Grafana-panel, men hver forespørgsel kan kun udføres mod én Prometheus-server. På den anden side kan du med Thanos forespørge og aggregere data fra flere Prometheus-servere, da de alle er tilgængelige fra et enkelt slutpunkt.
Tidligere, for at få et globalt overblik over Improbable, organiserede vi vores Prometheus-instanser i en lagdelt . Dette betød at oprette én Prometheus-metaserver, der indsamler et delmængde af metrikker fra hver "leaf"-server.
Denne fremgangsmåde viste sig problematisk. Det introducerede mere konfigurationskompleksitet, et yderligere potentielt fejlpunkt og komplekse regler for at sikre, at kun de nødvendige data leveres til det fødererede slutpunkt. Derudover giver denne type føderation ikke mulighed for et reelt globalt overblik, da ikke alle data er tilgængelige fra en enkelt API-anmodning.
Tæt forbundet med dette er den samlede visning af data indsamlet på Prometheus-servere med høj tilgængelighed (HA). Prometheus' HA-model indsamler data to gange uafhængigt af hinanden, hvilket er så simpelt som det kan blive. Det ville dog være meget mere bekvemt at bruge en kombineret og deduplikeret repræsentation af begge strømme.
Der er selvfølgelig behov for Prometheus-servere med høj tilgængelighed. Hos Improbable tager vi minut-for-minut dataovervågning meget alvorligt, men at have én Prometheus-instans pr. klynge er et enkelt fejlpunkt. Enhver konfigurationsfejl eller hardwarefejl kan potentielt resultere i tab af vigtige data. Selv en simpel implementering kan resultere i mindre forstyrrelser i indsamlingen af metrikker, da genstarten kan være betydeligt længere end scraping-intervallet.
Pålidelig lagring af historiske data
Billig, hurtig og langsigtet lagring af metrikker er vores drøm (som deles af de fleste Prometheus-brugere). I Improbable var vi tvunget til at sætte opbevaringsperioden for metrikker til ni dage (for Prometheus 1.8). Dette tilføjer åbenlyse begrænsninger for, hvor langt tilbage vi kan se.
Prometheus 2.0 er forbedret i denne henseende, da antallet af tidsserier ikke længere påvirker serverens samlede ydeevne (se ). Prometheus gemmer dog data på en lokal disk. Selvom meget effektiv datakomprimering kan reducere lokal SSD-forbrug betydeligt, er der i sidste ende stadig en grænse for mængden af historiske data, der kan gemmes.
Derudover lægger vi hos Improbable vægt på pålidelighed, enkelhed og omkostninger. Store lokale diske er vanskeligere at betjene og sikkerhedskopiere. De koster mere og kræver flere backupværktøjer, hvilket tilføjer unødvendig kompleksitet.
Nedsampling
Da vi begyndte at arbejde med historiske data, indså vi, at der var grundlæggende vanskeligheder med big-O, der gjorde forespørgsler langsommere og langsommere, efterhånden som vi arbejdede med uger, måneder og år med data.
Standardløsningen på dette problem ville være (downsampling) — reduktion af signalets samplingsfrekvens. Ved at nedsample kan vi "zoome ud" til et større tidsinterval og stadig opretholde det samme antal prøver, hvilket vil holde forespørgslerne responsive.
Nedsampling af gamle data er et uundgåeligt krav for enhver langtidslagringsløsning og ligger uden for rammerne af den vanilla Prometheus.
Yderligere mål
Et af de oprindelige mål med Thanos-projektet var problemfri integration med enhver eksisterende Prometheus-installation. Det andet mål var at være nem at betjene med minimale adgangsbarrierer. Eventuelle afhængigheder bør være lette at opfylde for både små og store brugere, hvilket også betyder en lav basisomkostning.
Thanos Arkitektur
Nu hvor vi har listet vores mål i det foregående afsnit, lad os arbejde på dem og se, hvordan Thanos løser disse problemer.
Globalt overblik
For at få et globalt overblik over eksisterende Prometheus-instanser skal vi knytte et enkelt forespørgselsindgangspunkt til alle servere. Det er præcis, hvad Thanos-komponenten gør. . Den installeres ved siden af hver Prometheus-server og fungerer som en proxy, der betjener lokale Prometheus-data via en gRPC Store API, der giver dig mulighed for at hente tidsseriedata efter tag og tidsinterval.
På den anden side er der en horisontalt skalerbar, statsløs Querier-komponent, der ikke gør meget mere end blot at svare på PromQL-forespørgsler via standard Prometheus HTTP API. Querier, Sidecar og andre Thanos-komponenter interagerer med hinanden .
- Når en forespørger modtager en anmodning, opretter den forbindelse til den tilsvarende Store API-server, dvs. vores Sidecars, og modtager tidsseriedata fra de tilsvarende Prometheus-servere.
- Derefter kombinerer den svarene og udfører en PromQL-forespørgsel på dem. Querier kan flette både disjunkte data og duplikerede data fra Prometheus HA-servere.
Dette løser en vigtig brik i vores puslespil - at kombinere data fra isolerede Prometheus-servere i én visning. Faktisk kan Thanos kun bruges til denne evne. Der kræves ingen ændringer på eksisterende Prometheus-servere!
Ubegrænset holdbarhed!
Men før eller siden vil vi ønske at gemme data, der falder uden for Prometheus' normale opbevaringstid. Vi valgte objektlagring til at gemme historiske data. Det er bredt tilgængeligt i enhver cloud såvel som i lokale datacentre og er meget omkostningseffektivt. Derudover er stort set al objektlagring tilgængelig via den velkendte S3 API.
Prometheus skriver data fra RAM til disk cirka hver anden time. Blokken af lagrede data indeholder alle data i en fast periode og er uforanderlig. Dette er meget praktisk, fordi Thanos Sidecar blot kan se Prometheus-datamappen og, når nye blokke bliver tilgængelige, indlæse dem i objektlagringsbunke.
Indlæsning i objektlager umiddelbart efter skrivning til disk giver dig også mulighed for at bevare enkelheden ved en "skraber" (Prometheus og Thanos Sidecar). Hvilket forenkler support, omkostninger og systemdesign.
Som du kan se, er databackup meget nemt at implementere. Men hvad med forespørgsler om data i objektlagring?
Thanos Store-komponenten fungerer som en proxy til at hente data fra objektlageret. Ligesom Thanos Sidecar deltager den i Gossip-klyngen og implementerer Store API'en. På denne måde kan eksisterende forespørgere behandle den som en sidevogn, som en anden kilde til tidsseriedata - ingen særlig konfiguration kræves.
Tidsseriedatablokke består af flere store filer. At indlæse dem efter behov ville være ret ineffektivt, og lokal cachelagring ville kræve en enorm mængde hukommelse og diskplads.
I stedet ved Store Gateway, hvordan man håndterer Prometheus-lagringsformatet. Ved at bruge en smart forespørgselsplanlægger og kun cache de nødvendige indeksdele af blokke er det muligt at reducere komplekse forespørgsler til et minimum antal HTTP-anmodninger til objektlagringsfiler. På denne måde kan du reducere antallet af anmodninger med fire til seks størrelsesordener og opnå svartider, der generelt er vanskelige at skelne fra anmodninger til data på en lokal SSD.
Som vist i diagrammet ovenfor reducerer Thanos Querier omkostningerne ved en enkelt forespørgsel mod objektlagringsdata betydeligt ved at bruge Prometheus-lagringsformatet og placere relaterede data tæt sammen. Ved hjælp af denne tilgang kan vi kombinere mange enkeltstående forespørgsler til et minimalt antal bulk-operationer.
Komprimering og nedsampling
Når en ny blok af tidsseriedata er indlæst i objektlagring, behandler vi den som "historiske" data, som er øjeblikkeligt tilgængelige via Store Gateway.
Men efter et stykke tid akkumuleres blokke fra én kilde (Prometheus med Sidecar) og udnytter ikke længere det fulde indekseringspotentiale. For at løse dette problem introducerede vi en anden komponent kaldet Compactor. Den anvender simpelthen Prometheus' lokale komprimeringsmekanisme på historiske data i objektlagring og kan køres som et simpelt periodisk batchjob.
Takket være effektiv komprimering er det ikke et problem med hensyn til datastørrelse at forespørge lageret over en længere periode. De potentielle omkostninger ved at udpakke en milliard værdier og køre dem gennem forespørgselshåndteringen vil dog uundgåeligt resultere i en dramatisk stigning i forespørgselsudførelsestiden. På den anden side, da der er hundredvis af datapunkter pr. pixel på skærmen, bliver det umuligt at visualisere dataene i fuld opløsning. Således er downsampling ikke blot mulig, men vil ikke resultere i et mærkbart tab af præcision.
For at nedskalere data aggregerer Compactor løbende data med opløsninger på fem minutter og en time. For hver rå chunk kodet med TSDB XOR-komprimering gemmes forskellige typer aggregerede data, såsom min, max eller sum for én blok. Dette gør det muligt for Querier automatisk at vælge det aggregat, der er passende for en given PromQL-forespørgsel.
Brugeren behøver ingen særlig konfiguration for at bruge data med lav præcision. Querier skifter automatisk mellem forskellige opløsninger og rådata, når brugeren zoomer ind og ud. Hvis det ønskes, kan brugeren styre dette direkte via parameteren "step" i anmodningen.
Da omkostningerne ved at lagre én GB er lave, lagrer Thanos som standard rådata, data med fem minutters opløsning og data med en times opløsning. Det er ikke nødvendigt at slette de oprindelige data.
Regler for optagelse
Selv med Thanos er optagelsesregler en essentiel del af overvågningsstakken. De reducerer kompleksiteten, latensen og omkostningerne ved forespørgsler. De er også nemme for brugerne at indhente aggregerede data om metrikker. Thanos er baseret på almindelige Prometheus-instanser, så det er helt acceptabelt at gemme optagelsesregler og alarmregler på en eksisterende Prometheus-server. I nogle tilfælde er dette dog muligvis ikke nok:
- Global alarm og regel (f.eks. alarm når en tjeneste er nede på mere end to ud af tre klynger).
- Regel for data uden for lokal lagring.
- Ønsket om at gemme alle regler og advarsler ét sted.
I alle disse tilfælde inkluderer Thanos en separat komponent kaldet Ruler, som evaluerer regler og advarsler via Thanos-forespørgsler. Ved at tilbyde den velkendte StoreAPI kan Query-noden få adgang til friskberegnede metrikker. De gemmes senere også i objektlageret og gøres tilgængelige via Store Gateway.
Thanos' kraft
Thanos er fleksibel nok til at blive tilpasset dine behov. Dette er især nyttigt, når man migrerer fra almindelig Prometheus. Lad os hurtigt gennemgå, hvad vi har lært om Thanos-komponenter, ved hjælp af et lille eksempel. Sådan flytter du din vanilla Prometheus ind i en verden af "ubegrænset metriklagring":
- Tilføj en Thanos Sidecar til dine Prometheus-servere - for eksempel en tilstødende container i en Kubernetes pod.
- Implementer flere Thanos Querier-replikaer for at aktivere datasøgning. På dette stadie er det nemt at opsætte sladder mellem Scraper og Querier. Brug metrikken 'thanos_cluster_members' for at kontrollere komponenternes interaktion.
Blot disse to trin er nok til at give et globalt overblik og problemfri datadeduplikering fra potentielle Prometheus HA-replikaer! Du skal blot tilslutte dine dashboards til HTTP Querier-slutpunktet, eller bruge Thanos-brugergrænsefladen direkte.
Hvis du dog har brug for backup og langtidslagring af målinger, skal du gennemføre tre trin mere:
- Opret en AWS S3- eller GCS-bucket. Konfigurer Sidecar til at kopiere data til disse buckets. Nu kan du minimere lokal datalagring.
- Implementer Store Gateway, og forbind den til en eksisterende Gossip-klynge. Du kan nu forespørge om dine backupdata!
- Implementer Compactor for at forbedre forespørgselsydeevnen over længere tidsperioder ved hjælp af komprimering og downsampling.
Hvis du vil vide mere, er du velkommen til at tage et kig på vores и !
I blot fem trin forvandlede vi Prometheus til et robust overvågningssystem med globalt overblik, ubegrænset opbevaring og potentiel høj tilgængelighed af metrikker.
Træk anmodning: Vi har brug for dig!
har været et open source-projekt fra starten. Problemfri integration med Prometheus og muligheden for kun at bruge en del af Thanos gør det til et godt valg til at skalere dit overvågningssystem uden besvær.
Vi modtager altid gerne GitHub Pull Requests og Issues. I mellemtiden er du velkommen til at kontakte os via Github Issues eller Slack., hvis du har spørgsmål eller feedback, eller hvis du vil dele din oplevelse med at bruge det! Hvis du kan lide det, vi laver hos Improbable, er du velkommen til at kontakte os — !
Kilde: www.habr.com
