Oversættelsen af artiklen er udarbejdet specifikt til kursets studerende .
er softwareudvikler, Go-fanatiker og problemløser. Han er også Prometheus-vedligeholder og medstifter af Kubernetes SIG-instrumentering. Tidligere var han produktionsingeniør hos SoundCloud og ledede overvågningsteamet 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 SRE-produktionserfaring i verdensklasse hos Improbable. Dedikeret til at forbedre verden af mikrotjenester. Hans tre kærligheder: Golang, open source og volleyball.
Når du ser på vores flagskibsprodukt SpatialOS, kan du gætte, at Improbable kræver en meget dynamisk, global-skala cloud-infrastruktur med snesevis af Kubernetes-klynger. Vi var en af de første til at bruge et overvågningssystem . Prometheus er i stand til at spore millioner af metrics i realtid og kommer med et kraftfuldt forespørgselssprog, der giver dig mulighed for at udtrække den information, du har brug for.
Prometheus' enkelhed og pålidelighed er en af dens vigtigste fordele. Men når vi nåede forbi en vis skala, stødte vi på flere ulemper. For at løse disse problemer har vi udviklet er 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, som ligger uden for vanilje Prometheus' evner. Hvordan opbevarer man pålideligt og økonomisk petabytes af historiske data? Kan dette gøres uden at gå på kompromis med responstiden? Er det muligt at få adgang til alle metrics placeret på forskellige Prometheus-servere med en enkelt API-anmodning? Er der nogen måde at kombinere replikerede data indsamlet ved hjælp af Prometheus HA?
For at løse disse problemer oprettede vi Thanos. De følgende afsnit beskriver, hvordan vi greb disse problemer an og forklarer vores mål.
Forespørgsel om data fra flere Prometheus-instanser (global forespørgsel)
Prometheus tilbyder en funktionel tilgang til skæring. Selv en enkelt Prometheus-server giver tilstrækkelig skalerbarhed til at frigøre brugere fra kompleksiteten af horisontal sharding i næsten alle brugssager.
Selvom dette er en fantastisk implementeringsmodel, er det ofte nødvendigt at få adgang til data på forskellige Prometheus-servere gennem en enkelt API eller UI - en global visning. Det er selvfølgelig muligt at vise flere forespørgsler i ét Grafana-panel, men hver forespørgsel kan kun udføres på én Prometheus-server. På den anden side kan du med Thanos forespørge og samle data fra flere Prometheus-servere, da de alle er tilgængelige fra et enkelt slutpunkt.
Tidligere, for at få et globalt overblik i Improbable, organiserede vi vores Prometheus-forekomster i et multi-level . Dette betød at oprette en Prometheus-metaserver, der indsamler nogle af metrikken fra hver bladserver.
Denne tilgang viste sig problematisk. Dette har resulteret i mere komplekse konfigurationer, tilføjelse af et yderligere potentielt fejlpunkt og anvendelse af komplekse regler for at sikre, at det fødererede slutpunkt kun modtager de data, det har brug for. Derudover tillader denne form for føderation dig ikke at få et ægte globalt overblik, da ikke alle data er tilgængelige fra en enkelt API-anmodning.
Tæt forbundet med dette er en samlet visning af de data, der er indsamlet på Prometheus-servere med høj tilgængelighed (HA). Prometheus' HA-model indsamler uafhængigt data to gange, hvilket er så enkelt, at det ikke kunne være enklere. Det ville dog være meget mere praktisk at bruge en kombineret og deduplikeret visning af begge vandløb.
Selvfølgelig er der behov for højt tilgængelige Prometheus-servere. Hos Improbable tager vi minut-for-minut dataovervågning virkelig alvorligt, men at have én Prometheus-instans pr. klynge er et enkelt fejlpunkt. Enhver konfigurationsfejl eller hardwarefejl kan potentielt føre til tab af vigtige data. Selv en simpel implementering kan forårsage mindre afbrydelser i metrikindsamlingen, fordi genstart kan være betydeligt længere end skrabeintervallet.
Pålidelig lagring af historiske data
Billig, hurtig, langsigtet metric-lagring er vores drøm (delt af de fleste Prometheus-brugere). I Improbable blev vi tvunget til at konfigurere metric-retentionsperioden til ni dage (for Prometheus 1.8). Dette tilføjer åbenlyse grænser 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 overordnede ydeevne (se. ). Prometheus gemmer dog data på lokal disk. Selvom højeffektiv datakomprimering betydeligt kan reducere lokal SSD-brug, er der i sidste ende stadig en grænse for mængden af historiske data, der kan gemmes.
Derudover bekymrer vi os hos Improbable om pålidelighed, enkelhed og omkostninger. Store lokale diske er sværere at betjene og sikkerhedskopiere. De koster mere og kræver flere backupværktøjer, hvilket resulterer i unødvendig kompleksitet.
Nedsampling
Da vi begyndte at arbejde med historiske data, indså vi, at der er grundlæggende vanskeligheder med big-O, der gør forespørgsler langsommere og langsommere, efterhånden som vi arbejder med uger, måneder og år med data.
Standardløsningen på dette problem ville være (downsampling) - reduktion af signalets samplingsfrekvens. Med downsampling kan vi "skalere ned" til et større tidsinterval og opretholde det samme antal samples, hvilket holder forespørgsler responsive.
Nedsampling af gamle data er et uundgåeligt krav for enhver langtidslagringsløsning og ligger uden for vanilla Prometheus' rammer.
Yderligere mål
Et af de oprindelige mål med Thanos-projektet var at integrere problemfrit med eksisterende Prometheus-installationer. Det andet mål var nem betjening med minimale adgangsbarrierer. Eventuelle afhængigheder bør let kunne tilfredsstilles for både små og store brugere, hvilket også betyder en lav basisomkostning.
Thanos arkitektur
Efter at have angivet vores mål i det foregående afsnit, lad os arbejde dem igennem og se, hvordan Thanos løser disse problemer.
Global visning
For at få et globalt overblik over eksisterende Prometheus-instanser skal vi linke et enkelt anmodningsindgangspunkt til alle servere. Det er præcis, hvad Thanos-komponenten gør. . Den er installeret ved siden af hver Prometheus-server og fungerer som en proxy, der serverer lokale Prometheus-data gennem gRPC Store API, hvilket gør det muligt at hente tidsseriedata efter tag og tidsinterval.
På den anden side er den udskalerede, statsløse Querier-komponent, som ikke gør meget mere end blot at besvare PromQL-forespørgsler via standard Prometheus HTTP API. Querier, Sidecar og andre Thanos-komponenter kommunikerer via .
- Querier, ved at modtage en anmodning, forbinder til den tilsvarende Store API-server, det vil sige til vores sidevogne 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 usammenhængende 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 en enkelt visning. Faktisk kan Thanos kun bruges til denne funktion. Der skal ikke foretages ændringer på eksisterende Prometheus-servere!
Ubegrænset holdbarhed!
Men før eller siden vil vi gerne gemme data ud over den normale Prometheus-opbevaringstid. Vi valgte objektlagring til at gemme historiske data. Det er bredt tilgængeligt i enhver sky såvel som i lokale datacentre og er meget omkostningseffektivt. Derudover er næsten enhver objektlagring tilgængelig gennem den velkendte S3 API.
Prometheus skriver data fra RAM til disk cirka hver anden time. Den lagrede datablok indeholder alle data i en fast periode og er uforanderlig. Dette er meget praktisk, fordi Thanos Sidecar blot kan se på Prometheus-databiblioteket og, efterhånden som nye blokke bliver tilgængelige, indlæse dem i objektlager.
Indlæsning i objektlager umiddelbart efter skrivning til disk giver dig også mulighed for at bevare skraberens enkelhed (Prometheus og Thanos Sidecar). Hvilket forenkler support, omkostninger og systemdesign.
Som du kan se, er sikkerhedskopiering af data meget enkel. Men hvad med at forespørge data i objektlagring?
Thanos Store-komponenten fungerer som en proxy til at hente data fra objektlageret. Ligesom Thanos Sidecar deltager den i sladderklyngen og implementerer Store API. På denne måde kan eksisterende Querier behandle det som en sidevogn, som en anden kilde til tidsseriedata - ingen speciel konfiguration påkrævet.
Tidsseriedatablokke består af flere store filer. At indlæse dem efter behov ville være ret ineffektivt, og at cache dem lokalt ville kræve en enorm mængde hukommelse og diskplads.
I stedet ved Store Gateway, hvordan man håndterer Prometheus-lagringsformatet. Takket være en smart forespørgselsplanlægning og caching af kun de nødvendige indeksdele af blokke, er det muligt at reducere komplekse forespørgsler til et minimum af HTTP-anmodninger til objektlagringsfiler. På denne måde kan du reducere antallet af forespørgsler med fire til seks størrelsesordener og opnå svartider, der generelt er svære at skelne fra forespørgsler til data på en lokal SSD.
Som vist i diagrammet ovenfor reducerer Thanos Querier betydeligt omkostningerne pr. forespørgsel på objektlagringsdata ved at udnytte Prometheus-lagringsformatet og placere relaterede data side om side. Ved at bruge denne tilgang kan vi kombinere mange enkeltforespørgsler til et minimum antal bulkoperationer.
Komprimering og nedsampling
Når en ny blok af tidsseriedata er blevet indlæst i objektlageret, behandler vi det som "historiske" data, som er umiddelbart tilgængelige gennem Store Gateway.
Efter nogen tid akkumuleres blokke fra én kilde (Prometheus med sidevogn) og bruger ikke længere det fulde indekseringspotentiale. For at løse dette problem introducerede vi en anden komponent kaldet Compactor. Den anvender blot Prometheus' lokale komprimeringsmotor til historiske data i objektlagring og kan køres som et simpelt periodisk batchjob.
Takket være effektiv komprimering udgør det ikke et problem med hensyn til datastørrelse at forespørge lageret over en længere periode. Imidlertid vil de potentielle omkostninger ved at pakke en milliard værdier ud og køre dem gennem en forespørgselsprocessor uundgåeligt resultere i en dramatisk stigning i forespørgsels eksekveringstid. På den anden side, da der er hundredvis af datapunkter pr. pixel på skærmen, bliver det umuligt overhovedet at visualisere dataene i fuld opløsning. Nedsampling er således ikke kun mulig, men vil heller ikke føre til et mærkbart tab af nøjagtighed.
For at nedsample data samler Compactor kontinuerligt data med en opløsning på fem minutter og en time. For hver rå chunk, der er kodet ved hjælp af TSDB XOR-komprimering, lagres forskellige typer aggregerede data, såsom min, max eller sum for en blok. Dette gør det muligt for Querier automatisk at vælge et aggregat, der er passende til en given PromQL-forespørgsel.
Der kræves ingen speciel konfiguration for at brugeren kan bruge data med reduceret 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 gennem "trin"-parameteren i anmodningen.
Da omkostningerne ved at opbevare en GB er lave, gemmer Thanos som standard rådata, fem minutters og en times opløsningsdata. Der er ingen grund til at slette de originale data.
Regler for optagelse
Selv med Thanos er optagelsesregler en væsentlig del af overvågningsstakken. De reducerer kompleksitet, latenstid og omkostninger ved forespørgsler. De er også praktiske for brugere at opnå aggregerede data efter metrics. Thanos er baseret på vanilla Prometheus-instanser, så det er helt acceptabelt at gemme optagelsesregler og advarselsregler på en eksisterende Prometheus-server. Men i nogle tilfælde kan dette ikke være nok:
- Global advarsel og regel (f.eks. en advarsel, når en tjeneste ikke fungerer på mere end to af tre klynger).
- Regel for data uden for lokal lagring.
- Ønsket om at gemme alle regler og advarsler ét sted.
For alle disse tilfælde inkluderer Thanos en separat komponent kaldet Ruler, som beregner regel og advarsel via Thanos Queries. Ved at levere en velkendt StoreAPI kan forespørgselsnoden få adgang til nyberegnet metrics. Senere gemmes de også i objektlager og gøres tilgængelige via Store Gateway.
Thanos magt
Thanos er fleksibel nok til at blive tilpasset til dine behov. Dette er især nyttigt, når du migrerer fra almindelig Prometheus. Lad os hurtigt opsummere, hvad vi har lært om Thanos-komponenter med et hurtigt eksempel. Sådan tager du din vanilje Prometheus ind i en verden af "ubegrænset metric storage":
- Tilføj Thanos Sidecar til dine Prometheus-servere - for eksempel en sidevognsbeholder i en Kubernetes-pod.
- Implementer flere Thanos Querier-replikaer for at kunne se data. På dette tidspunkt er det nemt at oprette sladder mellem Scraper og Querier. For at kontrollere interaktionen mellem komponenter skal du bruge metrikken 'thanos_cluster_members'.
Bare disse to trin er nok til at give et globalt overblik og problemfri datadeduplikering fra potentielle Prometheus HA-replikaer! Tilslut blot dine dashboards til Querier HTTP-slutpunktet, eller brug Thanos UI direkte.
Men hvis du har brug for sikkerhedskopiering af metrics og langtidslagring, skal du udføre yderligere tre trin:
- Opret en AWS S3- eller GCS-spand. Konfigurer Sidecar til at kopiere data til disse buckets. Lokal datalagring kan nu minimeres.
- Implementer Store Gateway og tilslut den til din eksisterende sladderklynge. Nu kan du forespørge på de sikkerhedskopierede data!
- Implementer Compactor for at forbedre forespørgselseffektiviteten over lange perioder ved hjælp af komprimering og nedsampling.
Hvis du vil vide mere, så tøv ikke med at tage et kig på vores и !
På kun fem trin forvandlede vi Prometheus til et pålideligt overvågningssystem med global visning, ubegrænset lagertid og potentiel høj tilgængelighed af metrics.
Træk anmodning: vi har brug for dig!
har været et open source-projekt lige fra begyndelsen. Sømløs integration med Prometheus og muligheden for kun at bruge en del af Thanos gør det til et fremragende valg til ubesværet at skalere dit overvågningssystem.
Vi hilser altid GitHub Pull-anmodninger og -problemer velkommen. I mellemtiden er du velkommen til at kontakte os via Github Issues eller slackhvis du har spørgsmål eller feedback, eller vil dele din oplevelse med at bruge det! Hvis du kan lide det, vi laver hos Improbable, så tøv ikke med at kontakte os - !
Kilde: www.habr.com