Заббик је систем за праћење. Као и сваки други систем, он се суочава са три главна проблема свих система за праћење: прикупљање и обрада података, чување историје и њено чишћење.
Фазе пријема, обраде и снимања података захтевају време. Не много, али за велики систем то може довести до великих кашњења. Проблем складиштења је проблем приступа подацима. Користе се за извештаје, провере и окидаче. Латенције у приступу подацима такође утичу на перформансе. Када базе података расту, нерелевантни подаци морају бити избрисани. Уклањање је тешка операција која такође троши неке ресурсе.
Проблеми кашњења током прикупљања и складиштења у Заббик-у се решавају кеширањем: неколико типова кеша, кеширање у бази података. Да би решио трећи проблем, кеширање није погодно, па је Заббик користио ТимесцалеДБ. Он ће вам рећи о томе Андреи Гусхцхин - Инжењер техничке подршке . Андреи подржава Заббик више од 6 година и има директно искуство са перформансама.
Како функционише ТимесцалеДБ, какве перформансе може дати у поређењу са обичним ПостгреСКЛ-ом? Какву улогу Заббик игра за ТимесцалеДБ базу података? Како почети од нуле и како прећи са ПостгреСКЛ-а и која конфигурација има боље перформансе? О свему овоме под резом.
Изазови продуктивности
Сваки систем за праћење суочава се са специфичним изазовима перформанси. Говорићу о три од њих: прикупљању и обради података, складиштењу и чишћењу историје.
Брзо прикупљање и обрада података. Добар систем за праћење треба брзо да прими све податке и да их обради према изразима окидача - према својим критеријумима. Након обраде, систем такође мора брзо да сачува ове податке у бази података за каснију употребу.
Складиштење историје. Добар систем за праћење треба да чува историју у бази података и да омогући лак приступ метрикама. Историја је потребна да би се користила у извештајима, графиконима, покретачима, праговима и израчунатим ставкама података упозорења.
Брисање историје. Понекад дође дан када не морате да чувате метрику. Зашто су вам потребни подаци који су прикупљени пре 5 година, месец или два: неки чворови су избрисани, неки хостови или метрика више нису потребни јер су застарели и више се не прикупљају. Добар систем за праћење треба да складишти историјске податке и да их с времена на време брише како база података не би расла.
Чишћење застарелих података је критично питање које у великој мери утиче на перформансе базе података.
Кеширање у Заббик-у
У Заббик-у, први и други позив се решавају помоћу кеширања. РАМ се користи за прикупљање и обраду података. За складиштење - историја у окидачима, графиконима и израчунатим елементима података. На страни базе података постоји кеширање за основне селекције, на пример, графиконе.
Кеширање на страни самог Заббик сервера је:
- ЦонфигуратионЦацхе;
- ВалуеЦацхе;
- ХисториЦацхе;
- ТрендсЦацхе.
Размотрите их детаљније.
ЦонфигуратионЦацхе
Ово је главни кеш где чувамо метрике, хостове, ставке података, покретаче – све што нам је потребно за претходну обраду и за прикупљање података.
Све ово се чува у ЦонфигуратионЦацхе-у како не би стварали непотребне упите у бази података. Након што се сервер покрене, ажурирамо ову кеш меморију, креирамо и повремено ажурирамо конфигурације.
Прикупљање података
Дијаграм је прилично велик, али главна ствар у њему је колекционари. То су разни "поллерс" - процеси монтаже. Они су одговорни за различите врсте склапања: прикупљају податке преко СНМП-а, ИПМИ-ја и све то преносе у Препроцесинг.
Колектори су означени наранџастом бојом.
Заббик је израчунао ставке агрегације које су потребне за агрегирање чекова. Ако их имамо, преузимамо податке за њих директно из ВалуеЦацхе-а.
ПреПроцессинг ХисториЦацхе
Сви сакупљачи користе ЦонфигуратионЦацхе за примање послова. Затим их преносе у претходну обраду.
ПреПроцессинг користи ЦонфигуратионЦацхе за примање корака ПреПроцессинг. Ове податке обрађује на различите начине.
Након обраде података помоћу ПреПроцессинг-а, чувамо их у ХисториЦацхе-у за обраду. Ово завршава прикупљање података и прелазимо на главни процес у Заббик-у - синхронизатор историје, пошто се ради о монолитној архитектури.
Напомена: Предобрада је прилично тешка операција. Са в 4.2 је премештен на проки. Ако имате веома велики Заббик са великим бројем елемената података и учесталошћу прикупљања, онда то знатно олакшава рад.
ВалуеЦацхе, кеш историје и трендова
Синцер историје је главни процес који атомски обрађује сваки елемент података, односно сваку вредност.
Синцер историје преузима вредности из ХисториЦацхе-а и проверава конфигурацију да ли постоје окидачи за прорачуне. Ако постоје, израчунава се.
Синцер историје креира догађај, ескалацију за креирање упозорења ако то захтева конфигурација и записе. Ако постоје покретачи за накнадну обраду, он чува ову вредност у ВалуеЦацхе-у како не би приступио табели историје. Овако се ВалуеЦацхе попуњава подацима који су неопходни за израчунавање покретача и израчунатих елемената.
Синцер историје уписује све податке у базу података, а она уписује на диск. Процес обраде се овде завршава.
Кеширање у бази података
На страни базе података постоје различите кеш меморије када желите да видите графиконе или извештаје о догађајима:
Innodb_buffer_poolна страни МиСКЛ;shared_buffersна страни ПостгреСКЛ-а;effective_cache_sizeна страни Орацле;shared_poolна страни ДБ2.
Постоји много других кеш меморија, али ово су главне за све базе података. Они вам омогућавају да складиштите податке у РАМ-у који су често потребни за упите. За то имају своје технологије.
Перформансе базе података су критичне
Заббик сервер стално прикупља податке и уписује их. Када се поново покрене, такође чита из историје да би попунио ВалуеЦацхе. Користи скрипте и извештаје Заббик АПИ, који је изграђен на веб интерфејсу. Заббик АПИ приступа бази података и преузима потребне податке за графиконе, извештаје, листе догађаја и најновије проблеме.
За визуелизацију - Графана. Ово је популарно решење међу нашим корисницима. Може директно да шаље захтеве преко Заббик АПИ-ја и у базу података и ствара одређену конкуренцију за пријем података. Због тога је потребно финије и боље подешавање базе података да би одговарало брзој испоруци резултата и тестирању.
Домаћица
Трећи изазов перформанси у Заббик-у је чишћење историје помоћу Хоусекеепер-а. Прати сва подешавања – елементи података показују колико дуго треба чувати динамику промена (трендова) у данима.
ТрендсЦацхе израчунавамо у ходу. Када подаци стигну, агрегирамо их за један сат и бележимо у табеле за динамику промена тренда.
Домаћица покреће и брише информације из базе података користећи уобичајене „селекте“. Ово није увек ефикасно, као што се може видети из графикона перформанси интерних процеса.
Црвени графикон показује да је синхронизатор историје стално заузет. Наранџасти графикон на врху је Хоусекеепер, који стално ради. Он чека да база података избрише све редове које је навео.
Када треба да онемогућите кућну помоћницу? На пример, постоји „ИД ставке“ и потребно је да обришете последњих 5 хиљада редова у одређеном времену. Наравно, ово се дешава по индексу. Али обично је скуп података веома велик, а база података и даље чита са диска и ставља је у кеш меморију. Ово је увек веома скупа операција за базу података и, у зависности од величине базе података, може довести до проблема са перформансама.
Домаћица је лако онемогућити. У веб интерфејсу постоји поставка у „Општа администрација“ за кућну помоћницу. Онемогућавамо интерно одржавање домаћинства за интерну историју трендова и оно више не управља њиме.
Домаћица је искључена, графови изравнани - који проблеми би могли бити у овом случају и шта би могло помоћи у решавању трећег изазова перформанси?
Партиционисање - партиционисање или партиционисање
Обично се партиционисање конфигурише на другачији начин у свакој релационој бази података коју сам навео. Свака има своју технологију, али су генерално сличне. Креирање нове партиције често доводи до одређених проблема.
Обично се партиције конфигуришу у зависности од „подешавања“ - количине података која се креира у једном дану. По правилу, партиција се издаје за један дан, ово је минимум. За трендове нове серије - 1 месец.
Вредности се могу променити ако је „подешавање“ веома велико. Ако је мала „поставка“ до 5 нвпс (нове вредности у секунди), средња је од 000 до 5, онда је велика изнад 000 нвпс. То су велике и веома велике инсталације које захтевају пажљиву конфигурацију базе података.
На веома великим инсталацијама, период од једног дана можда није оптималан. Видео сам МиСКЛ партиције од 40 ГБ или више дневно. Ово је веома велика количина података која може да изазове проблеме и треба да се смањи.
Шта партиционисање даје?
Партициони столови. Често су то засебне датотеке на диску. План упита оптималније бира једну партицију. Обично се партиционисање користи по опсегу - ово важи и за Заббик. Тамо користимо „временску ознаку“ - време од почетка ере. Ово су за нас обични бројеви. Поставите почетак и крај дана - ово је партиција.
Брзо уклањање - DELETE. Изабрана је једна датотека/подтабела, а не избор редова за брисање.
Значајно убрзава преузимање података SELECT - користи једну или више партиција, а не целу табелу. Ако приступате подацима старим два дана, они се брже преузимају из базе података јер треба да учитате само једну датотеку у кеш и вратите је, а не велику табелу.
Често се многе базе података такође убрзавају INSERT — уметања у дечију табелу.
ТимесцалеДБ
За верзију 4.2, скренули смо пажњу на ТимесцалеДБ. Ово је проширење за ПостгреСКЛ са изворним интерфејсом. Проширење ефикасно функционише са подацима временских серија, без губљења предности релационих база података. ТимесцалеДБ се такође аутоматски дели.
ТимесцалеДБ има концепт хипертабле (хипертабела) коју креирате. Садржи цхункс - партиције. Комадићи су аутоматски управљани фрагменти хипертабеле који не утичу на друге фрагменте. Сваки део има свој временски опсег.
ТимесцалеДБ против ПостгреСКЛ-а
ТимесцалеДБ ради заиста ефикасно. Произвођачи екстензија тврде да користе исправнији алгоритам за обраду захтева, посебно инсертс. Како величина уметања скупа података расте, алгоритам одржава константне перформансе.
Након 200 милиона редова, ПостгреСКЛ обично почиње значајно да пада и губи перформансе на 0. ТимесцалеДБ вам омогућава да ефикасно убаците „уметке“ за било коју количину података.
Инсталација
Инсталирање ТимесцалеДБ је прилично једноставно за било који пакет. ИН све је детаљно описано - зависи од званичних ПостгреСКЛ пакета. ТимесцалеДБ се такође може направити и саставити ручно.
За Заббик базу података једноставно активирамо екстензију:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Ви активирате extension и креирајте га за Заббик базу података. Последњи корак је креирање хипертабеле.
Миграција табела историје у ТимесцалеДБ
За ово постоји посебна функција create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Функција има три параметра. Први - табела у бази података, за који треба да креирате хипертабелу. Друго - поље, према којем треба да креирате chunk_time_interval — интервал партиционих комада који ће се користити. У мом случају, интервал је један дан - 86.
Трећи параметар - migrate_data. Ако поставите true, онда се сви тренутни подаци преносе у унапред креиране делове. Ја сам га користио migrate_data. Имао сам око 1 ТБ, што је трајало више од сат времена. Чак сам у неким случајевима током тестирања обрисао историјске податке типова знакова који нису били потребни за складиштење, да их не бих пренео.
Последњи корак - UPDATE: ин db_extension ставити timescaledbтако да база података разуме да ово проширење постоји. Заббик га активира и правилно користи синтаксу и упите бази података - оне карактеристике које су неопходне за ТимесцалеДБ.
Конфигурација хардвера
Користио сам два сервера. Први - ВМваре машина. Прилично је мали: 20 Интел® Ксеон® ЦПУ Е5-2630 в 4 на 2.20 ГХз процесора, 16 ГБ РАМ-а и 200 ГБ ССД.
На њега сам инсталирао ПостгреСКЛ 10.8 са Дебиан 10.8-1.пгдг90+1 ОС и кфс системом датотека. Све сам конфигурисао минимално да користим ову конкретну базу података, минус оно што ће сам Заббик користити.
На истој машини је био Заббик сервер, ПостгреСКЛ и агенти за оптерећење. Имао сам 50 активних агенаса које сам користио LoadableModuleда врло брзо генерише различите резултате: бројеве, низове. Попунио сам базу података са много података.
У почетку је конфигурација садржана 5 елемената података по хосту. Скоро сваки елемент је садржао окидач да би био сличан стварним инсталацијама. У неким случајевима било је више од једног окидача. За један мрежни чвор је било 3-000 окидача.
Интервал ажурирања ставке података − КСНУМКС-КСНУМКС секунди. Регулисао сам само оптерећење користећи не само 50 агенаса, већ и додавањем више. Такође, користећи елементе података, динамички сам прилагодио оптерећење и смањио интервал ажурирања на 4 с.
ПостгреСКЛ. 35 нвпс
Моје прво покретање на овом хардверу било је на чистом ПостгреСКЛ-у - 35 хиљада вредности у секунди. Као што видите, убацивање података траје делиће секунде - све је добро и брзо. Једина ствар је да се ССД диск од 200 ГБ брзо пуни.
Ово је стандардна контролна табла перформанси Заббик сервера.
Први плави графикон је број вредности у секунди. Други графикон са десне стране је учитавање процеса изградње. Трећи је учитавање интерних процеса изградње: синхронизатора историје и Хоусекеепер-а, који овде ради већ дуже време.
Четврти графикон приказује употребу ХисториЦацхе-а. Ово је нека врста бафера пре убацивања у базу података. Зелени пети графикон приказује коришћење ВалуеЦацхе-а, односно колико ВалуеЦацхе погодака за окидаче - ово је неколико хиљада вредности у секунди.
ПостгреСКЛ. 50 нвпс
Затим сам повећао оптерећење на 50 хиљада вредности у секунди на истом хардверу.
Приликом учитавања из Хоусекеепер-а, уметање 10 хиљада вредности трајало је 2-3 секунде.
Домаћица већ почиње да омета посао.
Трећи графикон показује да је, генерално, оптерећење ловца и синчера историје и даље на 60%. У четвртом графикону, ХисториЦацхе већ почиње да се пуни прилично активно током рада кућне помоћнице. Попуњен је 20%, што је око 0,5 ГБ.
ПостгреСКЛ. 80 нвпс
Затим сам повећао оптерећење на 80 хиљада вредности у секунди. Ово је отприлике 400 хиљада елемената података и 280 хиљада окидача.
Цена учитавања тридесет синчера историје је већ прилично висока.
Такође сам повећао различите параметре: синхронизаторе историје, кеш меморије.
На мом хардверу, учитавање синхронизатора историје се повећало до максимума. ХисториЦацхе се брзо напунио подацима - подаци за обраду су се акумулирали у баферу.
Све ово време сам посматрао како се користе процесор, РАМ и други системски параметри и открио да је искоришћеност диска на максимуму.
Постигао сам употребу максималне могућности диска на овом хардверу и на овој виртуелној машини. Са таквим интензитетом, ПостгреСКЛ је почео прилично активно да испира податке, а диск више није имао времена за писање и читање.
Други сервер
Узео сам други сервер, који је већ имао 48 процесора и 128 ГБ РАМ-а. Подешао сам га - подесио га на 60 синхронизатор историје и постигао прихватљиве перформансе.
У ствари, ово је већ граница продуктивности где нешто треба да се уради.
ТимесцалеДБ. 80 нвпс
Мој главни задатак је да тестирам могућности ТимесцалеДБ-а у односу на Заббик оптерећење. 80 хиљада вредности у секунди је много, учесталост прикупљања метрика (осим Иандек-а, наравно) и прилично велико „подешавање“.
У сваком графикону постоји пад – то је управо миграција података. Након кварова на Заббик серверу, профил учитавања синхронизатора историје се доста променио - пао је три пута.
ТимесцалеДБ вам омогућава да убаците податке скоро 3 пута брже и користите мање ХисториЦацхе-а.
Сходно томе, податке ћете добити благовремено.
ТимесцалеДБ. 120 нвпс
Затим сам повећао број елемената података на 500 хиљада. Главни задатак је био да тестирам могућности ТимесцалеДБ - добио сам израчунату вредност од 125 хиљада вредности у секунди.
Ово је радна „поставка“ која може да ради дуго времена. Али пошто је мој диск имао само 1,5 ТБ, напунио сам га за неколико дана.
Најважније је да су у исто време створене нове ТимесцалеДБ партиције.
Ово је потпуно неприметно за перформансе. Када се, на пример, креирају партиције у МиСКЛ-у, све је другачије. Ово се обично дешава ноћу јер блокира опште уметање, рад са табелама и може да изазове деградацију услуге. Ово није случај са ТимесцалеДБ.
Као пример, приказаћу један графикон од многих у заједници. На слици је омогућена ТимесцалеДБ, захваљујући којој је оптерећење на коришћењу ио.веигхт на процесору пало. Такође је смањена употреба унутрашњих елемената процеса. Штавише, ово је обична виртуелна машина на обичним палачинкама, а не ССД.
Налази
ТимесцалеДБ је добро решење за мала „подешавања“, што утиче на перформансе диска. То ће вам омогућити да наставите да радите добро док се база података не мигрира на хардвер што је брже могуће.
ТимесцалеДБ се лако конфигурише, даје повећање перформанси, добро ради са Заббик-ом и има предности у односу на ПостгреСКЛ.
Ако користите ПостгреСКЛ и не планирате да га мењате, препоручујем користите ПостгреСКЛ са екстензијом ТимесцалеДБ у комбинацији са Заббик-ом. Ово решење ефикасно функционише до средњег „подешавања“.
Када кажемо „високе перформансе“ мислимо . Нећете морати дуго да чекате да сазнате о технологијама и праксама које омогућавају услугама да служе милионима корисника. Листа за 7. и 8. новембар смо већ саставили, али овде може се предложити више.
Претплатите се на наше и , у којој откривамо карактеристике предстојеће конференције, и сазнајемо како да из ње извучемо максимум.
Извор: ввв.хабр.цом