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

De vertaling van het artikel is speciaal voorbereid voor studenten van de cursus \u00abDevOps-praktijken en -tools\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 softwareontwikkelaar, Go-fan en liefhebber van het oplossen van complexe vraagstukken. Hij is ook de maintainer van Prometheus en medeoprichter van Kubernetes SIG instrumentation. Daarvoor was hij production engineer bij SoundCloud en leidde hij het monitoringteam bij CoreOS. Momenteel werkt hij bij Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 infrastructuuringenieur bij Improbable. Hij houdt zich bezig met nieuwe technologie\u00ebn en uitdagingen in gedistribueerde systemen. Heeft ervaring met low-level programmeren bij Intel, is contributor bij Mesos en heeft wereldwijd production ervaring als SRE bij Improbable. Hij werkt aan het verbeteren van de wereld van microservices. Zijn drie passies: Golang, open source en volleybal.<\/i><\/p>\n

Als je naar ons vlaggenschipproduct SpatialOS kijkt, kun je raden dat Improbable een zeer dynamische cloudinfrastructuur nodig heeft van wereldformaat met tientallen Kubernetes-clusters. Wij waren een van de eersten die het monitoring systeem Prometheus<\/a><\/noindex>gebruikten. Prometheus kan miljoenen metrics in real time volgen en wordt geleverd met een krachtige query-taal waarmee je de benodigde informatie kunt ophalen.<\/p>\n

De eenvoud en betrouwbaarheid van Prometheus is een van zijn belangrijkste voordelen. Echter, na een bepaalde schaling stuiten we op verschillende nadelen. Om deze problemen aan te pakken, hebben we Thanos<\/a><\/noindex> ontwikkeld \u2014 een open source-project, gemaakt door Improbable, om bestaande Prometheus-clusters naadloos te transformeren in \u00e9\u00e9n monitoring systeem met onbeperkte opslag van historische data. Thanos is beschikbaar op Github hier<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Blijf op de hoogte van het laatste nieuws van Improbable.<\/a><\/noindex><\/p>\n

Onze doelen met Thanos<\/h2>\n

\nBij een bepaalde schaling ontstaan er problemen die de capaciteiten van vanilla Prometheus overschrijden. Hoe sla je petabytes aan historische gegevens betrouwbaar en kosteneffectief op? Is het mogelijk om dit te doen zonder de responstijd van aanvragen te schaden? Kun je toegang krijgen tot alle metrics die zich op verschillende Prometheus-servers bevinden met \u00e9\u00e9n API-aanroep? Is het op de een of andere manier mogelijk om gereplicateerde gegevens, verzameld met Prometheus HA, samen te voegen?<\/p>\n

Om deze vragen te beantwoorden, hebben we Thanos gecre\u00eberd. In de volgende secties beschrijven we hoe we deze uitdagingen zijn aangegaan en de doelen die we voor ogen hadden.<\/p>\n

Data aanvragen van meerdere Prometheus-instanties (global query)<\/h4>\n

\nPrometheus biedt een functionele benadering van sharding. Zelfs \u00e9\u00e9n Prometheus-server biedt voldoende schaalbaarheid om gebruikers te verlossen van de complexiteiten van horizontaal sharden in vrijwel alle gebruikstoepassingen.<\/p>\n

Hoewel dit een uitstekende implementatiemodel is, is het vaak nodig om toegang te krijgen tot gegevens op verschillende Prometheus-servers via \u00e9\u00e9n API of UI \u2014 global view. Natuurlijk is er de mogelijkheid om meerdere verzoeken in \u00e9\u00e9n Grafana-panel weer te geven, maar elk verzoek kan alleen op \u00e9\u00e9n Prometheus-server worden uitgevoerd. Aan de andere kant kun je met Thanos gegevens opvragen en aggregeren van meerdere Prometheus-servers, omdat ze allemaal vanaf \u00e9\u00e9n eindpunt toegankelijk zijn.<\/p>\n

Eerder, om een global view in Improbable te verkrijgen, hebben we onze Prometheus-instanties in een gelaagde Hi\u00ebrarchische Federatie<\/a><\/noindex>. Dit betekende het cre\u00ebren van \u00e9\u00e9n meta-server van Prometheus, die een deel van de metrics van elke \"leaf\" server verzamelt.<\/p>\n

