Zabbix – це система моніторингу. Як і будь-яка інша система, вона стикається з трьома основними проблемами всіх систем моніторингу: збирання та обробка даних, зберігання історії, її очищення.
Етапи отримання, обробки та запису даних займають час. Небагато, але для великої системи це може виливатися у великі затримки. Проблема зберігання – це питання доступу до даних. Вони використовуються для звітів, перевірок та тригерів. Затримки доступу до даних також впливають на продуктивність. Коли БД розростаються, неактуальні дані доводиться видаляти. Вилучення - це важка операція, яка також з'їдає частину ресурсів.
Проблеми затримок при збиранні та зберіганні в Zabbix вирішуються кешуванням: кілька видів кешів, кешування у БД. Для вирішення третьої проблеми кешування не підходить, тому в Zabbix застосували TimescaleDB. Про це розповість Андрій Гущин - інженер технічної підтримки . У підтримці 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 досить важка операція. З v 4.2 він винесений на proxy. Якщо у вас дуже великий Zabbix з великою кількістю елементів даних і частотою збору, це полегшує роботу.
ValueCache, history & trends cache
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 та в БД, і створює певну конкурентність для отримання даних. Тому потрібне більш тонке і хороше налаштування БД, щоб відповідати швидкій видачі результатів та тестування.
Економка
Третій виклик продуктивності в Zabbix – це очищення історії за допомогою Housekeeper. Він дотримується всіх налаштувань - в елементах даних вказано, скільки зберігати динаміку змін (трендів) у днях.
TrendsCache ми обчислюємо на льоту. Коли надходять дані, ми агрегуємо їх за одну годину і записуємо в таблиці для динаміки змін трендів.
Housekeeper запускається та видаляє інформацію з БД звичайними «selects». Це не завжди ефективно, що можна зрозуміти за графіками продуктивності внутрішніх процесів.
Червоний графік показує, що History syncer постійно зайнятий. Помаранчевий графік зверху – це Housekeeper, який постійно запускається. Він чекає від БД, коли вона вилучить усі рядки, які він поставив.
Коли варто вимкнути Housekeeper? Наприклад, є Item ID і потрібно видалити останні 5 тисяч рядків за певний час. Звісно, це відбувається за індексами. Але зазвичай dataset дуже великий, і БД все одно зчитує з диска і піднімає кеш. Це дуже дорога операція для БД і, залежно від розмірів бази, може призводити до проблем продуктивності.
Housekeeper просто вимкнути. У Web-інтерфейсі є налаштування «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-таблицю.
Часовий шкалаDB
Для v 4.2 ми звернули увагу на TimescaleDB. Це розширення для PostgreSQL із нативним інтерфейсом. Розширення ефективно працює з time series даними, при цьому не втрачаючи переваг реляційних БД. TimescaleDB також автоматично партикує.
У TimescaleDB є поняття гіпертаблиця (Hypertable), яку ви створюєте. У ній знаходяться чанки - Партиції. Чанки – це автоматично керовані фрагменти гіпертаблиці, що не впливає на інші фрагменти. Для кожного чанка свій часовий діапазон.
TimescaleDB vs PostgreSQL
TimescaleDB працює дійсно ефективно. Виробники розширення стверджують, що вони використовують більш правильний алгоритм обробки запитів, зокрема inserts . Коли розміри dataset-вставки зростають, алгоритм підтримує постійну продуктивність.
Після 200 млн рядків PostgreSQL зазвичай починає сильно просідати і втрачає продуктивність до 0. TimescaleDB дозволяє ефективно вставляти «inserts» за будь-якого обсягу даних.
Встановлення
Встановити TimescaleDB досить просто для будь-яких пакетів. У все докладно описано – він залежить від офіційних пакетів 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.
Третій параметр - migrate_data. Якщо виставити true, то всі поточні дані переносяться у заздалегідь створені чанки. Я сам використав migrate_data. У мене було близько 1 ТБ, що зайняло понад годину. Навіть у якихось випадках під час тестування я видаляв необов'язкові для зберігання історичні дані символьних типів, щоб їх переносити.
Останній крок - UPDATE:в db_extension ставимо timescaledbщоб БД розуміла, що є це розширення. Zabbix його активує та правильно використовує синтаксис та запити вже до БД – ті фічі, які необхідні для TimescaleDB.
Конфігурація заліза
Я використовував два сервери. Перший - VMware-машина. Вона досить маленька: 20 процесорів Intel Xeon CPU E5-2630 v 4 @ 2.20GHz, 16 ГБ оперативної пам'яті і SSD-диск на 200 ГБ.
Я встановив на ній PostgreSQL 10.8 з ОС Debian 10.8-1.pgdg90+1 та файловою системою xfs. Все мінімально налаштував, щоб використовувати саме цю базу даних, за винятком того, що використовуватиме сам Zabbix.
На цій же машині стояв Zabbix-сервер, PostgreSQL та навантажувальні агенти. У мене було 50 активних агентів, які використали LoadableModule, щоб дуже швидко генерувати різні результати: числа, рядки. Я забивав базу великою кількістю даних.
Спочатку конфігурація містила 5 елементів даних за кожен хост. Майже кожен елемент містив тригер, щоб це було схоже на реальні інсталяції. У деяких випадках було більше одного тригера. На один вузол мережі доводилось 3-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 ГБ оперативної пам'яті. Затюнінгував його - поставив 60 history syncer, і досяг прийнятної швидкодії.
Фактично це вже межа продуктивності, де необхідно щось робити.
TimescaleDB. 80 000 nvps
Моє головне завдання – перевірити можливості TimescaleDB від навантаження Zabbix. 80 тис значень за секунду - це багато, частота збору метрик (крім Яндекса, звичайно) і досить великий "setup".
На кожному графіку є провал — це саме міграція даних. Після провалів у Zabbix-сервері профіль завантаження history syncer дуже сильно змінився - впав утричі.
TimescaleDB дозволяє вставляти дані практично в 3 рази швидше і використовувати менше 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".
Говоримо «висока продуктивність» - маємо на увазі . Чекати, щоб познайомитися з технологіями та практиками, що дозволяють сервісам обслуговувати мільйони користувачів, зовсім недовго. перелік на 7 та 8 листопада ми вже склали, а ось ще можна запропонувати.
Підписуйтесь на нашу и , в яких ми розкриваємо фішки майбутньої конференції, і дізнайтеся, як отримати максимум користі.
Джерело: habr.com