ProHoster > Blogs > Administrācija > TSDB analīze programmā Prometheus 2

TSDB analīze programmā Prometheus 2

TSDB analīze programmā Prometheus 2

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: StackScript. Reālistiskākai slodzes Ä£enerÄ“Å”anai, izmantojot Å”o StackScript Es palaidu vairākus MySQL mezglus ar reālu slodzi (Sysbench TPC-C tests), no kuriem katrs emulēja 10 Linux/MySQL mezglus.
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 atmiņas ierobežojums. 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.

TSDB analīze programmā Prometheus 2

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 mērinstrumentu panelis. 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.

TSDB analīze programmā Prometheus 2

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.

TSDB analīze programmā Prometheus 2

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.

TSDB analīze programmā Prometheus 2

Å Ä·iet, ka blÄ«vÄ“Å”ana nekādā veidā nav ierobežota un izpildes laikā var izraisÄ«t lielus diska I/O tapas.

TSDB analīze programmā Prometheus 2

CPU slodzes tapas

TSDB analīze programmā Prometheus 2

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ā.

TSDB analīze programmā Prometheus 2

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.

TSDB analīze programmā Prometheus 2

TSDB analīze programmā Prometheus 2

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.

TSDB analīze programmā Prometheus 2

TSDB analīze programmā Prometheus 2

Å 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.

TSDB analīze programmā Prometheus 2

Varat arī pamanīt, ka Prometheus eksportētājs uz vienu sekundi izslēdzas.

TSDB analīze programmā Prometheus 2

Varam pamanīt korelācijas ar atkritumu savākŔanu (GC).

TSDB analīze programmā Prometheus 2

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

Pievieno komentāru