🥇Висока производителност и родно партициониране: Zabbix с поддръжка на TimescaleDB

Zabbix е система за мониторинг. Както всяка друга система, тя среща три основни проблема, с които се сблъскват всички мониторингови системи: събиране и обработка на данни, съхранение на история и нейното почистване.

Етапите на получаване, обработка и запис на данни отнемат време. Малко, но за голяма система това може да се окаже значително забавяне. Проблемът със съхранението е свързан с достъпа до данните. Те се използват за отчети, проверки и тригери. Забавянията при достъпа до данните също влияят на производителността. Когато базите данни нарастват, остарелите данни трябва да бъдат премахвани. Премахването е тежка операция, която също отнема част от ресурсите.

Проблемите със забавянето при събиране и съхранение в Zabbix се решават чрез кеширане: различни видове кешове, кеширане в базата данни. За решаване на третия проблем кеширането не е подходящо, затова в Zabbix се използва TimescaleDB. За това ще разкажем Андрей Гущин — инженер по техническа поддръжка Zabbix SIA. В поддръжката на Zabbix, Андрей работи повече от 6 години и директно се сблъсква с въпросите относно производителността.

Как работи TimescaleDB, каква производителност може да предостави в сравнение с обикновен PostgreSQL? Каква роля играе Zabbix за базата данни TimescaleDB? Как да стартирате от нулата и как да мигрирате от PostgreSQL и коя конфигурация предоставя най-добра производителност? Всичко това ще намерите по-долу.

Предизвикателства по производителността

Всяка система за мониторинг се сблъсква с определени предизвикателства по производителността. Ще ви разкажа за три от тях: събиране и обработка на данни, съхранение и почистване на историята.

Бързо събиране и обработка на данни. Добрата система за мониторинг трябва бързо да получава всички данни и да ги обработва съобразно тригерните изрази — по своите критерии. След обработка, системата трябва също бързо да запази тези данни в базата данни, за да могат да бъдат използвани по-късно.

Съхранение на история. Добрата система за мониторинг трябва да съхранява история в базата данни и да предоставя удобен достъп до метриките. Историята е необходима за използване в отчети, графики, тригери, праг и изчисляеми елементи за уведомления.

Почистване на история. Понякога настъпва ден, в който не е нужно да съхранявате метрики. Защо ви трябват данни, събрани преди 5 години, месец или два: някои узли са премахнати, някои хостове или метрики вече не са нужни, защото са остарели и не се събират. Добрата мониторинг система трябва да съхранява исторически данни и от време на време да ги изтрива, за да не се увеличава базата данни.

Премахването на остарели данни е важен въпрос, който оказва сериозно влияние върху производителността на базата данни.

Кеширане в Zabbix

В Zabbix първите и вторите извиквания се решават с помощта на кеширане. За събиране и обработка на данни се използва оперативна памет. За съхранение — история в тригерите, графиките и изчислените елементи данни. От страната на базата данни има определено кеширане за основни заявки, например, графици.

Кеширане от страна на самия Zabbix-сървър е:

ConfigurationCache;
ValueCache;
HistoryCache;
TrendsCache.

Неа да ги разгледаме по-подробно.

ConfigurationCache

Това е основният кеш, в който съхраняваме метрики, хостове, елементи данни, тригери — всичко, което е нужно за PreProcessing и за събиране на данни.

Всичко това се съхранява в ConfigurationCache, за да не се създават ненужни заявки в базата данни. След стартиране на сървъра обновяваме този кеш, създаваме и периодично обновяваме конфигурации.

Събиране на данни

Схемата е достатъчно голяма, но основното в нея е събирачите. Това са различни "pollers" — процеси на събиране. Те отговарят за различни видове събиране: събират данни по SNMP, IPMI, и предават всичко това на PreProcessing.

Събирачите са обгърнати с оранжева линия.

В Zabbix има изчисляеми агрегатни елементи данни, които са необходими, за да агрегатират проверки. Ако ги имаме, вземаме данни за тях директно от ValueCache.

PreProcessing HistoryCache

Всички събирачи използват ConfigurationCache, за да получат задания. След това те ги предават на PreProcessing.

PreProcessing използва ConfigurationCache, за да получава стъпките на PreProcessing. Той обработва тези данни по различни начини.

След обработка на данните с помощта на PreProcessing, ги запазваме в HistoryCache, за да се обработят. На това приключва събирането на данни и преминаваме към основния процес в Zabbix — history syncer, тъй като това е монолитна архитектура.

