Prometheus 2 жүйесіндегі уақыт қатарларының дерекқоры (TSDB) мәліметтерді жинақтау жылдамдығы, сұрауларды орындау және ресурс тиімділігі тұрғысынан Prometheus 2 жүйесіндегі v1 сақтау орнынан үлкен жақсартуларды ұсынатын инженерлік шешімнің тамаша үлгісі болып табылады. Біз Prometheus 2 бағдарламасын Percona Monitoring and Management (PMM) жүйесінде енгіздік және мен Prometheus 2 TSDB өнімділігін түсінуге мүмкіндік алдым. Бұл мақалада мен осы бақылаулардың нәтижелері туралы айтатын боламын.
Прометейдің орташа жұмыс жүктемесі
Жалпы мақсаттағы дерекқорлармен айналысатындар үшін әдеттегі 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 серверінде орындалды. Немесе Прометей терминімен айтқанда, 800 нысана, секундына 440 скреп, секундына 380 мың жазба және 1,7 миллион белсенді уақыт сериясы.
жобалау
Prometheus 1.x пайдаланғанды қоса алғанда, дәстүрлі дерекқорлардың әдеттегі тәсілі болып табылады . Егер жүктемені өңдеу жеткіліксіз болса, сіз жоғары кідірістерге тап боласыз және кейбір сұраулар орындалмайды. Prometheus 2 жадты пайдалану перне арқылы конфигурацияланады storage.tsdb.min-block-duration, ол дискіге тазарту алдында жазбалар жадта қанша уақыт сақталатынын анықтайды (әдепкі бойынша 2 сағат). Қажетті жад көлемі таза кіріс ағынына қосылған уақыт қатарларының, белгілердің және сызаттар санына байланысты болады. Дискідегі кеңістік тұрғысынан Прометей әр жазбаға (үлгі) 3 байтты пайдалануды мақсат етеді. Екінші жағынан, жад талаптары әлдеқайда жоғары.
Блок өлшемін конфигурациялау мүмкін болса да, оны қолмен конфигурациялау ұсынылмайды, сондықтан сіз Prometheus-ке жұмыс жүктемеңізге қанша қажет болса, сонша жад беруге мәжбүрсіз.
Кіріс метрика ағынын қолдау үшін жад жеткіліксіз болса, Прометей жадынан шығып қалады немесе OOM өлтіруші оған жетеді.
Prometheus жады таусылғанда, бұзылуды кешіктіру үшін своп қосу шынымен көмектеспейді, себебі бұл функцияны пайдалану жадты тұтынуды тудырады. Менің ойымша, бұл 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
}Прометейдегі нығыздамалар бас блогының дискіге шаю уақытына байланысты. Осы кезде бірнеше осындай операцияларды орындауға болады.
Тығыздау ешбір жолмен шектелмеген және орындау кезінде дискінің енгізу/шығаруының үлкен сілкіністерін тудыруы мүмкін сияқты.
Орталық процессордың жүктемесі
Әрине, бұл жүйенің жылдамдығына айтарлықтай теріс әсер етеді, сонымен қатар 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 салдарынан қалпына келмеуі мүмкін. Мен тапқан жалғыз шешім - деректерді жинауды өшіру, серверді қосу, оны қалпына келтіруге және жинақ қосылған кезде қайта жүктеуге мүмкіндік беру.
Жылу
Қыздыру кезінде есте сақтау керек тағы бір мінез-құлық - бұл іске қосылғаннан кейін төмен өнімділік пен жоғары ресурстарды тұтыну арасындағы байланыс. Кейбір, бірақ барлығы емес, мен процессор мен жадқа айтарлықтай жүктемені байқадым.
Жадты пайдаланудағы олқылықтар Prometheus барлық жинақтарды басынан конфигурациялай алмайтынын және кейбір ақпараттың жоғалғанын көрсетеді.
Мен жоғары процессор мен жад жүктемесінің нақты себептерін анықтаған жоқпын. Менің ойымша, бұл жоғары жиіліктегі бас блокта жаңа уақыттық қатарларды құруға байланысты.
Орталық процессордың жүктемесі жоғарылайды
Енгізу-шығару жүктемесінің айтарлықтай жоғары болуын тудыратын нығыздауларға қоса, мен әрбір екі минут сайын процессордың жүктемесінің айтарлықтай өсуін байқадым. Кіріс ағыны жоғары болған кезде серпілістер ұзағырақ болады және олар Go қоқыс жинағышынан туындаған сияқты, кем дегенде кейбір ядролар толығымен жүктеледі.
Бұл секірулер соншалықты аз емес. Бұл орын алған кезде, Прометейдің ішкі кіру нүктесі мен көрсеткіштері қолжетімсіз болып, дәл осы уақыт кезеңдері ішінде деректер олқылықтарын тудыратын сияқты.
Сондай-ақ Prometheus экспорттаушысы бір секундқа өшетінін байқай аласыз.
Біз қоқыс жинаумен (GC) корреляцияны байқай аламыз.
қорытынды
Prometheus 2-дегі TSDB жылдам, миллиондаған уақыттық қатарларды және сонымен бірге өте қарапайым жабдықты пайдаланып секундына мыңдаған жазбаларды өңдеуге қабілетті. CPU және дискінің енгізу/шығаруын пайдалану да әсерлі. Менің мысалым қолданылған ядроға секундына 200 000 метрикаға дейін көрсетті.
Кеңейтуді жоспарлау үшін жадтың жеткілікті көлемін есте сақтау керек және бұл нақты жад болуы керек. Мен байқаған жад көлемі кіріс ағынының секундына 5 100 жазбасына шамамен 000 ГБ құрады, ол операциялық жүйе кэшімен бірге шамамен 8 ГБ бос жадты береді.
Әрине, процессор мен дискідегі енгізу/шығару өсімдерін реттеу үшін әлі көп жұмыс істеу керек, және бұл TSDB Prometheus 2-ні InnoDB, TokuDB, RocksDB, WiredTiger-пен қаншалықты салыстыратынын ескерсек, таңқаларлық емес, бірақ олардың барлығында ұқсас болды. олардың өмірлік циклінің басында проблемалар.
Ақпарат көзі: www.habr.com