Prometheus 2-ko denbora-serieen datu-basea (TSDB) Prometheus 2-en v1 biltegiratzearekiko hobekuntza handiak eskaintzen dituen ingeniaritza-soluzio baten adibide bikaina da datu-metatze-abiadurari, kontsultaren exekuzioari eta baliabideen eraginkortasunari dagokionez. Prometheus 2 inplementatzen ari ginen Percona Monitoring and Management (PMM) eta Prometheus 2 TSDBren errendimendua ulertzeko aukera izan nuen. Artikulu honetan behaketa horien emaitzei buruz hitz egingo dut.
Prometheusen batez besteko lan-karga
Helburu orokorreko datu-baseekin jorratzen ohituta daudenentzat, Prometheus-en ohiko lan-karga nahiko interesgarria da. Datuen metaketa-tasa egonkorra izan ohi da: normalean kontrolatzen dituzun zerbitzuek gutxi gorabehera metrika kopuru bera bidaltzen dute eta azpiegitura nahiko motel aldatzen da.
Informazio eskaerak hainbat iturritatik etor daitezke. Horietako batzuk, alertak adibidez, balio egonkor eta aurreikusgarri bat lortzeko ahalegina egiten dute. Beste batzuek, hala nola, erabiltzaileen eskaerak, leherketak eragin ditzakete, lan-karga gehienetan horrela ez den arren.
Karga proba
Probetan, datuak pilatzeko gaitasunean zentratu nintzen. Go 2.3.2-ekin konpilatutako Prometheus 1.10.1 (PMM 1.14-ren zati gisa) zabaldu nuen Linode zerbitzuan script hau erabiliz: . Kargarik errealistena sortzeko, hau erabiliz Hainbat MySQL nodo abiarazi nituen benetako karga batekin (Sysbench TPC-C Test), eta horietako bakoitzak 10 Linux/MySQL nodo emulatzen zituen.
Ondorengo proba guztiak zortzi nukleo birtual eta 32 GB memoria dituen Linode zerbitzari batean egin dira, 20 karga-simulazio exekutatzen dituzten berrehun MySQL instantzia kontrolatuz. Edo, Prometheus terminoetan, 800 helburu, 440 scrape segundoko, 380 mila erregistro segundoko eta 1,7 milioi denbora serie aktibo.
Diseinua
Datu-base tradizionalen ohiko ikuspegia, Prometheus 1.x-ek erabiltzen duena barne, hau da . Karga kudeatzeko nahikoa ez bada, latentzia handiak izango dituzu eta eskaera batzuek huts egingo dute. Prometheus 2-n memoriaren erabilera teklaren bidez konfigura daiteke storage.tsdb.min-block-duration, eta horrek zehazten du zenbat denboran gordeko diren grabazioak memorian diskora hustu aurretik (lehenetsia 2 ordu da). Beharrezko memoria kopurua sarrerako korronte sarean gehitutako denbora-serie, etiketa eta scrape-kopuruaren araberakoa izango da. Diskoko espazioari dagokionez, Prometheus-ek erregistro bakoitzeko 3 byte erabiltzea du helburu (lagina). Bestalde, memoria-eskakizunak askoz handiagoak dira.
Blokearen tamaina konfiguratzea posible den arren, ez da gomendagarria eskuz konfiguratzea, beraz, behartuta zaude Prometheusi zure lan-kargarako behar adina memoria ematera.
Sarrerako metrika jarioa onartzen duen memoria nahikorik ez badago, Prometheus memoriatik desagertuko da edo OOM hiltzailea bertara iritsiko da.
Prometheus memoria agortzen denean hutsegitea atzeratzeko trukea gehitzeak ez du benetan laguntzen, funtzio hau erabiltzeak memoria-kontsumo lehergarria eragiten duelako. Uste dut Go-rekin, bere zabor-biltzailearekin eta trukearekin lan egiteko moduarekin zerikusia duela.
Beste ikuspegi interesgarri bat buru-blokea une jakin batean diskora garbitzeko konfiguratzea da, prozesuaren hasieratik zenbatu beharrean.
Grafikoan ikus dezakezun bezala, diskora husketak bi orduz behin gertatzen dira. Min-bloke-iraupen parametroa ordu batera aldatzen baduzu, orduan berrezarri hauek orduro egingo dira, ordu erdiren buruan hasita.
Hau eta beste grafiko batzuk erabili nahi badituzu zure Prometheus instalazioan, hau erabil dezakezu . PMMrako diseinatu zen baina, aldaketa txikiekin, Prometheus edozein instalaziotan sartzen da.
Buru-bloke izeneko bloke aktibo bat dugu, memorian gordetzen dena; datu zaharragoak dituzten blokeak bidez eskuragarri daude mmap(). Honek cachea bereizita konfiguratzeko beharra ezabatzen du, baina sistema eragilearen cacherako nahikoa leku utzi behar duzula esan nahi du buruaren blokeak har dezakeena baino zaharragoak diren datuak kontsultatu nahi badituzu.
Horrek ere esan nahi du Prometheus memoria birtualaren kontsumoa nahiko altua izango dela, eta hori ez da kezkatu behar.
Beste diseinu puntu interesgarri bat WAL (write ahead log) erabiltzea da. Biltegiratzeko dokumentazioan ikus dezakezun bezala, Prometheus-ek WAL erabiltzen du hutsegiterik ez izateko. Datuen biziraupena bermatzeko mekanismo espezifikoak, zoritxarrez, ez daude ondo dokumentatuta. Prometheus-en 2.3.2 bertsioak WAL diskoan 10 segunduro garbitzen du eta aukera hau ez da erabiltzaileak konfiguragarria.
Trinketak
Prometheus TSDB LSM (Log Structured Merge) denda baten moduan diseinatu da: buru-blokea aldian-aldian garbitzen da diskora, eta trinkotze-mekanismo batek bloke anitz konbinatzen ditu, kontsultak zehar bloke gehiegi eskaneatzea ekiditeko. Hemen karga egun baten ondoren proba sisteman ikusi ditudan bloke kopurua ikus dezakezu.
Dendari buruz gehiago jakin nahi baduzu, meta.json fitxategia azter dezakezu, zeinak eskuragarri dauden blokeei eta nola sortu zirenei buruzko informazioa dauka.
{
"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
}Prometheus-en trinkotzeak buru-blokea diskora husten den denborarekin lotuta daude. Une honetan, horrelako hainbat eragiketa egin daitezke.
Badirudi trinkotzeak ez direla inola ere mugatuak eta diskoko I/O piko handiak eragin ditzakeela exekuzioan zehar.
PUZaren karga-puntak
Noski, horrek eragin nahiko negatiboa du sistemaren abiaduran, eta erronka larria ere sortzen du LSM biltegiratzeko: nola egin trinkotzea eskaera-tasa altuak onartzeko gastu gehiegirik eragin gabe?
Memoriaren erabilera trinkotze-prozesuan ere nahiko interesgarria dirudi.
Ikus dezakegu nola, trinkotu ondoren, memoriaren zatirik handiena Cached-etik Librera egoera aldatzen den: horrek esan nahi du balio izan dezakeen informazioa handik kendu dela. Kuriosoa hemen erabiltzen den fadvice() edo minimizatzeko beste teknikaren bat, ala cachea trinkotzean suntsitutako blokeetatik askatu delako?
Porrot baten ondoren berreskuratzea
Porrotetatik berreskuratzeak denbora behar du, eta arrazoi onengatik. Segundoko milioi bat erregistroko sarrerako korronte baterako, 25 minutu inguru itxaron behar izan nuen berreskurapena SSD unitatea kontuan hartuta egiten zen bitartean.
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."Berreskuratze-prozesuaren arazo nagusia memoria-kontsumo handia da. Egoera normal batean zerbitzariak memoria kopuru berarekin egonkor funtziona dezakeen arren, huts egiten badu, baliteke OOM dela eta ez berreskuratzea. Aurkitu nuen irtenbide bakarra datu-bilketa desgaitzea izan zen, zerbitzaria agertzea, berreskuratzea eta bilketa gaituta berrabiaraztea.
Berotzen
Beroketa garaian kontuan izan beharreko beste jokaera bat errendimendu baxuaren eta baliabideen kontsumo handiaren arteko erlazioa da hasi eta berehala. Hasiera batzuetan, baina ez guztietan, karga larria ikusi nuen CPUan eta memorian.
Memoriaren erabileran hutsuneak adierazten du Prometheus-ek ezin dituela bilduma guztiak hasieratik konfiguratu, eta informazio batzuk galtzen direla.
Ez ditut asmatu CPU eta memoria karga handiaren arrazoi zehatzak. Susmoa dut hau maiztasun handiko buru blokean denbora serie berriak sortzea dela eta.
CPU karga igotzen da
I/O karga nahiko altua sortzen duten trinkotzeez gain, PUZaren kargaren piko larriak nabaritu nituen bi minuturo. Leherketak luzeagoak dira sarrera-fluxua handia denean eta Go-ren zabor-biltzaileak eragindakoa dirudi, gutxienez nukleo batzuk guztiz kargatuta daudela.
Jauzi hauek ez dira hain hutsalak. Badirudi hauek gertatzen direnean, Prometheus-en barne-sarrera-puntua eta neurketak erabilgarri ez direla, eta datu-hutsuneak eragiten ditu denbora-tarte horietan.
Prometheus esportatzailea segundo batez itzaltzen dela ere nabarituko duzu.
Zabor bilketarekin (GC) korrelazioak nabari ditzakegu.
Ondorioa
Prometheus 2-n TSDB azkarra da, milioika denbora serie eta, aldi berean, segundoko milaka erregistro kudeatzeko gai den hardware apala erabiliz. CPU eta disko I/O erabilera ere ikusgarria da. Nire adibideak erabilitako nukleo bakoitzeko 200 metrika segundoko erakusten zituen.
Hedapena planifikatzeko, memoria kopuru nahikoa gogoratu behar duzu, eta hau benetako memoria izan behar du. Erabilitako memoria kopurua 5 GB ingurukoa zen sarrerako korrontearen 100 erregistroko segundoko, eta sistema eragilearen cachearekin batera okupatutako memoria 000 GB inguru eman zuen.
Jakina, oraindik lan asko dago egiteko CPU eta diskoko I/O pikak menperatzeko, eta hori ez da harritzekoa kontuan hartuta TSDB Prometheus 2 gaztea InnoDB, TokuDB, RocksDB, WiredTiger-ekin alderatuta, baina denek antzekoa zuten. arazoak beren bizitza-zikloaren hasieran.
Iturria: www.habr.com