TSDB analüüs programmis Prometheus 2

Prometheus 2 aegridade andmebaas (TSDB) on suurepärane näide insenerilahendusest, mis pakub Prometheus 2 v1-salvestusega võrreldes olulisi täiustusi andmete kogumise kiiruse, päringu täitmise ja ressursitõhususe osas. Rakendasime Prometheus 2 Percona monitooringus ja juhtimises (PMM) ja mul oli võimalus mõista Prometheus 2 TSDB toimivust. Selles artiklis räägin nende vaatluste tulemustest.

Prometheuse keskmine töökoormus

Neile, kes on harjunud tegelema üldotstarbeliste andmebaasidega, on tüüpiline Prometheuse töökoormus üsna huvitav. Andmete kogumise kiirus kipub olema stabiilne: tavaliselt saadavad teie jälgitavad teenused ligikaudu sama palju mõõdikuid ja infrastruktuur muutub suhteliselt aeglaselt.
Teabepäringud võivad pärineda erinevatest allikatest. Mõned neist, näiteks hoiatused, püüdlevad ka stabiilse ja prognoositava väärtuse poole. Teised, näiteks kasutajate taotlused, võivad põhjustada sarivõtte, kuigi enamiku töökoormuste puhul see nii ei ole.

Koormustesti

Testimisel keskendusin andmete kogumise võimele. Juurutasin Prometheus 2.3.2, mis on kompileeritud Go 1.10.1-ga (PMM 1.14 osana) Linode'i teenuses, kasutades järgmist skripti: StackScript. Kõige realistlikuma koormuse genereerimiseks kasutage seda StackScript Käivitasin mitu MySQL sõlme reaalse koormusega (Sysbench TPC-C Test), millest igaüks emuleeris 10 sõlme. Linux/MySQL.
Kõik järgmised testid viidi läbi Linode serveris, millel oli kaheksa virtuaaltuuma ja 32 GB mälu ning mis käivitas 20 koormussimulatsiooni, mis jälgis kahtsada MySQL-i eksemplari. Või Prometheuse terminites 800 sihtmärki, 440 kraapimist sekundis, 380 tuhat kirjet sekundis ja 1,7 miljonit aktiivset aegrida.

Disain

Traditsiooniliste andmebaaside, sealhulgas Prometheus 1.x-i poolt kasutatavate andmebaaside tavaline lähenemisviis on mälu piirang. Kui koormuse käsitsemiseks sellest ei piisa, kogete suurt latentsust ja mõned taotlused ebaõnnestuvad. Prometheus 2 mälukasutust saab konfigureerida võtmega storage.tsdb.min-block-duration, mis määrab, kui kaua salvestusi enne kettale loputamist mällu hoitakse (vaikimisi on 2 tundi). Vajalik mälumaht sõltub neto sissetulevasse voogu lisatud aegridade, siltide ja kriimustuste arvust. Kettaruumi osas on Prometheuse eesmärk kasutada 3 baiti kirje (näidise) kohta. Teisest küljest on mälunõuded palju suuremad.

Kuigi ploki suurust on võimalik konfigureerida, ei ole soovitatav seda käsitsi konfigureerida, nii et olete sunnitud andma Prometheusele nii palju mälu, kui see teie töökoormuse jaoks nõuab.
Kui sissetuleva mõõdikuvoo toetamiseks pole piisavalt mälu, kukub Prometheus mälust välja või jõuab OOM-i tapja selleni.
Vahetusfunktsiooni lisamine krahhi edasilükkamiseks, kui Prometheuse mälu saab otsa, ei aita tegelikult kaasa, sest selle funktsiooni kasutamine põhjustab plahvatuslikku mälutarbimist. Ma arvan, et see on midagi pistmist Go-ga, selle prügikogujaga ja sellega, kuidas see vahetustega tegeleb.
Veel üks huvitav lähenemine on konfigureerida peaplokk nii, et see loputatakse kettale teatud ajahetkel, selle asemel, et seda protsessi algusest peale lugeda.

Nagu graafikult näha, toimub loputus kettale iga kahe tunni tagant. Kui muudate parameetri min-block-duration väärtuseks üks tund, siis lähtestatakse neid iga tund, alates poole tunni pärast.
Kui soovite kasutada seda ja muid graafikuid oma Prometheuse installis, saate seda kasutada armatuurlaud. See oli mõeldud PMM-i jaoks, kuid sobib väikeste muudatustega igasse Prometheuse paigaldusse.
Meil on mällu salvestatud aktiivne plokk nimega head block; vanemate andmetega plokid on saadaval aadressil mmap(). See välistab vajaduse vahemälu eraldi konfigureerida, kuid tähendab ka seda, et peate jätma operatsioonisüsteemi vahemälu jaoks piisavalt ruumi, kui soovite pärida andmeid, mis on vanemad, kui peaplokk mahutab.
See tähendab ka seda, et Prometheuse virtuaalmälu tarbimine tundub üsna suur, mis pole põhjust muretsemiseks.

