TSDB analüüs Prometheus 2-s

Ajaandmete ajalooteabe andmebaas (TSDB, time series database) Prometheus 2-s on suurepärane näide insenerilahendusest, mis pakub tõsiseid parandusi võrreldes Prometheus 1 v2 salvestusega andmete kogumise ja päringute täitmise kiirusel ning ressursside efektiivsuses. Me rakendasime Prometheus 2 Percona Monitoring and Management (PMM) süsteemis ja mul oli võimalus uurida Prometheus 2 TSDB jõudlust. Selles artiklis jagan oma tähelepanekute tulemusi.

Prometheuse keskmine töökoormus

Neile, kes on harjunud tegelema peamise sihiga andmebaasidega, on Prometheuse tavaline töökoormus üsna huvitav. Andmete kogumise kiirus püsib stabiilsena: tavaliselt saadavad jälgitavad teenused umbes sama arvu mõõdikuid ja infrastruktuur muutub suhteliselt aeglaselt.
Informatsiooni päringud võivad tulla erinevatest allikatest. Mõned neist, näiteks häired, püüdlevad samuti stabiilsete ja ettearvatavate väärtuste poole. Teised, nagu kasutajate päringud, võivad tekitada tippe, kuigi see ei ole iseloomulik suuremale osale koormusest.

Koormustest

Testimise käigus keskendusin võimele andmeid koguda. Jõudsin välja Prometheus 2.3.2, mis kompileeriti Go 1.10.1 abil (osa PMM 1.14) Linode teenuses, kasutades seda skripti: StackScript. Maksimaalselt realistliku koormuse genereerimise jaoks, kasutades seda, StackScript käivitasin mitu MySQL nodi reaalse koormusega (Sysbench TPC-C Test), millest igaüks emuleeris 10 Linux/MySQL nodi.
Kõik järgnevad testid viidi läbi Linode serveris, millel on kaheksa virtuaalset tuuma ja 32 GB mälu, kus töötas 20 koormuse simulatsiooni kahel neljasaja MySQL instantsil. Või, Prometheuse terminoloogiaga, 800 sihtmärki (targets), 440 kogumist (scrapes) sekundis, 380 tuhat salvestust (samples) sekundis ja 1,7 miljonit aktiivset ajalugu.

Kujundus

Traditsiooniliste andmebaaside tavaline lähenemine, sealhulgas see, mida kasutas Prometheus 1.x, põhineb mälu piirangul. Kui seda pole piisavalt, et koormust taluda, puutute kokku suurte viivitustega ja mõned päringud jäävad täitmata. Aja kasutamine Prometheus 2-s konfigureeritakse võtmega storage.tsdb.min-block-duration, mis määrab, kui kaua salvestatud andmed mälu olemasolevad enne kettale kirjutamist (vaikimisi 2 tundi). Vajalik mälumaht sõltub ajajoonte arvust, sildistamisest (labels) ja andmete kogumise intensiivsusest (scrapes) koos puhta siseneva vooluga. Diskiruumi osas püüab Prometheus kasutada 3 baiti igast kirjest (sample). Teisest küljest, mälunõuded on palju kõrgemad.

Kuigi blokki suurust on võimalik konfigureerida, ei ole soovitatav seda käsitsi häälestada, seega olete sunnitud andma Prometheusele nii palju mälu, kui ta teie koormuse jaoks vajab.
Kui mälu ei piisa sisenevate mõõtmete toetamiseks, kukub Prometheus välja mälu puuduse tõttu või jõuab sinna OOM killer.
Swap mälu lisamine, et edasi lükata hetke, mil Prometheuse mälu otsa saab, ei aita eriti, kuna selle funktsiooni kasutamine põhjustab mälu kasutuse plahvatuslikku kasvu. Ma arvan, et asi on Go-s, selle prügifiltris ning selles, kuidas see swapiga toimib.
Teine huvitav lähenemine on seada peabloki kirjutamine kettale kindlaksmääratud ajal, selle asemel et arvutada seda protsessi käivitamise ajast.

Nagu näete graafikult, toimub kettale kirjutamine iga kahe tunni tagant. Kui muudate parameetrit min-block-duration üheks tunniks, siis need kirjutised toimuvad iga tunni järel, alustades poole tunni pärast.
Kui soovite kasutada seda ja teisi graafikuid oma Prometheuse installatsioonis, võite kasutada seda juhtpaneeli. See on välja töötatud PMM-i jaoks, kuid väikeste muudatustega sobib see kõigile Prometheuse installatsioonidele.
Meil on aktiivne blokk, mida nimetatakse peablokiks, mis säilib mälus; vanemate andmetega blokid on saadaval läbi mmap(). See eemaldab vajaduse vahemälu eraldi konfigureerimise järele, kuid tähendab ka, et peate jätma piisavalt ruumi operatsioonisüsteemi vahemälu jaoks, kui soovite teha päringuid andmetele, mis on vanemad kui need, mida peablokk suudab mahutada.
Ja see tähendab ka, et Prometheuse virtuaalmälu tarbimine näeb välja üsna kõrge, mis ei peaks muret tekitama.

Veel huvitav aspekt disainis on WAL-i (write ahead log) kasutamine. Nagu näha ladustamise dokumentatsioonist, kasutab Prometheus WAL-i andmete kaotuse vältimiseks süsteemi kokkuvarisemise korral. Kahjuks ei ole konkreetseid andmekindluse tagamise mehhanisme piisavalt kirjeldatud. Prometheus 2.3.2 kirjutab WAL-i kettale iga 10 sekundi tagant ning see seadistus ei ole kasutaja poolt konfigureeritav.

