De databank foar tiidsearjes (TSDB) yn Prometheus 2 is in treflik foarbyld fan in yngenieursoplossing dy't grutte ferbetteringen biedt oer de v2-opslach yn Prometheus 1 yn termen fan gegevensakkumulaasjesnelheid, query-útfiering en effisjinsje fan boarnen. Wy ymplementearren Prometheus 2 yn Percona Monitoring and Management (PMM) en ik hie de kâns om de prestaasjes fan Prometheus 2 TSDB te begripen. Yn dit artikel sil ik prate oer de resultaten fan dizze observaasjes.
Gemiddelde Prometheus wurkdruk
Foar dyjingen dy't wend binne om te gean mei databases foar algemiene doelen, is de typyske Prometheus-wurkdruk frij ynteressant. It taryf fan gegevensakkumulaasje hat de neiging stabyl te wêzen: meastal stjoere de tsjinsten dy't jo kontrolearje sawat itselde oantal metriken, en de ynfrastruktuer feroaret relatyf stadich.
Oanfragen foar ynformaasje kinne komme út ferskate boarnen. Guon fan harren, lykas warskôgings, stribje ek nei in stabile en foarsisbere wearde. Oaren, lykas brûkersoanfragen, kinne bursts feroarsaakje, hoewol dit net it gefal is foar de measte wurkloads.
Load test
Tidens testen rjochte ik my op de mooglikheid om gegevens te sammeljen. Ik haw Prometheus 2.3.2 kompilearre mei Go 1.10.1 (as part fan PMM 1.14) ynset op 'e Linode-tsjinst mei dit skript: . Foar de meast realistyske lading generaasje, mei help fan dit Ik lansearre ferskate MySQL-knooppunten mei in echte lading (Sysbench TPC-C Test), elk fan dy emulearre 10 Linux / MySQL-knooppunten.
Alle folgjende testen waarden útfierd op in Linode-tsjinner mei acht firtuele kearnen en 32 GB ûnthâld, mei 20 loadsimulaasjes dy't twahûndert MySQL-eksimplaren kontrolearje. Of, yn Prometheus-termen, 800 doelen, 440 scrapes per sekonde, 380 tûzen records per sekonde, en 1,7 miljoen aktive tiidsearjes.
design
De gewoane oanpak fan tradisjonele databases, ynklusyf de iene brûkt troch Prometheus 1.x, is om . As it net genôch is om de lading te behanneljen, sille jo hege latencies ûnderfine en guon oanfragen sille mislearje. Unthâldgebrûk yn Prometheus 2 is konfigurearber fia kaai storage.tsdb.min-block-duration, dy't bepaalt hoe lang opnames sille wurde bewarre yn it ûnthâld foardat spoelen nei skiif (standert is 2 oeren). De hoemannichte fereaske ûnthâld sil ôfhingje fan it oantal tiidsearjes, etiketten en scrapes tafoege oan de netto ynkommende stream. Yn termen fan skiifromte is Prometheus fan doel om 3 bytes per record (sample) te brûken. Oan 'e oare kant binne ûnthâld easken folle heger.
Hoewol it mooglik is om de blokgrutte te konfigurearjen, is it net oan te rieden om it manuell te konfigurearjen, dus jo wurde twongen om Prometheus safolle ûnthâld te jaan as it fereasket foar jo wurkdruk.
As d'r net genôch ûnthâld is om de ynkommende stream fan metriken te stypjen, sil Prometheus út it ûnthâld falle of de OOM-moardner sil it krije.
It tafoegjen fan swap om de crash te fertrage as Prometheus sûnder ûnthâld rint, helpt net echt, om't it brûken fan dizze funksje eksplosyf ûnthâldferbrûk feroarsaket. Ik tink dat it wat te krijen hat mei Go, syn jiskefet en de manier wêrop it omgiet mei swap.
In oare nijsgjirrige oanpak is om it kopblok te konfigurearjen om op in bepaalde tiid nei skiif te spoelen, ynstee fan it te tellen fanôf it begjin fan it proses.
Sa't jo sjen kinne út de grafyk, flushes nei skiif plakfine elke twa oeren. As jo de parameter min-block-duration feroarje nei ien oere, dan sille dizze resets elk oere plakfine, begjinnend nei in healoere.
As jo dizze en oare grafiken brûke wolle yn jo Prometheus-ynstallaasje, kinne jo dit brûke . It is ûntworpen foar PMM, mar, mei lytse oanpassingen, past yn elke Prometheus-ynstallaasje.
Wy hawwe in aktyf blok neamd holle blok dat wurdt opslein yn it ûnthâld; blokken mei âldere gegevens binne beskikber fia mmap(). Dit elimineert de needsaak om de cache apart te konfigurearjen, mar betsjut ek dat jo genôch romte litte moatte foar de cache fan it bestjoeringssysteem as jo gegevens wolle opfreegje dy't âlder binne dan wat it haadblok kin passe.
Dit betsjut ek dat Prometheus firtuele ûnthâld konsumpsje sil sjen frij heech, dat is net wat te soargen oer.
In oar nijsgjirrich ûntwerppunt is it brûken fan WAL (skriuwe foarút log). Lykas jo kinne sjen fan 'e opslachdokumintaasje, brûkt Prometheus WAL om crashes te foarkommen. Spesifike meganismen foar it garandearjen fan survivability fan gegevens binne, spitigernôch, net goed dokumintearre. Prometheus ferzje 2.3.2 flushes WAL nei skiif elke 10 sekonden en dizze opsje is net brûker konfigurearje.
Compactions
Prometheus TSDB is ûntworpen as in LSM (Log Structured Merge) winkel: it kopblok wurdt periodyk nei skiif spoeld, wylst in kompakteringsmeganisme meardere blokken kombinearret om te foarkommen dat tefolle blokken skennen wurde tidens queries. Hjir kinne jo it oantal blokken sjen dat ik observearre op it testsysteem nei in dei fan laden.
As jo mear oer de winkel leare wolle, kinne jo it meta.json-bestân ûndersykje, dat ynformaasje hat oer de beskikbere blokken en hoe't se kamen.
{
"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
}Compactions yn Prometheus binne bûn oan 'e tiid dat de kop blok wurdt trochspoeld oan skiif. Op dit punt kinne ferskate sokke operaasjes wurde útfierd.
It docht bliken dat kompakteringen op gjin inkelde manier beheind binne en kinne grutte skiif I / O-spikes feroarsaakje by útfiering.
CPU load spikes
Fansels, dit hat in nochal negative ynfloed op de snelheid fan it systeem, en ek foarmet in serieuze útdaging foar LSM opslach: hoe te dwaan compaction te stypjen hege fersyk tariven sûnder wêrtroch tefolle overhead?
It gebrûk fan ûnthâld yn it kompakteringsproses liket ek heul ynteressant.
Wy kinne sjen hoe't, nei komprimearjen, it grutste part fan it ûnthâld feroaret tastân fan Cached nei Free: dit betsjut dat mooglik weardefolle ynformaasje is fuorthelle út dêr. Benijd oft it hjir brûkt wurdt fadvice() of in oare minimization technyk, of is it omdat de cache waard befrijd út blokken ferneatige tidens kompaktering?
Herstel nei in mislearring
Herstel fan mislearrings nimt tiid, en foar goede reden. Foar in ynkommende stream fan in miljoen records per sekonde moast ik sawat 25 minuten wachtsje wylst it herstel waard útfierd mei it rekkenjen fan it SSD-stasjon.
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."It wichtichste probleem fan it herstelproses is hege ûnthâldferbrûk. Nettsjinsteande it feit dat de tsjinner yn in normale situaasje stabyl kin wurkje mei deselde hoemannichte ûnthâld, as it crasht, kin it net herstelle troch OOM. De ienige oplossing dy't ik fûn wie om gegevenssammeling út te skeakeljen, de tsjinner op te heljen, it te herstellen en opnij op te starten mei sammeljen ynskeakele.
Opwaarmje
In oar gedrach om yn gedachten te hâlden by it opwaarmjen is de relaasje tusken lege prestaasjes en hege boarneferbrûk direkt nei it begjin. Tidens guon, mar net alle starts, observearre ik in serieuze lêst op 'e CPU en ûnthâld.
Hiaten yn ûnthâldgebrûk jouwe oan dat Prometheus net alle kolleksjes fan it begjin ôf kin konfigurearje, en guon ynformaasje is ferlern.
Ik haw net betocht de krekte redenen foar de hege CPU en ûnthâld load. Ik fermoedzje dat dit komt troch it meitsjen fan nije tiid rige yn 'e holle blok mei in hege frekwinsje.
CPU load surges
Neist de compactions, dy't meitsje in frij hege I / O load, Ik fernaam serieuze spikes yn CPU load elke twa minuten. De bursts binne langer as de ynfierstream heech is en liket te wêzen feroarsake troch Go's garbage collector, mei op syn minst guon kearnen folslein laden.
Dizze sprongen binne net sa ûnbelangryk. It liket derop dat as dizze foarkomme, Prometheus's ynterne yngongspunt en metriken net beskikber wurde, wêrtroch gegevensgatten yn deselde perioaden fan tiid feroarsaakje.
Jo kinne ek fernimme dat de Prometheus-eksporteur ien sekonde útskeakele.
Wy kinne fernimme korrelaasjes mei garbage collection (GC).
konklúzje
TSDB yn Prometheus 2 is fluch, by steat om te behanneljen miljoenen tiid rige en tagelyk tûzenen records per sekonde mei help fan frij beskieden hardware. CPU en skiif I / O gebrûk is ek yndrukwekkend. Myn foarbyld toande oant 200 metriken per sekonde per kearn brûkt.
Foar in plan útwreiding, Jo moatte ûnthâlde oer foldwaande hoemannichten ûnthâld, en dit moat wêze echte ûnthâld. De hoemannichte brûkte ûnthâld dat ik observearre wie sawat 5 GB per 100 records per sekonde fan 'e ynkommende stream, dy't tegearre mei it bestjoeringssysteemcache sawat 000 GB beset ûnthâld joech.
Fansels is d'r noch in protte wurk te dwaan om CPU- en skiif-I/O-spikes te temmen, en dit is net ferrassend, sjoen hoe't jonge TSDB Prometheus 2 wurdt fergelike mei InnoDB, TokuDB, RocksDB, WiredTiger, mar se hienen allegear ferlykbere problemen betiid yn har libbenssyklus.
Boarne: www.habr.com