🥇 TSDB analüüs Prometheus 2

Ajaandmete baas (TSDB, time series database) Prometheus 2-s on suurepärane näide insenerilahendusest, mis pakub märkimisväärseid parandusi võrreldes v2 hoiustamisega Prometheus 1-s andmete kogumise ja päringute täitmise kiirusel ning ressursside kasutamise efektiivsusel. Oleme rakendanud Prometheus 2 Percona Monitoring and Management (PMM) süsteemis ja mul oli võimalus uurida Prometheus 2 TSDB tulemuslikkust. Selles artiklis räägin nende tähelepanekute tulemustest.

Keskmine Prometheuse koormus

Neile, kes on harjunud töötama tavaliste andmebaasidega, on Prometheuse harilik koormus üsna huvitav. Andmete kogumise kiirus püüdleb stabiilse väärtuse poole: tavaliselt saadavad järelevalvetavad teenused umbes sama hulga meetrikaid ja infrastruktuur muutub suhteliselt aeglaselt.
Teavet võivad küsida erinevad allikad. Mõned neist, näiteks teatised, püüdlevad samuti stabiilse ja etteennustava väärtuse poole. Teised, nagu kasutajapäringud, võivad põhjustada kõrgete koormuse tõusu, kuid see ei ole tüüpiline suurema osa koormuse jaoks.

Koormustest

Testimise käigus keskendusin andmete kogumise võimele. Käivitasin Prometheus 2.3.2, mille on koostanud Go 1.10.1 (osa PMM 1.14), teenuses Linode, kasutades seda skripti: StackScript. Maksimaalseks realistlikuks koormuse genereerimiseks, selle abil StackScript käivitasin mitu MySQL-i sõlme tegeliku koormusega (Sysbench TPC-C Test), millest igaüks emuleeris 10 Linuxi/MySQL sõlme.
Kogu järgmised testid viidi läbi Linode serveris, kus on kaheksa virtuaalset tuuma ja 32 GB mälu, kus oli käivitatud 20 koormuse simuleerimist kaheksasaja MySQL instantsi jälgimiseks. Või, Prometheuse terminoloogias, 800 sihti (targets), 440 kogumist (scrapes) sekundis, 380 tuhat kirjet (samples) sekundis ja 1,7 miljonit aktiivset ajaseeriat.

Disain

Tavapärane lähenemine traditsioonilistes andmebaasides, sealhulgas see, mida kasutas Prometheus 1.x, seisneb mälu piirangus. Kui seda ei ole piisavalt, et koormust taluda, kohtate suuri viivitusi ning mõni päring ei tule täidetud. Prometheus 2 mälu kasutamine on konfigureeritud läbi võtme storage.tsdb.min-block-duration, mis määrab, kui kaua salvestusi hoitakse mälus enne kettale kirjutamist (vaikimisi 2 tundi). Vajaminev mälu sõltub ajalisest järjestusest, siltidest (labels) ja andmete kogumise intensiivsusest (scrapes), samuti puhtast sisenevast voost. Ketaste mahutavuse osas püüab Prometheus kasutada 3 baiti salvestuse (sample) kohta. Teisest küljest on mälunõudmised palju kõrgemad.

Kuigi blokki suuruse konfigureerimine on võimalik, ei ole soovitatav seda käsitsi seadistada, mistõttu peate andma Prometheusele nii palju mälu, kui ta teie koormuse jaoks palub.
Kui mälu ei piisa sissetulevate mõõdikute hoidmiseks, kukub Prometheus välja, kuna mälu on otsas või tapab OOM killer.
Swap'i lisamine mälukao hetke edasilükkamiseks ei aita eriti, sest selle funktsiooni kasutamine põhjustab mälu plahvatuslikku tarbimist. Arvan, et probleem on Go-s, selle rämpsvaba (garbage collector) ja selles, kuidas see swapiga töötab.
Teine huvitav lähenemine on seadistada head blocki lähtestamine kettale kindlal ajal, selle asemel et arvestada seda protsessi käivitamise ajast.

Nagu näete graafikult, toimuvad kettale lähtestamised iga kahe tunni tagant. Kui muudate parameetri min-block-duration üheks tunniks, toimuvad need lähtestamised iga tunni tagant, alates poole tunni pärast.
Kui soovite seda ja teisi graafikuid oma Prometheuse paigalduses kasutada, saate kasutada seda dashboardi. See on välja töötatud PMM-i jaoks, kuid väikeste muudatustega sobib see mis tahes Prometheuse paigaldusse.
Meil on aktiivne plokk, mida nimetatakse head block´iks, mis on salvestatud mällu; vanemad andmeplokid on saadaval kaudu mmap(). See kõrvaldab vajaduse eraldi vahemälu konfiguratsiooni järele, kuid tähendab ka, et peate jätma piisavalt ruumi operatsioonisüsteemi vahemäluks, kui soovite küsida andmeid, mis on vanemad kui need, mida head block mahutab.
See tähendab ka, et Prometheuse virtuaalmälu tarbimine näeb välja üsna kõrge, millest ei tasu muretseda.

Veel huvitav disainitegur on WAL (write ahead log) kasutamine. Nagu on näha hoiustamise dokumentatsioonist, kasutab Prometheus WAL-i, et vältida andmete kadumist süsteemi kokkuhangetega. Kahjuks on konkreetseid andmete elujõudmise tagamise mehhanisme ebapiisavalt dokumenteeritud. Prometheus 2.3.2 versioon kirjutab WAL-i kettale iga 10 sekundi järel ja seda seadistust ei saa kasutaja muuta.

