Baza podataka vremenskih serija (TSDB) u Prometheusu 2 je odličan primjer inženjerskog rješenja koje nudi značajna poboljšanja u odnosu na Prometheus 2 skladište v1 u smislu prikupljanja podataka i brzine izvršavanja upita, te efikasnosti resursa. Implementirali smo Prometheus 2 u Percona Monitoring and Management (PMM) i imao sam priliku da razumijem performanse Prometheus 2 TSDB. U ovom članku ću govoriti o rezultatima ovih zapažanja.
Prometheus Average Workload
Za one koji su navikli da rade sa bazama podataka opšte namene, tipično radno opterećenje Prometheusa je prilično zanimljivo. Stopa akumulacije podataka teži stabilnoj vrijednosti: obično usluge koje nadgledate šalju približno istu količinu metrike, a infrastruktura se mijenja relativno sporo.
Zahtjevi za informacijama mogu doći iz različitih izvora. Neki od njih, poput upozorenja, također imaju za cilj stabilnu i predvidljivu vrijednost. Drugi, kao što su zahtjevi korisnika, mogu uzrokovati skokove, iako to nije slučaj za većinu radnog opterećenja.
Test opterećenja
Tokom testiranja, fokusirao sam se na sposobnost akumulacije podataka. Postavio sam Prometheus 2.3.2 kompajliran sa Go 1.10.1 (kao dio PMM 1.14) na Linode servis koristeći ovu skriptu: . Za najrealnije generiranje opterećenja, s ovim Pokrenuo sam nekoliko MySQL čvorova sa stvarnim opterećenjem (Sysbench TPC-C test), od kojih je svaki emulirao 10 Linux/MySQL čvorova.
Svi sljedeći testovi su izvedeni na Linode serveru sa osam vCore i 32 GB memorije, uz 20 simulacija opterećenja praćenja 800 MySQL instanci. Ili, u smislu Prometeja, 440 ciljeva (cilja), 380 naknada (scrape-ova) u sekundi, 1,7 hiljada zapisa (uzoraka) u sekundi i XNUMX miliona aktivnih vremenskih serija.
Dizajn
Uobičajeni tradicionalni pristup bazi podataka, uključujući i onaj koji koristi Prometheus 1.x, je da . Ako to nije dovoljno da se nosi sa opterećenjem, iskusit ćete veliku latenciju i neki zahtjevi neće biti ispunjeni. Upotreba memorije u Prometheusu 2 se može konfigurirati putem ključa storage.tsdb.min-block-duration, koji određuje koliko dugo će se zapisi čuvati u memoriji prije nego što se isprazne na disk (podrazumevano je 2 sata). Količina potrebne memorije ovisit će o broju vremenskih serija, oznaka i scrapeova, plus neto ulaz. Što se tiče prostora na disku, Prometheus ima za cilj da koristi 3 bajta po zapisu (uzorak). S druge strane, zahtjevi za memorijom su mnogo veći.
Iako je moguće konfigurirati veličinu bloka, nije preporučljivo da je postavljate ručno, tako da vam ostaje zadatak da date Prometheusu onoliko memorije koliko mu je potrebno za vaše radno opterećenje.
Ako nema dovoljno memorije da podrži dolazni tok metrike, Prometheus će ispasti iz memorije ili će ga uhvatiti OOM ubica.
Dodavanje zamjene za odlaganje pada kada Prometheusu ponestane memorije zapravo ne pomaže, jer korištenje ove funkcije uzrokuje eksplozije memorije. Mislim da se radi o Go-u, njegovom sakupljaču smeća i kako radi sa swapom.
Još jedan interesantan pristup je postavljanje glavnog bloka da se isprazni na disk u određeno vrijeme, umjesto da se računa od trenutka kada je proces započeo.
Kao što možete vidjeti iz grafikona, flushes na disk se dešavaju svaka dva sata. Ako promijenite parametar min-block-duration na jedan sat, tada će se ova resetiranja dogoditi svakih sat vremena, počevši od pola sata.
Ako želite koristiti ovaj i druge grafove u vašoj Prometheus instalaciji, možete koristiti ovo . Dizajniran je za PMM, ali se uz nekoliko modifikacija uklapa u svaku Prometheusovu instalaciju.
Imamo aktivni blok, koji se zove glavni blok, koji je pohranjen u memoriji; blokovi sa starijim podacima dostupni su preko mmap(). Ovo uklanja potrebu da zasebno konfigurišete keš memoriju, ali takođe znači da morate ostaviti dovoljno prostora za keš memoriju operativnog sistema ako želite da tražite podatke starije od glavnog bloka.
To također znači da će Prometheusova potrošnja virtuelne memorije izgledati prilično visoka, što nema razloga za brigu.
Još jedna zanimljiva tačka dizajna je upotreba WAL-a (dnevnik pisanja unaprijed). Kao što možete vidjeti iz dokumentacije spremišta, Prometheus koristi WAL da izbjegne padove. Specifični mehanizmi za garantovanje preživljavanja podataka, nažalost, nisu dobro dokumentovani. Prometheus 2.3.2 ispušta WAL na disk svakih 10 sekundi i ovu postavku korisnik ne može konfigurirati.
Seals
Prometheus TSDB je dizajniran na isti način kao LSM (Log Structured Merge) skladište: glavni blok se povremeno ispušta na disk, dok mehanizam za sabijanje spaja više blokova zajedno kako bi se izbjeglo skeniranje previše blokova na upite. Ovdje možete vidjeti broj blokova koje sam uočio na testnom sistemu nakon jednog dana opterećenja.
Ako želite saznati više o skladištu, možete provjeriti datoteku meta.json, koja sadrži informacije o dostupnim blokovima i kako su 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
}Pečati u Prometeju su vezani za vrijeme kada je blok glave ispran na disk. U ovom trenutku može se izvesti nekoliko takvih operacija.
Čini se da zbijanje nije ograničeno ni na koji način i može uzrokovati velike I/O skokove na disku tokom izvršavanja.
Brzi opterećenja CPU-a
Naravno, ovo ima prilično negativan uticaj na brzinu sistema, a takođe je i ozbiljan izazov za LSM skladišta: kako napraviti sažimanje da bi se podržale velike brzine upita bez izazivanja prevelikih troškova?
Upotreba memorije u procesu sabijanja također izgleda prilično znatiželjna.
Možemo vidjeti kako, nakon sažimanja, većina memorije mijenja stanje iz keširana u slobodna: to znači da su potencijalno vrijedne informacije odatle uklonjene. Zanima me da li se koristi ovdje fadvice() ili neka druga tehnika minimizacije, ili je to zato što je keš ispražnjen od blokova uništenih sabijanjem?
Oporavak nakon greške
Oporavak od katastrofe zahtijeva vrijeme, i to s dobrim razlogom. Za dolazni stream od milion zapisa u sekundi, morao sam čekati oko 25 minuta dok je oporavak uzimao u obzir SSD disk.
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."Glavni problem procesa oporavka je velika potrošnja memorije. Iako server može raditi stabilno sa istom količinom memorije u normalnoj situaciji, ako se sruši, možda neće rasti zbog OOM-a. Jedino rješenje koje sam pronašao je da isključim prikupljanje podataka, pokrenem server, pustim da se oporavi i ponovo pokrenem sa omogućenim prikupljanjem.
Zagrijavanje
Još jedno ponašanje koje treba imati na umu tokom zagrijavanja je omjer niske performanse i velike potrošnje resursa odmah nakon pokretanja. Tokom nekih, ali ne svih pokretanja, primijetio sam ozbiljno opterećenje CPU-a i memorije.
Padovi u korištenju memorije ukazuju na to da Prometheus ne može konfigurirati sve naknade od početka, a neke informacije su izgubljene.
Nisam otkrio tačne razloge za veliku potrošnju CPU-a i memorije. Pretpostavljam da je to zbog stvaranja novih vremenskih serija u glavnom bloku sa visokom frekvencijom.
CPU skokovi
Pored zgušnjavanja, koje stvaraju prilično veliko I/O opterećenje, primijetio sam ozbiljne skokove u opterećenju CPU-a svake dvije minute. Rafali su duži s velikim dolaznim prometom i izgledaju kao da su uzrokovani Go sakupljačem smeća, barem su neka jezgra potpuno napunjena.
Ovi skokovi nisu tako beznačajni. Čini se da kada se dogode, Prometheus interna ulazna tačka i metrika postaju nedostupni, što uzrokuje pad podataka u istim vremenskim intervalima.
Također možete primijetiti da se Prometheus izvoznik gasi na jednu sekundu.
Možemo vidjeti korelacije sa prikupljanjem smeća (GC).
zaključak
TSDB u Prometheusu 2 je brz, sposoban da rukuje milionima vremenskih serija i istovremeno hiljadama zapisa u sekundi koristeći prilično skroman hardver. Iskorišćenost CPU-a i diska I/O je takođe impresivna. Moj primjer je pokazao do 200 metrika u sekundi po korištenom jezgru.
Da biste planirali proširenje, morate zapamtiti da ima dovoljno memorije i da to mora biti stvarna memorija. Količina korišćene memorije, koju sam primetio, bila je oko 5 GB na 100 zapisa u sekundi dolaznog toka, što je, zajedno sa kešom operativnog sistema, dalo oko 000 GB zauzete memorije.
Naravno, ima još puno posla da se ukroti CPU i disk I/O skokovi, i to nije iznenađujuće, s obzirom na to koliko je TSDB Prometheus 2 mlad u poređenju sa InnoDB, TokuDB, RocksDB, WiredTigerom, ali svi su imali slični problemi na početku njihovog životnog ciklusa.
izvor: www.habr.com