„Prometheus 2“ laiko eilučių duomenų bazė (TSDB) yra puikus inžinerinio sprendimo pavyzdys, siūlantis esminius patobulinimus, palyginti su v2 saugykla „Prometheus 1“, atsižvelgiant į duomenų kaupimo greitį, užklausų vykdymą ir išteklių efektyvumą. Įdiegėme „Prometheus 2“ programoje „Percona Monitoring and Management“ (PMM) ir turėjau galimybę suprasti „Prometheus 2 TSDB“ veikimą. Šiame straipsnyje kalbėsiu apie šių stebėjimų rezultatus.
Vidutinis Prometėjo darbo krūvis
Tiems, kurie įpratę dirbti su bendros paskirties duomenų bazėmis, tipiškas Prometheus darbo krūvis yra gana įdomus. Duomenų kaupimo greitis paprastai būna stabilus: dažniausiai jūsų stebimos paslaugos siunčia maždaug tiek pat metrikų, o infrastruktūra keičiasi gana lėtai.
Informacijos prašymai gali būti gaunami iš įvairių šaltinių. Kai kurie iš jų, pavyzdžiui, įspėjimai, taip pat siekia stabilios ir nuspėjamos vertės. Kiti, pvz., vartotojų užklausos, gali sukelti serijas, nors tai netinka daugeliui darbo krūvių.
Apkrovos testas
Bandydama daugiausia dėmesio skyriau gebėjimui kaupti duomenis. „Linode“ paslaugoje įdiegiau „Prometheus 2.3.2“, sudarytą su „Go 1.10.1“ (kaip PMM 1.14 dalį), naudodamas šį scenarijų: . Norėdami sukurti realiausią apkrovą, naudokite šį Paleidau kelis MySQL mazgus su realia apkrova („Sysbench TPC-C Test“), kurių kiekvienas emuliavo 10 „Linux“ / „MySQL“ mazgų.
Visi toliau nurodyti testai buvo atlikti Linode serveryje su aštuoniais virtualiais branduoliais ir 32 GB atminties, vykdant 20 apkrovos modeliavimų, stebinčių du šimtus MySQL egzempliorių. Arba, Prometėjo terminais, 800 taikinių, 440 įbrėžimų per sekundę, 380 tūkstančių įrašų per sekundę ir 1,7 milijono aktyvių laiko eilučių.
Dizainas
Įprastas tradicinių duomenų bazių požiūris, įskaitant tą, kurį naudoja Prometheus 1.x, yra . Jei apkrovos tvarkymui nepakanka, patirsite daug delsos ir kai kurios užklausos nepavyks. Atminties naudojimas „Prometheus 2“ konfigūruojamas naudojant raktą storage.tsdb.min-block-duration, kuris nustato, kiek laiko įrašai bus saugomi atmintyje prieš iškraunant juos į diską (numatytasis nustatymas yra 2 valandos). Reikalingos atminties kiekis priklausys nuo laiko eilučių, etikečių ir įbrėžimų, pridėtų prie grynojo gaunamo srauto, skaičiaus. Kalbant apie vietos diske, „Prometheus“ siekia naudoti 3 baitus vienam įrašui (pavyzdžiui). Kita vertus, atminties reikalavimai yra daug didesni.
Nors bloko dydį galima sukonfigūruoti, nerekomenduojama jo konfigūruoti rankiniu būdu, todėl esate priversti Prometheus skirti tiek atminties, kiek reikia jūsų darbo krūviui.
Jei neužteks atminties gaunamam metrikų srautui palaikyti, „Prometheus“ iškris iš atminties arba prie jos pasieks OOM žudikas.
Apsikeitimo įtraukimas, kad būtų atidėtas gedimas, kai Prometheus baigiasi atmintis, tikrai nepadeda, nes naudojant šią funkciją labai sunaudojama daug atminties. Manau, kad tai yra kažkas bendro su „Go“, jos šiukšlių surinkėju ir tuo, kaip jis susiduria su mainais.
Kitas įdomus būdas yra sukonfigūruoti galvos bloką, kad jis būtų nuplaunamas į diską tam tikru metu, o ne skaičiuojant nuo proceso pradžios.
Kaip matote iš grafiko, diskas nuplaunamas kas dvi valandas. Jei pakeisite parametrą min-block-duration į vieną valandą, šie nustatymai iš naujo bus atliekami kas valandą, pradedant po pusvalandžio.
Jei norite naudoti šį ir kitus grafikus savo „Prometheus“ diegime, galite naudoti šį . Jis buvo sukurtas PMM, tačiau su nedideliais pakeitimais tinka bet kokiam Prometheus įrenginiui.
Turime aktyvų bloką, vadinamą galvos bloku, kuris saugomas atmintyje; blokai su senesniais duomenimis pasiekiami per mmap(). Tai pašalina būtinybę atskirai konfigūruoti talpyklą, bet taip pat reiškia, kad turite palikti pakankamai vietos operacinės sistemos talpyklai, jei norite pateikti užklausą senesnių duomenų nei gali talpinti galvos blokas.
Tai taip pat reiškia, kad „Prometheus“ virtualios atminties suvartojimas atrodys gana didelis, dėl ko jaudintis neverta.
Kitas įdomus dizaino aspektas yra WAL (rašyti į priekį žurnalo) naudojimas. Kaip matote iš saugojimo dokumentų, „Prometheus“ naudoja WAL, kad išvengtų gedimų. Konkretūs mechanizmai, užtikrinantys duomenų išlikimą, deja, nėra gerai dokumentuoti. 2.3.2 versija Prometheus išplauna WAL į diską kas 10 sekundžių ir šios parinkties vartotojas negali konfigūruoti.
Sutankinimai
„Prometheus TSDB“ sukurta kaip LSM (log Structured Merge) saugykla: pagrindinis blokas periodiškai nuplaunamas į diską, o sutankinimo mechanizmas sujungia kelis blokus, kad užklausų metu nebūtų nuskaitoma per daug blokų. Čia galite pamatyti blokų skaičių, kurį stebėjau bandymo sistemoje po įkrovos dienos.
Jei norite sužinoti daugiau apie parduotuvę, galite peržiūrėti failą meta.json, kuriame pateikiama informacija apie galimus blokus ir jų atsiradimą.
{
"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
}„Prometheus“ sutankinimai yra susieti su laiku, kai galvos blokas nuplaunamas į diską. Šiuo metu gali būti atliekamos kelios tokios operacijos.
Atrodo, kad sutankinimai jokiu būdu nėra ribojami ir vykdymo metu gali sukelti didelius disko įvesties/išvesties šuolius.
CPU apkrovos šuoliai
Žinoma, tai gana neigiamai veikia sistemos greitį, taip pat kelia rimtą iššūkį LSM saugyklai: kaip atlikti sutankinimą, kad būtų palaikomas didelis užklausų dažnis, nesukeliant per daug papildomų išlaidų?
Atminties naudojimas tankinimo procese taip pat atrodo gana įdomus.
Matome, kaip po sutankinimo didžioji dalis atminties pakeičia būseną iš talpyklos į laisvą: tai reiškia, kad iš ten buvo pašalinta potencialiai vertinga informacija. Įdomu, ar jis čia naudojamas fadvice() ar kokia kita minimalizavimo technika, ar taip yra todėl, kad talpykla buvo išlaisvinta iš blokų, sunaikintų tankinimo metu?
Atsigavimas po nesėkmės
Atsigavimas po nesėkmių užtrunka ir dėl geros priežasties. Įeinančio milijono įrašų per sekundę srauto turėjau laukti apie 25 minutes, kol buvo atliktas atkūrimas, atsižvelgiant į SSD diską.
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."Pagrindinė atkūrimo proceso problema yra didelis atminties suvartojimas. Nepaisant to, kad įprastoje situacijoje serveris gali stabiliai dirbti su tuo pačiu atminties kiekiu, sugenda jis gali neatkurti dėl OOM. Vienintelis sprendimas, kurį radau, buvo išjungti duomenų rinkimą, iškviesti serverį, leisti jam atsigauti ir paleisti iš naujo, kai rinkimas įjungtas.
Apšilimas
Kitas elgesys, kurį reikia nepamiršti apšilimo metu, yra ryšys tarp mažo našumo ir didelio išteklių suvartojimo iškart po starto. Kai kurių, bet ne visų startų metu pastebėjau rimtą procesoriaus ir atminties apkrovą.
Atminties naudojimo spragos rodo, kad „Prometheus“ negali sukonfigūruoti visų kolekcijų nuo pat pradžių ir prarandama dalis informacijos.
Tikslių didelio procesoriaus ir atminties apkrovos priežasčių nesupratau. Įtariu, kad taip yra dėl naujų laiko eilučių sukūrimo pagrindiniame bloke su dideliu dažniu.
CPU apkrovos šuoliai
Be sutankinimų, kurie sukuria gana didelę I/O apkrovą, pastebėjau rimtus procesoriaus apkrovos šuolius kas dvi minutes. Plyšiai yra ilgesni, kai įvesties srautas yra didelis, ir atrodo, kad juos sukelia „Go“ šiukšlių surinkėjas, o bent kai kurie branduoliai yra visiškai apkrauti.
Šie šuoliai nėra tokie nereikšmingi. Atrodo, kad kai tai įvyksta, „Prometheus“ vidinis įėjimo taškas ir metrika tampa nepasiekiami, todėl per tą patį laikotarpį atsiranda duomenų spragų.
Taip pat galite pastebėti, kad „Prometheus“ eksportuotojas vienai sekundei išsijungia.
Galime pastebėti sąsajas su šiukšlių surinkimu (GC).
išvada
TSDB „Prometheus 2“ yra greitas, galintis apdoroti milijonus laiko eilučių ir tuo pačiu tūkstančius įrašų per sekundę naudojant gana kuklią aparatinę įrangą. CPU ir disko I/O panaudojimas taip pat įspūdingas. Mano pavyzdys parodė iki 200 000 metrikų per sekundę vienam panaudotam branduoliui.
Norėdami planuoti plėtrą, turite atsiminti apie pakankamą atminties kiekį, ir tai turi būti tikra atmintis. Naudojamos atminties kiekis, kurį pastebėjau, buvo apie 5 GB 100 000 įrašų per sekundę gaunamo srauto, o tai kartu su operacinės sistemos talpykla davė apie 8 GB užimtos atminties.
Žinoma, dar reikia daug nuveikti, norint sutramdyti procesoriaus ir disko įvesties / išvesties šuolius, ir tai nenuostabu, atsižvelgiant į tai, kaip jauni TSDB Prometheus 2 yra lyginami su InnoDB, TokuDB, RocksDB, WiredTiger, tačiau jie visi turėjo panašius problemų jų gyvenimo ciklo pradžioje.
Šaltinis: www.habr.com