De vertaling van het artikel is speciaal gemaakt voor de studenten van de cursus .
is een softwareontwikkelaar, Go-fanaat en probleemoplosser. Hij is ook Prometheus-onderhouder en mede-oprichter van Kubernetes SIG-instrumentatie. In het verleden was hij productie-ingenieur bij SoundCloud en leidde hij het monitoringteam bij CoreOS. Werkt momenteel bij Google.
- Infrastructuuringenieur bij Improble. Hij is geïnteresseerd in nieuwe technologieën en problemen van gedistribueerde systemen. Hij heeft programmeerervaring op laag niveau bij Intel, ervaring als bijdrager bij Mesos en SRE-productie-ervaring van wereldklasse bij Improbable. Toegewijd aan het verbeteren van de wereld van microservices. Zijn drie liefdes: Golang, open source en volleybal.
Als je naar ons vlaggenschipproduct SpatialOS kijkt, kun je raden dat Improbable een zeer dynamische, wereldwijde cloudinfrastructuur met tientallen Kubernetes-clusters vereist. Wij waren een van de eersten die een monitoringsysteem gebruikten . Prometheus kan miljoenen statistieken in realtime volgen en wordt geleverd met een krachtige zoektaal waarmee u de informatie kunt extraheren die u nodig heeft.
De eenvoud en betrouwbaarheid van Prometheus is een van de belangrijkste voordelen. Toen we echter eenmaal een bepaalde schaal overschreden, kwamen we verschillende nadelen tegen. Om deze problemen op te lossen hebben wij ontwikkeld is een open source-project gemaakt door Improbable om bestaande Prometheus-clusters naadloos te transformeren in één enkel monitoringsysteem met onbeperkte opslag van historische gegevens. Thanos is beschikbaar op Github .
Onze doelen met Thanos
Op een bepaalde schaal ontstaan er problemen die de mogelijkheden van gewone Prometheus te boven gaan. Hoe kunnen we petabytes aan historische gegevens betrouwbaar en economisch opslaan? Kan dit worden gedaan zonder de responstijd in gevaar te brengen? Is het mogelijk om met één API-verzoek toegang te krijgen tot alle statistieken die zich op verschillende Prometheus-servers bevinden? Is er een manier om gerepliceerde gegevens verzameld met Prometheus HA te combineren?
Om deze problemen aan te pakken, hebben we Thanos gemaakt. In de volgende paragrafen wordt beschreven hoe we deze kwesties hebben aangepakt en worden onze doelstellingen toegelicht.
Gegevens opvragen uit meerdere Prometheus-instanties (algemene query)
Prometheus biedt een functionele benadering van sharding. Zelfs een enkele Prometheus-server biedt voldoende schaalbaarheid om gebruikers in vrijwel alle gebruikssituaties te bevrijden van de complexiteit van horizontale sharding.
Hoewel dit een geweldig implementatiemodel is, is het vaak nodig om toegang te krijgen tot gegevens op verschillende Prometheus-servers via één enkele API of UI: een globaal overzicht. Uiteraard is het mogelijk om meerdere queries in één Grafana-paneel weer te geven, maar elke query kan slechts op één Prometheus-server worden uitgevoerd. Aan de andere kant kun je met Thanos gegevens van meerdere Prometheus-servers opvragen en samenvoegen, omdat ze allemaal toegankelijk zijn vanaf één enkel eindpunt.
Om een globaal beeld te krijgen van Improbable, organiseerden we voorheen onze Prometheus-instanties in meerdere niveaus . Dit betekende dat er één Prometheus-metaserver moest worden gemaakt die een deel van de statistieken van elke leaf-server verzamelt.
Deze aanpak bleek problematisch. Dit heeft geresulteerd in complexere configuraties, de toevoeging van een extra potentieel storingspunt en de toepassing van complexe regels om ervoor te zorgen dat het federatieve eindpunt alleen de gegevens ontvangt die het nodig heeft. Bovendien kun je met dit soort federatie geen echt globaal beeld krijgen, omdat niet alle gegevens beschikbaar zijn via één enkel API-verzoek.
Nauw verwant hieraan is een uniform overzicht van de gegevens die zijn verzameld op Prometheus-servers met hoge beschikbaarheid (HA). Het HA-model van Prometheus verzamelt gegevens tweemaal onafhankelijk, wat zo eenvoudig is dat het niet eenvoudiger kan. Het zou echter veel handiger zijn om een gecombineerde en gededupliceerde weergave van beide stromen te gebruiken.
Natuurlijk is er behoefte aan Prometheus-servers met een hoge beschikbaarheid. Bij Improbable nemen we de gegevensmonitoring van minuut tot minuut heel serieus, maar het hebben van één Prometheus-instantie per cluster is een enkel punt van falen. Elke configuratiefout of hardwarefout kan mogelijk leiden tot het verlies van belangrijke gegevens. Zelfs een eenvoudige implementatie kan kleine verstoringen veroorzaken bij het verzamelen van metrische gegevens, omdat het opnieuw opstarten aanzienlijk langer kan duren dan het scraping-interval.
Betrouwbare opslag van historische gegevens
Goedkope, snelle opslag van meetgegevens voor de lange termijn is onze droom (gedeeld door de meeste Prometheus-gebruikers). In Improbable waren we gedwongen de bewaarperiode voor statistieken in te stellen op negen dagen (voor Prometheus 1.8). Dit voegt duidelijke grenzen toe aan hoe ver we terug kunnen kijken.
Prometheus 2.0 is in dit opzicht verbeterd, omdat het aantal tijdreeksen niet langer van invloed is op de algehele prestaties van de server (zie. ). Prometheus slaat gegevens echter op de lokale schijf op. Hoewel zeer efficiënte datacompressie het lokale SSD-gebruik aanzienlijk kan verminderen, is er uiteindelijk nog steeds een limiet aan de hoeveelheid historische gegevens die kan worden opgeslagen.
Bovendien geven we bij Improble om betrouwbaarheid, eenvoud en kosten. Grote lokale schijven zijn moeilijker te bedienen en er een back-up van te maken. Ze kosten meer en vereisen meer back-uptools, wat resulteert in onnodige complexiteit.
Downsampling
Toen we eenmaal met historische gegevens begonnen te werken, realiseerden we ons dat er fundamentele problemen zijn met big-O, waardoor zoekopdrachten steeds langzamer worden naarmate we met weken, maanden en jaren aan gegevens werken.
De standaardoplossing voor dit probleem zou zijn (downsampling) - vermindering van de signaalbemonsteringsfrequentie. Met downsampling kunnen we “terugschalen” naar een groter tijdsbereik en hetzelfde aantal samples behouden, waardoor vragen responsief blijven.
Het downsamplen van oude gegevens is een onvermijdelijke vereiste voor elke langetermijnopslagoplossing en valt buiten het bestek van Prometheus.
Extra doelen
Een van de oorspronkelijke doelstellingen van het Thanos-project was om naadloos te integreren met bestaande Prometheus-installaties. Het tweede doel was bedieningsgemak met minimale toegangsdrempels. Aan eventuele afhankelijkheden moet gemakkelijk worden voldaan voor zowel kleine als grote gebruikers, wat ook lage basiskosten betekent.
Thanos-architectuur
Nadat we onze doelen in het vorige gedeelte hebben opgesomd, gaan we ze doornemen en kijken hoe Thanos deze problemen oplost.
Globale kijk
Om een globaal beeld te krijgen van de bestaande Prometheus-instanties, moeten we één enkel verzoekingangspunt aan alle servers koppelen. Dit is precies wat de Thanos-component doet. . Het wordt naast elke Prometheus-server ingezet en fungeert als een proxy, waarbij lokale Prometheus-gegevens worden aangeboden via de gRPC Store API, waardoor tijdreeksgegevens kunnen worden opgehaald per tag en tijdsbereik.
Aan de andere kant staat de schaalbare, staatloze Querier-component, die weinig meer doet dan alleen PromQL-query's beantwoorden via de standaard Prometheus HTTP API. Querier, Sidecar en andere Thanos-componenten communiceren via .
- Querier maakt bij ontvangst van een verzoek verbinding met de overeenkomstige Store API-server, dat wil zeggen met onze Sidecars, en ontvangt tijdreeksgegevens van de overeenkomstige Prometheus-servers.
- Daarna combineert het de antwoorden en voert er een PromQL-query op uit. Querier kan zowel onsamenhangende gegevens als dubbele gegevens van Prometheus HA-servers samenvoegen.
Dit lost een groot deel van onze puzzel op: het combineren van gegevens van geïsoleerde Prometheus-servers in één weergave. In feite kan Thanos alleen voor deze functie worden gebruikt. Er hoeven geen wijzigingen te worden aangebracht aan bestaande Prometheus-servers!
Onbeperkte houdbaarheid!
Vroeg of laat zullen we echter gegevens willen opslaan die verder gaan dan de normale bewaartijd van Prometheus. Voor het opslaan van historische data hebben wij gekozen voor objectopslag. Het is overal beschikbaar in elke cloud en in datacenters op locatie en is zeer kosteneffectief. Daarnaast is vrijwel iedere objectopslag beschikbaar via de bekende S3 API.
Prometheus schrijft ongeveer elke twee uur gegevens van RAM naar schijf. Het opgeslagen datablok bevat alle gegevens voor een vaste periode en is onveranderlijk. Dit is erg handig omdat Thanos Sidecar eenvoudig naar de Prometheus-gegevensmap kan kijken en, zodra er nieuwe blokken beschikbaar komen, deze in objectopslagbuckets kan laden.
Als u onmiddellijk na het schrijven naar schijf in de objectopslag laadt, kunt u ook de eenvoud van de schraper (Prometheus en Thanos Sidecar) behouden. Wat de ondersteuning, de kosten en het systeemontwerp vereenvoudigt.
Zoals u kunt zien, is een gegevensback-up heel eenvoudig. Maar hoe zit het met het opvragen van gegevens in objectopslag?
De Thanos Store-component fungeert als een proxy om gegevens uit objectopslag op te halen. Net als Thanos Sidecar neemt het deel aan het roddelcluster en implementeert het de Store API. Op deze manier kan de bestaande Querier het behandelen als een zijspan, als een andere bron van tijdreeksgegevens - er is geen speciale configuratie vereist.
Tijdreeksgegevensblokken bestaan uit verschillende grote bestanden. Het op verzoek laden ervan zou behoorlijk inefficiënt zijn, en het lokaal cachen ervan zou een enorme hoeveelheid geheugen en schijfruimte vergen.
In plaats daarvan weet Store Gateway om te gaan met het Prometheus-opslagformaat. Dankzij een slimme queryplanner en het cachen van alleen de noodzakelijke indexdelen van blokken, is het mogelijk om complexe queries terug te brengen tot een minimum aantal HTTP-verzoeken om opslagbestanden te objecteren. Op deze manier kunt u het aantal verzoeken met vier tot zes ordes van grootte verminderen en responstijden bereiken die doorgaans moeilijk te onderscheiden zijn van verzoeken om gegevens op een lokale SSD.
Zoals in het bovenstaande diagram te zien is, verlaagt Thanos Querier de kosten per query van objectopslaggegevens aanzienlijk door gebruik te maken van het Prometheus-opslagformaat en gerelateerde gegevens naast elkaar te plaatsen. Met deze aanpak kunnen we veel afzonderlijke verzoeken combineren tot een minimum aantal bulkbewerkingen.
Verdichting en downsampling
Zodra een nieuw blok met tijdreeksgegevens met succes in de objectopslag is geladen, behandelen we deze als ‘historische’ gegevens, die onmiddellijk beschikbaar zijn via de Store Gateway.
Na enige tijd stapelen blokken uit één bron (Prometheus met Sidecar) zich echter op en benutten ze niet langer het volledige indexeringspotentieel. Om dit probleem op te lossen, hebben we een ander onderdeel geïntroduceerd, genaamd Compactor. Het past eenvoudigweg de lokale compactie-engine van Prometheus toe op historische gegevens in objectopslag en kan worden uitgevoerd als een eenvoudige periodieke batchtaak.
Dankzij de efficiënte compressie vormt het bevragen van de opslag over een langere periode geen probleem wat betreft de gegevensgrootte. De potentiële kosten van het uitpakken van een miljard waarden en het uitvoeren ervan door een queryprocessor zullen echter onvermijdelijk resulteren in een dramatische toename van de uitvoeringstijd van query's. Aan de andere kant, omdat er honderden datapunten per pixel op het scherm staan, wordt het onmogelijk om de gegevens zelfs maar met volledige resolutie te visualiseren. Downsampling is dus niet alleen mogelijk, maar zal ook niet leiden tot een merkbaar verlies aan nauwkeurigheid.
Om gegevens te downsamplen, verzamelt Compactor voortdurend gegevens met een resolutie van vijf minuten en een uur. Voor elk onbewerkt stuk dat is gecodeerd met TSDB XOR-compressie, worden verschillende soorten verzamelde gegevens opgeslagen, zoals min, max of som voor één blok. Hierdoor kan Querier automatisch een aggregatie selecteren die geschikt is voor een bepaalde PromQL-query.
Er is geen speciale configuratie vereist zodat de gebruiker gegevens met verminderde precisie kan gebruiken. Querier schakelt automatisch tussen verschillende resoluties en onbewerkte gegevens terwijl de gebruiker in- en uitzoomt. Indien gewenst kan de gebruiker dit direct aansturen via de “step” parameter in de request.
Omdat de kosten voor het opslaan van één GB laag zijn, slaat Thanos standaard onbewerkte gegevens, gegevens met een resolutie van vijf minuten en een uur op. Het is niet nodig om de originele gegevens te verwijderen.
Registratieregels
Zelfs bij Thanos zijn opnameregels een essentieel onderdeel van de monitoringstack. Ze verminderen de complexiteit, latentie en kosten van query's. Ze zijn ook handig voor gebruikers om geaggregeerde gegevens op basis van statistieken te verkrijgen. Thanos is gebaseerd op standaard Prometheus-instanties, dus het is volkomen acceptabel om opnameregels en waarschuwingsregels op te slaan op een bestaande Prometheus-server. In sommige gevallen kan dit echter niet voldoende zijn:
- Globale waarschuwing en regel (bijvoorbeeld een waarschuwing wanneer een service niet werkt op meer dan twee van de drie clusters).
- Regel voor gegevens buiten lokale opslag.
- De wens om alle regels en waarschuwingen op één plek op te slaan.
Voor al deze gevallen bevat Thanos een afzonderlijke component genaamd Ruler, die regels en waarschuwingen berekent via Thanos Queries. Door een bekende StoreAPI te bieden, heeft het Query-knooppunt toegang tot nieuw berekende statistieken. Later worden ze ook opgeslagen in objectopslag en beschikbaar gesteld via de Store Gateway.
De kracht van Thanos
Thanos is flexibel genoeg om aan uw behoeften te worden aangepast. Dit is vooral handig bij het migreren vanuit gewoon Prometheus. Laten we snel samenvatten wat we hebben geleerd over Thanos-componenten met een snel voorbeeld. Zo neemt u uw typische Prometheus mee naar de wereld van “onbeperkte opslag van statistieken”:
- Voeg Thanos Sidecar toe aan uw Prometheus-servers, bijvoorbeeld een zijspancontainer in een Kubernetes-pod.
- Implementeer meerdere Thanos Querier-replica's om gegevens te kunnen bekijken. In dit stadium is het gemakkelijk om roddels tussen Scraper en Querier op te zetten. Gebruik de statistiek 'thanos_cluster_members' om de interactie van componenten te controleren.
Alleen al deze twee stappen zijn voldoende om een globaal overzicht en naadloze gegevensontdubbeling van potentiële Prometheus HA-replica's te bieden! Verbind eenvoudig uw dashboards met het Querier HTTP-eindpunt of gebruik rechtstreeks de Thanos UI.
Als u echter een back-up van de statistieken en langdurige opslag nodig heeft, moet u nog drie stappen uitvoeren:
- Maak een AWS S3- of GCS-bucket. Configureer Sidecar om gegevens naar deze buckets te kopiëren. Lokale gegevensopslag kan nu worden geminimaliseerd.
- Implementeer Store Gateway en verbind deze met uw bestaande roddelcluster. Nu kunt u de back-upgegevens opvragen!
- Implementeer Compactor om de efficiëntie van zoekopdrachten over langere perioden te verbeteren met behulp van compactie en downsampling.
Wilt u meer weten, neem dan gerust een kijkje bij ons и !
In slechts vijf stappen hebben we van Prometheus een betrouwbaar monitoringsysteem gemaakt met een globaal overzicht, onbeperkte opslagtijd en potentieel hoge beschikbaarheid van meetgegevens.
Pull-verzoek: we hebben je nodig!
is vanaf het begin een open source-project geweest. Dankzij de naadloze integratie met Prometheus en de mogelijkheid om slechts een deel van Thanos te gebruiken, is het een uitstekende keuze om uw monitoringsysteem moeiteloos op te schalen.
We verwelkomen altijd GitHub Pull Requests en Issues. Neem in de tussentijd gerust contact met ons op via Github Issues of slackals u vragen of feedback heeft, of uw ervaringen met het gebruik ervan wilt delen! Als het je bevalt wat we bij Improbable doen, aarzel dan niet om contact met ons op te nemen - !
Bron: www.habr.com