Zabbix е система за мониторинг. Като всяка друга система, тя е изправена пред три основни проблема на всички системи за мониторинг: събиране и обработка на данни, съхраняване на хронологията и нейното изчистване.
Етапите на получаване, обработка и запис на данни отнемат време. Не много, но за голяма система това може да доведе до големи закъснения. Проблемът със съхранението е въпрос на достъп до данни. Те се използват за отчети, проверки и задействания. Забавянето на достъпа до данни също влияе върху производителността. Когато базата данни нараства, неподходящите данни трябва да бъдат изтрити. Изтриването е тежка операция, която също изяжда някои ресурси.
Проблемите със забавянето на събирането и съхранението в Zabbix се решават чрез кеширане: няколко вида кешове, кеширане в базата данни. За решаване на третия проблем, кеширането не е подходящо, така че TimescaleDB е използван в Zabbix. Ще разкаже за това Андрей Гушчин - инженер по техническа поддръжка . Андрей подкрепя Zabbix повече от 6 години и участва пряко в изпълнението.
Как работи TimescaleDB, каква производителност може да даде в сравнение с обикновения PostgreSQL? Каква роля играе Zabbix в TimescaleDB? Как да започна от нулата и как да мигрирам от PostgreSQL и коя производителност на конфигурацията е по-добра? Всичко това под разфасовката.
Предизвикателства за представяне
Всяка система за мониторинг е изправена пред определени предизвикателства в работата. Ще говоря за три от тях: събиране и обработка на данни, съхранение, почистване на историята.
Бързо събиране и обработка на данни. Добрата система за мониторинг трябва бързо да получава всички данни и да ги обработва според тригерните изрази - според собствените си критерии. След обработка системата трябва също бързо да съхрани тези данни в базата данни, за да ги използва по-късно.
Съхранение на историята. Една добра система за мониторинг трябва да съхранява историята в база данни и да осигурява лесен достъп до показателите. Хронологията е необходима за използване в отчети, графики, тригери, прагове и изчислени елементи за предупреждение.
Изчистване на историята. Понякога идва ден, в който не е необходимо да съхранявате показатели. Защо се нуждаете от данни, събрани преди 5 години, месец или два: някои възли са премахнати, някои хостове или показатели вече не са необходими, защото са остарели и вече не се събират. Добрата система за мониторинг трябва да съхранява исторически данни и да ги изтрива от време на време, така че базата данни да не се разраства.
Почистването на остарели данни е труден проблем, който оказва голямо влияние върху производителността на базата данни.
Кеширане в Zabbix
В Zabbix първото и второто извикване се разрешават с помощта на кеширане. RAM се използва за събиране и обработка на данни. За съхранение - история в тригери, графики и изчислени елементи. От страна на DB има малко кеширане за основни селекции, като например графики.
Кеширането от страна на самия Zabbix сървър е:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Разгледайте ги по-подробно.
ConfigurationCache
Това е основният кеш, в който съхраняваме метрики, хостове, елементи с данни, тригери - всичко, което е необходимо за предварителна обработка и за събиране на данни.
Всичко това се съхранява в ConfigurationCache, за да не се създават ненужни заявки в базата данни. След като сървърът стартира, ние актуализираме този кеш, създаваме и периодично актуализираме конфигурации.
Събиране на данни
Схемата е доста голяма, но основното в нея е колекционери. Това са различни "полери" - процеси на сглобяване. Те отговарят за различни видове асемблиране: те събират данни чрез SNMP, IPMI и ги прехвърлят към PreProcessing.
Берачите са оградени в оранжево.
Zabbix е изчислил елементи за агрегиране, които са необходими за агрегиране на проверки. Ако ги имаме, вземаме данните за тях директно от ValueCache.
Предварителна обработка HistoryCache
Всички колектори използват ConfigurationCache за получаване на задания. След това ги предават на PreProcessing.
PreProcessing използва ConfigurationCache, за да получи стъпките на PreProcessing. Той обработва тези данни по различни начини.
След обработката на данните с PreProcessing, ние ги съхраняваме в HistoryCache, за да ги обработим. Това завършва събирането на данни и преминаваме към основния процес в Zabbix - синхронизатор на историята, тъй като е монолитна архитектура.
Забележка: Предварителната обработка е доста тежка операция. От версия 4.2 той е преместен в прокси. Ако имате много голям Zabbix с голям брой елементи и честота на събиране, тогава това прави нещата много по-лесни.
ValueCache, кеш история и тенденции
Синхронизаторът на историята е основният процес, който атомарно обработва всеки елемент от данни, тоест всяка стойност.
Синхронизаторът на историята взема стойности от HistoryCache и проверява конфигурацията за тригери за изчисления. Ако са - изчислява.
Синхронизаторът на историята създава събитие, ескалира, за да създаде предупреждения, ако се изисква от конфигурацията, и записи. Ако има тригери за по-нататъшна обработка, тогава той запомня тази стойност в ValueCache, за да не се обръща към таблицата с хронологията. Ето как ValueCache се запълва с данните, които са необходими за изчисляване на задействания, изчислени елементи.
History syncer записва всички данни в базата данни, а тя записва на диска. Процесът на обработка приключва тук.
DB кеширане
Има различни кешове от страна на DB, когато искате да разгледате графики или отчети за събития:
Innodb_buffer_poolот страна на MySQL;shared_buffersот страна на PostgreSQL;effective_cache_sizeот страна на Oracle;shared_poolот страната на DB2.
Има много други кешове, но тези са основните за всички бази данни. Те ви позволяват да съхранявате данни в RAM, които често са необходими за заявки. Те имат собствена технология за това.
Производителността на базата данни е критична
Zabbix сървърът непрекъснато събира данни и ги записва. Когато се рестартира, той също чете от хронологията, за да запълни ValueCache. Използване на скриптове и отчети Zabbix API, който е изграден на базата на уеб интерфейса. Zabbix API осъществява достъп до базата данни и извлича необходимите данни за графики, отчети, списъци със събития и скорошни проблеми.
За визуализация - Графана. Това е популярно решение сред нашите потребители. Тя може директно да изпраща заявки чрез Zabbix API и към базата данни и създава определена паралелност за получаване на данни. Следователно е необходима по-фина и по-добра настройка на базата данни, за да се съчетае бързото предоставяне на резултати и тестване.
икономка
Третото предизвикателство за производителност в Zabbix е почистването на историята с Housekeeper. Спазва всички настройки - елементите от данни показват колко дълго да се съхранява динамиката на промените (тенденции) в дни.
TrendsCache изчисляваме в движение. Когато постъпят данните, ги агрегираме за един час и ги поставяме в таблици за динамиката на промените в тренда.
Housekeeper стартира и премахва информация от базата данни с обичайните "избирания". Това не винаги е ефективно, което може да се разбере от графиките на ефективността на вътрешните процеси.
Червената графика показва, че синхронизаторът на историята е постоянно зает. Оранжевата диаграма в горната част е Housekeeper, която работи постоянно. Той изчаква базата данни да изтрие всички редове, които е посочила.
Кога трябва да деактивирате Housekeeper? Например, има „ИД на артикул“ и трябва да изтриете последните 5 хиляди реда за определено време. Разбира се, това става по индекси. Но обикновено наборът от данни е много голям и базата данни все още чете от диска и го поставя в кеша. Това винаги е много скъпа операция за базата данни и в зависимост от размера на базата данни може да доведе до проблеми с производителността.
Икономката е лесна за деактивиране. В уеб интерфейса има настройка в „Обща администрация“ за Housekeeper. Деактивирайте вътрешното поддържане за вътрешна история на тенденциите и то вече не контролира това.
Housekeeper е деактивиран, графиките са изравнени - какви могат да бъдат проблемите в този случай и какво може да помогне при решаването на третото предизвикателство за производителност?
Преграждане - преграждане или преграждане
Разделянето обикновено се конфигурира по различен начин за всяка релационна база данни, която изброих. Всеки има своя собствена технология, но като цяло те са сходни. Създаването на нов дял често води до определени проблеми.
Дяловете обикновено се конфигурират в зависимост от "настройката" - количеството данни, което се създава за един ден. По правило Partitioning се настройва за един ден, това е минимумът. За нови тенденции на дялове — 1 месец.
Стойностите могат да се променят в случай на много голяма "настройка". Ако една малка „настройка“ е до 5 nvps (нови стойности за секунда), средната е от 000 до 5 000, тогава голямата е над 25 000 nvps. Това са големи и много големи инсталации, които изискват внимателно конфигуриране на самата база данни.
При много големи инсталации един ден може да не е оптимален. Виждал съм MySQL дялове от 40 GB или повече на ден. Това е много голямо количество данни, което може да доведе до проблеми и трябва да бъде намалено.
Какво дава Partitioning?
Преградни маси. Често това са отделни файлове на диска. Планът на заявката избира един дял по-оптимално. Обикновено разделянето се използва по диапазон - това важи и за Zabbix. Там използваме "timestamp" - времето от началото на епохата. Имаме редовни номера. Вие определяте началото и края на деня - това е разделяне.
Бързо премахване - DELETE. Избран е един файл/подтаблица, а не селекция от редове за изтриване.
Значително ускорява вземането на проби от данни SELECT - използва един или повече дялове, а не цялата таблица. Ако имате достъп до данни от преди два дни, той ги извлича от базата данни по-бързо, защото трябва само да ги заредите в кеша и да върнете само един файл, а не голяма таблица.
Често много бази данни също се ускоряват INSERT - вмъква се в дъщерната таблица.
Времева скалаDB
За версия 4.2 насочихме вниманието си към TimescaleDB. Това е разширение на PostgreSQL с собствен интерфейс. Разширението работи ефективно с данни от времеви серии, без да губи предимствата на релационните бази данни. TimescaleDB също автоматично разделя.
TimescaleDB има концепция хипертаблица (хипертаблица), която създавате. В него са буци - прегради. Парчетата са автоматично управлявани фрагменти от хипертаблица, които не засягат други фрагменти. Всяка част има свой собствен времеви диапазон.
TimescaleDB срещу PostgreSQL
TimescaleDB е наистина ефективен. Производителите на разширението твърдят, че използват по-правилен алгоритъм за обработка на заявки, по-специално inserts . С нарастването на размера на вмъкнатия набор от данни алгоритъмът поддържа постоянна производителност.
След 200 милиона реда PostgreSQL обикновено започва да отслабва много и да губи производителност до 0. TimescaleDB ви позволява ефективно да вмъквате „вмъквания“ с произволно количество данни.
Инсталация
Инсталирането на TimescaleDB е достатъчно лесно за всякакви пакети. IN всичко е подробно - зависи от официалните пакети на PostgreSQL. TimescaleDB също може да бъде изграден и компилиран на ръка.
За базата данни на Zabbix ние просто активираме разширението:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
активираш extension и го създайте за базата данни на 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.
Третият параметър е migrate_data. Ако е зададено true, тогава всички текущи данни се прехвърлят към предварително създадени парчета. Аз самият съм използвал migrate_data. Имах около 1TB, което отне повече от час. Дори в някои случаи при тестване изтрих историческите данни на типове символи, които не са задължителни за съхранение, за да не ги прехвърлям.
Последна стъпка - UPDATE: v db_extension слагам timescaledbтака че базата данни да разбере, че има това разширение. Zabbix го активира и използва правилно синтаксиса и заявките вече към базата данни - тези функции, които са необходими за TimescaleDB.
Хардуерна конфигурация
Използвах два сървъра. първо - VMware машина. Той е достатъчно малък: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 GB RAM и 200 GB SSD устройство.
Инсталирах PostgreSQL 10.8 на него с Debian OS 10.8-1.pgdg90+1 и файлова система xfs. Конфигурирах всичко минимално, за да използвам тази конкретна база данни, минус това, което самият Zabbix ще използва.
На същата машина имаше Zabbix сървър, PostgreSQL и агенти за натоварване. Имах 50 активни агента, които използвах LoadableModuleза генериране на различни резултати много бързо: числа, низове. Напълних базата данни с много данни.
Първоначално конфигурацията съдържаше 5 артикула данни на хост. Почти всеки елемент съдържа тригер, за да изглежда като истински инсталации. В някои случаи имаше повече от един тригер. Един мрежов възел имаше 3-000 задействания.
Интервал за актуализиране на артикул − 4-7 секунди. Регулирах самото натоварване, като използвах не само 50 агента, но добавих още. Също така, с помощта на елементи от данни, динамично регулирах натоварването и намалих интервала на актуализиране до 4 s.
PostgreSQL. 35 000 nvps
Първото ми стартиране на този хардуер беше на чист PostgreSQL - 35 хиляди стойности в секунда. Както можете да видите, вмъкването на данни отнема части от секундата - всичко е наред и бързо. Единственото нещо е, че 200 GB SSD устройство се запълва бързо.
Това е стандартно табло за управление на производителността на Zabbix сървър.
Първата синя графика е броят на стойностите в секунда. Втората графика вдясно показва процесите на зареждане на компилация. Третото е зареждането на вътрешни процеси за изграждане: синхронизатори на история и Housekeeper, който работи достатъчно време тук.
Четвъртата графика показва използването на HistoryCache. Това е един вид буфер преди вмъкване в базата данни. Зелената пета графика показва използването на ValueCache, тоест колко ValueCache хитове за тригери са няколко хиляди стойности в секунда.
PostgreSQL. 50 000 nvps
След това увеличих натоварването до 50 хиляди стойности в секунда на същия хардуер.
При зареждане от Housekeeper вмъкването на 10 хиляди стойности отне 2-3 секунди.
Икономката вече започва да пречи.
Третата графика показва, че като цяло зареждането на трапърите и синхронизаторите на историята е все още на ниво от 60%. На четвъртата графика HistoryCache по време на работа на Housekeeper вече започва да се запълва доста активно. Пълен е на 20% - около 0,5 GB.
PostgreSQL. 80 000 nvps
След това увеличих натоварването до 80 хиляди стойности в секунда. Това са приблизително 400 хиляди елемента от данни и 280 хиляди тригера.
Зареждащата вложка от тридесет синхронизатора на историята вече е доста висока.
Също така увеличих различни параметри: синхронизатори на историята, кешове.
На моя хардуер зареждането на синхронизаторите на историята се увеличи до максимум. HistoryCache бързо се напълни с данни - буферът е натрупал данни за обработка.
През цялото това време наблюдавах как се използват процесорът, RAM и други системни параметри и установих, че използването на диска е максимално.
Използвал съм максимален капацитет на диска на този хардуер и на тази виртуална машина. С такава интензивност PostgreSQL започна да изхвърля данни доста активно и дискът вече нямаше време да пише и чете.
Втори сървър
Взех друг сървър, който вече имаше 48 процесора и 128 GB RAM. Настроих го - зададох 60 синхронизатора на историята и постигнах приемлива производителност.
Всъщност това вече е ограничение на производителността, където трябва да се направи нещо.
timescaledb. 80 000 nvps
Основната ми задача е да тествам възможностите на TimescaleDB срещу натоварване на Zabbix. 80 хиляди стойности в секунда са много, честотата на събиране на показатели (с изключение на Yandex, разбира се) и доста голяма „настройка“.
Има спад на всяка графика - това е просто миграция на данни. След повреди в Zabbix сървъра, профилът на зареждане на синхронизатора на историята се промени много - падна три пъти.
TimescaleDB ви позволява да вмъквате данни почти 3 пъти по-бързо и да използвате по-малко HistoryCache.
Съответно ще получавате данни своевременно.
timescaledb. 120 000 nvps
След това увеличих броя на елементите с данни до 500 хил. Основната задача беше да проверя възможностите на TimescaleDB - получих изчислена стойност от 125 хиляди стойности в секунда.
Това е работеща „настройка“, която може да отнеме много време, за да работи. Но тъй като дискът ми беше само 1,5 TB, го напълних за няколко дни.
Най-важното е, че по същото време се създават нови TimescaleDB дялове.
За производителността това е напълно незабележимо. Когато се създават дялове в MySQL, например, нещата са различни. Това обикновено се случва през нощта, защото блокира общото вмъкване, манипулирането на таблицата и може да доведе до влошаване на услугата. Това не е случаят с TimescaleDB.
Например, ще покажа една графика от набора в общността. На снимката TimescaleDB е активиран, благодарение на което натоварването при използването на io.weight на процесора е паднало. Използването на елементи от вътрешни процеси също е намаляло. Освен това това е обикновена виртуална машина на обикновени палачинкови дискове, а не SSD.
Данни
TimescaleDB е добро решение за малки "настройки", които почиват на производителността на диска. Това ще ви позволи да продължите да работите добре, докато базата данни не бъде мигрирана към хардуер по-бързо.
TimescaleDB е лесен за настройка, дава тласък на производителността, работи добре със Zabbix и има предимства пред PostgreSQL.
Ако използвате PostgreSQL и не планирате да го променяте, препоръчвам използвайте PostgreSQL с разширение TimescaleDB във връзка със Zabbix. Това решение работи ефективно до средна "настройка".
Казваме "висока производителност" - имаме предвид . Не след дълго ще се запознаете с технологиите и практиките, които позволяват услугите да обслужват милиони потребители. списък за 7 и 8 ноември вече сме изготвили, но може да се предложи още.
Абонирайте се за нашите и , в който разкриваме характеристиките на предстоящата конференция и разбираме как да извлечете максимума от нея.
Източник: www.habr.com