Ang time series database (TSDB) sa Prometheus 2 usa ka maayong panig-ingnan sa usa ka solusyon sa inhenyeriya nga nagtanyag ug mahinungdanong mga pag-uswag sa Prometheus 2 storage v1 sa mga termino sa pagkolekta sa datos ug katulin sa pagpatuman sa pangutana, ug kahusayan sa kahinguhaan. Among gipatuman ang Prometheus 2 sa Percona Monitoring and Management (PMM) ug nakahigayon ko nga masabtan ang performance sa Prometheus 2 TSDB. Niini nga artikulo maghisgot ako mahitungod sa mga resulta niini nga mga obserbasyon.
Prometheus Average Workload
Alang sa mga naanad sa pag-atubang sa mga database sa kinatibuk-ang katuyoan, ang kasagaran nga workload sa Prometheus medyo makapaikag. Ang rate sa pagtipon sa datos lagmit sa usa ka lig-on nga kantidad: kasagaran ang mga serbisyo nga imong gibantayan nagpadala hapit parehas nga kantidad sa mga sukatan, ug ang imprastraktura hinay nga nagbag-o.
Ang mga hangyo alang sa kasayuran mahimong gikan sa lainlaing mga gigikanan. Ang uban niini, sama sa mga alerto, nagtumong usab sa usa ka lig-on ug matag-an nga kantidad. Ang uban, sama sa mga hangyo sa tiggamit, mahimong hinungdan sa mga spike, bisan kung dili kini ang kahimtang sa kadaghanan sa mga buluhaton.
Pagsulay sa pagkarga
Atol sa pagsulay, naka-focus ko sa abilidad sa pagtipon sa datos. Gi-deploy nako ang Prometheus 2.3.2 nga giipon sa Go 1.10.1 (isip bahin sa PMM 1.14) sa usa ka serbisyo sa Linode gamit kini nga script: . Alang sa labing realistiko nga henerasyon sa pagkarga, uban niini Gipadagan nako ang daghang mga MySQL node nga adunay tinuod nga load (Sysbench TPC-C Test), nga ang matag usa niini nagsunod sa 10 Linux/MySQL nodes.
Ang tanan nga mosunod nga mga pagsulay gihimo sa usa ka Linode server nga adunay walo ka vCores ug 32 GB nga memorya, nga nagpadagan sa 20 nga load simulations nga nagmonitor sa 800 nga MySQL instances. O, sa termino sa Prometheus, 440 nga mga target (target), 380 nga bayad (scrapes) kada segundo, 1,7 ka libo nga mga rekord (sample) kada segundo ug XNUMX milyon nga aktibo nga serye sa panahon.
disenyo
Ang naandan nga tradisyonal nga database nga pamaagi, lakip ang usa nga gigamit sa Prometheus 1.x, mao ang . Kung dili igo ang pagdumala sa load, makasinati ka og taas nga latency ug pipila ka mga hangyo dili matuman. Ang paggamit sa memorya sa Prometheus 2 ma-configure pinaagi sa usa ka yawe storage.tsdb.min-block-duration, nga nagtino kung unsa kadugay ang mga rekord itago sa panumduman sa dili pa i-flush sa disk (ang default mao ang 2 ka oras). Ang gidaghanon sa memorya nga gikinahanglan magdepende sa gidaghanon sa mga serye sa panahon, mga label, ug mga scrapes, dugang sa net input. Sa termino sa disk space, ang Prometheus nagtumong sa paggamit sa 3 bytes kada pagsulat (sample). Sa laing bahin, ang mga kinahanglanon sa panumduman mas taas.
Samtang posible nga i-configure ang gidak-on sa block, dili girekomenda nga itakda kini nga mano-mano, mao nga nahabilin ka sa tahas sa paghatag sa Prometheus sa daghang panumduman nga gikinahanglan alang sa imong workload.
Kung walay igo nga panumduman aron suportahan ang umaabot nga stream sa mga sukatan, ang Prometheus mawala sa memorya o madakpan sa usa ka mamumuno sa OOM.
Ang pagdugang sa swap aron malangan ang pagkahagsa kung ang Prometheus nahutdan sa memorya dili gyud makatabang, tungod kay ang paggamit niini nga bahin hinungdan sa mga pagbuto sa memorya. Sa akong hunahuna kini bahin sa Go, ang tigkolekta sa basura, ug kung giunsa kini molihok sa swap.
Ang laing makaiikag nga paagi mao ang pagbutang sa ulo block aron ma-flush sa disk sa usa ka piho nga oras, imbis nga ihap kini gikan sa pagsugod sa proseso.
Sama sa imong makita gikan sa graph, ang mga flushes sa disk mahitabo matag duha ka oras. Kung imong usbon ang parameter sa min-block-duration sa usa ka oras, nan kini nga mga pag-reset mahitabo matag oras, sugod sa tunga sa oras.
Kung gusto nimo gamiton kini ug uban pang mga graph sa imong pag-install sa Prometheus, mahimo nimo kini gamiton . Gidisenyo kini alang sa PMM, apan sa pipila ka mga pagbag-o kini mohaum sa bisan unsang pag-instalar sa Prometheus.
Kami adunay usa ka aktibo nga bloke, nga gitawag nga bloke sa ulo, nga gitipigan sa memorya; Ang mga bloke nga adunay daan nga datos magamit pinaagi sa mmap(). Gikuha niini ang panginahanglan nga i-configure ang cache nga gilain, apan nagpasabut usab kini nga kinahanglan nimo nga biyaan ang igo nga lawak alang sa cache sa operating system kung gusto nimo nga mangutana sa datos nga mas tigulang kaysa sa block sa ulo.
Nagpasabut usab kini nga ang pagkonsumo sa virtual nga panumduman ni Prometheus tan-awon nga taas, nga walaβy angay kabalak-an.
Laing makapaikag nga punto sa disenyo mao ang paggamit sa WAL (isulat sa unahan nga log). Sama sa imong makita gikan sa dokumentasyon sa repository, gigamit ni Prometheus ang WAL aron malikayan ang mga pag-crash. Ang piho nga mga mekanismo alang sa paggarantiya sa pagkaluwas sa datos, sa walay palad, dili maayo nga dokumentado. Ang Prometheus 2.3.2 nag-flush sa WAL sa disk matag 10 segundos ug kini nga setting dili ma-configure sa user.
Mga selyo
Ang Prometheus TSDB gidesinyo sa samang paagi sama sa LSM (Log Structured merge) storage: ang ulo block kanunay nga i-flush ngadto sa disk, samtang ang compaction mechanism naghiusa sa daghang mga block aron malikayan ang pag-scan sa daghan kaayong block sa mga pangutana. Dinhi makita nimo ang gidaghanon sa mga bloke nga akong naobserbahan sa sistema sa pagsulay pagkahuman sa usa ka adlaw nga pagkarga.
Kung gusto nimo mahibal-an ang dugang bahin sa pagtipig, mahimo nimong susihon ang meta.json file, nga adunay kasayuran bahin sa mga bloke nga magamit ug kung giunsa kini nahimo.
{
"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
}Ang mga selyo sa Prometheus gihigot sa panahon nga ang bloke sa ulo na-flush sa disk. Niini nga punto, daghang ingon nga mga operasyon ang mahimoβg himuon.
Mopatim-aw nga ang mga compaction dili limitado sa bisan unsang paagi ug mahimong hinungdan sa dagkong disk I/O spikes atol sa pagpatuman.
Mga spike sa load sa CPU
Siyempre, kini adunay negatibo nga epekto sa katulin sa sistema, ug usa usab ka seryoso nga hagit alang sa mga pagtipig sa LSM: kung giunsa ang paghimo sa mga compaction aron masuportahan ang taas nga katulin sa pangutana nga walaβy hinungdan sa sobra nga overhead?
Ang paggamit sa panumduman sa proseso sa compaction usab tan-awon nga talagsaon.
Atong makita kung giunsa, pagkahuman sa compaction, kadaghanan sa mga panumduman nagbag-o sa estado gikan sa Cached hangtod sa Libre: kini nagpasabut nga ang potensyal nga hinungdanon nga kasayuran gikuha gikan didto. Natingala kung kini gigamit dinhi fadvice() o uban pang pamaagi sa pagminus, o tungod ba kay ang cache nahaw-as sa mga bloke nga gilaglag pinaagi sa compaction?
Pagkapakyas Pagbawi
Ang pag-ayo sa katalagman nagkinahanglan og panahon, ug alang sa maayong rason. Alang sa umaabot nga stream sa usa ka milyon nga mga rekord matag segundo, kinahanglan kong maghulat mga 25 minuto samtang ang pagbawi nag-isip sa SSD drive.
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."Ang nag-unang problema sa proseso sa pagbawi mao ang taas nga konsumo sa memorya. Bisan kung ang server makadagan nga lig-on nga adunay parehas nga gidaghanon sa memorya sa usa ka normal nga sitwasyon, kung kini nahagsa, kini mahimong dili mobangon tungod sa OOM. Ang bugtong solusyon nga akong nakit-an mao ang pagpalong sa pagkolekta sa datos, pagpataas sa server, pagpaayo niini, ug pag-reboot sa pagkolekta.
Pag-init
Ang laing kinaiya nga hinumduman sa panahon sa pagpainit mao ang ratio sa ubos nga performance ngadto sa taas nga konsumo sa kapanguhaan human dayon sa pagsugod. Atol sa pipila, apan dili tanan nagsugod, akong naobserbahan ang usa ka seryoso nga pagkarga sa CPU ug memorya.
Ang mga dips sa paggamit sa memorya nagpakita nga ang Prometheus dili maka-configure sa tanan nga mga bayronon gikan sa sinugdanan, ug ang pipila ka impormasyon nawala.
Wala nako nahibal-an ang eksaktong mga hinungdan sa taas nga paggamit sa CPU ug memorya. Nagduda ko nga kini tungod sa pagmugna sa bag-ong time series sa head block nga adunay taas nga frequency.
Mga spike sa CPU
Agi og dugang sa mga compaction, nga naghimo sa usa ka medyo taas nga I / O load, akong namatikdan ang seryoso nga mga spike sa processor load matag duha ka minuto. Ang mga pagbuto mas taas nga adunay taas nga umaabot nga trapiko ug morag kini tungod sa Go garbage collector, labing menos pipila ka mga cores puno na.
Kini nga mga paglukso dili kaayo hinungdanon. Morag kung mahitabo kini, ang Prometheus internal nga entry point ug metrics mahimong dili magamit, hinungdan nga ang mga datos mous-os sa parehas nga mga agwat sa oras.
Mahimo usab nimong mamatikdan nga ang eksporter sa Prometheus nagsira sa usa ka segundo.
Makita nato ang mga correlasyon sa garbage collection (GC).
konklusyon
Ang TSDB sa Prometheus 2 paspas, makahimo sa pagdumala sa milyon-milyon nga serye sa oras ug sa parehas nga oras libu-libo nga mga rekord matag segundo gamit ang medyo kasarangan nga hardware. Ang paggamit sa CPU ug disk I/O makapahingangha usab. Ang akong pananglitan nagpakita sa 200 metrics kada segundo kada gigamit nga core.
Aron magplano alang sa pagpalapad, kinahanglan nimong hinumdoman nga adunay igo nga panumduman, ug kini kinahanglan nga tinuod nga panumduman. Ang gidaghanon sa panumduman nga gigamit, nga akong naobserbahan, mga 5 GB matag 100 nga mga rekord matag segundo sa umaabot nga sapa, nga, sa kinatibuk-an sa cache sa operating system, naghatag mga 000 GB nga gi-okupar nga memorya.
Siyempre, aduna pa'y daghang trabaho nga pagabuhaton aron sa pagpaaghop sa CPU ug disk I/O spikes, ug kini dili ikatingala, tungod kay ang batan-ong TSDB Prometheus 2 gitandi sa InnoDB, TokuDB, RocksDB, WiredTiger, apan silang tanan adunay susama nga mga problema sa sinugdanan sa ilang siklo sa kinabuhi.
Source: www.habr.com