\"Thanos
\n
\nDeze aanpak bleek problematisch te zijn. Het leidde tot een gecompliceerdere configuratie, de toevoeging van een extra potenti\u00eble noodstop en het toepassen van complexe regels om de federated eindpunt alleen de benodigde gegevens te bieden. Bovendien maakt deze soort federatie het niet mogelijk om een echte global view te verkrijgen, aangezien niet alle gegevens beschikbaar zijn vanuit \u00e9\u00e9n API-aanroep.<\/p>\n

Dit is nauw verbonden met een uniforme weergave van gegevens, verzameld op hoge beschikbaarheid (high-availability, HA) Prometheus-servers. Het HA-model van Prometheus verzamelt gegevens onafhankelijk twee keer, wat zo eenvoudig is dat het niet eenvoudiger kan. Het zou echter veel handiger zijn om een gecombineerde en gededupliceerde weergave van beide stroomgegevens te gebruiken.<\/p>\n

Natuurlijk is er behoefte aan hoge beschikbaarheid in Prometheus-servers. Bij Improbable nemen we gegevensmonitoring per minuut zeer serieus, maar het hebben van \u00e9\u00e9n Prometheus-instantie per cluster is een enkelvoudig punt van falen. Elke configuratiefout of hardwarestoring kan potentieel leiden tot het verlies van belangrijke gegevens. Zelfs een eenvoudige implementatie kan leiden tot kleine onderbrekingen in het verzamelen van metrics, aangezien een herstart aanzienlijk langer kan duren dan de scrapesnelheid.<\/p>\n

Betrouwbare opslag van historische gegevens<\/h4>\n

\nGoedkope, snelle en duurzame metricopslag is onze droom (die door de meeste gebruikers van Prometheus wordt gedeeld). Bij Improbable waren we gedwongen om de opslagduur van metrics in te stellen op negen dagen (voor Prometheus 1.8). Dit legt duidelijke beperkingen op hoe ver we terug kunnen kijken.<\/p>\n

Prometheus 2.0 is hierin verbeterd, omdat het aantal time series niet langer invloed heeft op de algehele serverprestaties (zie de KubeCon keynote over Prometheus 2<\/a><\/noindex>). Desondanks slaat Prometheus gegevens lokaal op. Hoewel hoogwaardige gegevenscompressie het gebruik van lokale SSD's aanzienlijk kan verminderen, blijft er uiteindelijk een limiet op de hoeveelheid opgeslagen historische data.<\/p>\n

Bij Improbable geven we bovendien om betrouwbaarheid, eenvoud en kosten. Grote lokale schijven zijn moeilijker te beheren en te back-uppen. Ze zijn duurder en vereisen meer tools voor back-up, wat leidt tot overbodige complexiteit.<\/p>\n

Downsampling<\/h4>\n

\nZodra we begonnen te werken met historische gegevens, realiseerden we ons dat er fundamentele complicaties zijn met O-groot, die queries steeds trager maken als we werken met gegevens over weken, maanden en jaren.<\/p>\n

De standaardoplossing voor dit probleem is downsampling<\/a><\/noindex> \u2014 het verlagen van de samplingfrequentie van een signaal. Door de samplingfrequentie te verlagen kunnen we het 'schalen' naar een grotere tijdsperiode en het aantal monsters behouden, waardoor de responstijd van de queries behouden blijft.<\/p>\n

Downsampling van oude gegevens is een onvermijdelijke vereiste voor elke oplossing voor langdurige opslag en gaat verder dan vanilla Prometheus.<\/p>\n

Aanvullende doelen<\/h4>\n

\nEen van de oorspronkelijke doelen van het Thanos-project was een naadloze integratie met bestaande Prometheus-installaties. Het tweede doel was eenvoudige operationele mogelijkheden met een minimale instapdrempel. Alle afhankelijkheden moeten gemakkelijk voldoen aan zowel kleine als grote gebruikers, wat ook betekent dat de basis kosten laag moeten zijn.<\/p>\n

Architectuur van Thanos<\/h2>\n

