Podatkovna baza časovnih vrst (TSDB) v Prometheusu 2 je odličen primer inženirske rešitve, ki ponuja velike izboljšave v primerjavi s shranjevanjem v2 v Prometheusu 1 v smislu hitrosti kopičenja podatkov, izvajanja poizvedb in učinkovitosti virov. Implementirali smo Prometheus 2 v Percona Monitoring and Management (PMM) in imel sem priložnost razumeti delovanje Prometheus 2 TSDB. V tem članku bom govoril o rezultatih teh opazovanj.
Povprečna delovna obremenitev Prometheus
Za tiste, ki so navajeni delati s splošnimi bazami podatkov, je tipična Prometheusova delovna obremenitev zelo zanimiva. Hitrost kopičenja podatkov je običajno stabilna: običajno storitve, ki jih spremljate, pošiljajo približno enako število meritev, infrastruktura pa se spreminja relativno počasi.
Zahteve za informacije lahko prihajajo iz različnih virov. Nekateri od njih, kot so opozorila, prav tako stremijo k stabilni in predvidljivi vrednosti. Druge, kot so zahteve uporabnikov, lahko povzročijo izbruhe, čeprav to ne velja za večino delovnih obremenitev.
Obremenitveni test
Med testiranjem sem se osredotočil na zmožnost kopičenja podatkov. Prometheus 2.3.2, preveden z Go 1.10.1 (kot del PMM 1.14), sem namestil v storitvi Linode s tem skriptom: . Za najbolj realistično ustvarjanje obremenitve uporabite to Zagnal sem več MySQL vozlišč z resnično obremenitvijo (Sysbench TPC-C Test), od katerih je vsako posnemalo 10 Linux/MySQL vozlišč.
Vsi naslednji testi so bili izvedeni na strežniku Linode z osmimi navideznimi jedri in 32 GB pomnilnika, ki izvaja 20 simulacij obremenitve, ki spremljajo dvesto primerkov MySQL. Ali, v izrazih Prometheusa, 800 tarč, 440 prask na sekundo, 380 tisoč zapisov na sekundo in 1,7 milijona aktivnih časovnih vrst.
Oblikovanje
Običajni pristop tradicionalnih baz podatkov, vključno s tisto, ki jo uporablja Prometheus 1.x, je . Če ne zadostuje za obvladovanje obremenitve, boste imeli visoke zakasnitve in nekatere zahteve ne bodo uspele. Uporaba pomnilnika v Prometheusu 2 je nastavljiva s tipko storage.tsdb.min-block-duration, ki določa, kako dolgo bodo posnetki shranjeni v pomnilniku pred izpiranjem na disk (privzeto je 2 uri). Količina potrebnega pomnilnika bo odvisna od števila časovnih vrst, oznak in strganja, dodanih v neto dohodni tok. Kar zadeva prostor na disku, si Prometheus prizadeva uporabiti 3 bajte na zapis (vzorec). Po drugi strani pa so zahteve po pomnilniku veliko višje.
Čeprav je možno konfigurirati velikost bloka, ni priporočljivo, da ga konfigurirate ročno, tako da ste prisiljeni dati Prometheusu toliko pomnilnika, kot ga potrebuje za vašo delovno obremenitev.
Če ni dovolj pomnilnika za podporo dohodnega toka metrik, bo Prometheus izpadel iz pomnilnika ali pa bo do njega prišel ubijalec OOM.
Dodajanje zamenjave za odložitev zrušitve, ko Prometheusu zmanjka pomnilnika, v resnici ne pomaga, ker uporaba te funkcije povzroči eksplozivno porabo pomnilnika. Mislim, da je to povezano z Go, njegovim zbiralnikom smeti in načinom, kako obravnava zamenjavo.
Še en zanimiv pristop je konfiguracija glavnega bloka, ki se splakne na disk ob določenem času, namesto da bi ga šteli od začetka procesa.
Kot lahko vidite iz grafa, se izpiranja na disk zgodijo vsaki dve uri. Če spremenite parameter min-block-duration na eno uro, se bodo te ponastavitve izvajale vsako uro, začenši po pol ure.
Če želite uporabiti ta in druge grafe v svoji namestitvi Prometheus, lahko uporabite tega . Zasnovan je bil za PMM, vendar se z manjšimi spremembami prilega kateri koli namestitvi Prometheus.
Imamo aktivni blok, imenovan glavni blok, ki je shranjen v pomnilniku; bloki s starejšimi podatki so na voljo prek mmap(). To odpravlja potrebo po ločeni konfiguraciji predpomnilnika, pomeni pa tudi, da morate pustiti dovolj prostora za predpomnilnik operacijskega sistema, če želite poizvedovati po podatkih, starejših od tistega, kar lahko sprejme glavni blok.
To tudi pomeni, da bo poraba virtualnega pomnilnika Prometheus precej visoka, kar pa ni razlog za skrb.
Druga zanimiva oblikovalska točka je uporaba WAL (dnevnik pisanja naprej). Kot lahko vidite iz dokumentacije za shranjevanje, Prometheus uporablja WAL, da se izogne zrušitvam. Posebni mehanizmi za zagotavljanje preživetja podatkov na žalost niso dobro dokumentirani. Prometheus različice 2.3.2 izprazni WAL na disk vsakih 10 sekund in te možnosti uporabnik ne more konfigurirati.
Zbijanja
Prometheus TSDB je zasnovan kot shramba LSM (Log Structured Merge): glavni blok se občasno splakne na disk, medtem ko mehanizem za stiskanje združi več blokov skupaj, da se prepreči skeniranje preveč blokov med poizvedbami. Tukaj lahko vidite število blokov, ki sem jih opazil na testnem sistemu po dnevu obremenitve.
Če želite izvedeti več o trgovini, si lahko ogledate datoteko meta.json, ki vsebuje informacije o razpoložljivih blokih in o tem, kako so nastali.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}Zbijanja v Prometheusu so vezana na čas, ko se glavni blok splakne na disk. Na tej točki se lahko izvede več takih operacij.
Zdi se, da stiskanje ni na noben način omejeno in lahko med izvajanjem povzroči velike V/I skoke.
Skoki obremenitve procesorja
Seveda ima to precej negativen vpliv na hitrost sistema in predstavlja tudi resen izziv za shranjevanje LSM: kako narediti zgoščevanje, da bi podprli visoke stopnje zahtev, ne da bi povzročili prevelike stroške?
Tudi uporaba pomnilnika v procesu stiskanja je videti precej zanimiva.
Vidimo lahko, kako po stiskanju večina pomnilnika spremeni stanje iz predpomnjenega v prosto: to pomeni, da so bile od tam odstranjene potencialno dragocene informacije. Zanima me, če se uporablja tukaj fadvice() ali kakšno drugo tehniko minimiziranja ali pa zato, ker je bil predpomnilnik osvobojen blokov, uničenih med stiskanjem?
Okrevanje po neuspehu
Okrevanje po napakah zahteva čas in z dobrim razlogom. Za dohodni tok milijona zapisov na sekundo sem moral čakati približno 25 minut, medtem ko je potekala obnovitev ob upoštevanju pogona SSD.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."Glavna težava postopka obnovitve je velika poraba pomnilnika. Kljub dejstvu, da lahko strežnik v normalnih razmerah deluje stabilno z enako količino pomnilnika, se ob zrušitvi morda ne bo obnovil zaradi OOM. Edina rešitev, ki sem jo našel, je bila, da onemogočim zbiranje podatkov, zaženem strežnik, pustim, da si opomore in znova zaženem z omogočenim zbiranjem.
Ogrevanje
Drugo vedenje, ki ga morate upoštevati med ogrevanjem, je razmerje med nizko zmogljivostjo in visoko porabo virov takoj po začetku. Med nekaterimi, vendar ne pri vseh zagonih, sem opazil resno obremenitev procesorja in pomnilnika.
Vrzeli v uporabi pomnilnika kažejo, da Prometheus ne more konfigurirati vseh zbirk od začetka, in nekatere informacije so izgubljene.
Nisem ugotovil natančnih razlogov za visoko obremenitev procesorja in pomnilnika. Sumim, da je to posledica ustvarjanja novih časovnih vrst v bloku glave z visoko frekvenco.
skokovita obremenitev procesorja
Poleg zgoščevanja, ki ustvarja precej visoko V/I obremenitev, sem opazil resne skoke v obremenitvi CPU vsaki dve minuti. Izbruhi so daljši, ko je vhodni tok visok in se zdi, da jih povzroča Gojev zbiralnik smeti, pri čemer so vsaj nekatera jedra popolnoma naložena.
Ti skoki niso tako nepomembni. Zdi se, da ko se to zgodi, Prometheusova notranja vstopna točka in meritve postanejo nedostopni, kar povzroča vrzeli v podatkih v teh istih časovnih obdobjih.
Opazite lahko tudi, da se izvoznik Prometheus za eno sekundo izklopi.
Opazimo lahko korelacije z zbiranjem smeti (GC).
Zaključek
TSDB v Prometheusu 2 je hiter, z dokaj skromno strojno opremo zmore na milijone časovnih vrst in hkrati na tisoče zapisov na sekundo. Impresivna je tudi izkoriščenost procesorja in diska I/O. Moj primer je pokazal do 200 metrik na sekundo na uporabljeno jedro.
Če želite načrtovati širitev, se morate spomniti na zadostno količino pomnilnika in to mora biti pravi pomnilnik. Količina uporabljenega pomnilnika, ki sem jo opazil, je bila približno 5 GB na 100 zapisov na sekundo dohodnega toka, kar je skupaj s predpomnilnikom operacijskega sistema dalo približno 000 GB zasedenega pomnilnika.
Seveda je treba opraviti še veliko dela, da bi ukrotili konice V/I CPU in diska, kar ni presenetljivo glede na to, kako mlad je TSDB Prometheus 2 v primerjavi z InnoDB, TokuDB, RocksDB, WiredTiger, vendar so vsi imeli podobno težave zgodaj v njihovem življenjskem ciklu.
Vir: www.habr.com