Ще разгледаме работата на Zabbix с TimescaleDB като backend. Ще покажем как да стартирате от нула и как да мигрирате от PostgreSQL. Също така ще представим сравнителни тестове за производителност на две конфигурации.
HighLoad++ Сибир 2019. Зала «Томск». 24 юни, 16:00. Тезиси и . Следващата конференция HighLoad++ ще се проведе на 6 и 7 април 2020 година в Санкт Петербург. Подробности и билети .
Андрей Гущин (по-долу – АГ): – Аз съм инженер по техническа поддръжка на ZABBIX (по-долу – «Заббикс»), треньор. Работя повече от 6 години в техническа поддръжка и пряко съм се сблъсквал с производителността. Днес ще говоря за производителността, която TimescaleDB може да предложи в сравнение с обикновения PostgreSQL 10. Също така ще има малко въведение за това как всичко работи.
Основни предизвикателства за производителността: от събиране до почистване на данни
Ще започнем с това, че съществуват определени предизвикателства за производителността, с които се сблъсква всяка мониторингова система. Първото предизвикателство за производителността е бързото събиране и обработка на данни.
Добрата мониторингова система трябва да получава всички данни своевременно и бързо, да ги обработва съобразно триггерните изрази, т.е. да ги обработва по определени критерии (в различни системи е по различен начин) и да ги съхранява в база данни, за да могат в последствие да бъдат използвани.
Второто предизвикателство за производителността е съхраняването на история. Често е необходимо да се съхраняват в базата данни и да има бърз и удобен достъп до метриките, които са били събрани за определен период от време. Най-важното е тези данни да са лесно достъпни, за да могат да се използват в отчети, графики, триггери и в някакви прагови стойности за известия и т.н.
Третото предизвикателство за производителността е почистването на историята, т.е. когато идва ден, в който не е нужно да се съхраняват детайлни метрики, които са събирани в продължение на 5 години (включително месеци или дори два месеца). Някои възли от мрежата са били изтрити или някои хостове, метриките вече не са необходими, защото са остарели и вече не се събират. Това всичко трябва да се почисти, за да не расте базата данни до голям размер. И изобщо, почистването на историята често е сериозно предизвикателство за хранилището – често оказва много силно влияние върху производителността.
Как да решим проблемите с кеширането?
Сега ще говоря конкретно за «Zabbix». В «Zabbix» първият и вторият повик са решени с кеширане.
Събиране и обработка на данни – използваме оперативна памет за съхранение на всички тези данни. В момента ще говоря по-подробно за тези данни.
Също така на страната на базата данни има определено кеширане за основните извадки – за графики и други неща.
Кеширане на страната на самия Zabbix-сървър: имаме ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Какво представляват те?
ConfigurationCache – това е основният кеш, в който съхраняваме метрики, хостове, елементи на данни, триггери; всичко, което е необходимо за обработка на предпроцесинг, събиране на данни, от кои хостове да се събират данните, с каква честота. Всичко това се съхранява в ConfigurationCache, за да не ходим до базата данни и да не създаваме излишни запитвания. След стартиране на сървъра обновяваме този кеш (създаваме го) и периодично го обновяваме (в зависимост от настройките на конфигурацията).
Кеширане в Zabbix. Събиране на данни
Тук схемата е достатъчно голяма:
Основните в схемата – тези събирачи:
Това са самите процеси на събиране, различни «поллери», които отговарят за различни видове събиране. Те събират данни по icmp, ipmi, по различни протоколи и предават всичко това за предпроцесинг.
PreProcessing HistoryCache
Също така, ако имаме изчисляеми елементи на данни (който познава «Zabbix» – знае), т.е. изчисляеми, агрегатни елементи на данни, – ние ги взимаме директно от ValueCache. За това как той се запълва, ще говоря по-късно. Всички тези събирачи използват ConfigurationCache за получаване на своите задания и след това предават на предпроцесинг.
Предпроцесингът също използва ConfigurationCache за получаване на стъпките на предпроцесинг, обработва тези данни по различен начин. Започвайки от версия 4.2, той е изнесен на прокси. Това е много удобно, защото самият предпроцесинг е доста тежка операция. А ако имате много голям «Zabbix», с много елементи на данни и висока честота на събиране, то това значително улеснява работата.
Съответно, след като обработим тези данни по някакъв начин чрез предпроцесинг, ги съхраняваме в HistoryCache, за да ги обработим по-късно. На това приключва събирането на данни. Преминаваме към основния процес.
Работа на History syncer
Основният процес в «Zabbix» (тъй като това е монолитна архитектура) е History syncer. Това е основният процес, който се занимава с атомарната обработка на всеки елемент от данните, т.е. всяка стойност:
- постъпва стойността (тя я взима от HistoryCache);
- проверява в Configuration syncer: има ли тригери за изчисления – изчислява ги;
ако има – създава събития, създава ескалация за генериране на уведомление, ако това е необходимо по конфигурация; - записва тригерите за последваща обработка, агрегация; ако агрегирате за последния час и така нататък, тази стойност се запомня в ValueCache, за да не се налага да се обръща към историята; по този начин, ValueCache се запълва с нужните данни, които са необходими за изчисление на тригерите, изчисляваните елементи и т.н.;
- после History syncer записва всички данни в базата данни;
- базата данни ги записва на диск – на това обработката завършва.
Бази данни. Кеширане
На страната на БД, когато искате да видите графики или някакви доклади за събития, има различни кешове. Но в рамките на това изказване няма да говоря за тях.
За MySQL има Innodb_buffer_pool, и още куп различни кешове, които също могат да бъдат настроени.
Но това са основните:
- shared_buffers;
- effective_cache_size;
- shared_pool.
За всички бази данни съм посочил, че има определени кешове, които позволяват да се задържат в оперативната памет данни, които често са необходими за заявки. Там имат свои технологии за това.
За производителността на базата данни
Съответно, има конкурентна среда, т.е. «Zabbix» сървърът събира данни и ги записва. При рестартиране също чете от историята, за да запълни ValueCache и т.н. Съществуват и скриптове и доклади, които използват «Zabbix» API, който е построен на базата на уеб интерфейс. «Zabbix» API влиза в БД и получава необходимите данни за генериране на графики, документи или списък на събития и последни проблеми.
Също така много популярно решение за визуализация е Grafana, което нашите потребители използват. То може да влиза директно както чрез «Zabbix» API, така и през БД. И то също създава определена конкуренция за получаване на данни: необходима е по-фина, добра настройка на БД, за да отговори на бързото извеждане на резултати и тестовете.
Изчистване на историята. В Zabbix има Housekeeper
Третото извикване, което се използва в „Zabbix“, е изчистването на историята с помощта на Housekeeper. „Housekeeper“ спазва всички настройки, т.е. в нашите елементи на данните е указано колко да се съхранява (в дни), колко да се съхраняват тенденциите и динамиката на промените.
Не споменах за TrendCache, който изчисляваме в реално време: постъпват данни, агрегираме ги за един час (основно това са числа за последния час), средно/минимално количество и записваме това веднъж на час в таблицата за динамика на промените („Trends“). „Housekeeper“ се стартира и изтрива данни от БД с обикновени селекти, което не винаги е ефективно.
Как да разберем, че това не е ефективно? Можете да видите такава картина на графиките за производителността на вътрешните процеси:
Вашият History syncer постоянно е зает (червен график). И графикът, който преминава отгоре. Това е „Housekeeper“, който се стартира и чака от БД да изтрие всички редове, които е задавал.
Да вземем някакъв Item ID: необходимо е да се изтрият последните 5000; разбира се, по индексите. Но обикновено датасетът е достатъчно голям – базата данни все пак го считай на диска и го извежда в кэш, а това е много скъпа операция за БД. В зависимост от размерите й, това може да доведе до определени проблеми с производителността.
Можете да изключите „Housekeeper“ по прост начин – имаме познатия уеб интерфейс. Настройката в Administration general (настройки за „Housekeeper“) изключваме вътрешното housekeeping за вътрешната история и тенденции. Следователно, „Housekeeper“ вече не управлява това:
Какво можете да правите по-нататък? Изключили сте, графиците ви са се изравнили… Какви проблеми могат да възникнат в такъв случай? Какво може да помогне?
Партициониране
Обикновено това се настройва на всяка релационна база данни, която изброих, по различен начин. На MySQL има своя технология. Но в общи линии те са много подобни, ако говорим за PostgreSQL 10 и MySQL. Разбира се, там има много вътрешни различия, как това всичко е реализирано и как това влияе на производителността. Но в общи линии създаването на нова партиция често също води до определени проблеми.
В зависимост от вашия setup (колко много данни създавате в един ден), обикновено се задава най-ниската стойност – 1 ден/партиция, а за „трендовете“, динамиката на промените – 1 месец/нова партиция. Това може да се променя, ако имате много голям setup.
Нека веднага да спомена размерите на setup-а: до 5000 нови стойности в секунда (т.нар. nvps) – това се счита за малък setup. Среден – от 5000 до 25000 стойности в секунда. Всичко над това е вече големи и много големи инсталации, които изискват много прецизна настройка на самата база данни.
На много големи инсталации 1 ден може да не е оптимално. Лично съм виждал на MySQL партиции от 40 гигабайта за ден (и повече могат да бъдат). Това е много голям обем данни, който може да доведе до някои проблеми. Трябва да се намалява.
Защо е нужно партициониране?
Какво дава Partitioning, мисля, че всички знаят – това е секциониране на таблиците. Често това са отделни файлове на диска и спан-запроси. Той по-оптимално избира една партиция, ако това попада в обичайното партициониране.
За „Zabbix“, по-специално, се използва по диапазон, т.е. използваме таймстамп (обикновено число, времето от началото на епохата). Задавате начало на деня/край на деня и това е партиция. Съответно, ако запитвате за данни от преди два дни, всичко това се извлича от базата данни по-бързо, защото трябва само да се зареди един файл в кеша и да се издаде (а не цяла таблица).
Много БД също ускорява вмъкването (вставка в една child-таблица). Докато говоря абстрактно, но това също е възможно. Партиционирането често помага.
Elasticsearch за NoSQL
Наскоро, в 3.4, внедрихме решение за NoSQL. Добавихме възможност за запис в Elasticsearch. Можете да записвате отделни типове: избирате – или числа пишете, или някакви символи; имаме текстови низове, логовете можете да записвате в Elasticsearch... Съответно, уеб интерфейсът също ще се обръща към Elasticsearch. Това отлично работи в някои случаи, но в момента може да се използва.
TimescaleDB. Хипертаблици
За 4.4.2 обърнахме внимание на нещо, което е TimescaleDB. Какво е това? Това е разширение за PostgreSQL, тоест има натурален интерфейс на PostgreSQL. Плюс, това разширение позволява много по-ефективна работа с данни от времеви серии и автоматично партициониране. Как изглежда това:
Това е hypertable – съществува такова понятие в Timescale. Това е хипертаблица, която създавате, и в нея се намират чанкове (chunk). Чанкът – това са партиции, те са детски таблици, ако не се лъжа. Наистина е ефективно.
TimescaleDB и PostgreSQL
Както уверяват производителите на TimescaleDB, те използват по-правилен алгоритъм за обработка на заявки, по-специално за insert-и, който позволява поддържане на почти постоянна производителност при увеличение на размера на данните, които се вмъкват. Тоест след 200 милиона реда PostgreSQL обикновено започва да пада много драстично и губи производителността си буквално до нула, докато Timescale позволява вмъкването на данни възможно най-ефективно независимо от количеството им.
Как да инсталирате TimescaleDB? Всичко е просто!
Има го в документацията, описано – можете да го инсталирате от пакети за всякакви... Зависим е от официалните пакети на PostgreSQL. Може да се компилира ръчно. Така се случи, че трябваше да компилирам за БД.
В Zabbix просто активираме разширението. Мисля, че тези, които са ползвали разширение в PostgreSQL... Просто активирате разширението, създавате го за БД Zabbix, която ползвате.
И последната стъпка...
TimescaleDB. Миграция на таблици с история
Трябва да създадете hypertable. За това има специална функция – Create hypertable. В нея първият параметър е таблицата, необходима в тази БД (за която трябва да се създаде хипертаблица).
Полето, по което трябва да се създаде, и chunk_time_interval (това е интервалът на чанкса (партициите, които трябва да се използват). 86 400 – това е един ден.
Параметър migrate_data: ако зададете true, това пренася всички текущи данни в предварително създадените чанкове.
Аз самият използвах migrate_data – това отнема значително време, в зависимост от размера на вашата БД. При мен имаше повече от терабайт – създаването отне повече от час. В някои случаи, при тестване, изтрих исторически данни за текста (history_text) и стринга (history_str), за да не пренасям – те не бяха наистина интересни за мен.
И последният апдейт, който правим в нашето db_extension: инсталираме timescaledb, за да може БД и по-специално нашият «Заббикс» да разбира, че съществува db_extension. Той го активира и използва правилно синтаксиса и заявките към БД, ползвайки вече онези „функции“, които са необходими за TimescaleDB.
Конфигурация на сървъра
Използвах два сървъра. Първият сървър е виртуална машина, доста малка - 20 процесора, 16 гигабайта оперативна памет. Настроих на нея „Постгрес“ 10.8:
Операционната система беше Debian, файловата система – xfs. Направих минимални настройки, за да ползвам точно тази база данни, с изключение на това, че самият „Заббикс“ ще я използва. На същата машина беше инсталиран „Заббикс“-сервер, PostgreSQL и натоварващи агенти.
Използвах 50 активни агента, които ползват LoadableModule, за бързо генериране на различни резултати. Те генерираха редове, числа и така нататък. Запълвах БД с голямо количество данни. Първоначално конфигурацията съдържаше 5 хиляди елемента данни на всеки хост и приблизително всеки елемент данни имаше тригер – за да е реална настройката. Понякога за употреба дори се изисква повече от един тригер.
Интервалът на обновление и самото натоварване регулирах не само чрез използване на 50 агента (добавях още), но и с помощта на динамични елементи данни, като намалих интервала на обновление до 4 секунди.
Тест на производителността. PostgreSQL: 36 хиляди NVPs.
Първият старт, първоначалната настройка, която имах, беше на чисто PostgreSQL 10 на този хардуер (35 хиляди стойности в секунда). Както се вижда на екрана, вкарването на данни отнема части от секунда – всичко е добре и бързо, SSD дискове (200 гигабайта). Единственото, което 20 ГБ се запълват доста бързо.
Ще има доста подобни графики занапред. Това е стандартният dashboard на производителността на „Заббикс“-сервера.
Първата графика – броят стойности в секунда (синя, в горния ляв ъгъл), 35 хиляди стойности в този случай. Това (в горната част в центъра) е натоварването на процесите по събиране, а това (в горния десен ъгъл) е натоварването на вътрешните процеси: history syncers и housekeeper, които тук (в долния център) са работили доста време.
Тази графика (по-долу в центъра) показва използването на ValueCache – колко хита има на ValueCache за тригери (няколко хиляди стойности в секунда). Друг важен график е четвъртият (вдясно долу), който показва използването на HistoryCache, за който говорих, и който е буфер преди запис на данни в БД.
Тест за производителност. PostgreSQL: 50 хиляди NVPs
След това увеличих натоварването до 50 хиляди стойности в секунда на същото оборудване. При зареждане с "Хаускипер" 10 хиляди стойности се записваха за 2-3 секунди с изчисления. Това, в собствено изражение, е показано на следващия екран.
"Хаускипер" вече започва да пречи на работата, но общото натоварване на трапите хистори-синкери все още е на ниво 60 % (трети график, горе вдясно). HistoryCache вече по време на работа с "Хаускипер" започва активно да се запълва (вдясно долу). Той беше около половин гигабайт и се запълваше с 20%.
Тест за производителност. PostgreSQL: 80 хиляди NVPs
След това увеличих до 80 хиляди стойности в секунда:
Това бяха около 400 хиляди елемента данни, 280 хиляди тригери. Вставката, каквато е видно, по натоварването на хистори-синкерите (имаше 30 от тях) вече беше доста висока. След това увеличавах различни параметри: хистори-синкери, кеш… На това оборудване натоварването на хистори-синкерите започна да се увеличава до максимума, практически "в полка" – съответно, HistoryCache премина в много високо натоварване:
През цялото това време наблюдавах всички параметри на системата (как се използва процесорът, оперативна памет) и открих, че използването на дисковете беше максимално – постигнах максималната възможност на този диск на това оборудване, на тази виртуална машина. "Постгрес" започна да изхвърля данни достатъчно активно при такава интензивност и дискът вече не успяваше да записва, чете…
Взех друг сървър, който вече имаше 48 процесора и 128 гигабайта оперативна памет:
Също така го "оптимизирах" – инсталирах History syncer (60 штук) и постигнах приемливо бързодействие. Всъщност не сме "в полка", но вероятно това е пределът на производителността, при който е необходимо нещо да се предприеме.
Тест за производителност. TimescaleDB: 80 хиляди NVPs
Основната ми задача беше да използвам TimescaleDB. На всеки график е виден спад:
Тези неуспехи са именно свързани с миграцията на данни. След това в „Zabbix“ сървъра профилът на зареждане на history-sync-er-ите, както виждате, се е променил значително. Той практически позволява вмъкване на данни три пъти по-бързо и използва по-малко HistoryCache – съответно, данните ще се предоставят своевременно. Отново, 80 хиляди стойности в секунда – това е доста висок темп (разбира се, не за „Яндекс“). В общи линии, това е доста голям setup с един сървър.
Тест за производителност на PostgreSQL: 120 хиляди NVPs
След това увеличих стойността на количеството данни до половин милион и получих изчислително значение от 125 хиляди в секунда:
И получих такива графики:
В принципе, това е работещ setup, който може да работи достатъчно дълго време. Но тъй като имах диск само от 1,5 терабайта, го изразходвах за няколко дни. Най-важното е, че по същото време се създаваха нови партиции на TimescaleDB и това преминаваше напълно незабелязано за производителността, нещо, което не може да се каже за MySQL.
Обикновено партициите се създават през нощта, защото това блокира изцяло вмъкването и работата с таблиците и може да доведе до деградация на услугата. В този случай това не е така! Основната задача беше да се провери възможностите на TimescaleDB. Получи се такава цифра: 120 хиляди стойности в секунда.
Също така има примери в „комюнитито“:
Човек също активира TimescaleDB и натоварването по използване на io.weight падна на процесора; и употребата на елементите от вътрешните процеси също намаля, благодарение на активирането на TimescaleDB. Освен това, това са обикновени дискове, тоест стандартна виртуалка на обикновени дискове (не SSD)!
За някакви малки setups, които стигат до лимита на производителността на диска, TimescaleDB, както ми се струва, е много добро решение. То позволява да продължавате да работите до миграцията на по-бързо оборудване за базата данни.
Каня всички вас на нашите събития: Конференция – в Москва, Самит – в Рига. Използвайте нашите канали – „Телеграм“, форум, IRC. Ако имате някакви въпроси – елате при нас на щанда, можем да поговорим за всичко.
Въпроси от аудиторията
Въпрос от аудиторията (по-нататък – А): – Ако TimescaleDB е толкова лесен за настройка и предлага такъв ръст на производителността, то може би е добре да се използва като най-добра практика за настройка на "Забикс" с "Постгрес"? И има ли някакви подводни камъни или недостатъци в това решение, или в крайна сметка, ако реша да правя "Забикс", мога спокойно да взема "Постгрес", да инсталирам "Таймскейл" веднага, да го използвам и да не мисля за никакви проблеми?
АГ: – Да, бих казал, че това е добра препоръка: да се използва "Постгрес" веднага с разширението TimescaleDB. Както вече споменах, много добри отзиви, въпреки че тази "функция" е експериментална. Но наистина тестовете показват, че това е отлично решение (с TimescaleDB), и мисля, че ще се развива! Следим как се развива това разширение и ще поправим това, което е нужно.
Дори по време на разработката се опирахме на една от техните известни "функции": там можеше да се работи с чанкове по малко по-различен начин. Но след това те премахнаха това в следващия релиз и ни се наложи да не се опираме на този код. Бих препоръчал да се използва това решение в много настройки. Ако използвате MySQL… За средни настройки всяко решение работи добре.
А: – На последните графики, които бяха от общността, имаше графика с "Хаускипер":
Той продължи да работи. Какво прави "Хаускипер" в случая с TimescaleDB?
АГ: – В момента не мога да кажа точно – ще прегледам кода и ще кажа по-подробно. Той използва заявки именно от TimescaleDB, а не за изтриване на чанкове, а по-скоро агрегира. Все още не съм готов да отговоря на този технически въпрос. На стенда днес или утре ще уточним.
А: – Имам подобен въпрос – за производителността на операцията по изтриване в "Таймскейл".
А (отговор от аудиторията): – Когато изтривате данни от таблица, ако го правите чрез delete, трябва да преминете през таблицата – да изтриете, да почистите, да маркирате всичко за бъдещ вакуум. В "Таймскейл", тъй като имате чанкове, можете да изтривате. Грубо казано, просто казвате на файла, който лежи в big data: "Изтрий!"
«Таймскейл» просто разбира се, че такъв чанк вече не съществува. И понеже той се интегрира в планировчика на заявки, той улавя вашите условия в select или в други операции и веднага разбира, че този чанк вече не е наличен – «Аз няма повече да отида там!» (данните липсват). И това е всичко! Тоест, сканирането на таблицата се заменя с изтриването на бинарния файл, така че това е бързо.
А: – Вече споменахме темата за не-SQL. Колкото разбирам, «Заббиксу» не му е особено необходимо да модифицира данните, а всичко това е нещо като лог. Може ли да се използват специализирани БД, които не могат да променят своите данни, но в същото време много по-бързо съхраняват, натрупват и предоставят – например Clickhouse, нещо като кафка-образно?.. Kafka – също е лог! Може ли да ги интегрираме по някакъв начин?
АГ: – Може да се направи извличане. Имаме определена «функция» от версия 3.4: можете да записвате всички исторически файлове, събития и всичко останало в файлове; и след това по някакъв обработчик да ги изпращате в друга БД. Всъщност много хора правят промени и записват директно в БД. На летището хистори-синкерите записват всичко в файлове, ротират тези файлове и така нататък, и можете да ги прехвърляте в «Кликхаус». Не мога да кажа за плановете, но вероятно по-нататъшната поддръжка на NoSQL решения (като «Кликхаус») ще продължи.
А: – Всъщност, може ли напълно да се откажем от postgres?
АГ: – Разбира се, най-трудната част в «Заббиксе» са историческите таблици, които създават най-много проблеми, и събитията. В този случай, ако не съхранявате събития дълго време и държите история с трендове в някакво друго бързо хранилище, то по принцип не би трябвало да имате проблеми.
А: – Можете ли да оцените колко по-бързо всичко ще работи, ако преминем на «Кликхаус», например?
АГ: – Не съм тествал. Мисля, че поне същите числа може да се постигнат сравнително лесно, имайки предвид, че «Кликхаус» има свой интерфейс, но не мога да кажа с абсолютна точност. Най-добре е да се проведе тест. Всичко зависи от конфигурацията: колко хостове имате и така нататък. Вмъкването е едно, но също така трябва да извличате тези данни – Grafana или нещо подобно.
А: – Тоест, става въпрос за равна борба, а не за голямо предимство на тези бързи БД?
АГ: – Мисля, че когато интегрираме, ще имаме по-точни тестове.
А: – А къде изчезна старият добър RRD? Какво накара да преминем на SQL бази данни? Първоначално всички метрики се събираха на RRD.
АГ: – В "Zabbix" RRD, може би, е имало в много древна версия. Винаги е имало SQL бази – класическият подход. Класическият подход включва MySQL, PostgreSQL (вече съществуват от много време). Ние почти никога не сме използвали общ интерфейс за SQL бази данни и RRD.
Малко реклама 🙂
Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, , уникален аналог на entry-level сървъри, който е създаден от нас за вас: (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това
Източник: habr.com