Veel üks huvitav disainipunkt on WAL-i kasutamine (logi ette kirjutamine). Nagu salvestusdokumentatsioonist näha, kasutab Prometheus krahhide vältimiseks WAL-i. Konkreetsed mehhanismid andmete säilivuse tagamiseks ei ole kahjuks hästi dokumenteeritud. Prometheuse versioon 2.3.2 loputab WAL-i kettale iga 10 sekundi järel ja seda valikut ei saa kasutaja konfigureerida.

Tihendamine

Prometheus TSDB on loodud nagu LSM-i (logistruktuuride ühendamise) pood: peaplokk loputatakse perioodiliselt kettale, samas kui tihendusmehhanism ühendab mitu plokki kokku, et vältida päringute ajal liiga paljude plokkide skannimist. Siin näete plokkide arvu, mida ma pärast päeva laadimist testsüsteemis jälgisin.

Kui soovite poe kohta lisateavet, võite uurida faili meta.json, mis sisaldab teavet saadaolevate 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
}

Tihendamine Prometheuses on seotud ajaga, mil peaplokk kettale loputatakse. Sel hetkel saab teha mitu sellist toimingut.

Näib, et tihendamine ei ole mingil viisil piiratud ja võib käivitamise ajal põhjustada suuri ketta sisend-/väljundpiike.

CPU koormuse hüpped

Loomulikult mõjutab see süsteemi kiirust üsna negatiivselt ja esitab LSM-salvestusele ka tõsise väljakutse: kuidas tihendada, et toetada kõrgeid päringumäärasid ilma liigseid üldkulusid tekitamata?
Päris huvitav tundub ka mälu kasutamine tihendusprotsessis.

Näeme, kuidas pärast tihendamist muutub enamik mälust oleku vahemällu salvestatud olekust vabaks: see tähendab, et potentsiaalselt väärtuslik teave on sealt eemaldatud. Huvitav, kas seda siin kasutatakse fadvice() või mõni muu minimeerimistehnika või on põhjus selles, et vahemälu vabanes tihendamise käigus hävinud plokkidest?

Taastumine pärast ebaõnnestumist

Ebaõnnestumisest taastumine võtab aega ja seda mõjuval põhjusel. Sissetuleva miljoni salvestuse voo jaoks sekundis pidin ootama umbes 25 minutit, kuni taastamine toimus, võttes arvesse SSD-draivi.

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

Taastamisprotsessi peamine probleem on suur mälutarbimine. Vaatamata sellele, et tavaolukorras suudab server sama mälumahuga stabiilselt töötada, ei pruugi krahhi korral OOM-i tõttu taastuda. Ainus lahendus, mille leidsin, oli andmete kogumise keelamine, serveri avamine, taaskäivitamine ja taaskäivitamine, kui kogumine on lubatud.

Soojendama

Teine käitumine, mida soojenduse ajal meeles pidada, on seos madala jõudluse ja suure ressursikulu vahel kohe pärast starti. Mõne, kuid mitte kõigi käivituste ajal täheldasin protsessori ja mälu tõsist koormust.

Mälukasutuse lüngad näitavad, et Prometheus ei saa kõiki kogusid algusest peale konfigureerida ja osa teabest läheb kaotsi.
Ma pole täpseid põhjuseid kõrge protsessori ja mälu koormuse jaoks välja selgitanud. Kahtlustan, et see on tingitud uute aegridade loomisest peaplokis kõrge sagedusega.

CPU koormuse tõusud

Lisaks tihendustele, mis tekitavad üsna suure I/O koormuse, märkasin iga kahe minuti järel tõsiseid naelu protsessori koormuses. Pursked on pikemad, kui sisendvoog on suur ja näib olevat põhjustatud Go prügikogujast, kusjuures vähemalt mõned südamikud on täielikult laetud.

Need hüpped polegi nii tähtsusetud. Näib, et kui need juhtuvad, muutuvad Prometheuse sisemine sisestuspunkt ja mõõdikud kättesaamatuks, põhjustades samadel ajaperioodidel andmelünki.

Samuti võite märgata, et Prometheuse eksportija lülitub üheks sekundiks välja.

Võime märgata seoseid prügiveoga (GC).

Järeldus

Prometheus 2 TSDB on kiire, üsna tagasihoidliku riistvara abil võimeline käsitlema miljoneid aegridu ja samal ajal tuhandeid kirjeid sekundis. CPU ja ketta I/O kasutamine on samuti muljetavaldav. Minu näide näitas kuni 200 000 mõõdikut sekundis kasutatud tuuma kohta.

Laiendamise planeerimiseks peate meeles pidama piisavat mälumahtu ja see peab olema tõeline mälu. Kasutatud mälumaht, mida ma täheldasin, oli umbes 5 GB sissetuleva voo 100 000 kirje kohta sekundis, mis koos operatsioonisüsteemi vahemäluga andis umbes 8 GB hõivatud mälu.

Muidugi on protsessori ja ketaste I/O naelu taltsutamisega veel palju tööd teha ja see pole üllatav, arvestades, kui noor TSDB Prometheus 2 on võrreldes InnoDB, TokuDB, RocksDB, WiredTigeriga, kuid neil kõigil oli sarnane probleeme nende elutsükli alguses.

Allikas: www.habr.com