Забележка: PreProcessing е доста тежка операция. От версия 4.2, той е изнесен на прокси. Ако имате много голям Zabbix с много елементи данни и честота на събиране, то това улеснява работата значително.

ValueCache, история и кэш трендов

History syncer — основен процес, който атомарно обработва всеки елемент от данните, т.е. всяка стойност.

History syncer взема стойности от HistoryCache и проверява наличието на тригери за изчисления в Configuration. Ако има, извършва изчисление.

History syncer създава събитие, ескалация, за да генерира известия, ако е необходимо според конфигурацията, и записва. Ако има тригери за последваща обработка, той запаметява тази стойност в ValueCache, за да не се свързва с таблицата на историята. Така ValueCache се запълва с данни, необходими за изчисление на тригерите, изчислените елементи.

History syncer записва всички данни в БД, а тя — на диска. Процесът на обработка приключва тук.

Кеширане в БД

Отстрани на БД има различни кешове, когато искате да разглеждате графики или отчети по събития:

Innodb_buffer_pool от страна на MySQL;
shared_buffers от страна на PostgreSQL;
effective_cache_size от страна на Oracle;
shared_pool от страна на DB2.

Има още много други кешове, но тези са основни за всички БД. Те позволяват да се поддържат в оперативната памет данни, които често са необходими за запитвания. Всеки от тях разполага със собствени технологии за това.

Производителността на БД е критично важна

Zabbix-серверът постоянно събира данни и ги записва. При рестартиране, той също чете от историята, за да запълни ValueCache. Използва скриптове и отчети. Zabbix API, който е построен на основата на Web-интерфейса. Zabbix API прави запитвания към базата данни и получава необходимите данни за графики, отчети, списъци на събития и последни проблеми.

За визуализация — Grafana. Това е популярно решение сред нашите потребители. То позволява директно изпращане на запитвания чрез Zabbix API и към БД, и създава определена конкурентност за получаване на данни. Ето защо е необходима по-фина и добра настройка на БД, за да се съответства на бърза доставка на резултати и тестване.

Housekeeper

Третият предизвикателство за производителността в Zabbix е почистването на историята чрез Housekeeper. Той спазва всички настройки — в елементите на данните е указано колко време да се съхранява динамиката на промените (трендовете) в дни.

TrendsCache изчисляваме на място. Когато постъпват данни, ние ги агрегирираме за един час и записваме в таблиците за динамика на промените на трендовете.

Housekeeper се стартира и премахва информация от базата данни с обикновени «selects». Това не винаги е ефективно, което може да се види от графиките на производителността на вътрешните процеси.

Червената графика показва, че History syncer постоянно е зает. Оранжевата графика отгоре — това е Housekeeper, който постоянно се стартира. Той чака от базата данни да премахне всички редове, които е зададе.

Кога е подходящо да се изключи Housekeeper? Например, има «Item ID» и е необходимо да се премахнат последните 5 хиляди реда за определен период от време. Разбира се, това става по индексите. Но обикновено наборът от данни е много голям, и базата данни все пак чете от диска и ги вдига в кеша. Това винаги е много скъпа операция за базата данни и, в зависимост от размера на базата, може да доведе до проблеми с производителността.

Housekeeper може просто да се изключи. В уеб-интерфейса има настройка в «Administration general» за Housekeeper. Изключваме вътрешния Housekeeping за вътрешната история на трендовете и той вече не управлява това.

Housekeeper е изключен, графиките са се изравнили — какви могат да бъдат проблемите в такъв случай и какво може да помогне за решаването на третото повикване за производителност?

Partitioning — секциониране или партициониране

Обикновено партиционирането се настройва по различен начин на всяка релационна база данни, която изброих. Всяка има своя технология, но те са сходни като цяло. Създаването на нова партиция често води до определени проблеми.

Обикновено партициите се настройват в зависимост от «setup» — количеството данни, което се създава за един ден. Като правило, Partitioning се задава за един ден, това е минимум. За трендовете новата партиция — за 1 месец.

Стойностите могат да се променят в случай на много голям «setup». Ако малкият «setup» е до 5 000 nvps (нови стойности в секунда), средният — от 5 000 до 25 000, то голям — над 25 000 nvps. Това са големи и много големи инсталации, които изискват внимателна настройка на самата база данни.

На много големи инсталации отрязък от един ден може да не бъде оптимален. Видях на MySQL партиции от 40 ГБ и повече на ден. Това е много голям обем данни, който може да доведе до проблеми, и трябва да се намалява.

Какво предлага Partitioning?

