Prometheus 2:n aikasarjatietokanta (TSDB) on erinomainen esimerkki suunnitteluratkaisusta, joka tarjoaa merkittäviä parannuksia Prometheus 2:n v1-tallennustilaan verrattuna tiedon keräämisnopeuden, kyselyn suorittamisen ja resurssitehokkuuden suhteen. Otimme Prometheus 2:ta käyttöön Percona Monitoring and Managementissa (PMM), ja minulla oli tilaisuus ymmärtää Prometheus 2 TSDB:n suorituskykyä. Tässä artikkelissa puhun näiden havaintojen tuloksista.
Prometheuksen keskimääräinen työmäärä
Niille, jotka ovat tottuneet käsittelemään yleiskäyttöisiä tietokantoja, tyypillinen Prometheuksen työmäärä on varsin mielenkiintoinen. Tietojen kertymisnopeus on yleensä vakaa: yleensä valvomasi palvelut lähettävät suunnilleen saman määrän mittareita, ja infrastruktuuri muuttuu suhteellisen hitaasti.
Tietopyynnöt voivat tulla eri lähteistä. Jotkut niistä, kuten hälytykset, pyrkivät myös vakaaseen ja ennustettavaan arvoon. Muut, kuten käyttäjien pyynnöt, voivat aiheuttaa purskeita, vaikka näin ei olekaan useimmissa työkuormissa.
Kuormitustesti
Testauksen aikana keskityin tiedon keräämiskykyyn. Otin käyttöön Prometheus 2.3.2:n, joka on käännetty Go 1.10.1:llä (osana PMM 1.14:ää) Linode-palvelussa käyttämällä tätä komentosarjaa: . Käytä tätä realistisimman kuorman luomiseksi Käynnistin useita MySQL-solmuja todellisella kuormalla (Sysbench TPC-C Test), joista jokainen emuloi 10 Linux/MySQL-solmua.
Kaikki seuraavat testit suoritettiin Linode-palvelimella, jossa oli kahdeksan virtuaaliydintä ja 32 Gt muistia ja jossa suoritettiin 20 kuormitussimulaatiota, jotka tarkkailivat kahtasadaa MySQL-instanssia. Tai Prometheuksen termein 800 kohdetta, 440 naarmua sekunnissa, 380 tuhatta tietuetta sekunnissa ja 1,7 miljoonaa aktiivista aikasarjaa.
Suunnittelu
Perinteisten tietokantojen, mukaan lukien Prometheus 1.x:n, tavallinen lähestymistapa on . Jos se ei riitä käsittelemään kuormaa, koet korkeita viiveitä ja jotkin pyynnöt epäonnistuvat. Muistin käyttö Prometheus 2:ssa on konfiguroitavissa avaimella storage.tsdb.min-block-duration, joka määrittää, kuinka kauan tallennuksia säilytetään muistissa ennen kuin ne tyhjennetään levylle (oletus on 2 tuntia). Tarvittava muistin määrä riippuu saapuvaan verkkovirtaan lisättyjen aikasarjojen, tarrojen ja naarmujen määrästä. Levytilan osalta Prometheus pyrkii käyttämään 3 tavua tietuetta (näytettä) kohti. Toisaalta muistivaatimukset ovat paljon korkeammat.
Vaikka lohkon kokoa on mahdollista määrittää, sitä ei suositella määrittämään manuaalisesti, joten sinun on annettava Prometheukselle niin paljon muistia kuin se vaatii työtaakkaasi varten.
Jos muisti ei riitä tukemaan tulevaa mittausvirtaa, Prometheus putoaa muistista tai OOM-tappaja pääsee siihen.
Swap-toiminnon lisääminen kaatumisen viivyttämiseksi, kun Prometheuksen muisti loppuu, ei todellakaan auta, koska tämän toiminnon käyttö kuluttaa räjähdysmäisesti muistia. Luulen, että se liittyy Goon, sen roskakoriin ja tapaan, jolla se käsittelee vaihtoa.
Toinen mielenkiintoinen lähestymistapa on määrittää päälohko huuhdettavaksi levylle tiettyyn aikaan sen sijaan, että se laskettaisiin prosessin alusta.
Kuten kaaviosta näkyy, levyn huuhtelu tapahtuu kahden tunnin välein. Jos muutat min-block-duration -parametrin yhdeksi tunniksi, nämä nollaukset tapahtuvat tunnin välein alkaen puolen tunnin kuluttua.
Jos haluat käyttää tätä ja muita kaavioita Prometheus-asennuksessasi, voit käyttää tätä . Se on suunniteltu PMM:lle, mutta pienillä muutoksilla se sopii kaikkiin Prometheus-asennuksiin.
Meillä on aktiivinen lohko nimeltä head block, joka on tallennettu muistiin; lohkot vanhemmilla tiedoilla ovat saatavilla kautta mmap(). Tämä eliminoi tarpeen määrittää välimuistia erikseen, mutta tarkoittaa myös sitä, että käyttöjärjestelmän välimuistille on jätettävä riittävästi tilaa, jos haluat kysyä tietoja, jotka ovat vanhempia kuin mitä head block mahtuu.
Tämä tarkoittaa myös sitä, että Prometheus-virtuaalimuistin kulutus näyttää melko korkealta, mikä ei ole huolestuttava asia.
Toinen mielenkiintoinen suunnittelukohta on WAL:n (write ahead log) käyttö. Kuten tallennusdokumentaatiosta näkyy, Prometheus käyttää WAL:ia kaatumisten välttämiseksi. Tiettyjä mekanismeja tietojen säilyvyyden takaamiseksi ei valitettavasti ole dokumentoitu hyvin. Prometheus-versio 2.3.2 huuhtelee WAL:n levylle 10 sekunnin välein, eikä tämä vaihtoehto ole käyttäjän määritettävissä.
Tiivistykset
Prometheus TSDB on suunniteltu LSM (Log Structured Merge) -säilöksi: päälohko huuhdellaan ajoittain levylle, kun taas tiivistysmekanismi yhdistää useita lohkoja yhteen välttääkseen liian monien lohkojen skannauksen kyselyiden aikana. Täältä näet niiden lohkojen määrän, jotka havaitsin testijärjestelmässä päivän latauspäivän jälkeen.
Jos haluat lisätietoja kaupasta, voit tutkia meta.json-tiedostoa, jossa on tietoa saatavilla olevista lohkoista ja niiden syntymisestä.
{
"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
}Prometheuksen tiivistykset on sidottu aikaan, jolloin päälohko huuhdellaan levylle. Tässä vaiheessa voidaan suorittaa useita tällaisia toimintoja.
Näyttää siltä, että tiivistämistä ei ole rajoitettu millään tavalla ja ne voivat aiheuttaa suuria levyn I/O-piikkejä suorituksen aikana.
Prosessorin kuormituspiikit
Tällä on tietysti melko kielteinen vaikutus järjestelmän nopeuteen, ja se on myös vakava haaste LSM-tallennukselle: kuinka tehdä tiivistys tukemaan korkeita pyyntönopeuksia aiheuttamatta liikaa ylimääräisiä kustannuksia?
Myös muistin käyttö tiivistysprosessissa näyttää varsin mielenkiintoiselta.
Näemme, kuinka suurin osa muistista muuttuu tiivistyksen jälkeen välimuistista vapaaksi: tämä tarkoittaa, että mahdollisesti arvokasta tietoa on poistettu sieltä. Kiinnostaa, onko sitä täällä käytetty fadvice() tai jokin muu minimointitekniikka, vai johtuuko se siitä, että kätkö vapautettiin tiivistyksen aikana tuhoutuneista lohkoista?
Toipuminen epäonnistumisen jälkeen
Vioista toipuminen vie aikaa, ja hyvästä syystä. Saapuvan miljoonan tietueen sekuntivirtaa varten jouduin odottamaan noin 25 minuuttia, kun palautus suoritettiin ottaen huomioon SSD-asema.
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."Palautusprosessin suurin ongelma on korkea muistin kulutus. Huolimatta siitä, että normaalitilanteessa palvelin voi toimia vakaasti samalla muistimäärällä, kaatuessaan se ei välttämättä palaudu OOM:n takia. Ainoa ratkaisu, jonka löysin, oli poistaa tietojen kerääminen käytöstä, tuoda palvelin esiin, antaa sen palautua ja käynnistää uudelleen keräämisen ollessa käytössä.
Lämmittely
Toinen toimintatapa, joka tulee muistaa lämmittelyn aikana, on heikon suorituskyvyn ja suuren resurssien kulutuksen välinen suhde heti käynnistyksen jälkeen. Joidenkin, mutta ei kaikkien käynnistysten aikana havaitsin vakavan kuormituksen suorittimessa ja muistissa.
Muistin käyttöaukot osoittavat, että Prometheus ei voi määrittää kaikkia kokoelmia alusta alkaen, ja osa tiedoista katoaa.
En ole selvittänyt tarkkoja syitä korkeaan prosessorin ja muistin kuormitukseen. Epäilen, että tämä johtuu uusien aikasarjojen luomisesta päälohkossa korkealla taajuudella.
Prosessorin kuormituspiikki
Varsin korkeaa I/O-kuormaa luovien tiivistysten lisäksi huomasin prosessorin kuormituksessa vakavia piikkejä kahden minuutin välein. Purskeet ovat pidempiä, kun syöttövirta on korkea, ja näyttävät johtuvan Go:n roskakeräyksestä, ja ainakin osa ytimistä on täynnä.
Nämä hyppyt eivät ole niin merkityksettömiä. Näyttää siltä, että kun nämä tapahtuvat, Prometheuksen sisäinen sisääntulopiste ja mittarit eivät ole käytettävissä, mikä aiheuttaa dataaukkoja samana ajanjaksona.
Voit myös huomata, että Prometheus-viejä sammuu yhdeksi sekunniksi.
Voimme havaita korrelaatioita jätekeräyksen (GC) kanssa.
Johtopäätös
Prometheus 2:n TSDB on nopea, ja se pystyy käsittelemään miljoonia aikasarjoja ja samalla tuhansia tietueita sekunnissa melko vaatimattomalla laitteistolla. Prosessorin ja levyn I/O-käyttöaste on myös vaikuttava. Esimerkkini osoitti jopa 200 000 mittaria sekunnissa käytettyä ydintä kohden.
Laajentamisen suunnittelua varten on muistettava riittävä määrä muistia, ja tämän on oltava oikeaa muistia. Käyttämäni muistin määrä oli noin 5 Gt per 100 000 tietuetta sekunnissa tulevaa virtaa, mikä yhdessä käyttöjärjestelmän välimuistin kanssa antoi noin 8 Gt varattua muistia.
Tietysti on vielä paljon tehtävää suorittimen ja levyn I/O-piikkien kesyttämiseksi, ja tämä ei ole yllättävää, kun otetaan huomioon kuinka nuori TSDB Prometheus 2 on verrattuna InnoDB:hen, TokuDB:hen, RocksDB:hen, WiredTigeriin, mutta kaikilla oli samanlainen. ongelmia elinkaarensa alussa.
Lähde: will.com