{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 skalerbar Prometheus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Overs\u00e6ttelsen er specielt udarbejdet til studerende p\u00e5 kurset \u201eDevOps praksis og v\u00e6rkt\u00f8jer\u201c<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> er softwareudvikler, Go-entusiast og elsker at l\u00f8se komplekse problemer. Han er ogs\u00e5 maintainer af Prometheus og medstifter af Kubernetes SIG instrumentation. Tidligere var han produktionsingeni\u00f8r hos SoundCloud og ledte overv\u00e5gningsgruppen hos CoreOS. I \u00f8jeblikket arbejder han hos Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> er infrastrukturingeni\u00f8r hos Improbable. Han interesserer sig for nye teknologier og udfordringer inden for distribuerede systemer. Han har erfaring med lavniveau-programmering hos Intel, har bidraget til Mesos og har verdensomsp\u00e6ndende SRE-erfaring hos Improbable. Han arbejder p\u00e5 at forbedre mikrotjenestens verden. Tre af hans passioner: Golang, open source og volleyball.<\/i><\/p>\n

N\u00e5r man ser p\u00e5 vores flagskibsprodukt SpatialOS, kan man fornemme, at Improbable har brug for en h\u00f8jtydende cloud-infrastruktur i global skala med dusinvis af Kubernetes-klynger. Vi var blandt de f\u00f8rste til at begynde at bruge overv\u00e5gningssystemet Prometheus<\/a><\/noindex>. Prometheus kan overv\u00e5ge millioner af metrics i realtid og leveres med et kraftfuldt foresp\u00f8rgselssprog, der g\u00f8r det muligt at tr\u00e6kke de n\u00f8dvendige oplysninger.<\/p>\n

Enkelheden og p\u00e5lideligheden af Prometheus er en af dets prim\u00e6re fordele. Men efter at have n\u00e5et en bestemt skala st\u00f8dte vi p\u00e5 flere ulemper. For at l\u00f8se disse problemer har vi udviklet Thanos<\/a><\/noindex> , et open source-projekt skabt af Improbable, til problemfri transformation af eksisterende Prometheus-klynger til et enkelt overv\u00e5gningssystem med ubegr\u00e6nset opbevaring af historiske data. Thanos er tilg\u00e6ngelig p\u00e5 Github her<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Bliv opdateret med de seneste nyheder fra Improbable.<\/a><\/noindex><\/p>\n

Vores m\u00e5l med Thanos<\/h2>\n

\nVed en given skala opst\u00e5r der problemer, der g\u00e5r ud over de muligheder, som vanille Prometheus har. Hvordan opbevarer man p\u00e5lideligt og \u00f8konomisk petabytes af historiske data? Kan dette g\u00f8res uden at g\u00e5 p\u00e5 kompromis med svartiden p\u00e5 foresp\u00f8rgsler? Kan man f\u00e5 adgang til alle metrics, der ligger p\u00e5 forskellige Prometheus-servere, med \u00e9t API-kald? Kan man p\u00e5 en eller anden m\u00e5de kombinere de replicerede data, der er indsamlet med Prometheus HA?<\/p>\n

For at besvare disse sp\u00f8rgsm\u00e5l har vi skabt Thanos. I de f\u00f8lgende afsnit beskriver vi, hvordan vi greb disse udfordringer an, og forklarer de m\u00e5l, vi har sat os.<\/p>\n

Dataforesp\u00f8rgsel fra flere Prometheus-instans (global query)<\/h4>\n

\nPrometheus tilbyder en funktionel tilgang til sharding. Selv en enkelt Prometheus-server giver tilstr\u00e6kkelig skalerbarhed til at befri brugerne fra kompleksiteten ved horisontal sharding i n\u00e6sten alle anvendelsesscenarier.<\/p>\n

Sk\u00f8nt dette er en fremragende implementeringsmodel, er det ofte n\u00f8dvendigt at f\u00e5 adgang til data p\u00e5 forskellige Prometheus-servere gennem et enkelt API eller UI \u2014 globalt overblik. Selvf\u00f8lgelig er der mulighed for at vise flere foresp\u00f8rgsler i et enkelt Grafana-panel, men hver foresp\u00f8rgsel kan kun udf\u00f8res p\u00e5 \u00e9n Prometheus-server. P\u00e5 den anden side, med Thanos kan du foresp\u00f8rge og aggregere data fra flere Prometheus-servere, da de alle er tilg\u00e6ngelige fra et enkelt endpoint.<\/p>\n

Tidligere, for at opn\u00e5 globalt overblik i Improbable, organiserede vi vores Prometheus-forekomster i en multilevel Hierarchical Federation<\/a><\/noindex>. Dette bet\u00f8d oprettelse af en metaserver for Prometheus, der indsamler en del af m\u00e5lingerne fra hver \"blad\" server.<\/p>\n

\"Thanos
\n
\nDenne tilgang viste sig at v\u00e6re problematisk. Den f\u00f8rte til en kompleks konfiguration, tilf\u00f8jede en yderligere potentiel fejlkilde og anvendte komplicerede regler for at give den federated endpoint kun de n\u00f8dvendige data. Desuden tillader denne form for federation ikke et \u00e6gte globalt overblik, da ikke alle data er tilg\u00e6ngelige fra en enkelt API-anmodning.<\/p>\n

Dette er t\u00e6t relateret til det ensartede datasyn, der er indsamlet p\u00e5 h\u00f8jtilg\u00e6ngelige (high-availability, HA) Prometheus-servere. HA-modellen for Prometheus indsamler data uafh\u00e6ngigt to gange, hvilket er s\u00e5 enkelt, at det ikke kan v\u00e6re lettere. Dog ville det v\u00e6re meget mere praktisk at bruge en samlet og dedupliceret fremstilling af begge str\u00f8mme.<\/p>\n

Der er selvf\u00f8lgelig et behov for h\u00f8jt tilg\u00e6ngelige Prometheus-servere. Hos Improbable tager vi minut-for-minut overv\u00e5gning af data meget alvorligt, men at have \u00e9n Prometheus-forekomst i klyngen er en enkelt fejlkilde. Enhver konfigurationsfejl eller hardwarefejl kan potentielt f\u00f8re til tab af vigtige data. Selv en simpel implementering kan f\u00f8re til sm\u00e5 afbrydelser i metricsindsamlingen, da genstart kan tage betydeligt l\u00e6ngere tid end skrabefrekvensen.<\/p>\n

P\u00e5lidelig opbevaring af historiske data<\/h4>\n

\nBilligt, hurtigt og langsigtet metric-lagring er vores dr\u00f8m (som deles af de fleste brugere af Prometheus). Hos Improbable m\u00e5tte vi indstille opbevaringsperioden for metrics til ni dage (for Prometheus 1.8). Dette skaber \u00e5benlyse begr\u00e6nsninger for, hvor langt tilbage vi kan se.<\/p>\n

Prometheus 2.0 er blevet bedre i denne henseende, da antallet af tidsserier ikke l\u00e6ngere p\u00e5virker serverens samlede ydeevne (se KubeCon-keynote om Prometheus 2<\/a><\/noindex>). Ikke desto mindre gemmer Prometheus data p\u00e5 den lokale disk. Selvom h\u00f8jtydende datakomprimering kan reducere brugen af lokal SSD betydeligt, er der stadig en gr\u00e6nse for m\u00e6ngden af historiske data, der kan gemmes.<\/p>\n

Derudover v\u00e6rner vi hos Improbable om p\u00e5lidelighed, enkelhed og omkostninger. Store lokale diske er mere komplekse at administrere og sikkerhedskopiere. De er dyrere og kr\u00e6ver flere v\u00e6rkt\u00f8jer til sikkerhedskopiering, hvilket f\u00f8rer til un\u00f8dvendig kompleksitet.<\/p>\n

Nedpr\u00f8ving<\/h4>\n

\nDa vi begyndte at arbejde med historiske data, inds\u00e5 vi, at der er fundamentale problemer med O-storstilet, som g\u00f8r foresp\u00f8rgsler langsommere og langsommere, n\u00e5r vi arbejder med data fra uger, m\u00e5neder og \u00e5r.<\/p>\n

Standardl\u00f8sningen p\u00e5 dette problem er nedpr\u00f8vning<\/a><\/noindex> (downsampling) \u2014 reduktion af signalets pr\u00f8vehastighed. Ved at s\u00e6nke pr\u00f8vehastigheden kan vi \"skalere ned\" til et st\u00f8rre tidsrum og opretholde det samme antal pr\u00f8ver, hvilket vil sikre foresp\u00f8rgningens responsivitet.<\/p>\n

Nedpr\u00f8vning af gamle data er et uundg\u00e5eligt krav for enhver l\u00f8sning til langsigtet lagring og g\u00e5r ud over standard Prometheus.<\/p>\n

Yderligere m\u00e5l<\/h4>\n

\nEt af de oprindelige m\u00e5l for Thanos-projektet var problemfri integration med eksisterende Prometheus-installationer. Det andet m\u00e5l var nem betjening med minimal adgangsbarriere. Enhver afh\u00e6ngighed skal v\u00e6re let at opfylde for b\u00e5de sm\u00e5 og store brugere, hvilket ogs\u00e5 foruds\u00e6tter lave grundomkostninger.<\/p>\n

Thanos-arkitektur<\/h2>\n

\nN\u00e5r vi nu har opremset vores m\u00e5l i det forrige afsnit, lad os arbejde hen imod dem og se, hvordan Thanos adresserer disse problemer.<\/p>\n

Global visning<\/h4>\n

\nFor a global view overlaying existing Prometheus instances, we need to link a single entry point for requests to all servers. This is exactly what the Thanos component does. Sidecar<\/a><\/noindex>. It is deployed alongside each Prometheus server and acts as a proxy, serving local Prometheus data through the gRPC Store API interface, which allows querying time series data by labels and time range.<\/p>\n

On the other hand, there is a horizontally scalable stateless Querier component that does a bit more than just responding to PromQL queries through the standard Prometheus HTTP API. The Querier, Sidecar, and other Thanos components interact via the gossip protocol.<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. When the Querier receives a request, it connects to the appropriate Store API server, meaning our Sidecars, and retrieves time series data from the corresponding Prometheus servers.<\/li>\n
  2. After that, it merges the responses and performs the PromQL query on them. The Querier can merge both non-overlapping data and duplicated data from HA Prometheus servers.<\/li>\n<\/ol>\n

    \nThis solves the main part of our puzzle \u2014 merging data from isolated Prometheus servers into a unified view. In fact, Thanos can be used solely for this capability. No changes are required to existing Prometheus servers!<\/p>\n

    Unlimited retention!<\/h4>\n

    \nHowever, sooner or later we will want to store data that goes beyond the usual retention period of Prometheus. For historical data storage, we have chosen object storage. It is widely available in any cloud, as well as in local data centers, and is very cost-effective. Moreover, virtually any object storage is accessible via the well-known S3 API.<\/p>\n

    Prometheus writes data from memory to disk approximately every two hours. Each block of stored data contains all data for a fixed time interval and is immutable. This is very convenient, as Thanos Sidecar can simply look at the Prometheus data directory and load new blocks into the object storage buckets as they appear.<\/p>\n

    \"Thanos
    \n
    \nUploading to the object storage immediately after writing to disk also helps to maintain the simplicity of the scraper (Prometheus and Thanos Sidecar). This simplifies the maintenance, cost, and design of the system.<\/p>\n

    Som du kan se, er sikkerhedskopiering af data meget enkelt at implementere. Men hvad med foresp\u00f8rgslen til data i objektlagringen?<\/p>\n

    Thanos Store-komponenten fungerer som en proxy til at hente data fra objektlagringen. Ligesom Thanos Sidecar deltager den i gossip-klassen og implementerer Store API. P\u00e5 denne m\u00e5de kan eksisterende Querier se den som en Sidecar, som en anden kilde til tidsserie-data \u2013 der kr\u00e6ves ingen s\u00e6rlig ops\u00e6tning.<\/p>\n

    \"Thanos
    \n
    \nTidsserie-data best\u00e5r af flere store filer. At hente dem efter behov ville v\u00e6re ret ineffektivt, og lokal caching ville kr\u00e6ve enorm m\u00e6ngde hukommelse og diskplads.<\/p>\n

    I stedet ved Store Gateway, hvordan man h\u00e5ndterer Prometheus lagringsformat. Takket v\u00e6re en smart foresp\u00f8rgselsplanl\u00e6gger og caching af kun de n\u00f8dvendige indeksdele af filerne, er det blevet muligt at reducere komplekse foresp\u00f8rgsler til et minimum antal HTTP-foresp\u00f8rgsler til objektlagringen. Dermed kan antallet af anmodninger reduceres med fire til seks st\u00f8rrelsesordener og opn\u00e5 en responstid, der generelt er sv\u00e6r at skelne fra anmodninger til data p\u00e5 en lokal SSD.<\/p>\n

    \"Thanos
    \n
    \nSom vist i diagrammet ovenfor reducerer Thanos Querier betydeligt omkostningerne ved en enkelt foresp\u00f8rgsel til data i objektlagringen ved at bruge Prometheus lagringsformatet og placere relaterede data t\u00e6t p\u00e5 hinanden. Ved at bruge denne tilgang kan vi kombinere mange enkeltst\u00e5ende anmodninger til et minimalt antal bulk-operationer.<\/p>\n

    Kompaktering og nedsampling<\/h4>\n

    \nN\u00e5r en ny blok af tidsserie-data er blevet uploadet til objektlagringen, betragter vi den som 'historiske' data, der straks er tilg\u00e6ngelige via Store Gateway.<\/p>\n

    Efter noget tid ophobes blokke fra en kilde (Prometheus med Sidecar) og udnytter ikke l\u00e6ngere hele potentialet for indeksering. For at l\u00f8se dette problem har vi introduceret en anden komponent kaldet Compactor. Den anvender blot den lokale komprimeringsmekanisme fra Prometheus til de historiske data i objektlagringen og kan k\u00f8res som en simpel periodisk batchopgave.<\/p>\n

    \"Thanos
    \n
    \nTakket v\u00e6re effektiv komprimering udg\u00f8r en foresp\u00f8rgsel til lageret over l\u00e6ngere tid ikke et problem med hensyn til datast\u00f8rrelse. Den potentielle omkostning ved at dekomprimere en milliard v\u00e6rdier og k\u00f8re dem gennem foresp\u00f8rgselsbehandleren vil imidlertid uundg\u00e5eligt f\u00f8re til en betydelig stigning i foresp\u00f8rgselens behandlingstid. P\u00e5 den anden side, da der er hundrede datapunkter for hver sk\u00e6rmpixel, bliver det umuligt selv at visualisere dataene i fuld opl\u00f8sning. S\u00e5ledes er nedsampling ikke kun muligt, men vil heller ikke f\u00f8re til m\u00e6rkbare tab i pr\u00e6cision. <\/p>\n

    \"Thanos
    \n
    \nTil nedsampling af data aggregerer Compactor kontinuerligt data med en opl\u00f8sning p\u00e5 fem minutter og en time. For hvert r\u00e5 fragment, der er kodet med TSDB XOR-komprimering, lagres forskellige typer aggregerede data, s\u00e5som min, max eller sum for en blok. Dette g\u00f8r det muligt for Querier automatisk at v\u00e6lge den aggregerede data, der passer til den givne PromQL-foresp\u00f8rgsel. <\/p>\n

    For at bruge data med nedsat n\u00f8jagtighed kr\u00e6ves der ingen speciel konfiguration fra brugeren. Querier skifter automatisk mellem forskellige opl\u00f8sninger og r\u00e5data, n\u00e5r brugeren zoomer ind og ud. Hvis brugeren \u00f8nsker det, kan de styre dette direkte via \u2018step\u2019-parameteren i foresp\u00f8rgslen. <\/p>\n

    Da omkostningen ved at opbevare \u00e9n GB er lille, gemmer Thanos som standard originale data, data med en opl\u00f8sning p\u00e5 fem minutter og en time. Der er ikke behov for at slette de originale data.<\/p>\n

    Recording rules<\/h2>\n

    \nSelv med Thanos er recording rules en v\u00e6sentlig del af overv\u00e5gningsstakken. De reducerer kompleksiteten, forsinkelsen og omkostningerne ved foresp\u00f8rgsler. De er ogs\u00e5 praktiske for brugere, der \u00f8nsker at f\u00e5 aggregerede data om metrikker. Thanos er baseret p\u00e5 vanilje-forekomster af Prometheus, s\u00e5 det er helt acceptabelt at gemme recording rules og alerting rules p\u00e5 den eksisterende Prometheus-server. I nogle tilf\u00e6lde kan dette dog v\u00e6re utilstr\u00e6kkeligt:<\/p>\n