{"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\/no\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 skalerbar Prometheus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Oversettelsen av artikkelen er forberedt spesielt for studentene i kurset \u201cDevOps Practices and Tools\u201d<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 programvareutvikler, Go-entusiast og glad i \u00e5 l\u00f8se komplekse problemer. Han er ogs\u00e5 vedlikeholder av Prometheus og medgr\u00fcnder av Kubernetes SIG instrumentation. Tidligere var han produksjonsingeni\u00f8r hos SoundCloud og ledet overv\u00e5kningsgruppen i CoreOS. N\u00e5 jobber han i Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 infrastrukturingeni\u00f8r hos Improbable. Han interesserer seg for nye teknologier og utfordringer innen distribuerte systemer. Har erfaring med lavniv\u00e5programmering i Intel, erfaring som bidragsyter i Mesos og produksjonsopplevelse innen SRE i verdensklasse hos Improbable. Han jobber med \u00e5 forbedre mikroserviceverdenen. Hans tre kj\u00e6rligheter: Golang, open source og volleyball.<\/i><\/p>\n

Ser man p\u00e5 v\u00e5rt flaggskipprodukt SpatialOS, kan man gjette at Improbable trenger en h\u00f8y-dynamisk skyinfrastruktur p\u00e5 global skala med titalls Kubernetes-klynger. Vi var blant de f\u00f8rste til \u00e5 begynne \u00e5 bruke overv\u00e5kningssystemet Prometheus<\/a><\/noindex>. Prometheus kan spore millioner av metrikker i sanntid og leveres med et kraftig sp\u00f8rringsspr\u00e5k som gj\u00f8r det mulig \u00e5 hente n\u00f8dvendig informasjon.<\/p>\n

Simplicity and reliability is one of Prometheus's main advantages. However, after reaching a certain scale, we faced several shortcomings. To solve these issues, we developed Thanos<\/a><\/noindex> \u2014 et prosjekt med \u00e5pen kildekode utviklet av Improbable, for s\u00f8ml\u00f8s transformasjon av eksisterende Prometheus-klynger til et samlet overv\u00e5kingssystem med ubegrenset lagring av historiske data. Thanos er tilgjengelig p\u00e5 Github her<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Hold deg oppdatert med de siste nyhetene fra Improbable.<\/a><\/noindex><\/p>\n

V\u00e5re m\u00e5l med Thanos<\/h2>\n

\nVed en viss skala oppst\u00e5r problemer som overstiger evnene til vanilje-Prometheus. Hvordan lagre petabyte av historiske data p\u00e5 en trygg og kostnadseffektiv m\u00e5te? Kan dette gj\u00f8res uten \u00e5 g\u00e5 p\u00e5 bekostning av responstiden p\u00e5 foresp\u00f8rselen? Kan man f\u00e5 tilgang til alle metrikker p\u00e5 forskjellige Prometheus-servere med \u00e9n API-foresp\u00f8rsel? Er det mulig \u00e5 p\u00e5 en eller annen m\u00e5te kombinere dupliserte data samlet med Prometheus HA?<\/p>\n

For \u00e5 l\u00f8se disse sp\u00f8rsm\u00e5lene har vi laget Thanos. I de f\u00f8lgende avsnittene beskrives hvordan vi n\u00e6rmet oss l\u00f8sningene p\u00e5 disse problemene og de m\u00e5lene vi hadde.<\/p>\n

Foresp\u00f8rsel om data fra flere Prometheus-installasjoner (global query)<\/h4>\n

\nPrometheus tilbyr en funksjonell tiln\u00e6rming til sharding. Selv en enkelt Prometheus-server gir tilstrekkelig skalerbarhet til \u00e5 frigj\u00f8re brukerne fra kompleksiteten av horisontal sharding i praktisk talt alle bruksomr\u00e5der.<\/p>\n

Selv om dette er en utmerket distribusjonsmodell, er det ofte n\u00f8dvendig \u00e5 f\u00e5 tilgang til data p\u00e5 forskjellige Prometheus-servere via et enkelt API eller UI \u2014 global visning. Selvf\u00f8lgelig kan flere foresp\u00f8rseler vises i en enkelt Grafana-panel, men hver foresp\u00f8rsel kan kun utf\u00f8res p\u00e5 \u00e9n Prometheus-server. P\u00e5 den annen side kan du med Thanos foresp\u00f8rre og aggregere data fra flere Prometheus-servere, siden alle er tilgjengelige fra ett endepunkt.<\/p>\n

Tidligere, for \u00e5 oppn\u00e5 global visning i Improbable, organiserte vi v\u00e5re Prometheus-installasjoner i en lagdelt Hierarchical Federation<\/a><\/noindex>. Dette innebar \u00e5 opprette en meta-server for Prometheus, som samler inn en del m\u00e5linger fra hver \"leaf\" server.<\/p>\n

\"Thanos
\n
\nDenne tiln\u00e6rmingen viste seg \u00e5 v\u00e6re problematisk. Den f\u00f8rte til komplisert konfigurasjon, la til en ekstra potensiell feilkilde og p\u00e5f\u00f8rte komplekse regler for \u00e5 tilby den federerte endepunktet kun de n\u00f8dvendige dataene. I tillegg tillater ikke slik federasjon virkelig \u00e5 oppn\u00e5 en global visning, ettersom ikke alle data er tilgjengelige fra \u00e9n API-foresp\u00f8rsel.<\/p>\n

Dette er n\u00e6rt knyttet til et enhetlig syn p\u00e5 data samlet p\u00e5 h\u00f8ytilgjengelige (high-availability, HA) Prometheus-servere. HA-modellen til Prometheus samler uavhengig data to ganger, noe som er s\u00e5 enkelt at det knapt kan bli enklere. Det ville imidlertid v\u00e6rt veldig praktisk \u00e5 bruke et samlet og deduplisert syn p\u00e5 begge str\u00f8mmer.<\/p>\n

Selvf\u00f8lgelig er det et behov for h\u00f8ytilgjengelige servere for Prometheus. I Improbable tar vi virkelig dataoverv\u00e5king p\u00e5 minuttbasis alvorlig, men \u00e5 ha en enkelt instans av Prometheus i klyngen er et enkelt feilpunkt. Enhver konfigurasjonsfeil eller maskinvarefeil kan potensielt f\u00f8re til tap av viktig data. Selv en enkel distribusjon kan f\u00f8re til sm\u00e5 avbrudd i innsamlingen av metrikker, siden omstart kan ta betydelig lengre tid enn skrapetintervallet.<\/p>\n

P\u00e5litelige historiske data lagring<\/h4>\n

\nBillig, rask og langvarig lagring av metrikker er v\u00e5r dr\u00f8m (som deles av de fleste brukere av Prometheus). Hos Improbable m\u00e5tte vi sette lagringsperioden for metrikker til ni dager (for Prometheus 1.8). Dette legger \u00e5penbare begrensninger p\u00e5 hvor langt tilbake vi kan se.<\/p>\n

Prometheus 2.0 har blitt bedre p\u00e5 dette omr\u00e5det, ettersom antall tidsserier ikke lenger p\u00e5virker den totale ytelsen til serveren (se KubeCon keynote om Prometheus 2<\/a><\/noindex>). Likevel lagrer Prometheus data p\u00e5 lokal disk. Selv om h\u00f8yeffektiv datakomprimering kan redusere bruken av lokal SSD betydelig, finnes det til slutt fortsatt en grense for mengden historiske data som kan lagres.<\/p>\n

I tillegg bryr vi oss hos Improbable om p\u00e5litelighet, enkelhet og kostnad. Store lokale disker er vanskeligere \u00e5 administrere og sikkerhetskopiere. De er dyrere og krever flere verkt\u00f8y for sikkerhetskopiering, noe som f\u00f8rer til un\u00f8dvendig kompleksitet.<\/p>\n

Nedsampling<\/h4>\n

\nDa vi begynte \u00e5 jobbe med historiske data, inns\u00e5 vi at det finnes fundamentale vanskeligheter med O-stor, som gj\u00f8r at foresp\u00f8rslene blir tregere og tregere n\u00e5r vi jobber med data over uker, m\u00e5neder og \u00e5r.<\/p>\n

Den standard l\u00f8sningen p\u00e5 dette problemet vil v\u00e6re nedsampling<\/a><\/noindex> (downsampling) \u2014 redusere samplingfrekvensen av signalet. Ved \u00e5 senke samplingfrekvensen kan vi \"skalere ned\" til et st\u00f8rre tidsrom og opprettholde det samme antallet pr\u00f8ver, noe som vil bevare responsiviteten i foresp\u00f8rslene.<\/p>\n

Nedsampling av eldre data er et uunng\u00e5elig krav for enhver l\u00f8sning for langsiktig lagring og g\u00e5r utover vanilje-Prometheus.<\/p>\n

Ytterligere m\u00e5l<\/h4>\n

\nEt av de opprinnelige m\u00e5lene med Thanos-prosjektet var s\u00f8ml\u00f8s integrasjon med eksisterende Prometheus-installasjoner. Det andre m\u00e5let var enkel drift med minimal inngangsbarriere. Eventuelle avhengigheter m\u00e5 kunne oppfylles enkelt for b\u00e5de sm\u00e5 og store brukere, noe som ogs\u00e5 inneb\u00e6rer at den grunnleggende kostnaden er ubetydelig.<\/p>\n

Thanos-arkitektur<\/h2>\n

\nEtter at vi har listet opp v\u00e5re m\u00e5l i avsnittet ovenfor, la oss jobbe med dem og se hvordan Thanos l\u00f8ser disse problemene.<\/p>\n

Global visning<\/h4>\n

\nFor a global view over existing Prometheus instances, we need to link a single entry point for requests to all servers. This is precisely 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, allowing for time series data selection by labels and time range.<\/p>\n

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

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

    \n
  1. When the Querier receives a request, it connects to the corresponding Store API server, namely our Sidecars, and retrieves time series data from the relevant Prometheus servers.<\/li>\n
  2. It then combines the responses and executes the PromQL query on them. The Querier can merge both non-overlapping 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 single view. In fact, Thanos can be used solely for this capability. No modifications are needed on existing Prometheus servers!<\/p>\n

    Unlimited storage duration!<\/h4>\n

    \nHowever, sooner or later we will want to retain data that goes beyond the usual retention period of Prometheus. For storing historical data, we chose object storage. It is widely available in any cloud and also in local data centers, and it's 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. A 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 object storage immediately after writing to disk also helps maintain the simplicity of the scraper (Prometheus and Thanos Sidecar), which simplifies system maintenance, cost, and design.<\/p>\n

    Som du kan se, er det veldig enkelt \u00e5 ta sikkerhetskopi av data. Men hva med foresp\u00f8rselen til dataene i objektlagringen?<\/p>\n

    Thanos Store-komponenten fungerer som en proxy for \u00e5 hente data fra objektlagringen. Akkurat som Thanos Sidecar deltar den i et gossip-kluster og implementerer Store API. Dermed kan eksisterende Querier behandle den som Sidecar, som en annen kilde til tidsseriedata \u2014 ingen spesialkonfigurasjon er n\u00f8dvendig.<\/p>\n

    \"Thanos
    \n
    \nTidsseriedataene best\u00e5r av flere store filer. \u00c5 laste dem p\u00e5 foresp\u00f8rsel ville v\u00e6rt ganske ineffektivt, og lokal caching ville krevd enorme ressurser for minne og lagringsplass.<\/p>\n

    I stedet vet Store Gateway hvordan man h\u00e5ndterer Prometheus lagringsformat. Takket v\u00e6re en smart foresp\u00f8rselplanlegger og caching av bare n\u00f8dvendige indeksdeler av blokkene, er det mulig \u00e5 redusere komplekse foresp\u00f8rsel til et minimum av HTTP-foresp\u00f8rsel til filer i objektlagringen. Dermed kan antallet foresp\u00f8rsel reduseres med fire til seks st\u00f8rrelsesordener og oppn\u00e5 responstid som generelt er vanskelig \u00e5 skille fra foresp\u00f8rsel til data p\u00e5 lokal SSD.<\/p>\n

    \"Thanos
    \n
    \nSom vist i diagrammet ovenfor, reduserer Thanos Querier kostnadene for en foresp\u00f8rsel til data i objektlagringen betydelig ved \u00e5 bruke Prometheus lagringsformat og plassere relaterte data n\u00e6r hverandre. Ved \u00e5 bruke denne tiln\u00e6rmingen kan vi sammensl\u00e5 mange individuelle foresp\u00f8rsel til et minimum av bulk-operasjoner.<\/p>\n

    Kompresjon og nedsampling<\/h4>\n

    \nEtter at en ny blokk med tidsseriedata har blitt lastet opp til objektlagringen, betrakter vi den som \"historiske\" data som umiddelbart blir tilgjengelige via Store Gateway.<\/p>\n

    Imidlertid, etter en stund, akkumuleres blokkene fra en kilde (Prometheus med Sidecar) og utnytter ikke lenger hele indekseringspotensialet. For \u00e5 l\u00f8se dette problemet har vi introdusert en annen komponent kalt Compactor. Den bruker ganske enkelt den lokale kompresjonsmekanismen til Prometheus p\u00e5 de historiske dataene i objektlagringen og kan kj\u00f8res som en enkel periodisk batchjobb.<\/p>\n

    \"Thanos
    \n
    \nTakk vere effektiv komprimering, utgjer ikkje foresp\u00f8rselen i lagringssystemet eit problem sj\u00f8lv over lengre tid fr\u00e5 eit datast\u00f8rrelsesynspunkt. Men den potensielle kostnaden ved \u00e5 pakke ut milliardar av verdiar og k\u00f8yre dei gjennom foresp\u00f8rselbehandlaren vil uunng\u00e5eleg f\u00f8re til ein markant auke i behandlingstida for foresp\u00f8rselen. P\u00e5 den andre sida, sidan kvar skjermpiksel har hundrevis av datapunkt, blir det umogleg \u00e5 visualisere data i full oppl\u00f8ysing. S\u00e5leis er nedoverpr\u00f8ving ikkje berre mogleg, men f\u00f8rer heller ikkje til merkbar tap av presisjon. <\/p>\n

    \"Thanos
    \n
    \nFor nedoverpr\u00f8ving av data aggregerer Compactor kontinuerleg data med ei oppl\u00f8ysing p\u00e5 fem minutt og ein time. For kvar r\u00e5del av data koda med TSDB XOR-komprimering, blir ulike typar aggregerte data lagra, som min, max eller sum for ei blokk. Dette gjer at Querier automatisk kan velje aggreget som passar for den aktuelle PromQL-foresp\u00f8rselen. <\/p>\n

    For \u00e5 bruke data med redusert presisjon treng brukaren ingen spesialkonfigurasjon. Querier vekslar automatisk mellom ulike oppl\u00f8ysingar og r\u00e5data etter kvart som brukaren zoomar inn og ut. Om \u00f8nskelig kan brukaren styre dette direkte via parameteren \u201cstep\u201d i foresp\u00f8rselen. <\/p>\n

    Sidan kostnaden for lagring av ein GB er l\u00e5g, lagrar Thanos som standard r\u00e5data, data med ei oppl\u00f8ysing p\u00e5 fem minutt og p\u00e5 ein time. Det er ikkje behov for \u00e5 slette raw data.<\/p>\n

    Opptakreglar<\/h2>\n

    \nSj\u00f8lv utan Thanos er opptakreglar ein viktig del av overv\u00e5kingsstakken. Dei reduserer kompleksitet, latency og kostnad ved foresp\u00f8rslene. Dei er ogs\u00e5 nyttige for brukarar n\u00e5r det gjeld \u00e5 f\u00e5 aggregerte data om metrikkar. Thanos bygger p\u00e5 vanlige instansar av Prometheus, s\u00e5 det er heilt akseptabelt \u00e5 lagre opptakreglar og varslingsreglar p\u00e5 den eksisterande Prometheus-serveren. Men i nokre tilfelle kan dette vere utilstrekkeleg:<\/p>\n