Kompaktsioonid

Prometheus TSDB on kavandatud LSM-ladustamise (Log Structured Merge) põhjal: pea plokk kirjutatakse perioodiliselt kettale, samal ajal kui kompaktsiooni mehhanism ühendab mitu plokki, et vältida liialt suurte plokkide skaneerimist päringute käigus. Siit on näha plokkide arvu, mida ma testi süsteemis ühe päeva koormuse järel jälgisin.

Kui soovite teada rohkem ladustamise kohta, võite uurida meta.json faili, kus on teavet olemasolevate plokkide kohta ja selle kohta, kuidas need tekkisid.

{
       "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
}

Prometheuses kompaktsioonid on seotud pea ploki ketta peal kirjutamise ajaga. Selle aja jooksul võib toimuda mitu sellist operatsiooni.

Tundub, et tihendamine ei ole kuidagi piiratud ja võib põhjustada suuri disk I/O hüppeid teostamise ajal.

CPU koormuse hüpped

Muidugi, see mõjutab süsteemi töökiirus negatiivselt ja on tõsine väljakutse LSM-laodaridele: kuidas teostada tihendamist kõrge päringukiirus säilitamiseks ning samas vältida liiga suurt ülekatet?
Mälu kasutamine tihendamiste protsessis näib samuti olevat üsna huvitav.

Näeme, et pärast tihendamist muutub suur osa mälust olekust Cached olekusse Free: see tähendab, et potentsiaalselt väärtuslik teave on sealt eemaldatud. Huvitav, kas siin kasutatakse fadvice() või mõnda muud vähendamise tehnikat, või on see tingitud sellest, et vahemälu vabastati eemaldatud plokkidest, mis hävitati tihendamise käigus?

Tõrke taastamine

Tõrgete taastamiseks kulub aega ja see on põhjendatud. Miljoni kirje sekundis siseneva voolu jaoks pidin ootama umbes 25 minutit, kuni taastamine toimus SSD-ketta arvestades.

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Käivitamine 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="Alustamine ühenduste kuulamiseks" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="TSDB käivitamine ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="leitud terve plokk" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="marutüki eelmine osa" prefix=\/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="leitud terve plokk" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="leitud terve plokk" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="leitud terve plokk" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="leitud terve plokk" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL-i rike tuvastatud; lühenemine" err="ootamatu CRC32 kontrollsumma d0465484, oota 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 käivitatud"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Konfiguratsioonifaili laadimine" filename=\/etc\/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Konfiguratsioonifaili laadimise lõpetamine" filename=\/etc\/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server on valmis veebipäringute vastuvõtmiseks."

Peamine probleem taastamisprotsessis on kõrge mälu tarbimine. Kuigi tavapärastel tingimustel võib server sarnase mäluhulga puhul stabiilselt töötada, võib see krahhi korral OOM-i tõttu mitte taastuda. Ainus lahendus, mille ma leidsin, on andmete kogumise välja lülitamine, serveri käivitamine, taastumise võimaldamine ja seejärel uuesti käivitamine andmete kogumise sisselülitamisega.

Soojenemine

Teine käitumine, mida tuleb soojenemise ajal jälgida, on madala jõudluse ja kõrge ressursikasutuse suhe kohe pärast käivitamist. Mõnedel, kuid mitte kõigil käivitustel olen täheldanud tõsist koormust CPU-l ja mälus.

Mälu kasutamise tõusud näitavad, et Prometheus ei suuda alguses kõiki kogumise seadistusi teha ja teatud teave kaob.
Ma ei selgitanud kõrge protsessori ja mälu koormuse täpseid põhjuseid. Kahtlustan, et see on seotud uute ajarealiste loomisega peablokis kõrge sagedusega.

CPU koormuse hüpped

Peale tihendite, mis tekitavad üsna kõrget I/O koormust, märkasin tõsiseid hüppeid protsessori koormuses iga kahe minuti tagant. Hüpped kestavad kauem kõrge sisendi voolu korral ja tundub, et neid põhjustab Go prügikogumisepunkt, vähemalt mõned tuumad on täielikult koormatud.

Need hüpped ei ole sugugi ebaolulised. Tundub, et nende esinemisel muutuvad sisemine sisenemispunkt ja Prometheuse mõõdikud kättesaamatuks, mis põhjustab andmesügavusi samadel aegadel.

Samuti võib märkida, et Prometheuse eksportöör ummistub sekundiks.

Saame märgata seoseid prügikogumise (GC) ja vahel.

Kokkuvõte

Prometheuse 2 ajarealiste andmebaas (TSDB) töötab kiiresti, suudab hallata miljoneid ajarealisi andmeid ja samas tuhandete kirjeid sekundis, kasutades üsna tagasihoidlikku riistvara. CPU ja disk I/O kasutamine on samuti muljetavaldav. Minu näide näitas kuni 200 000 mõõdikut sekundis ühe kasutatud tuuma kohta.

Laienemise planeerimisel tuleb arvestada piisava mälu mahuga, ja see peab olema reaalne mälu. Kasutatud mälu maht, mida ma jälgisin, oli umbes 5 Gt 100 000 sõnumi sekundis sisendi voolu puhul, mis koos operatsioonisüsteemi vahemäega andis kokku umbes 8 Gt kasutuses olevat mälu.

Muidugi on veel palju tööd ees, et mõõdukuid CPU ja disk I/O taltsutada, ja see ei ole üllatav, arvestades, kui noor on Prometheuse 2 TSDB võrreldes InnoDB, TokuDB, RocksDB, WiredTiger, kuid kõik need olid alguses sarnaste probleemidega.

Allikas: habr.com