A basa di dati di a serie temporale (TSDB) in Prometheus 2 hè un esempiu eccellente di una soluzione di ingegneria chì offre grandi migliorie annantu à l'almacenamiento v2 in Prometheus 1 in quantu à a velocità di accumulazione di dati, l'esekzione di e dumande è l'efficienza di risorse. Avemu implementatu Prometheus 2 in Percona Monitoring and Management (PMM) è aghju avutu l'uppurtunità di capisce u rendiment di Prometheus 2 TSDB. In questu articulu, parraraghju di i risultati di sti osservazioni.
Carica di travagliu mediu di Prometheus
Per quelli chì sò abituati à trattà cù basa di dati generale, a carica di travagliu tipica di Prometheus hè abbastanza interessante. A tarifa di l'accumulazione di dati tende à esse stabile: di solitu i servizii chì monitorate mandanu apprussimatamente u listessu numeru di metriche, è l'infrastruttura cambia relativamente lentamente.
E dumande di informazioni ponu vene da diverse fonti. Certi di elli, cum'è l'alerte, s'impegnanu ancu per un valore stabile è prevedibile. L'altri, cum'è e richieste di l'utilizatori, ponu pruvucà scoppi, ancu s'ellu ùn hè micca u casu per a maiò parte di i carichi di travagliu.
Test di carica
Durante a prova, aghju focu annantu à a capacità di accumulà dati. Aghju implementatu Prometheus 2.3.2 compilatu cù Go 1.10.1 (cum'è parte di PMM 1.14) nantu à u serviziu Linode utilizendu stu script: . Per a generazione di carica più realistica, usendu questu Aghju lanciatu parechji nodi MySQL cù una carica reale (Sysbench TPC-C Test), ognunu di quale emulava 10 nodi Linux / MySQL.
Tutte e seguenti teste sò state realizate nantu à un servitore Linode cù ottu core virtuale è 32 GB di memoria, eseguendu simulazioni di carica 20 monitorendu duie centu istanze MySQL. O, in termini di Prometheus, 800 targets, 440 scrapes per second, 380 mila records per second, è 1,7 million series time active.
cuncezzione
L'approcciu abituale di basa di dati tradiziunali, cumpresu quellu utilizatu da Prometheus 1.x, hè di . S'ellu ùn hè micca abbastanza per trattà a carica, vi sperimentà alta latenza è alcune dumande falla. L'usu di memoria in Prometheus 2 hè cunfigurabile via chjave storage.tsdb.min-block-duration, chì determina quantu longu i registrazioni seranu guardati in memoria prima di flussu à u discu (predeterminatu hè 2 ore). A quantità di memoria necessaria dipenderà da u numeru di serie di tempu, etichette è scrapes aghjuntu à u flussu in entrata netu. In quantu à u spaziu di discu, Prometheus hà u scopu di utilizà 3 bytes per record (mostra). Per d 'altra banda, i requisiti di memoria sò assai più altu.
Ancu s'ellu hè pussibule cunfigurà a dimensione di u bloccu, ùn hè micca cunsigliatu per cunfigurà manualmente, cusì vi sò obligatu à dà Prometheus quant'è memoria necessaria per a vostra carica di travagliu.
Se ùn ci hè micca abbastanza memoria per sustene u flussu entrante di metriche, Prometheus cascà da a memoria o l'assassinu OOM ghjunghjerà.
L'aghjunghje swap per ritardà u crash quandu Prometheus esce da memoria ùn aiuta micca veramente, perchè l'usu di sta funzione provoca un cunsumu di memoria splusivi. Pensu chì hè qualcosa di fà cù Go, u so cullettore di basura è a manera di tratta di scambià.
Un altru approcciu interessante hè di cunfigurà u bloccu di testa per esse lavatu à u discu à un certu tempu, invece di cuntà da u principiu di u prucessu.
Comu pudete vede da u graficu, i flushe à u discu si facenu ogni duie ore. Se cambiate u paràmetru di min-block-duration à una ora, allora sti resettati saranu ogni ora, cumincendu dopu à una meza ora.
Se vulete usà questu è altri grafici in a vostra installazione Prometheus, pudete aduprà questu . Hè statu cuncepitu per PMM ma, cù modifiche minori, si mette in ogni installazione Prometheus.
Avemu un bloccu attivu chjamatu bloccu capu chì hè guardatu in memoria; blocchi cù dati più vechje sò dispunibili via mmap(). Questu elimina a necessità di cunfigurà a cache per separatamente, ma significa ancu chì avete bisognu di lascià spaziu abbastanza per a cache di u sistema operatore se vulete interrogà e dati più vechji di ciò chì u bloccu di capu pò accoglie.
Questu significa ancu chì u cunsumu di memoria virtuale di Prometheus parerà abbastanza altu, chì ùn hè micca qualcosa di preoccupatu.
Un altru puntu di cuncepimentu interessante hè l'usu di WAL (write ahead log). Comu pudete vede da a documentazione di almacenamiento, Prometheus usa WAL per evità i crashes. Meccanismi specifichi per guarantiscenu a sopravvivenza di e dati sò, sfurtunatamenti, micca bè documentati. A versione Prometheus 2.3.2 lava WAL à u discu ogni 10 seconde è sta opzione ùn hè micca configurabile da l'utilizatori.
Cumpazzioni
Prometheus TSDB hè cuncepitu cum'è un magazinu LSM (Log Structured Merge): u bloccu di testa hè lavatu periodicamente à u discu, mentre chì un mecanismu di compactazione combina parechji blocchi inseme per evità di scansà troppu blocchi durante e dumande. Quì pudete vede u numeru di blocchi chì aghju osservatu nantu à u sistema di teste dopu un ghjornu di carica.
Se vulete sapè più nantu à a tenda, pudete esaminà u schedariu meta.json, chì hà infurmazione nantu à i blocchi dispunibuli è cumu si sò ghjunti.
{
"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
}I compactions in Prometheus sò ligati à u tempu chì u bloccu di u capu hè lavatu à u discu. A stu puntu, parechji tali operazioni pò esse realizatu.
Sembra chì i compactions ùn sò micca limitati in ogni modu è ponu causà grandi spikes I / O di discu durante l'esekzione.
Spikes di carica di CPU
Di sicuru, questu hà un impattu piuttostu negativu nantu à a rapidità di u sistema, è ancu pone una seria sfida per l'almacenamiento LSM: cumu fà a cumpattazione per sustene l'alti tassi di dumanda senza causà troppu sopra?
L'usu di a memoria in u prucessu di compactazione hè ancu assai interessante.
Pudemu vede cumu, dopu à a compattazione, a maiò parte di a memoria cambia u statu da Cached à Free: questu significa chì l'infurmazioni potenzialmente preziosi sò stati eliminati da quì. Curioso s'ellu hè usatu quì fadvice() o qualchì altra tecnica di minimizazione, o hè perchè a cache hè stata liberata da i blocchi distrutti durante a compactazione?
Recuperazione dopu un fallimentu
A ricuperazione da i fallimenti piglia u tempu, è per una bona ragione. Per un flussu in entrata di un milione di dischi per seconda, aghju avutu aspittà circa 25 minuti mentre a ricuperazione hè stata realizata tenendu in contu l'unità 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."U prublema principali di u prucessu di ricuperazione hè un altu cunsumu di memoria. Malgradu u fattu chì in una situazione normale u servitore pò travaglià stabile cù a listessa quantità di memoria, s'ellu crash ùn pò micca ricuperà per via di OOM. L'unica suluzione chì aghju trovu era di disattivà a cullizzioni di dati, allughjà u servitore, lasciate ricuperà è reboot cù a cullizzioni attivata.
Scaldà si
Un altru cumpurtamentu per mantene in mente durante u warm-up hè a relazione trà u bassu rendimentu è u cunsumu di risorse altu ghjustu dopu à u principiu. Duranti certi, ma micca tutti i principii, aghju osservatu una carica seria nantu à u CPU è a memoria.
Lacune in l'usu di memoria indicanu chì Prometheus ùn pò micca cunfigurà tutte e cullezzione da u principiu, è qualchì infurmazione hè persa.
Ùn aghju micca capitu i motivi esatti per l'alta CPU è a carica di memoria. Sospettate chì questu hè dovutu à a creazione di una nova serie di tempu in u bloccu di u capu cù una freccia alta.
A carica di CPU aumenta
In più di i compactions, chì creanu una carica I / O abbastanza alta, aghju nutatu spikes serii in a carica di CPU ogni dui minuti. I sbattimenti sò più longu quandu u flussu di input hè altu è parenu esse causati da u cullettivu di basura di Go, cù almenu alcuni nuclei chì sò cumpletamente caricati.
Questi salti ùn sò micca cusì insignificanti. Sembra chì quandu si verificanu, u puntu di ingressu internu di Prometheus è e metriche ùn sò micca dispunibili, causendu lacune di dati durante questi stessi periodi di tempu.
Pudete ancu nutà chì l'esportatore Prometheus chjude per una seconda.
Pudemu nutà correlazioni cù a cullizzioni di basura (GC).
cunchiusioni
TSDB in Prometheus 2 hè veloce, capace di gestisce milioni di serie di tempu è à u stessu tempu millaie di dischi per seconda utilizendu hardware abbastanza modestu. L'utilizazione di CPU è di discu I / O hè ancu impressiunanti. U mo esempiu hà dimustratu finu à 200 000 metriche per seconda per core utilizatu.
Per pianificà l'espansione, avete bisognu di ricurdà di quantità sufficienti di memoria, è questu deve esse memoria vera. A quantità di memoria utilizata chì aghju osservatu era di circa 5 GB per 100 000 record per seconda di u flussu in entrata, chì inseme cù a cache di u sistema operatore hà datu circa 8 GB di memoria occupata.
Di sicuru, ci hè ancu assai travagliu da fà per ammansà u CPU è u discu I / O spikes, è questu ùn hè micca surprisante cunsiderendu quantu u ghjovanu TSDB Prometheus 2 hè paragunatu à InnoDB, TokuDB, RocksDB, WiredTiger, ma tutti avianu simili. prublemi in principiu di u so ciclu di vita.
Source: www.habr.com