De oersetting fan it artikel waard spesifyk taret foar de learlingen fan 'e kursus .
is in softwareûntwikkelder, Go fanatyk, en probleemoplosser. Hy is ek in Prometheus-ûnderhâlder en mei-oprjochter fan Kubernetes SIG-ynstrumintaasje. Yn it ferline wie hy in produksje-yngenieur by SoundCloud en late it tafersjochteam by CoreOS. Wurket op it stuit by Google.
- Ynfrastruktueringenieur by Improbable. Hy is ynteressearre yn nije technologyen en problemen fan ferdielde systemen. Hy hat programmearringûnderfining op leech nivo by Intel, meiwurkerûnderfining by Mesos, en SRE-produksjeûnderfining fan wrâldklasse by Improbable. Tawijd oan it ferbetterjen fan de wrâld fan mikrotsjinsten. Syn trije leafdes: Golang, iepen boarne en follybal.
As jo sjogge nei ús flaggeskipprodukt SpatialOS, kinne jo riede dat Improbable in heul dynamyske, wrâldwide wolkynfrastruktuer fereasket mei tsientallen Kubernetes-klusters. Wy wiene ien fan de earsten dy't in tafersjochsysteem brûkten . Prometheus is yn steat om miljoenen metriken yn echte tiid te folgjen en komt mei in krêftige query-taal wêrmei jo de ynformaasje kinne ekstrahearje dy't jo nedich binne.
De ienfâld en betrouberens fan Prometheus is ien fan har wichtichste foardielen. As wy lykwols in bepaalde skaal foarby kamen, tsjinkamen wy ferskate neidielen. Om dizze problemen op te lossen hawwe wy ûntwikkele is in iepen boarne-projekt makke troch Improbable om besteande Prometheus-klusters naadloos te transformearjen yn ien inkeld tafersjochsysteem mei ûnbeheinde opslach fan histoaryske gegevens. Thanos is beskikber op Github .
Us doelen mei Thanos
Op in bepaalde skaal ûntsteane problemen dy't bûten de mooglikheden fan vanille Prometheus binne. Hoe kinne jo petabytes oan histoaryske gegevens betrouber en ekonomysk opslaan? Kin dit dien wurde sûnder de reaksjetiid te kompromittearjen? Is it mooglik om tagong te krijen ta alle metriken dy't lizze op ferskate Prometheus-tsjinners mei ien API-fersyk? Is d'r ien manier om replike gegevens te kombinearjen sammele mei Prometheus HA?
Om dizze problemen oan te pakken, hawwe wy Thanos makke. De folgjende seksjes beskriuwe hoe't wy dizze problemen oanpakten en ús doelen ferklearje.
Gegevens opfreegje fan meardere Prometheus-eksimplaren (globale query)
Prometheus biedt in funksjonele oanpak foar sharding. Sels in inkele Prometheus-tsjinner biedt genôch skalberens om brûkers te befrijen fan 'e kompleksiteiten fan horizontale sharding yn hast alle gebrûksgefallen.
Hoewol dit in geweldich ynsetmodel is, is it faaks nedich om tagong te krijen ta gegevens op ferskate Prometheus-tsjinners fia ien API of UI - in globale werjefte. Fansels is it mooglik om meardere queries yn ien Grafana-paniel te werjaan, mar elke query kin allinich útfierd wurde op ien Prometheus-tsjinner. Oan 'e oare kant kinne jo mei Thanos gegevens opfreegje en aggregearje fan meardere Prometheus-tsjinners, om't se allegear tagonklik binne fan ien einpunt.
Earder, om in globale werjefte yn Improbable te krijen, organisearren wy ús Prometheus-eksimplaren yn in multi-level . Dit betsjutte it meitsjen fan ien Prometheus-metaserver dy't guon fan 'e metriken fan elke blêdserver sammelet.
Dizze oanpak bliek problematysk. Dit hat resultearre yn mear komplekse konfiguraasjes, de tafoeging fan in ekstra potinsjeel punt fan mislearring, en it tapassen fan komplekse regels om te soargjen dat it federearre einpunt allinich de gegevens ûntfangt dy't it nedich is. Derneist lit dit soarte federaasje jo net in wiere globale werjefte krije, om't net alle gegevens beskikber binne fan ien API-fersyk.
Nau besibbe oan dit is in ienriedige werjefte fan de gegevens sammele op hege-beskikberens (HA) Prometheus tsjinners. It HA-model fan Prometheus sammelt twa kear ûnôfhinklik gegevens, wat sa ienfâldich is dat it net ienfâldiger kin. It brûken fan in kombinearre en deduplicate werjefte fan beide streamen soe lykwols folle handiger wêze.
Fansels is d'r ferlet fan heech beskikbere Prometheus-tsjinners. By Improbable nimme wy minút foar minút gegevensmonitoring echt serieus, mar ien Prometheus-eksimplaar per kluster hawwe is in ienich punt fan mislearring. Elke konfiguraasjeflater of hardwarefout kin mooglik liede ta it ferlies fan wichtige gegevens. Sels in ienfâldige ynset kin lytse fersteuringen feroarsaakje yn it sammeljen fan metriken, om't opstarten oanmerklik langer kinne wêze dan it skrapynterval.
Betroubere opslach fan histoaryske gegevens
Goedkeape, rappe opslach fan metriken op lange termyn is ús dream (dield troch de measte Prometheus-brûkers). Yn Improbable waarden wy twongen om de behâldperioade fan metriken te konfigurearjen nei njoggen dagen (foar Prometheus 1.8). Dit foeget dúdlike grinzen ta oan hoe fier werom wy kinne sjen.
Prometheus 2.0 is yn dit ferbân ferbettere, om't it oantal tiidsearjes net mear ynfloed hat op de algemiene prestaasjes fan 'e tsjinner (sjoch. ). Prometheus bewarret lykwols gegevens op lokale skiif. Hoewol't hege-effisjinsje gegevens kompresje kin gâns ferminderje lokale SSD gebrûk, der is úteinlik noch in limyt oan it bedrach fan histoaryske gegevens dat kin wurde opslein.
Derneist jouwe wy by Improbable oer betrouberens, ienfâld en kosten. Grutte lokale skiven binne dreger te betsjinjen en reservekopy. Se kostje mear en fereaskje mear reservekopy-ark, wat resulteart yn ûnnedige kompleksiteit.
Downsampling
Sadree't wy begon te wurkjen mei histoaryske gegevens, realisearre wy dat d'r fûnemintele swierrichheden binne mei big-O dy't fragen stadiger en stadiger meitsje as wy wurkje mei wiken, moannen en jierren oan gegevens.
De standert oplossing foar dit probleem soe wêze (downsampling) - it ferminderjen fan it sinjaal sampling frekwinsje. Mei downsampling kinne wy "ôfskaalje" nei in grutter tiidberik en itselde oantal samples behâlde, queries responsyf hâlde.
Downsampling fan âlde gegevens is in ûnûntkombere eask fan elke oplossing op lange termyn opslach en is bûten it berik fan vanille Prometheus.
Oanfoljende doelen
Ien fan 'e oarspronklike doelen fan it Thanos-projekt wie om naadloos te yntegrearjen mei alle besteande Prometheus-ynstallaasjes. It twadde doel wie gemak fan operaasje mei minimale barriêres foar yngong. Elke ôfhinklikens moatte maklik tefreden wêze foar sawol lytse as grutte brûkers, wat ek in lege basiskosten betsjut.
Thanos arsjitektuer
Nei't jo ús doelen yn 'e foarige seksje listje, litte wy der troch wurkje en sjen hoe't Thanos dizze problemen oplost.
Global werjefte
Om in globale werjefte te krijen boppe op besteande Prometheus-eksimplaren, moatte wy in inkeld fersykyngongspunt oan alle servers keppelje. Dit is krekt wat de Thanos-komponint docht. . It wurdt ynset neist elke Prometheus-tsjinner en fungearret as proxy, dy't lokale Prometheus-gegevens tsjinnet fia de gRPC Store API, wêrtroch tiidreeksgegevens kinne wurde ophelle troch tag en tiidberik.
Oan 'e oare kant is de skaalfergrutting, steatleaze Querier-komponint, dy't net folle mear docht dan allinich PromQL-fragen beantwurdzje fia de standert Prometheus HTTP API. Querier, Sidecar en oare Thanos-komponinten kommunisearje fia .
- Querier, by ûntfangst fan in fersyk, ferbynt mei de oerienkommende Store API tsjinner, dat is, nei ús Sidecars en ûntfangt tiid rige gegevens fan de oerienkommende Prometheus tsjinners.
- Dêrnei kombinearret it de antwurden en fiert in PromQL-query derop út. Querier kin sawol disjoint gegevens en dûbele gegevens fan Prometheus HA-tsjinners fusearje.
Dit lost in wichtich stik fan ús puzel op - it kombinearjen fan gegevens fan isolearre Prometheus-tsjinners yn ien werjefte. Eins kin Thanos allinich brûkt wurde foar dizze funksje. Gjin feroarings hoege te meitsjen oan besteande Prometheus-tsjinners!
Unbeheind houdbaarheid!
Earder of let sille wy lykwols gegevens wolle opslaan bûten de normale retinsjetiid fan Prometheus. Wy hawwe foarwerp opslach keazen om histoaryske gegevens op te slaan. It is breed beskikber yn elke wolk lykas datasintra op it terrein en is heul kosteneffektiv. Dêrneist is hast alle objekt opslach beskikber fia de bekende S3 API.
Prometheus skriuwt gegevens fan RAM nei skiif sawat elke twa oeren. It bewarre gegevensblok befettet alle gegevens foar in fêste perioade en is ûnferoarlik. Dit is heul handich, om't Thanos Sidecar gewoan kin sjen nei de Prometheus-gegevensmap en, as nije blokken beskikber wurde, se laden yn objektopslachbakken.
Laden yn objekt opslach fuortendaliks nei it skriuwen op skiif kinne jo ek behâlde de ienfâld fan de scraper (Prometheus en Thanos Sidecar). Wat simplifies stipe, kosten en systeem design.
Sa't jo sjen kinne, gegevens backup is hiel simpel. Mar hoe sit it mei it opfreegjen fan gegevens yn objektopslach?
De Thanos Store-komponint fungearret as proxy om gegevens op te heljen fan objektopslach. Lykas Thanos Sidecar, docht it mei oan it roddelkluster en ymplementearret de Store API. Op dizze manier kin besteande Querier it behannelje as in Sidecar, as in oare boarne fan tiidreeksgegevens - gjin spesjale konfiguraasje nedich.
Tiid rige gegevens blokken besteane út ferskate grutte triemmen. It laden fan se op fraach soe frij net effisjint wêze, en it pleatsen fan se lokaal soe in enoarme hoemannichte ûnthâld en skiifromte fereaskje.
Ynstee wit Store Gateway hoe't jo it Prometheus-opslachformaat moatte behannelje. Mei tank oan in tûke query scheduler en caching allinnich de nedige yndeks dielen fan blokken, is it mooglik om te ferminderjen komplekse queries nei in minimum oantal HTTP-fersiken om objekt opslach triemmen. Op dizze manier kinne jo it oantal oanfragen ferminderje mei fjouwer oant seis oarders fan grutte en berikke reaksjetiden dy't oer it algemien dreech te ûnderskieden binne fan fersiken nei gegevens op in lokale SSD.
Lykas werjûn yn it diagram hjirboppe, ferleget Thanos Querier de kosten per query fan objektopslachgegevens signifikant troch it Prometheus-opslachformaat te brûken en relatearre gegevens njonken inoar te pleatsen. Mei dizze oanpak kinne wy in protte inkele oanfragen kombinearje yn in minimum oantal bulk operaasjes.
Ferpakking en downsampling
Sadree't in nij blok fan tiidreeksgegevens mei súkses yn objektopslach laden is, behannelje wy it as "histoaryske" gegevens, dy't direkt beskikber binne fia de Store Gateway.
Nei in skoft sammele blokken fan ien boarne (Prometheus mei Sidecar) lykwols en brûke it folsleine yndeksearpotinsjeel net mear. Om dit probleem op te lossen, yntrodusearre wy in oare komponint neamd Compactor. It tapast gewoan de lokale kompakteringsmotor fan Prometheus op histoaryske gegevens yn objektopslach en kin wurde útfierd as in ienfâldige periodike batch-taak.
Mei tank oan effisjinte kompresje is it freegjen fan de opslach oer in lange perioade gjin probleem yn termen fan gegevensgrutte. De potinsjele kosten fan it útpakken fan in miljard wearden en it útfieren fan se fia in query-prosessor sille lykwols ûnferjitlik resultearje yn in dramatyske ferheging fan query-útfiertiid. Oan 'e oare kant, om't d'r hûnderten gegevenspunten per piksel op it skerm binne, wurdt it ûnmooglik om de gegevens sels yn folsleine resolúsje te visualisearjen. Sa is downsampling net allinich mooglik, mar sil ek net liede ta in merkber ferlies fan krektens.
Om gegevens te downsample, sammelt Compactor kontinu gegevens mei in resolúsje fan fiif minuten en ien oere. Foar elke rauwe brok kodearre mei TSDB XOR-kompresje, wurde ferskate soarten aggregaatgegevens opslein, lykas min, max of som foar ien blok. Hjirmei kin Querier automatysk in aggregaat selektearje dat passend is foar in opjûne PromQL-fraach.
Gjin spesjale konfiguraasje is nedich foar de brûker te brûken fermindere presyzje gegevens. Querier skeakelt automatysk tusken ferskate resolúsjes en rauwe gegevens as de brûker yn- en útzoomt. As jo wolle, kin de brûker dit direkt kontrolearje fia de "stap" parameter yn it fersyk.
Sûnt de kosten foar it opslaan fan ien GB leech binne, bewarret Thanos standert rûge gegevens, resolúsjegegevens fan fiif minuten en ien oere. It is net nedich om de orizjinele gegevens te wiskjen.
Opname regels
Sels mei Thanos binne opnameregels in essinsjeel ûnderdiel fan 'e tafersjochstapel. Se ferminderje kompleksiteit, latency en kosten fan queries. Se binne ek handich foar brûkers om aggregearre gegevens te krijen troch metriken. Thanos is basearre op vanille Prometheus-eksimplaren, dus it is perfoarst akseptabel om opnameregels en warskôgingsregels op te slaan op in besteande Prometheus-tsjinner. Yn guon gefallen kin dit lykwols net genôch wêze:
- Globale warskôging en regel (bygelyks in warskôging as in tsjinst net wurket op mear as twa fan trije klusters).
- Regel foar gegevens bûten lokale opslach.
- De winsk om alle regels en warskôgings op ien plak te bewarjen.
Foar al dizze gefallen omfettet Thanos in aparte komponint neamd Ruler, dy't regel en warskôging berekkent fia Thanos Queries. Troch in bekende StoreAPI te leverjen, kin de Query-knooppunt tagong krije ta nij berekkene metriken. Letter wurde se ek opslein yn objektopslach en beskikber steld fia de Store Gateway.
De krêft fan Thanos
Thanos is fleksibel genôch om oan te passen oan jo behoeften. Dit is benammen nuttich by it migrearjen fan gewoane Prometheus. Litte wy fluch gearfetsje wat wy hawwe leard oer Thanos-komponinten mei in rap foarbyld. Hjir is hoe't jo jo vanille Prometheus meinimme yn 'e wrâld fan "ûnbeheinde opslach fan metriken":
- Foegje Thanos Sidecar ta oan jo Prometheus-servers - bygelyks in sidecar-container yn in Kubernetes-pod.
- Ynsette meardere Thanos Querier-replika's om gegevens te besjen. Op dit stadium is it maklik om roddels op te setten tusken Scraper en Querier. Om de ynteraksje fan komponinten te kontrolearjen, brûk de metrik 'thanos_cluster_members'.
Krekt dizze twa stappen binne genôch om globale werjefte en naadleaze gegevens deduplication fan potinsjele Prometheus HA replika's! Ferbine jo dashboards gewoan oan it Querier HTTP-einpunt of brûk de Thanos UI direkt.
As jo lykwols metriken-backup en opslach op lange termyn nedich binne, moatte jo noch trije stappen foltôgje:
- Meitsje in AWS S3- as GCS-emmer. Sidecar konfigurearje om gegevens nei dizze bakken te kopiearjen. Lokale gegevens opslach kin no wurde minimalisearre.
- Ynsette Store Gateway en ferbine it mei jo besteande roddelkluster. No kinne jo de reservekopy gegevens opfreegje!
- Ynsette Compactor om query-effisjinsje te ferbetterjen oer lange perioaden mei komprimearjen en downsampling.
As jo mear witte wolle, aarzel dan net om ús te besjen и !
Yn mar fiif stappen hawwe wy Prometheus feroare yn in betrouber tafersjochsysteem mei globale werjefte, ûnbeheinde opslachtiid en potinsjele hege beskikberens fan metriken.
Pull fersyk: wy hawwe jo nedich!
hat fan it begjin ôf in iepen boarne-projekt west. Naadleaze yntegraasje mei Prometheus en de mooglikheid om mar in diel fan Thanos te brûken makket it in poerbêste kar foar it maklik skaaljen fan jo tafersjochsysteem.
Wy ferwolkomje altyd GitHub Pull-oanfragen en problemen. Fiel jo yn 'e tuskentiid frij om kontakt mei ús op te nimmen fia Github Issues of slackas jo fragen of feedback hawwe, of jo ûnderfining mei it diele wolle diele! As jo leuk fine wat wy dogge by Improbable, aarzel dan net om kontakt mei ús op te nimmen - !
Boarne: www.habr.com