Laika rindu datubāze (TSDB) programmā Prometheus 2 ir lielisks inženierijas risinājuma piemērs, kas piedāvā ievērojamus uzlabojumus salīdzinājumā ar Prometheus 2 v1 krātuvi datu uzkrāšanas ātruma, vaicājumu izpildes un resursu efektivitātes ziņā. Mēs ieviesām Prometheus 2 programmā Percona Monitoring and Management (PMM), un man bija iespēja izprast Prometheus 2 TSDB veiktspēju. Šajā rakstā es runāšu par šo novērojumu rezultātiem.
Vidējā Prometeja darba slodze
Tiem, kas pieraduši strādāt ar vispārējas nozīmes datu bāzēm, tipiskā Prometheus darba slodze ir diezgan interesanta. Datu uzkrāšanas ātrums mēdz būt stabils: parasti jūsu pārraudzītie pakalpojumi nosūta aptuveni tādu pašu rādītāju skaitu, un infrastruktūra mainās salīdzinoši lēni.
Informācijas pieprasījumi var nākt no dažādiem avotiem. Daži no tiem, piemēram, brīdinājumi, arī tiecas pēc stabilas un paredzamas vērtības. Citi, piemēram, lietotāju pieprasījumi, var izraisīt sēriju, lai gan lielākajai daļai darba slodžu tas tā nav.
Slodzes tests
Testēšanas laikā es koncentrējos uz spēju uzkrāt datus. Es izvietoju Prometheus 2.3.2, kas kompilēts ar Go 1.10.1 (kā daļa no PMM 1.14), Linode pakalpojumā, izmantojot šo skriptu: . Reālistiskākai slodzes ģenerēšanai, izmantojot šo Es palaidu vairākus MySQL mezglus ar reālu slodzi (Sysbench TPC-C tests), katrs no tiem emulēja 10 mezglus. Linux/MySQL.
Visi tālāk minētie testi tika veikti Linode serverī ar astoņiem virtuālajiem kodoliem un 32 GB atmiņu, palaižot 20 slodzes simulācijas, pārraugot divus simtus MySQL gadījumu. Vai, runājot Prometeja izteiksmē, 800 mērķi, 440 skrāpējumi sekundē, 380 tūkstoši ierakstu sekundē un 1,7 miljoni aktīvo laikrindu.
Dizains
Parastā pieeja tradicionālajām datu bāzēm, ieskaitot to, ko izmanto Prometheus 1.x, ir . Ja ar to nepietiek, lai apstrādātu slodzi, būs liels latentums un daži pieprasījumi neizdosies. Atmiņas lietojumu programmā Prometheus 2 var konfigurēt, izmantojot atslēgu storage.tsdb.min-block-duration, kas nosaka, cik ilgi ieraksti tiks saglabāti atmiņā pirms izskalošanas diskā (noklusējums ir 2 stundas). Nepieciešamais atmiņas apjoms būs atkarīgs no neto ienākošajai straumei pievienoto laikrindu, etiķešu un skrāpējumu skaita. Runājot par diska vietu, Prometheus mērķis ir izmantot 3 baitus vienam ierakstam (paraugam). No otras puses, atmiņas prasības ir daudz augstākas.
Lai gan ir iespējams konfigurēt bloka lielumu, nav ieteicams to konfigurēt manuāli, tāpēc esat spiests piešķirt Prometheus tik daudz atmiņas, cik tas prasa jūsu darba slodzi.
Ja nav pietiekami daudz atmiņas, lai atbalstītu ienākošo metrikas straumi, Prometheus izkritīs no atmiņas vai OOM slepkava tiks pie tās.
Mijmaiņas pievienošana, lai aizkavētu avāriju, kad Prometheus beidzas atmiņa, īsti nepalīdz, jo šīs funkcijas izmantošana izraisa eksplozīvu atmiņas patēriņu. Es domāju, ka tas ir kaut kas saistīts ar Go, tā atkritumu savācēju un veidu, kā tas nodarbojas ar mijmaiņas darījumiem.
Vēl viena interesanta pieeja ir konfigurēt galvas bloku tā, lai tas noteiktā laikā tiktu izskalots diskā, nevis skaitītu to no procesa sākuma.
Kā redzams diagrammā, diska skalošana notiek ik pēc divām stundām. Ja maināt parametru min-block-duration uz vienu stundu, šīs atiestatīšanas tiks veiktas katru stundu, sākot pēc pusstundas.
Ja vēlaties izmantot šo un citus grafikus savā Prometheus instalācijā, varat izmantot šo . Tas bija paredzēts PMM, bet ar nelielām izmaiņām iekļaujas jebkurā Prometheus instalācijā.
Mums ir aktīvs bloks, ko sauc par galvas bloku, kas tiek saglabāts atmiņā; bloki ar vecākiem datiem ir pieejami, izmantojot mmap(). Tas novērš nepieciešamību atsevišķi konfigurēt kešatmiņu, bet arī nozīmē, ka jums ir jāatstāj pietiekami daudz vietas operētājsistēmas kešatmiņai, ja vēlaties vaicāt datus, kas ir vecāki par to, ko var uzņemt galvas blokā.
Tas arī nozīmē, ka Prometheus virtuālās atmiņas patēriņš izskatīsies diezgan augsts, par ko nav jāuztraucas.
Vēl viens interesants dizaina aspekts ir WAL izmantošana (uzrakstīt žurnālu). Kā redzams uzglabāšanas dokumentācijā, Prometheus izmanto WAL, lai izvairītos no avārijām. Konkrēti mehānismi datu saglabāšanas garantēšanai diemžēl nav labi dokumentēti. Prometheus versija 2.3.2 izskalo WAL diskā ik pēc 10 sekundēm, un šo opciju lietotājs nevar konfigurēt.
Blīvējumi
Prometheus TSDB ir veidots kā LSM (Log Structured Merge) veikals: galvas bloks periodiski tiek izskalots diskā, savukārt blīvēšanas mehānisms apvieno vairākus blokus, lai izvairītos no pārāk daudzu bloku skenēšanas vaicājumu laikā. Šeit jūs varat redzēt bloku skaitu, ko es novēroju testa sistēmā pēc slodzes dienas.
Ja vēlaties uzzināt vairāk par veikalu, varat izpētīt failu meta.json, kurā ir informācija par pieejamajiem blokiem un to rašanos.
{
"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
}Sablīvēšanās Prometheus ir saistīta ar laiku, kad galvas bloks tiek izskalots ar disku. Šajā brīdī var veikt vairākas šādas darbības.
Šķiet, ka blīvēšana nekādā veidā nav ierobežota un izpildes laikā var izraisīt lielus diska I/O tapas.
CPU slodzes tapas
Protams, tas diezgan negatīvi ietekmē sistēmas ātrumu, kā arī rada nopietnu izaicinājumu LSM krātuvei: kā veikt blīvēšanu, lai atbalstītu augstu pieprasījumu ātrumu, neradot pārāk lielas izmaksas?
Diezgan interesanti izskatās arī atmiņas izmantošana blīvēšanas procesā.
Mēs redzam, kā pēc sablīvēšanas lielākā daļa atmiņas maina statusu no Kešatmiņas uz Brīvu: tas nozīmē, ka no turienes ir noņemta potenciāli vērtīgā informācija. Interesanti, vai tas tiek izmantots šeit fadvice() vai kāds cits minimizēšanas paņēmiens, vai tas ir tāpēc, ka kešatmiņa tika atbrīvota no blīvēšanas laikā iznīcinātajiem blokiem?
Atveseļošanās pēc neveiksmes
Atgūšanās no neveiksmēm prasa laiku, un tam ir labs iemesls. Ienākošajai straumei miljona ierakstu sekundē man bija jāgaida apmēram 25 minūtes, kamēr tika veikta atkopšana, ņemot vērā SSD disku.
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."Galvenā atkopšanas procesa problēma ir liels atmiņas patēriņš. Neskatoties uz to, ka normālā situācijā serveris var stabili strādāt ar tādu pašu atmiņas apjomu, avārijas gadījumā tas var neatkopties OOM dēļ. Vienīgais risinājums, ko atradu, bija atspējot datu vākšanu, atvērt serveri, ļaut tam atgūties un atsāknēt ar iespējotu vākšanu.
Iesildīšanās
Vēl viena uzvedība, kas jāpatur prātā iesildīšanās laikā, ir saistība starp zemu veiktspēju un lielu resursu patēriņu uzreiz pēc starta. Dažos, bet ne visos startos novēroju nopietnu CPU un atmiņas slodzi.
Atmiņas lietojuma nepilnības norāda, ka Prometheus nevar konfigurēt visas kolekcijas no paša sākuma, un daļa informācijas tiek zaudēta.
Es neesmu noskaidrojis precīzus augstās CPU un atmiņas slodzes iemeslus. Man ir aizdomas, ka tas ir saistīts ar jaunu laika rindu izveidi galvas blokā ar augstu frekvenci.
CPU slodzes pieaugums
Papildus blīvējumiem, kas rada diezgan lielu I/O slodzi, es pamanīju nopietnus CPU slodzes lēcienus ik pēc divām minūtēm. Pārrāvumi ir garāki, ja ievades plūsma ir liela, un šķiet, ka tos izraisa Go atkritumu savācējs, un vismaz daži serdeņi ir pilnībā noslogoti.
Šie lēcieni nemaz nav tik mazsvarīgi. Šķiet, ka tad, kad tie notiek, Prometheus iekšējais ievades punkts un metrika kļūst nepieejami, radot datu nepilnības tajos pašos laika periodos.
Varat arī pamanīt, ka Prometheus eksportētājs uz vienu sekundi izslēdzas.
Varam pamanīt korelācijas ar atkritumu savākšanu (GC).
Secinājums
Prometheus 2 TSDB ir ātrs, spēj apstrādāt miljoniem laikrindu un tajā pašā laikā tūkstošiem ierakstu sekundē, izmantojot diezgan pieticīgu aparatūru. CPU un diska I/O izmantošana arī ir iespaidīga. Mans piemērs parādīja līdz 200 000 metrikas sekundē uz vienu izmantoto kodolu.
Lai plānotu paplašināšanu, jums jāatceras par pietiekamu atmiņas apjomu, un tai ir jābūt reālai atmiņai. Manis novērotais izmantotās atmiņas apjoms bija aptuveni 5 GB uz 100 000 ierakstu sekundē ienākošās straumes, kas kopā ar operētājsistēmas kešatmiņu deva aptuveni 8 GB aizņemtās atmiņas.
Protams, vēl ir daudz jāstrādā, lai pieradinātu CPU un disku I/O tapas, un tas nav pārsteidzoši, ņemot vērā to, cik jauns TSDB Prometheus 2 ir salīdzinājumā ar InnoDB, TokuDB, RocksDB, WiredTiger, taču tiem visiem bija līdzīgi problēmas dzīves cikla sākumā.
Avots: www.habr.com
