Prometheus 2деги убакыт серияларынын маалымат базасы (TSDB) инженердик чечимдин эң сонун үлгүсү болуп саналат, ал Prometheus 2деги v1 сактагычка караганда маалыматтарды топтоо ылдамдыгы, сурамдардын аткарылышы жана ресурстун натыйжалуулугу жагынан олуттуу жакшыртууларды сунуш кылат. Биз Prometheus 2 программасын Percona Monitoring and Management (PMM) программасында ишке ашырып жатканбыз жана мен Prometheus 2 TSDBнин иштешин түшүнүүгө мүмкүнчүлүк алдым. Бул макалада мен бул байкоолордун натыйжалары жөнүндө сөз кылам.
Орточо Prometheus жумуш жүгү
Жалпы максаттагы маалымат базалары менен иштегендер үчүн Prometheusтун типтүү иш жүгү абдан кызыктуу. Маалыматтарды топтоо ылдамдыгы туруктуу болот: адатта сиз көзөмөлдөгөн кызматтар болжол менен бирдей сандагы көрсөткүчтөрдү жөнөтүшөт жана инфраструктура салыштырмалуу жай өзгөрөт.
Маалымат үчүн суроо-талаптар ар кандай булактардан келип чыгышы мүмкүн. Алардын айрымдары, мисалы, эскертүүлөр, ошондой эле туруктуу жана болжолдуу мааниге умтулушат. Башкалары, мисалы, колдонуучунун суроо-талаптары жарылууга алып келиши мүмкүн, бирок бул көпчүлүк жүктөмдө андай эмес.
Жүктөө сыноо
Сыноо учурунда мен маалыматтарды топтоо жөндөмүнө басым жасадым. Мен бул скрипттин жардамы менен Linode кызматына Go 2.3.2 (PMM 1.10.1 бөлүгү катары) менен түзүлгөн Prometheus 1.14ди жайгаштырдым: . Эң реалдуу жүктөө үчүн, муну колдонуу Мен чыныгы жүктөмү бар бир нече MySQL түйүндөрүн ишке киргиздим (Sysbench TPC-C Test), алардын ар бири 10 Linux/MySQL түйүнүнө окшоштурулган.
Төмөнкү сыноолордун бардыгы эки жүз MySQL инстанциясын көзөмөлдөгөн 32 жүктөө симуляциясын иштетип, сегиз виртуалдык өзөгү жана 20 ГБ эс тутуму бар Linode серверинде аткарылды. Же Prometheus менен айтканда, 800 буталар, секундасына 440 скрепер, секундасына 380 миң жазуу жана 1,7 миллион активдүү убакыт сериясы.
дизайн
Prometheus 1.x колдонгон, анын ичинде салттуу маалымат базаларынын кадимки мамилеси болуп саналат . Эгерде ал жүктү көтөрүү үчүн жетишсиз болсо, сиз жогорку кечигүүлөрдү баштан өткөрөсүз жана айрым сурамдар аткарылбай калат. Prometheus 2де эстутум колдонуу ачкыч аркылуу конфигурацияланат storage.tsdb.min-block-duration, бул дискке түшүрүү алдында жазуулар эстутумда канча убакыт сакталаарын аныктайт (демейки 2 саат). Талап кылынган эстутумдун көлөмү таза кирүүчү агымга кошулган убакыт серияларынын, энбелгилердин жана скраптардын санына жараша болот. Дисктеги мейкиндик жагынан Prometheus ар бир жазуу (үлгү) үчүн 3 байт колдонууга багытталган. Башка жагынан алганда, эс талаптары алда канча жогору.
Блоктун өлчөмүн конфигурациялоо мүмкүн болсо да, аны кол менен конфигурациялоо сунушталбайт, андыктан сиз Прометейге иш жүгүңүзгө канча талап кылса, ошончо эстутумду берүүгө аргасыз болосуз.
Кирүүчү метрика агымын колдоо үчүн эстутум жетишсиз болсо, Prometheus эс тутумунан чыгып калат же OOM өлтүргүч ага жетет.
Прометейдин эс тутуму түгөнүп калганда, бузулууну кечиктирүү үчүн своп кошуу чындап эле жардам бербейт, анткени бул функцияны колдонуу жарылуучу эстутумду талап кылат. Менин оюмча, бул Go менен, анын таштанды жыйноочусуна жана алмашууга байланыштуу.
Дагы бир кызыктуу ыкма - процесстин башталышынан баштап аны санабай, белгилүү бир убакта дискке жуулчу блокту конфигурациялоо.
Графиктен көрүнүп тургандай, дискке жуурулушуу ар бир эки саатта болуп турат. Эгер сиз мин-блоктун узактыгы параметрин бир саатка өзгөртсөңүз, анда бул баштапкы абалга келтирүү жарым сааттан кийин саат сайын ишке ашат.
Эгер сиз Prometheus орнотууңузда ушул жана башка графиктерди колдонгуңуз келсе, муну колдонсоңуз болот . Ал PMM үчүн иштелип чыккан, бирок анча-мынча өзгөртүүлөр менен Prometheus орнотууларына туура келет.
Бизде эстутумда сакталган баш блок деп аталган активдүү блок бар; эски маалыматтар менен блоктору аркылуу жеткиликтүү mmap(). Бул кэшти өзүнчө конфигурациялоонун зарылдыгын жокко чыгарат, бирок ошондой эле сиз баш блогу жайгаша алгандан эски маалыматтарды сурагыңыз келсе, операциялык тутумдун кэши үчүн жетиштүү орун калтырышыңыз керек дегенди билдирет.
Бул ошондой эле Prometheus виртуалдык эстутум керектөө абдан жогору көрүнөт дегенди билдирет, бул тынчсыздана турган нерсе эмес.
Дагы бир кызыктуу дизайн пункту WAL (алдыга жазуу журналы) колдонуу болуп саналат. Сактоо документтеринен көрүнүп тургандай, Prometheus бузулууларды болтурбоо үчүн WAL колдонот. Маалыматтын сакталышын кепилдөөнүн конкреттүү механизмдери, тилекке каршы, жакшы документтештирилген эмес. Prometheus 2.3.2 версиясы WALди дискке ар бир 10 секундада жууп салат жана бул параметр колдонуучу конфигурациялоого болбойт.
Компрессиялар
Prometheus TSDB LSM (Log Structured Merge) дүкөнү сыяктуу иштелип чыккан: баш блогу дискке мезгил-мезгили менен жууп турат, ал эми тыгыздоо механизми суроо учурунда өтө көп блокторду сканерлөөдөн качуу үчүн бир нече блокторду бириктирет. Бул жерде сиз бир күндүк жүктөөдөн кийин тест системасында байкаган блоктордун санын көрө аласыз.
Дүкөн жөнүндө көбүрөөк билгиңиз келсе, колдо болгон блоктор жана алардын кантип пайда болгондугу тууралуу маалыматы бар meta.json файлын карасаңыз болот.
{
"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
}Прометейдеги ныкташтыруулар баш блоктун дискке жуурулушкан убактысына байланыштуу. Бул учурда, мындай бир нече операцияларды жүзөгө ашырууга болот.
Бул тыгыздалуу эч кандай жол менен чектелбейт жана аткаруу учурунда чоң дисктин I/O чокусуна алып келиши мүмкүн окшойт.
CPU жүктөө ылдамдыгы
Албетте, бул системанын ылдамдыгына терс таасирин тийгизет, ошондой эле LSM сактоо үчүн олуттуу кыйынчылык туудурат: өтө көп чыгым келтирбестен, жогорку суроо-талаптарды колдоо үчүн кантип компактациялоо керек?
Кысуу процессинде эстутумду колдонуу да абдан кызыктуу көрүнөт.
Кысылгандан кийин эс тутумдун көбү Кэштелгенден Акысызга кандайча өзгөрөрүн көрө алабыз: бул потенциалдуу баалуу маалымат ал жерден алынып салынганын билдирет. Кызык, бул жерде колдонулганбы fadvice() же башка минимизациялоо ыкмасы, же бул кэш ныктоо учурунда жок кылынган блоктордон бошотулгандыктанбы?
Катачылыктан кийин калыбына келтирүү
Кыйынчылыктарды калыбына келтирүү убакытты талап кылат жана жүйөлүү себептерден улам. Секундасына миллиондогон жазуулардын кирүүчү агымы үчүн мен SSD дискин эске алуу менен калыбына келтирилгенде 25 мүнөт күтүшүм керек болчу.
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."Калыбына келтирүү процессинин негизги көйгөйү - эстутумдун көп керектөөсү. Кадимки кырдаалда сервер бирдей көлөмдөгү эс тутум менен туруктуу иштей ала турганына карабастан, ал бузулуп калса, OOMден улам калыбына келтирилбей калышы мүмкүн. Мен тапкан жалгыз чечим - маалыматтарды чогултууну өчүрүү, серверди ачуу, аны калыбына келтирүүгө жана чогултуу иштетилгенде кайра жүктөө.
Жылуу
Жылытуу учурунда эстен чыгарбоо керек болгон дагы бир жүрүм-турум - бул башталгычтан кийин аз өндүрүмдүүлүк менен ресурстарды көп керектөөнүн ортосундагы байланыш. Кээ бир учурларда, бирок баары эмес, мен CPU жана эс тутумга олуттуу жүктөмдөрдү байкадым.
Эстутумду колдонуудагы боштуктар Prometheus башынан эле бардык коллекцияларды конфигурациялай албаганын жана кээ бир маалыматтар жоголуп жатканын көрсөтүп турат.
Процессордун жана эс тутумдун көп болушунун так себептерин түшүнө элекмин. Мен бул жогорку жыштык менен баш блогунда жаңы убакыт катар түзүү менен шартталган деп шектенүүдө.
CPU жүктөмү көтөрүлөт
Киргизүү/чыгаруу жүгүн жетишерлик жогорку деңгээлде жараткан тыгыздалуулардан тышкары, мен ар бир эки мүнөт сайын CPU жүктөөсүндө олуттуу өсүштөрдү байкадым. Киргизүү агымы жогору болгондо жарылуулар узунураак болот жана Go'нун таштанды жыйгычынан келип чыккандай көрүнөт, жок дегенде кээ бир өзөктөр толук жүктөлөт.
Бул секирүүлөр анчалык деле аз эмес. Булар пайда болгондо, Прометейдин ички кирүү чекити жана көрсөткүчтөрү жеткиликсиз болуп, ошол эле убакыт аралыгында маалымат боштуктарын пайда кылат.
Prometheus экспорттоочусу бир секундага өчүрүлгөнүн да байкай аласыз.
Биз таштанды чогултуу (GC) менен байланышты байкай алабыз.
жыйынтыктоо
Prometheus 2деги TSDB ылдам, миллиондогон убакыт серияларын жана ошол эле учурда өтө жөнөкөй аппараттык каражаттарды колдонуу менен секундасына миңдеген жазууларды иштетүүгө жөндөмдүү. CPU жана дискти киргизүү/чыгаруу да таасирдүү. Менин мисалымда колдонулган ядро үчүн секундасына 200 000 метрге чейин көрсөтүлгөн.
Кеңейтүүнү пландаштыруу үчүн, сиз эстутумдун жетиштүү көлөмүн эстешиңиз керек жана бул чыныгы эс тутум болушу керек. Мен байкаган эстутумдун көлөмү кирүүчү агымдын секундасына 5 100 жазуусу үчүн болжол менен 000 ГБ болгон, ал операциялык тутумдун кэши менен бирге болжол менен 8 ГБ ээлеген эстутумду берген.
Албетте, процессордун жана дисктин I/O спиктерин жөнгө салуу үчүн дагы көп иштер жасалышы керек жана бул таң калыштуу эмес, жаш TSDB Prometheus 2 InnoDB, TokuDB, RocksDB, WiredTiger менен салыштырылган, бирок алардын бардыгы окшош болгон. көйгөйлөр, алардын жашоо циклинин башында.
Source: www.habr.com