Die vertaling van die artikel is spesifiek vir die studente van die kursus voorberei .
is 'n sagteware-ontwikkelaar, Go-fanaties en probleemoplosser. Hy is ook die onderhouer van Prometheus en medestigter van Kubernetes SIG-instrumentasie. In die verlede was hy 'n produksie-ingenieur by SoundCloud en het die moniteringspan by CoreOS gelei. Werk tans by Google.
- Infrastruktuuringenieur by Improbable. Hy is lief vir nuwe tegnologieë en probleme van verspreide stelsels. Hy het laevlak-programmeringservaring by Intel, bydraer-ervaring by Mesos, en wêreldklas SRE-produksie-ervaring by Improbable. Is betrokke by die verbetering van die wêreld van mikrodienste. Sy drie liefdes is Golang, oopbron en vlugbal.
As u na ons vlagskipproduk SpatialOS kyk, kan u raai dat Improbable 'n hoogs dinamiese globale wolkinfrastruktuur met dosyne Kubernetes-klusters benodig. Ons was van die eerstes wat die moniteringstelsel begin gebruik het . Prometheus is in staat om miljoene intydse statistieke op te spoor en kom met 'n kragtige navraagtaal om die inligting te onttrek wat jy nodig het.
Die eenvoud en betroubaarheid van Prometheus is een van sy belangrikste voordele. Nadat ons 'n sekere skaal geslaag het, het ons egter verskeie nadele ondervind. Om hierdie probleme op te los, het ons ontwikkel is 'n oopbronprojek wat deur Improbable geskep is om bestaande Prometheus-klusters naatloos in 'n enkele moniteringstelsel met onbeperkte historiese databerging te transformeer. Thanos is beskikbaar op Github .
Ons doelwitte met Thanos
Op 'n sekere skaal ontstaan probleme wat buite die vermoëns van vanielje Prometheus is. Hoe om petagrepe van historiese data veilig en ekonomies te stoor? Kan dit gedoen word sonder om navraag se reaksietyd te benadeel? Is dit moontlik om toegang te verkry tot alle maatstawwe wat op verskillende Prometheus-bedieners geleë is met 'n enkele API-versoek? Is daar enige manier om die herhaalde data wat ingesamel is saam te voeg met Prometheus HA?
Om hierdie kwessies aan te spreek, het ons Thanos geskep. Die volgende afdelings beskryf hoe ons hierdie kwessies benader het en verduidelik die doelwitte wat ons nagestreef het.
Doen navraag oor data van verskeie Prometheus-gevalle (globale navraag)
Prometheus bied 'n funksionele benadering tot skering. Selfs 'n enkele Prometheus-bediener bied genoeg skaalbaarheid om gebruikers in byna alle gebruiksgevalle te bevry van die kompleksiteite van horisontale versplintering.
Alhoewel dit 'n uitstekende ontplooiingsmodel is, word dit dikwels vereis om toegang tot data op verskillende Prometheus-bedieners te verkry deur 'n enkele API of UI - die globale aansig. Dit is natuurlik moontlik om verskeie versoeke in een Grafana-paneel te vertoon, maar elke versoek kan slegs aan een Prometheus-bediener gerig word. Aan die ander kant, met Thanos kan jy navraag doen en data van verskeie Prometheus-bedieners af navraag doen, aangesien hulle almal vanaf dieselfde eindpunt toeganklik is.
Vroeër, om 'n globale siening in Improbable te kry, het ons ons Prometheus-gevalle in 'n multi-vlak georganiseer . Dit het beteken dat een Prometheus-metabediener geskep word wat 'n gedeelte van die statistieke van elke "blaar"-bediener versamel.
Hierdie benadering het problematies geblyk. Dit het gelei tot 'n meer komplekse konfigurasie, die toevoeging van 'n bykomende potensiële punt van mislukking, en die toepassing van komplekse reëls om die gefedereerde eindpunt te voorsien van slegs die data wat dit benodig. Boonop laat hierdie soort federasie jou nie toe om 'n ware globale aansig te kry nie, aangesien nie alle data vanaf 'n enkele API-versoek beskikbaar is nie.
Nou verwant hiermee is 'n enkele aansig van data wat op hoë-beskikbaarheid (HA) Prometheus-bedieners ingesamel is. Die Prometheus HA-model versamel data onafhanklik twee keer, wat so eenvoudig is as wat dit kan wees. Die gebruik van 'n gekombineerde en gededupliseerde voorstelling van beide strome sal egter baie geriefliker wees.
Natuurlik is daar 'n behoefte aan hoogs beskikbare Prometheus-bedieners. By Improbable is ons regtig ernstig daaroor om data elke minuut te monitor, maar om een Prometheus-instansie per groepering te hê, is 'n enkele punt van mislukking. Enige konfigurasiefout of hardewarefout kan moontlik lei tot die verlies van belangrike data. Selfs 'n eenvoudige ontplooiing kan tot geringe foute in die versameling van statistieke lei omdat die herbegin aansienlik langer as die skraapinterval kan wees.
Betroubare berging van historiese data
Goedkoop, vinnige en langtermynberging van metrieke is ons droom (gedeel deur die meerderheid Prometheus-gebruikers). In Onwaarskynlik is ons gedwing om die bewaringstydperk van die maatstawwe op nege dae te stel (vir Prometheus 1.8). Dit voeg ooglopende perke by hoe ver terug ons kan kyk.
Prometheus 2.0 het in hierdie verband verbeter, aangesien die aantal tydreekse nie meer die algehele werkverrigting van die bediener beïnvloed nie (sien hieronder). ). Prometheus stoor egter data op die plaaslike skyf. Alhoewel hoogs doeltreffende datakompressie die gebruik van 'n plaaslike SSD aansienlik kan verminder, is daar uiteindelik 'n beperking op die hoeveelheid historiese data wat gestoor kan word.
Boonop gee ons by Improbable om oor betroubaarheid, eenvoud en koste. Groot plaaslike aandrywers is moeiliker om te onderhou en te rugsteun. Hulle kos meer en vereis meer rugsteunnutsmiddels, wat lei tot onnodige kompleksiteit.
Afsteekproefneming
Sodra ons met historiese data begin werk het, het ons besef dat daar fundamentele probleme met groot O is wat navrae stadiger en stadiger maak as ons vir weke, maande en jare met data werk.
Die standaard oplossing vir hierdie probleem sou wees (downsampling) - die vermindering van die steekproeffrekwensie van die sein. Met afsteekproefneming kan ons "afskaal" na 'n groter tydsbestek en dieselfde aantal monsters handhaaf, wat ons navrae responsief sal hou.
Afsteekproefneming van ou data is 'n onvermydelike vereiste van enige langtermyn bergingsoplossing en gaan verder as vanielje Prometheus.
Bykomende doelwitte
Een van die oorspronklike doelwitte van die Thanos-projek was naatlose integrasie met enige bestaande Prometheus-installasies. Die tweede doelwit was eenvoudige operasie met 'n minimum versperring tot toegang. Enige afhanklikhede moet maklik bevredig word vir beide klein en groot gebruikers, wat ook 'n weglaatbare onderliggende koste impliseer.
Thanos argitektuur
Nadat ons ons doelwitte in die vorige afdeling gelys het, kom ons werk daaraan en kyk hoe Thanos hierdie probleme oplos.
Globale aansig
Om 'n globale uitsig oor bestaande Prometheus-gevalle te kry, moet ons 'n enkele versoekingangspunt aan alle bedieners koppel. Dit is presies wat die Thanos-komponent doen. . Dit word langs elke Prometheus-bediener ontplooi en dien as 'n instaanbediener wat plaaslike Prometheus-data bedien via die gRPC Store API, wat jou toelaat om tydreeksdata volgens tydstempel en tydreeks te kies.
Aan die ander kant is 'n horisontaal skaalbare, staatlose Querier-komponent wat weinig meer doen as om op PromQL-navrae te reageer deur die standaard Prometheus HTTP API. Komponente Querier, Sidecar en ander Thanos interaksie via .
- Querier, by ontvangs van 'n versoek, koppel aan die ooreenstemmende Store API-bediener, dit wil sê aan ons Sidecars, en ontvang tydreeksdata van die ooreenstemmende Prometheus-bedieners.
- Daarna kombineer dit die antwoorde en voer 'n PromQL-navraag daarop uit. Querier kan beide nie-oorvleuelende data en gedupliseerde data vanaf Prometheus HA-bedieners saamvoeg.
Dit los die hoofgedeelte van ons legkaart op - die kombinasie van data van geïsoleerde Prometheus-bedieners in 'n enkele aansig. Trouens, Thanos kan net vir hierdie geleentheid gebruik word. Bestaande Prometheus-bedieners benodig geen wysigings nie!
Onbeperkte stoortyd!
Vroeër of later sal ons egter data wil stoor wat verder gaan as die normale Prometheus-retensietyd. Vir die stoor van historiese data, het ons voorwerpberging gekies. Dit is wyd beskikbaar in enige wolk sowel as in datasentrums op die perseel en is baie koste-effektief. Daarbenewens is byna enige voorwerpberging beskikbaar deur die bekende S3 API.
Prometheus skryf ongeveer elke twee uur data vanaf RAM na skyf. Die gestoorde datablok bevat alle data vir 'n vasgestelde tydperk en is onveranderlik. Dit is baie gerieflik, aangesien Thanos Sidecar eenvoudig na die Prometheus-datagids kan kyk en, soos nuwe blokke verskyn, dit in objekbergingsemmers laai.
Die laai in objekberging onmiddellik nadat dit na skyf geskryf is, hou ook die "skraper" eenvoud (Prometheus en Thanos Sidecar) ongeskonde. Dit vergemaklik die instandhouding, koste en ontwerp van die stelsel.
Soos u kan sien, is die rugsteun van data baie maklik om te implementeer. Maar wat van navraag na data in objekberging?
Die Thanos Store-komponent dien as 'n instaanbediener om data van die voorwerpstoor af te kry. Soos Thanos Sidecar, neem dit deel aan die skindergroepering en implementeer die Store API. Bestaande Queriers kan dit dus as 'n Sidecar behandel, as 'n ander bron van tydreeksdata - geen spesiale konfigurasie word vereis nie.
Tydreeksdatablokke bestaan uit verskeie groot lêers. Om hulle op aanvraag te laai, sal taamlik ondoeltreffend wees, en om hulle plaaslik te kas sal 'n groot hoeveelheid geheue en skyfspasie verg.
In plaas daarvan weet Store Gateway hoe om die Prometheus-bergingformaat te hanteer. Danksy 'n slim navraagbeplanner en die kas van slegs die nodige indeksdele van blokke, het dit moontlik geword om komplekse versoeke te verminder tot die minimum aantal HTTP-versoeke om stoorlêers te beswaar. Dit is dus moontlik om die aantal versoeke met vier tot ses ordes van grootte te verminder en 'n reaksietyd te bereik wat oor die algemeen moeilik is om te onderskei van versoeke vir data op 'n plaaslike SSD.
Soos in die diagram hierbo getoon, verminder Thanos Querier die koste per versoek vir data in objekberging aansienlik deur die Prometheus-bergingformaat te gebruik en verwante data langs mekaar te plaas. Deur hierdie benadering te gebruik, kan ons baie enkele versoeke kombineer in 'n minimum aantal grootmaatbewerkings.
Kompaksie en afsteekproefneming
Nadat 'n nuwe blok tydreeksdata suksesvol in die voorwerpstoor gelaai is, beskou ons dit as "historiese" data, wat onmiddellik deur die Winkelpoort beskikbaar is.
Na 'n geruime tyd versamel blokke van een bron (Prometheus met Sidecar) egter en gebruik nie meer die volle potensiaal van indeksering nie. Om hierdie probleem op te los, het ons 'n ander komponent genaamd Compactor bekendgestel. Dit pas eenvoudig die plaaslike Prometheus-kompaksiemeganisme toe op die historiese data in objekberging en kan as 'n eenvoudige periodieke bondelwerk uitgevoer word.
As gevolg van doeltreffende kompressie, hou navraag oor die berging oor 'n lang tydperk nie 'n probleem in terme van datagrootte nie. Die potensiële koste om 'n miljard waardes uit te pak en dit deur 'n navraagverwerker te laat loop, sal egter onvermydelik lei tot 'n dramatiese toename in die uitvoering van navraag. Aan die ander kant, aangesien daar honderde datapunte per pixel op die skerm is, word dit onmoontlik om selfs die data teen volle resolusie weer te gee. Afsteekproefneming is dus nie net moontlik nie, maar sal nie tot 'n merkbare verlies aan akkuraatheid lei nie.
Vir data-afsteekproefneming, versamel Compactor voortdurend data teen 'n resolusie van vyf minute en een uur. Vir elke rou fragment wat met TSDB XOR-kompressie geënkodeer is, word verskeie tipes saamgevoegde data gestoor, soos min, maksimum of som vir een blok. Dit laat Querier toe om outomaties 'n totaal te kies wat geskik is vir 'n gegewe PromQL-navraag.
Geen spesiale konfigurasie is nodig vir die gebruiker om data met verminderde presisie te gebruik nie. Querier skakel outomaties tussen verskillende resolusies en rou data soos die gebruiker in- en uitzoem. Indien verlang, kan die gebruiker dit direk beheer deur die "stap" parameter in die versoek.
Aangesien die bergingskoste van een GB laag is, stoor Thanos die oorspronklike data by verstek, data met 'n resolusie van vyf minute en een uur. Dit is nie nodig om die oorspronklike data uit te vee nie.
Opname reëls
Selfs met Thanos is opnamereëls 'n noodsaaklike deel van die moniteringstapel. Dit verminder die kompleksiteit, vertraging en koste van navrae. Dit is ook gerieflik vir gebruikers om saamgestelde data volgens maatstawwe te kry. Thanos is gebaseer op vanielje-gevalle van Prometheus, so dit is heeltemal aanvaarbaar om opneemreëls en waarskuwingsreëls op 'n bestaande Prometheus-bediener te hou. In sommige gevalle kan dit egter nie genoeg wees nie:
- Globale waarskuwing en reël (byvoorbeeld 'n waarskuwing wanneer 'n diens af is op meer as twee van die drie groepe).
- Reël vir data buite plaaslike berging.
- Die begeerte om alle reëls en waarskuwings op een plek te stoor.
Vir al hierdie gevalle sluit Thanos 'n aparte komponent genaamd Ruler in wat reël en waarskuwing via Thanos-navrae evalueer. Deur 'n bekende StoreAPI te verskaf, kan die Query-nodus toegang tot vars berekende statistieke kry. Later word hulle ook in objekberging gestoor en deur die Store Gateway beskikbaar gestel.
Mag van Thanos
Thanos is buigsaam genoeg om by jou behoeftes aangepas te word. Dit is veral nuttig wanneer jy van gewone Prometheus migreer. Kom ons hersien vinnig wat ons oor Thanos-komponente geleer het deur 'n klein voorbeeld te gebruik. Hier is hoe om jou vanielje Prometheus in die wêreld van "onbeperkte metrieke berging" te bring:
- Voeg Thanos Sidecar by jou Prometheus-bedieners - byvoorbeeld 'n naburige houer in 'n Kubernetes-peul.
- Ontplooi verskeie Thanos Querier-replikas om data te sien. Op hierdie stadium is dit maklik om skinderpraatjies tussen Scraper en Querier op te stel. Om die interaksie van komponente na te gaan, gebruik die 'thanos_cluster_members'-metriek.
Hierdie twee stappe alleen is genoeg om 'n globale aansig en naatlose data-deduplisering van potensiële Prometheus HA-replikas te verskaf! Koppel eenvoudig jou kontroleskerms aan die HTTP Querier-eindpunt of gebruik die Thanos UI-koppelvlak direk.
As u egter metrieke-rugsteun en langtermynbehoud benodig, is daar nog drie stappe wat u moet neem:
- Skep 'n AWS S3- of GCS-emmer. Stel Sidecar op om data na hierdie emmers te kopieer. Jy kan nou plaaslike databerging minimaliseer.
- Ontplooi 'n Winkelpoort en koppel dit aan 'n bestaande skindergroepering. Nou kan jy versoeke na data in rugsteun stuur!
- Ontplooi Compactor om navraagprestasie oor lang tydperke te verbeter deur verdigting en afsteekproefneming te gebruik.
As jy meer wil weet, kyk gerus na ons и !
In net vyf stappe het ons Prometheus in 'n robuuste moniteringstelsel verander met 'n globale aansig, onbeperkte bergingstyd en potensiële hoë beskikbaarheid van statistieke.
Trek versoek: ons het jou nodig!
was van die begin af 'n oopbronprojek. Naatlose integrasie met Prometheus en die vermoë om slegs 'n gedeelte van Thanos te gebruik maak dit 'n uitstekende keuse om jou moniteringstelsel moeiteloos te skaal.
Ons verwelkom altyd GitHub Pull-versoeke en -kwessies. Kontak ons intussen gerus via Github Issues of slackas jy vrae of terugvoer het, of jou ervaring wil deel! As jy hou van wat ons by Improbable doen kontak ons gerus - !
Bron: will.com