Секциониране на таблици. Често това са отделни файлове на диска. Планът за заявки оптимално избира една партиция. Обикновено партиционирането се използва по диапазон — това важи и за Zabbix. Там използваме „timestamp“ — време от началото на епохата. При нас това са обикновени числа. Задавате начало и край на деня — това е партиция.

Бързо изтриване — DELETE. Избира се един файл/субтаблица, а не селекция на редове за изтриване.

Забележимо ускорява извличането на данни SELECT — използва една или повече партиции, а не цялата таблица. Ако искате данни от преди два дни, те се извлекат от БД по-бързо, защото трябва да заредите в кеша и да дадете само един файл, а не голяма таблица.

Често мнозинството от БД също ускорява INSERT — вставки в child-таблица.

TimescaleDB

За версия 4.2 обърнахме внимание на TimescaleDB. Това е разширение за PostgreSQL с нативен интерфейс. Разширението работи ефективно с данни от времеви серии, като не изостава от предимствата на релационните БД. TimescaleDB също автоматично партиционира.

В TimescaleDB съществува понятието хипертаблица (hypertable), която създавате. В нея се намират чанкове — партиции. Чанковете са автоматично управлявани фрагменти на хипертаблицата, които нямат влияние върху други фрагменти. Всеки чанк има свой времеви диапазон.

TimescaleDB срещу PostgreSQL

TimescaleDB работи наистина ефективно. Производителите на разширението твърдят, че използват по-правилен алгоритъм за обработка на заявки, по-специално, <code>inserts</code>. Когато размерите на dataset-вставките нарастват, алгоритъмът поддържа постоянна производителност.

След 200 млн реда PostgreSQL обикновено започва да губи производителност до 0. TimescaleDB позволява ефективно вмъкване на „inserts“ при всякакъв обем данни.

Инсталиране на

Инсталирането на TimescaleDB е доста просто за всякакви пакети. В документацията всичко е подробно описано — то зависи от официалните пакети на PostgreSQL. TimescaleDB може да бъде също така събрано и компилирано ръчно.

За БД Zabbix просто активираме разширението:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Вие активирате разширението и го създавате за БД Zabbix. Последната стъпка е създаването на хипертаблицата.

Миграция на таблиците с история на TimescaleDB

За това има специална функция 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 400.

Третият параметър — мигрирай_данни. Ако се зададе true, всички текущи данни ще се прехвърлят в предварително създадените партици. Аз самият използвах мигрирай_данни. Имах около 1 ТБ, което отне повече от час. Дори в някои случаи при тестове изтривах ненужни исторически данни от символни типове, за да не ги прехвърлям.

Последната стъпка — АКТУАЛИЗИРАЙ: в : в поставяме db_extensiontimescaledb

, за да може базата данни да разбира, че има това разширение. Zabbix го активира и правилно използва синтаксиса и заявките към базата данни — тези функции, които са необходими за TimescaleDB.

Конфигурация на хардуера Използвах два сървъра. Първият —VMware машина

. Тя е сравнително малка: 20 процесора Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 ГБ RAM и SSD диск с капацитет 200 ГБ.

Инсталирах PostgreSQL 10.8 на нея с операционна система Debian 10.8-1.pgdg90+1 и файловата система xfs. Всичко е минимално настройроно, за да можем да използваме именно тази база данни, с изключение на това, което ще използва самият Zabbix. На същата машина беше инсталиран Zabbix сървър, PostgreSQL иагенти за натоварване . Имах 50 активни агента, които използваха, за да генерират много бързо различни резултати: числа, строки. Запълвах базата с голямо количество данни.

Първоначалната конфигурация съдържаше 5 000 елемента данни на всеки хост. Почти всеки елемент съдържаше тригер, за да бъде подобен на реалните инсталации. В някои случаи имаше повече от един тригер. На един възел от мрежата се падаха 3 000-7 000 тригера.

Интервалът на обновление на елементите данни — 4-7 секунди. Регулирах натиска, като използвах не само 50 агента, а добавих и повече. Също така, с помощта на динамични данни, регулирах натиска и намалих интервала за обновяване до 4 секунди.

PostgreSQL. 35 000 nvps

Първото стартиране на това оборудване беше с чист PostgreSQL — 35 хиляди стойности в секунда. Както се вижда, вмъкването на данни отнема фракции от секундата — всичко е нормално и бързо. Единственото е, че SSD дискът с 200 ГБ бързо се запълва.

Това е стандартният dashboard за производителността на Zabbix — сървъри.