Kompaktsused (Compactions)

Prometheuse TSDB on projekteeritud LSM-hoidla (Log Structured Merge) põhjal: peaklassi kirjutatakse perioodiliselt kettale, samal ajal kui kompaktsioonimehhanism liidab mitu plokki kokku, et vältida liiga paljude plokkide skaneerimist päringute käigus. Siin on näha plokkide arvu, mida ma oma testimis süsteemis ühe päeva koormuse järel jälgisin.

Kui soovite rohkem teada hoidlast, saate uurida faili meta.json, kus on teavet olemasolevate plokkide ja nende tekkimise kohta.

{
       "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 tehingud on seotud peahaarde ploki kirjutamise ajaga. Sel hetkel võib toimuda mitu sellist operatsiooni.

Tundub, et tihendite tegemine ei ole mingil viisil piiratud ja need võivad põhjustada suuri diskikõrge I/O tõuse nende teostamisel.

CPU koormuse tõusud

Muidugi mõjutab see süsteemi töökiirust negatiivselt ning on tõsine väljakutse LSM-salvestustele: kuidas teostada tihendusi, et säilitada kõrge päringute kiirus ja samal ajal vältida liiga suurt overhead'i?
Mälu kasutamine tihendamisprotsessi ajal näeb samuti välja üsna huvitav.

Me võime näha, et pärast tihendamist muutub suur osa mälust olekust Cached olekusse Free: see tähendab, et potentsiaalselt väärtuslik teave on sealt eemaldatud. Huvi pakub, kas kasutatakse fadvice() või mõnda muud minimeerimise tehnikat, või on see tingitud sellest, et vahemälu on vabastatud tihendamise käigus hävitatud plokkidest?

Taasteprotsess

Rikkest taastamine võtab aega, ja see on õigustatud. Miljoni kirje sekundi sisenemise voogu arvesse võttes pidin ootama umbes 25 minutit, kuni taastamine SSD-diski arvestusega toimus.

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Alustamine 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="Hakkab kuulama ühendusi" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Alustamine TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="leitud tervislik plokk" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="marsruudi eelosa" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="leitud tervislik plokk" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="leitud tervislik plokk" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="leitud tervislik plokk" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="leitud tervislik plokk" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL häire tuvastatud; kärpimine" err="ootamatu CRC32 kontrollsumma d0465484, soovitud 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="Laadimise konfiguratsioonifail" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Konfiguratsioonifaili laadimine lõpule viidud" 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 suur mälu tarbimine. Kuigi normaalsetes tingimustes suudab server sama mäluhulga juures stabiilselt töötada, võib see avarii korral mitte tõusta OOM-i tõttu. Ainus lahendus, mille leidsin, on andmete kogumise väljalülitamine, serveri tõstmine, taastamise lubamine ja seejärel uuesti käivitamine, andmete kogumise sisse lülitamisega.

Kuumutamine

Teine käitumine, mida kuumutamise käigus silmas pidada, on madala jõudluse ja kõrge ressursikasutuse suhe vahetult pärast käivitamist. Mõnel, kuid mitte kõigil käivitustel olen täheldanud tõsist koormust CPU-le ja mälule.

Mälu kasutamise langused näitavad, et Prometheus ei suuda alguses kõiki kogumisi konfigureerida ja mõni teave jääb kaduma.
Ma ei selgitanud täpsed põhjused kõrge koormuse tekkimiseks protsessoris ja mälus. Kahtlustan, et see on seotud uute ajaseeriate loomisega head block'is kõrge sagedusega.

CPU koormuse hüpped

Lisaks tihenditele, mis loovad üsna kõrge I/O koormuse, olen märganud tõsiseid protsessori koormushooge iga kahe minuti tagant. Puhangud kestavad kauem kõrgete sissetulevate voogude korral ning tundub, et need on põhjustatud Go prügikorjajast, vähemalt mõningate tuumade koormus on täielikult täis.

Need tõusud ei ole sugugi ebaolulised. Tundub, et kui need tekivad, siis sise sissepääs ja Prometheuse mõõdikud muutuvad kättesaamatuks, mis põhjustab andmekatkestusi samade ajavahemike jooksul.

Samuti on märgata, et Prometheuse eksportija takerdub üheks sekundiks.

Me võime märgata seoseid prügikorjamise (GC) kanssa.

Kokkuvõte

Prometheuse 2 TSDB toimib kiiresti, suudab toime tulla miljonite ajareadadega ning samal ajal tuhandeid kirjeid sekundis, kasutades üsna tagasihoidlikku riistvara. CPU ja kettasisse/öllus on samuti muljetavaldav. Minu näide näitas kuni 200 000 mõõdikut sekundis ühel kasutusel oleval tuumal.

Laiennikuse planeerimisel tuleb arvestada piisavate mälu mahtudega, ning see peab olema tegelik mälu. Minu jälgimisel oli kasutatud mälu maht umbes 5 GB 100 000 salvestuse sekundi sissetulevas voos, mis koos operatsioonisüsteemi vahemälu kogusega andis kokku umbes 8 GB kasutatud mälu.

Muidugi on veel palju tööd CPU ja kettasüsteemi plahvatuste taltsutamiseks, ja see ei ole üllatav, arvestades, kui noor on TSDB Prometheus 2 võrreldes InnoDB, TokuDB, RocksDB, WiredTiger, kuid kõikidel neil olid algfaasis sarnased probleemid.

Allikas: habr.com

TSDB analüüs Prometheus 2-s