La tempa serio-datumbazo (TSDB) en Prometheus 2 estas bonega ekzemplo de inĝenieristika solvo, kiu ofertas gravajn plibonigojn super la v2-stokado en Prometheus 1 rilate al rapideco de akumulado de datumoj, ekzekuto de demandoj kaj efikeco de rimedoj. Ni efektivigis Prometheus 2 en Percona Monitoring and Management (PMM) kaj mi havis la ŝancon kompreni la agadon de Prometheus 2 TSDB. En ĉi tiu artikolo mi parolos pri la rezultoj de ĉi tiuj observoj.
Meza Prometheus Laborkvanto
Por tiuj, kiuj kutimas trakti ĝeneraluzeblajn datumbazojn, la tipa laborŝarĝo de Prometheus estas sufiĉe interesa. La indico de amasiĝo de datumoj tendencas esti stabila: kutime la servoj, kiujn vi kontrolas, sendas proksimume la saman nombron da metrikoj, kaj la infrastrukturo ŝanĝiĝas relative malrapide.
Petoj pri informoj povas veni de diversaj fontoj. Iuj el ili, kiel atentigoj, ankaŭ strebas al stabila kaj antaŭvidebla valoro. Aliaj, kiel uzantpetoj, povas kaŭzi eksplodojn, kvankam tio ne estas la kazo por plej multaj laborŝarĝoj.
Ŝarĝo-testo
Dum testado, mi koncentriĝis pri la kapablo amasigi datumojn. Mi deplojis Prometheus 2.3.2 kompilitan kun Go 1.10.1 (kiel parto de PMM 1.14) sur la Linode-servo uzante ĉi tiun skripton: . Por la plej realisma ŝarĝogeneracio, uzante ĉi tion Mi lanĉis plurajn MySQL-nodojn kun vera ŝarĝo (Sysbench TPC-C Test), ĉiu el kiuj emulis 10 Linukso/MySQL-nodojn.
Ĉiuj jenaj provoj estis faritaj sur Linode-servilo kun ok virtualaj kernoj kaj 32 GB da memoro, kurante 20 ŝarĝajn simuladojn monitorante ducent MySQL-instancojn. Aŭ, laŭ Prometeo, 800 celoj, 440 skrapaĵoj sekundo, 380 mil rekordoj sekundo, kaj 1,7 milionoj da aktivaj temposerio.
Dezajno
La kutima aliro de tradiciaj datumbazoj, inkluzive de tiu uzata de Prometheus 1.x, estas al . Se ne sufiĉas trakti la ŝarĝon, vi spertos altajn latentecojn kaj iuj petoj malsukcesos. Memoruzo en Prometheus 2 estas agordebla per klavo storage.tsdb.min-block-duration, kiu determinas kiom longe registradoj estos konservitaj en memoro antaŭ fluado al disko (defaŭlte estas 2 horoj). La kvanto de memoro bezonata dependos de la nombro da temposerio, etikedoj kaj skrapaĵoj aldonitaj al la neta envenanta fluo. Koncerne diskospacon, Prometeo celas uzi 3 bajtojn per registro (specimeno). Aliflanke, memorpostuloj estas multe pli altaj.
Kvankam eblas agordi la blokgrandecon, ne rekomendas agordi ĝin permane, do vi estas devigita doni al Prometheus tiom da memoro kiom ĝi postulas por via laborŝarĝo.
Se ne estas sufiĉe da memoro por subteni la envenantan fluon de metrikoj, Prometheus falos el memoro aŭ la OOM-murdinto atingos ĝin.
Aldoni interŝanĝon por prokrasti la kraŝon kiam Prometheus elĉerpiĝas memoro ne vere helpas, ĉar uzi ĉi tiun funkcion kaŭzas eksplodeman memorkonsumon. Mi pensas, ke ĝi rilatas al Go, ĝia rubkolektisto kaj la maniero kiel ĝi traktas interŝanĝon.
Alia interesa aliro estas agordi la kapblokon por esti fluita al disko en certa tempo, anstataŭ kalkuli ĝin de la komenco de la procezo.
Kiel vi povas vidi de la grafikaĵo, fluflugoj al disko okazas ĉiujn du horojn. Se vi ŝanĝas la parametron de min-bloko-daŭro al unu horo, tiam ĉi tiuj rekomencoj okazos ĉiun horon, komencante post duonhoro.
Se vi volas uzi ĉi tiun kaj aliajn grafikaĵojn en via Prometheus-instalaĵo, vi povas uzi ĉi tion . Ĝi estis dizajnita por PMM sed, kun negravaj modifoj, konvenas en ajnan Prometheus-instalaĵon.
Ni havas aktivan blokon nomatan ĉefbloko kiu estas konservita en memoro; blokoj kun pli malnovaj datumoj haveblas per mmap(). Ĉi tio forigas la bezonon agordi la kaŝmemoron aparte, sed ankaŭ signifas, ke vi devas lasi sufiĉe da spaco por la operaciuma kaŝmemoro se vi volas pridemandi datumojn pli malnovajn ol kion la ĉefbloko povas akomodi.
Ĉi tio ankaŭ signifas, ke Prometheus virtuala memorkonsumo aspektos sufiĉe alta, kio ne estas io por zorgi.
Alia interesa dezajnpunkto estas la uzo de WAL (skribi antaŭe protokolo). Kiel vi povas vidi el la stokaddokumentado, Prometheus uzas WAL por eviti kraŝojn. Specifaj mekanismoj por garantii datumviveblecon estas bedaŭrinde ne bone dokumentitaj. Prometheus-versio 2.3.2 fluigas WAL al disko ĉiujn 10 sekundojn kaj ĉi tiu opcio ne estas agordebla por la uzanto.
Kompaktiĝoj
Prometheus TSDB estas desegnita kiel LSM (Log Structured Merge) vendejo: la ĉefbloko estas fluigita periode al disko, dum kompakta mekanismo kombinas plurajn blokojn kune por eviti skanadon de tro da blokoj dum demandoj. Ĉi tie vi povas vidi la nombron da blokoj, kiujn mi observis sur la testa sistemo post tago de ŝarĝo.
Se vi volas lerni pli pri la vendejo, vi povas ekzameni la meta.json-dosieron, kiu havas informojn pri la disponeblaj blokoj kaj kiel ili estiĝis.
{
"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
}Kompaktiĝoj en Prometeo estas ligitaj al la tempo kiam la kapbloko estas fluigita al disko. Je ĉi tiu punkto, pluraj tiaj operacioj povas esti faritaj.
Ŝajnas, ke kompaktiĝoj neniel estas limigitaj kaj povas kaŭzi grandajn diskajn I/O-pikojn dum ekzekuto.
CPU-ŝarĝaj pikiloj
Kompreneble, ĉi tio havas sufiĉe negativan efikon sur la rapideco de la sistemo, kaj ankaŭ prezentas gravan defion por LSM-stokado: kiel fari kompakton por subteni altajn petajn tarifojn sen kaŭzi tro da ŝarĝo?
La uzo de memoro en la kompakta procezo ankaŭ aspektas sufiĉe interesa.
Ni povas vidi kiel, post kompaktado, la plej granda parto de la memoro ŝanĝas staton de Cached al Libera: tio signifas, ke eble valoraj informoj estis forigitaj de tie. Scivolas ĉu ĝi estas uzata ĉi tie fadvice() aŭ iu alia minimumigtekniko, aŭ ĉu ĉar la kaŝmemoro estis liberigita de blokoj detruitaj dum kompaktado?
Reakiro post fiasko
Reakiro de malsukcesoj bezonas tempon, kaj pro bona kialo. Por alvenanta fluo de miliono da diskoj sekundo, mi devis atendi ĉirkaŭ 25 minutojn dum la reakiro estis farita konsiderante la SSD-diskon.
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."La ĉefa problemo de la reakiro estas alta konsumo de memoro. Malgraŭ tio, ke en normala situacio la servilo povas funkcii stabile kun la sama kvanto de memoro, se ĝi kraŝas ĝi eble ne resaniĝos pro OOM. La sola solvo, kiun mi trovis, estis malŝalti datumkolektadon, alporti la servilon, lasi ĝin resaniĝi kaj rekomenci kun kolekto ebligita.
Varmiĝo
Alia konduto por konservi en menso dum varmigo estas la rilato inter malalta rendimento kaj alta resursa konsumo tuj post la komenco. Dum kelkaj, sed ne ĉiuj komencoj, mi observis gravan ŝarĝon sur la CPU kaj memoro.
Mankoj en memoruzo indikas ke Prometeo ne povas agordi ĉiujn kolektojn de la komenco, kaj iuj informoj estas perditaj.
Mi ne eltrovis la precizajn kialojn de la alta CPU kaj memorŝarĝo. Mi suspektas, ke tio ŝuldiĝas al la kreado de novaj temposerio en la ĉefbloko kun alta ofteco.
CPU-ŝarĝo pliiĝas
Krom la kompaktiĝoj, kiuj kreas sufiĉe altan I/O-ŝarĝon, mi rimarkis gravajn pikilojn en CPU-ŝarĝo ĉiujn du minutojn. La eksplodoj estas pli longaj kiam la eniga fluo estas alta kaj ŝajnas esti kaŭzitaj de la rubkolektisto de Go, kun almenaŭ kelkaj kernoj estas plene ŝarĝitaj.
Ĉi tiuj saltoj ne estas tiel sensignifaj. Ŝajnas, ke kiam ĉi tiuj okazas, la interna enirejpunkto kaj metriko de Prometeo fariĝas neatingeblaj, kaŭzante datumajn mankojn dum ĉi tiuj samaj tempodaŭroj.
Vi ankaŭ povas rimarki, ke la eksportisto de Prometheus fermiĝas dum unu sekundo.
Ni povas rimarki korelaciojn kun rubkolekto (GC).
konkludo
TSDB en Prometheus 2 estas rapida, kapabla pritrakti milionojn da temposerio kaj samtempe milojn da rekordoj sekundo uzante sufiĉe modestan aparataron. CPU kaj disko I/O utiligo ankaŭ estas impona. Mia ekzemplo montris ĝis 200 metrikoj je sekundo per kerno uzata.
Por plani vastiĝon, vi devas memori pri sufiĉaj kvantoj da memoro, kaj ĉi tio devas esti reala memoro. La kvanto de memoro uzata, kiun mi observis, estis ĉirkaŭ 5 GB por 100 000 registroj je sekundo de la envenanta fluo, kiu kune kun la mastruma kaŝmemoro donis ĉirkaŭ 8 GB da okupata memoro.
Kompreneble, estas ankoraŭ multe da laboro farenda por malsovaĝigi CPU kaj disko I/O-pikilojn, kaj ĉi tio ne estas surpriza konsiderante kiom juna TSDB Prometheus 2 estas komparita kun InnoDB, TokuDB, RocksDB, WiredTiger, sed ili ĉiuj havis similajn. problemoj frue en sia vivociklo.
fonto: www.habr.com