Първият син график — брой стойности в секунда. Вторият график вдясно — натоварване на процесите за обработка. Третият — натоварване на вътрешните процеси на обработка: history syncers и Housekeeper, който тук работеше достатъчно време.

Четвъртият график показва използването на HistoryCache. Това е буфер преди вмъкването в базата данни. Далеко зелените пети график показва използването на ValueCache, т.е. колко попадения има ValueCache за тригери — това е няколко хиляди стойности в секунда.

PostgreSQL. 50 000 nvps

След това увеличих натиска до 50 хиляди стойности в секунда на същото оборудване.

При зареждане с Housekeeper, 10 хиляди стойности се записваха за 2-3 секунди.

Housekeeper вече започва да пречи на работата.

От третия график се вижда, че, като цяло, натоварването на трапери и history syncers все още е на ниво 60%. На четвъртия график HistoryCache по време на работа на Housekeeper вече се запълва активно. Той се запълни на 20% — около 0,5 ГБ.

PostgreSQL. 80 000 nvps

След това увеличих натиска до 80 хиляди стойности в секунда. Това е около 400 хиляди данни и 280 хиляди тригери.

Вмъкването при натоварване на тридесет history syncers е вече доста високо.

Също така увеличавах различни параметри: history syncers, кешове.

На моето оборудване натоварването на history syncers се увеличаваше до максимум. HistoryCache бързо се запълни с данни — в буфера се натрупаха данни за обработка.

През цялото време наблюдавах как се използват процесора, оперативната памет и други параметри на системата и установих, че натоварването на дисковете е максимално.

Постигнах използване на максималните възможности на диска на това оборудване и на тази виртуална машина. При такава интензивност PostgreSQL започна активно да изтегля данни и дискът вече не успяваше да работи за запис и четене.

Втори сървър

Взех друг сървър с 48 процесора и 128 ГБ RAM. Оптимизирах го — инсталирах 60 history syncer и постигнах приемливо бързо действие.

Всъщност, това е пределът на производителността, където трябва да се предприемат действия.

TimescaleDB. 80 000 nvps

Основната ми задача е да проверя възможностите на TimescaleDB под натиска на Zabbix. 80 хиляди стойности в секунда — това е много, честотата на събиране на метрики (освен Яндекс, разбира се) и доста голям „setup“.

На всеки график има спад – точно в момента на миграция на данни. След спадовете на Zabbix-сървъра профилът на натоварване на history syncer се промени значително — спадна три пъти.

TimescaleDB позволява вмъкване на данни почти три пъти по-бързо и изисква по-малко HistoryCache.

Съответно, данните ще се предоставят навреме.

TimescaleDB. 120 000 nvps

След това увеличих количеството на данните до 500 хиляди. Основната задача беше да проверя възможностите на TimescaleDB — получих изчисленото значение от 125 хиляди стойности в секунда.

Това е работещ „setup“, който може да функционира дълго. Но тъй като диска ми беше само 1,5 ТБ, го напълних за няколко дни.

Най-важното е, че по същото време се създаваха нови партиции в TimescaleDB.

За производителността това е съвсем незабележимо. Когато се създават партиции в MySQL, например, всичко е различно. Обикновено това става през нощта, защото блокира общото вмъкване, работата с таблиците и може да създаде деградация на услугата. При TimescaleDB това не се случва.

За пример ще покажа един график от многото в community. На картинката е включен TimescaleDB, благодарение на което натоварването на io.weight на процесора намаля. Използването на елементи от вътрешните процеси също намаля. Важно е да се спомене, че това е обикновена виртуална машина на обикновени харддискове, а не SSD.

Изводи

TimescaleDB е добро решение за малки „setup“-и, които достигат до пределите на производителността на диска. То ще позволи да продължите да работите до миграцията на БД на по-бързо устройство.

TimescaleDB е лесен за настройка, предлага увеличение на производителността, работи добре с Zabbix и има предимства в сравнение с PostgreSQL.

Ако използвате PostgreSQL и не планирате да го променяте, препоръчвам да използвате PostgreSQL с разширението TimescaleDB в комбинация с Zabbix. Това решение е ефективно до средни „setup“-и.

Когато говорим за „висока производителност“ — имаме предвид HighLoad++. Не е нужно много време, за да се запознаете с технологиите и практиките, които позволяват на услугите да обслужват милиони потребители. Списъкът на докладите за 7 и 8 ноември вече е готов, а за митапите все още може да се предложи.
Абонирайте се за нашия бюлетин и telegram, в който разкриваме детайли за предстоящата конференция и ще разберете как да извлечете максимална полза.

Източник: habr.com