TSDB анализа во Прометеј 2

Базата на податоци за временски серии (TSDB) во Prometheus 2 е одличен пример за инженерско решение кое нуди значителни подобрувања во однос на складирањето Prometheus 2 v1 во однос на собирањето податоци и брзината на извршување на барањата, како и ефикасноста на ресурсите. Имплементиравме Prometheus 2 во Percona Monitoring and Management (PMM) и имав можност да ги разберам перформансите на Prometheus 2 TSDB. Во оваа статија ќе зборувам за резултатите од овие набљудувања.

Прометеј Просечен обем на работа

За оние кои се навикнати да се занимаваат со бази на податоци за општа намена, типичниот обем на работа на Prometheus е доста интересен. Стапката на акумулација на податоци има тенденција да биде стабилна: обично услугите што ги следите испраќаат приближно иста количина на метрика, а инфраструктурата се менува релативно бавно.
Барањата за информации може да доаѓаат од различни извори. Некои од нив, како предупредувањата, исто така имаат за цел стабилна и предвидлива вредност. Други, како што се барањата на корисниците, може да предизвикаат скокови, иако тоа не е случај за поголемиот дел од обемот на работа.

Тест на оптоварување

За време на тестирањето, се фокусирав на способноста да се акумулираат податоци. Го распоредив Prometheus 2.3.2 компајлиран со Go 1.10.1 (како дел од PMM 1.14) на услуга Linode користејќи ја оваа скрипта: StackScript. За најреална генерација на оптоварување, со ова StackScript Истрчав неколку MySQL јазли со вистинско оптоварување (Sysbench TPC-C Test), од кои секој емулираше 10 Linux/MySQL јазли.
Сите следни тестови беа извршени на Linode сервер со осум vCres и 32 GB меморија, со 20 симулации на оптоварување следејќи 800 MySQL примери. Или, во однос на Prometheus, 440 цели (цели), 380 такси (гребење) во секунда, 1,7 илјади записи (примероци) во секунда и XNUMX милиони активни временски серии.

Дизајн

Вообичаениот традиционален пристап на базата на податоци, вклучувајќи го и оној што го користи Prometheus 1.x, е да ограничување на меморијата. Ако не е доволно да се справите со товарот, ќе доживеете голема латентност и некои барања нема да бидат исполнети. Користењето на меморијата во Prometheus 2 може да се конфигурира преку клуч storage.tsdb.min-block-duration, што одредува колку долго записите ќе се чуваат во меморијата пред да се префрлат на дискот (стандардно е 2 часа). Количината на потребната меморија ќе зависи од бројот на временски серии, ознаки и гребнатини, плус нето-влезот. Во однос на просторот на дискот, Prometheus има за цел да користи 3 бајти по запишување (примерок). Од друга страна, барањата за меморија се многу повисоки.

Иако е можно да се конфигурира големината на блокот, не се препорачува рачно да се постави, така што останува со задачата да му дадете на Prometheus онолку меморија колку што му е потребно за вашиот обем на работа.
Ако нема доволно меморија за поддршка на дојдовниот проток на метрика, Прометеј ќе испадне од меморијата или ќе биде фатен од убиец на OOM.
Додавањето swap за да се одложи падот кога Prometheus снема меморија навистина не помага, бидејќи користењето на оваа функција предизвикува експлозии на меморијата. Мислам дека се работи за Go, неговиот собирач на ѓубре и како работи со swap.
Друг интересен пристап е да го поставите блокот за глава да се измие на дискот во одредено време, наместо да се брои од моментот кога започнал процесот.

Како што можете да видите од графиконот, испирање на дискот се случуваат на секои два часа. Ако го промените параметарот мин-блок-траење на еден час, тогаш овие ресетирање ќе се случуваат секој час, почнувајќи од половина час.
Ако сакате да го користите овој и други графикони во вашата инсталација на Prometheus, можете да го користите ова контролна табла. Дизајниран е за PMM, но со неколку модификации се вклопува во секоја инсталација на Prometheus.
Имаме активен блок, наречен head block, кој се чува во меморијата; блокови со постари податоци се достапни преку mmap(). Ова ја отстранува потребата да го конфигурирате кешот посебно, но исто така значи дека треба да оставите доволно простор за кешот на оперативниот систем ако сакате да барате податоци постари од блокот за глава.
Тоа исто така значи дека потрошувачката на виртуелна меморија на Prometheus ќе изгледа доста висока, што не е ништо за грижа.

Друга интересна точка на дизајнирање е употребата на WAL (напишете однапред дневник). Како што можете да видите од документацијата за складиштето, Prometheus користи WAL за да избегне падови. Специфичните механизми за гарантирање на опстанокот на податоците, за жал, не се добро документирани. Prometheus 2.3.2 го испушта WAL на дискот на секои 10 секунди и оваа поставка не може да се конфигурира од страна на корисникот.

Печати

Prometheus TSDB е дизајниран според сликата на LSM складирање (Log Structured merge - log-structured merge tree): блокот на главата периодично се мие на дискот, додека механизмот за набивање спојува неколку блокови заедно за да избегне скенирање премногу блокови на барања. Овде можете да го видите бројот на блокови што ги забележав на системот за тестирање по еден ден на оптоварување.

Ако сакате да дознаете повеќе за складирањето, можете да ја проверите датотеката 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() или некоја друга техника за минимизирање, или поради тоа што кешот е испразнет од блокови уништени со набивање?

Обнова на неуспех

За обновувањето од катастрофи е потребно време, и тоа има добра причина. За дојдовен поток од милион записи во секунда, морав да чекам околу 25 минути додека обновувањето го зема предвид SSD-уредот.

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 не може да ги конфигурира сите надоместоци од самиот почеток, а некои информации се изгубени.
Не ги дознав точните причини за високата употреба на процесорот и меморијата. Се сомневам дека тоа се должи на создавањето на нови временски серии во главниот блок со висока фреквенција.

Боцки на процесорот

Покрај згуснувањата, кои создаваат прилично високо I/O оптоварување, забележав сериозни скокови во оптоварувањето на процесорот на секои две минути. Рафалите се подолги со голем дојдовен сообраќај и изгледаат како да се предизвикани од собирачот на ѓубре Go, барем некои јадра се целосно наполнети.

Овие скокови не се толку безначајни. Се чини дека кога ќе се појават, внатрешната влезна точка и метриката на Прометеј стануваат недостапни, предизвикувајќи падови на податоците во истите временски интервали.

Може да забележите и дека извозникот Prometheus се исклучува на една секунда.

Можеме да видиме корелации со собирање ѓубре (GC).

Заклучок

TSDB во Prometheus 2 е брз, способен да ракува со милиони временски серии и во исто време илјадници записи во секунда користејќи прилично скромен хардвер. Употребата на процесорот и влезот/излезот на дискот е исто така импресивна. Мојот пример покажа до 200 метрики во секунда по искористено јадро.

За да планирате проширување, треба да запомните дека има доволно меморија и мора да биде вистинска меморија. Количината на користена меморија, што ја забележав, беше околу 5 GB на 100 записи во секунда од дојдовниот стрим, што, вкупно со кешот на оперативниот систем, даде околу 000 GB зафатена меморија.

Се разбира, има уште многу работа да се направи за да се скротат скоковите на CPU и I/O на дискот, и тоа не е изненадувачки, со оглед на тоа колку младиот TSDB Prometheus 2 се споредува со InnoDB, TokuDB, RocksDB, WiredTiger, но сите тие имаа слични проблеми на почетокот на нивниот животен циклус.

Извор: www.habr.com