\nNadat we in de vorige sectie onze doelen hebben opgesomd, laten we ze aanpakken en bekijken hoe Thanos deze problemen oplost.<\/p>\n

Globaal overzicht<\/h4>\n

\nOm een global view te verkrijgen bovenop bestaande Prometheus-instanties, moeten we een enkele toegangspunt voor verzoeken verbinden aan alle servers. Dat is precies wat het Thanos-component doet. Sidecar<\/a><\/noindex>. Het wordt naast elke Prometheus-server uitgerold en fungeert als proxy die lokale Prometheus-gegevens levert via de gRPC-interface van de Store API, waarmee time series-gegevens op basis van labels en een tijdsbereik kunnen worden opgehaald.<\/p>\n

Aan de andere kant is er een horizontaal schaalbaar, stateless component genaamd Querier, dat iets meer doet dan alleen reageren op PromQL-verzoeken via de standaard Prometheus HTTP API. De componenten Querier, Sidecar en andere Thanos-onderdelen communiceren via het gossip-protocol.<\/a><\/noindex>.<\/p>\n

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

    \n
  1. Wanneer Querier een verzoek ontvangt, verbindt hij zich met de overeenkomstige Store API-server, dat wil zeggen met onze Sidecars, en ontvangt hij time series-gegevens van de bijbehorende Prometheus-servers.<\/li>\n
  2. Daarna combineert hij de antwoorden en voert PromQL-verzoeken uit. Querier kan zowel niet-overlappende als duplicaatgegevens van HA-Prometheus-servers combineren.<\/li>\n<\/ol>\n

    \nDit lost het grootste deel van onze puzzel op \u2014 het combineren van gegevens van ge\u00efsoleerde Prometheus-servers in een uniforme weergave. In feite kan Thanos alleen al voor deze functionaliteit worden gebruikt. Er zijn geen wijzigingen nodig aan bestaande Prometheus-servers!<\/p>\n

    Onbeperkte opslagduur!<\/h4>\n

    \nMaar vroeg of laat willen we gegevens opslaan die de gebruikelijke opslagperiode van Prometheus overschrijden. Voor het opslaan van historische gegevens hebben we objectopslag gekozen. Deze is breed beschikbaar in elke cloud en ook in lokale datacentra, en is zeer kosteneffectief. Bovendien is vrijwel elke objectopslag toegankelijk via de goed bekende S3 API.<\/p>\n

    Prometheus schrijft gegevens ongeveer elke twee uur van het RAM naar de schijf. Een blok met opgeslagen gegevens bevat alle gegevens voor een vaste tijdsperiode en is onveranderlijk. Dit is erg handig, omdat Thanos Sidecar simpelweg de gegevenscatalogus van Prometheus kan bekijken en, naarmate er nieuwe blokken verschijnen, deze in de buckets van de objectopslag kan laden.<\/p>\n

    \"Thanos
    \n
    \nHet laden in objectopslag direct na het schrijven naar de schijf maakt ook de eenvoud van de 'scraper' (Prometheus en Thanos Sidecar) mogelijk. Dit vereenvoudigt onderhoud, kosten en het ontwerp van het systeem.<\/p>\n

    Zoals u kunt zien, wordt het maken van een back-up van gegevens heel eenvoudig gerealiseerd. Maar hoe zit het met het opvragen van gegevens in de objectopslag?<\/p>\n

    De Thanos Store-component fungeert als een proxy voor het ophalen van gegevens uit de objectopslag. Net als de Thanos Sidecar maakt hij deel uit van een gossip-cluster en implementeert hij de Store API. Hierdoor kunnen bestaande Querier deze beschouwen als Sidecar, als een extra bron van time series-gegevens\u2014er is geen speciale configuratie nodig.<\/p>\n

    \"Thanos
    \n
    \nBlocks van time series-gegevens bestaan uit enkele grote bestanden. Het on-demand laden ervan zou behoorlijk ineffici\u00ebnt zijn, en lokaal cachen zou enorme hoeveelheden geheugen en schijfruimte vereisen.<\/p>\n

    In plaats daarvan weet de Store Gateway hoe om te gaan met het opslagformaat van Prometheus. Dankzij een slimme query-planner en het cachen van alleen de benodigde indexdelen van de blocks, is het nu mogelijk om complexe queries te verkorten tot een minimaal aantal HTTP-verzoeken naar bestanden in de objectopslag. Op deze manier kan het aantal verzoeken met vier tot zes ordes worden verminderd en kan een responstijd worden bereikt die in wezen moeilijk te onderscheiden is van verzoeken naar gegevens op lokale SSD's.<\/p>\n

    \"Thanos
    \n
    \nZoals weergegeven in de bovenstaande diagram, vermindert de Thanos Querier aanzienlijk de kosten van \u00e9\u00e9n verzoek om gegevens in de objectopslag, door het opslagformaat van Prometheus te gebruiken en gerelateerde gegevens dicht bij elkaar te plaatsen. Met deze aanpak kunnen we talrijke enkele verzoeken combineren in een minimaal aantal bulk-operaties.<\/p>\n

    Compacteren en downsampling<\/h4>\n

    \nNadat een nieuw block van time series-gegevens succesvol in de objectopslag is geladen, beschouwen we het als 'historische' gegevens die direct beschikbaar zijn via de Store Gateway.<\/p>\n

    Echter, na verloop van tijd stapelen blocks van dezelfde bron (Prometheus met Sidecar) zich op en benutten ze al niet meer het volledige potentieel van de indexering. Om dit probleem op te lossen, hebben we een andere component ge\u00efntroduceerd genaamd Compactor. Deze past simpelweg het lokale compaction-mechanisme van Prometheus toe op historische gegevens in de objectopslag en kan worden uitgevoerd als een eenvoudige periodieke batchtaak.<\/p>\n

    \"Thanos
    \n
    \nDankzij effici\u00ebnte compressie vormt een verzoek aan de opslag gedurende langere tijd geen probleem qua datagrootte. Echter, de potenti\u00eble kosten van het decomprimeren van een miljard waarden en het doorvoeren van deze door de queryverwerker zullen onvermijdelijk leiden tot een aanzienlijke toename van de query-uitvoeringstijd. Aan de andere kant, aangezien er honderden datapunten per pixel op het scherm zijn, wordt het zelfs onmogelijk om de gegevens in volledige resolutie te visualiseren. Daarom is downsampling niet alleen mogelijk, maar zal het ook niet leiden tot merkbare verlies van nauwkeurigheid. <\/p>\n

    \"Thanos
    \n
    \nVoor het downsampled gegevens verzamelt Compactor continu gegevens met een resolutie van vijf minuten en \u00e9\u00e9n uur. Voor elk onbewerkte fragment, gecodeerd met behulp van TSDB XOR-compressie, worden verschillende soorten geaggregeerde gegevens opgeslagen, zoals min, max of sum voor \u00e9\u00e9n blok. Dit stelt de Querier in staat om automatisch de aggregaat te kiezen die geschikt is voor de gegeven PromQL-query. <\/p>\n

    Voor het gebruik van gegevens met verminderde nauwkeurigheid hoeft de gebruiker geen speciale configuratie uit te voeren. De Querier schakelt automatisch tussen verschillende resoluties en onbewerkte gegevens naarmate de gebruiker in- en uitzoomt. Indien gewenst kan de gebruiker dit direct beheren via de parameter \u201cstep\u201d in de query. <\/p>\n

    Aangezien de kosten voor het opslaan van \u00e9\u00e9n GB laag zijn, slaat Thanos standaard de oorspronkelijke gegevens en gegevens met een resolutie van vijf minuten en \u00e9\u00e9n uur op. Er is geen noodzaak om de oorspronkelijke gegevens te verwijderen.<\/p>\n

    Recording rules<\/h2>\n

    \nZelfs met Thanos zijn recording rules een essentieel onderdeel van de monitoringstack. Ze verminderen de complexiteit, vertraging en kosten van queries. Ze zijn ook handig voor gebruikers om geaggregeerde gegevens op metrics te ontvangen. Thanos is gebaseerd op de vanilla instapversies van Prometheus, dus het is volkomen legitiem om recording rules en alerting rules op de bestaande Prometheus-server op te slaan. In sommige gevallen kan dit echter onvoldoende zijn:<\/p>\n