Ще разгледаме как Zabbix работи с базата данни TimescaleDB като бекенд. Ще ви покажем как да започнете от нулата и как да мигрирате от PostgreSQL. Предоставяме и сравнителни тестове за ефективност на двете конфигурации.
HighLoad++ Сибир 2019. Зала Томск. 24 юни, 16:00. Резюмета и . Следващата конференция HighLoad++ ще се проведе на 6 и 7 април 2020 г. в Санкт Петербург. Подробности и билети .
Андрей Гушчин (по-нататък - AG): – Аз съм инженер по техническа поддръжка на ZABBIX (наричан по-долу „Zabbix“), обучител. Работя в областта на техническата поддръжка повече от 6 години и имам пряк опит с изпълнението. Днес ще говоря за производителността, която TimescaleDB може да даде в сравнение с обикновения PostgreSQL 10. Също така малко уводна част за това как работи като цяло.
Основни предизвикателства за производителност: от събиране на данни до почистване на данни
Да започнем с това, че има определени предизвикателства в производителността, пред които е изправена всяка система за мониторинг. Първото предизвикателство за ефективността е бързото събиране и обработка на данни.
Една добра система за мониторинг трябва незабавно и своевременно да получава всички данни, да ги обработва според изрази на задействане, тоест да ги обработва според определени критерии (това е различно в различните системи) и да ги записва в базата данни, за да използва тези данни в бъдещето.
Второто предизвикателство за производителността е съхранението на историята. Съхранявайте често в база данни и имайте бърз и лесен достъп до тези показатели, които са били събрани за определен период от време. Най-важното е тези данни да са удобни за получаване, използване в отчети, графики, тригери, в някакви прагови стойности, за сигнали и т.н.
Третото предизвикателство за ефективността е почистването на историята, тоест когато имате ден, в който не е необходимо да съхранявате някои подробни показатели, които са били събирани в продължение на 5 години (дори месеци или два месеца). Някои мрежови възли са премахнати или някои хостове, показателите вече не са необходими, защото вече са остарели и вече не се събират. Всичко това трябва да се изчисти, така че вашата база данни да не нарасне до голям размер. И като цяло изчистването на историята най-често е сериозен тест за хранилището - често се отразява много на производителността.
Как да решим проблемите с кеширането?
Сега ще говоря конкретно за Zabbix. В Zabbix първото и второто извикване се решават с помощта на кеширане.
Събиране и обработка на данни - ние използваме RAM, за да съхраняваме всички тези данни. Сега тези данни ще бъдат разгледани по-подробно.
Също така от страна на базата данни има известно кеширане за основните селекции - за графики, други неща.
Кеширане от страна на самия Zabbix сървър: имаме ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Какво е?
ConfigurationCache е основният кеш, където съхраняваме показатели, хостове, елементи, тригери; всичко необходимо за обработка на предварителна обработка, събиране на данни, от кои хостове да се събират, с каква честота. Всичко това се съхранява в ConfigurationCache, за да не отива в базата данни, да не създава ненужни заявки. След като сървърът стартира, ние актуализираме този кеш (създаваме го) и го актуализираме периодично (в зависимост от настройките на конфигурацията).
Кеширане в Zabbix. Събиране на данни
Тук диаграмата е доста голяма:
Основните в схемата са тези асемблери:
Това са самите процеси на изграждане, различни „изследователи“, които са отговорни за различни видове компилации. Те събират данни чрез icmp, ipmi, използвайки различни протоколи и ги прехвърлят на предварителна обработка.
Предварителна обработка HistoryCache
Освен това, ако имаме изчислени елементи от данни (тези, които са запознати със Zabbix, знаят), тоест изчислени елементи от агрегирани данни, ние ги вземаме директно от ValueCache. Как се пълни, ще кажа по-късно. Всички тези колектори използват ConfigurationCache, за да получат своите задачи и след това да ги предадат на предварителна обработка.
Предварителната обработка също използва ConfigurationCache, за да получи стъпки за предварителна обработка и обработва тези данни по различен начин. Започвайки от версия 4.2, ние го преместихме в прокси. Това е много удобно, тъй като предварителната обработка сама по себе си е доста тежка операция. И ако имате много голям Zabbix, с голям брой елементи от данни и висока честота на събиране, тогава това значително улеснява работата.
Съответно, след като сме обработили тези данни по някакъв начин чрез предварителна обработка, ние ги запазваме в HistoryCache, за да ги обработим допълнително. Това завършва събирането на данни. Преминаваме към основния процес.
Операция за синхронизиране на историята
Основният процес в Zabbix (тъй като е монолитна архитектура) е синхронизаторът на историята. Това е основният процес, който се занимава с атомарната обработка на всеки елемент от данни, тоест всяка стойност:
- идва стойност (той я взема от HistoryCache);
- проверява в Configuration syncer: ако има тригери за изчисление - изчислява ги;
ако е налице, създава събития, създава ескалация, за да създаде предупреждение, ако е необходимо чрез конфигурация; - записва тригери за по-нататъшна обработка, агрегиране; ако обобщавате през последния час и т.н., тази стойност се запомня от ValueCache, така че да не отива в таблицата с хронологията; по този начин ValueCache се запълва с необходимите данни, които са необходими за оценка на задействания, изчислени елементи и т.н.;
- след това синхронизаторът на историята записва всички данни в базата данни;
- базата данни ги записва на диск - това завършва обработката.
База данни. кеширане
От страна на базата данни, когато искате да видите диаграми или някакъв вид отчети за събития, има различни кешове. Но в рамките на този доклад няма да говоря за тях.
За MySQL има Innodb_buffer_pool и куп различни кешове, които също могат да бъдат конфигурирани.
Но това са основните:
- споделени_буфери;
- ефективен_размер_кеша;
- споделен_пул.
Донесох за всички бази данни, че има определени кешове, които ви позволяват да съхранявате в RAM данните, които често са необходими за заявки. Те имат собствени технологии за това.
Относно производителността на базата данни
Съответно има конкурентна среда, тоест Zabbix сървърът събира данни и ги записва. Когато се рестартира, той също чете от хронологията, за да запълни ValueCache и т.н. Точно там можете да имате скриптове и отчети, които използват Zabbix-API, който е изграден на базата на уеб интерфейса. "Zabbix"-API влиза в базата данни и получава необходимите данни за получаване на графики, отчети или някакъв списък със събития, скорошни проблеми.
Друго много популярно решение за визуализация е Grafana, което се използва от нашите потребители. Възможност за директно влизане както през "Zabbix" -API, така и през базата данни. Това също така създава известна конкуренция за получаване на данни: необходима е по-фина, по-добра настройка на базата данни, за да се постигне бързо предоставяне на резултати и тестване.
Изчистване на историята. Zabbix има Housekeeper
Третото обаждане, което се използва в Zabbix, е изчистване на историята с Housekeeper. Housekeeper спазва всички настройки, тоест в нашите елементи от данни е посочено колко да се съхранява (в дни), колко дълго да се съхраняват тенденциите и динамиката на промените.
Не говорих за TrendCash, който изчисляваме в движение: идват данни, обобщаваме ги за един час (предимно числа за последния час), средната / минималната сума и я записваме веднъж на час в таблицата с тенденциите („Тенденции“). Икономката стартира и изтрива данни от базата данни с обичайните селекти, което не винаги е ефективно.
Как да разберем, че е неефективно? Можете да видите следната картина на графиките на ефективността на вътрешните процеси:
Вашият синхронизатор на историята е постоянно зает (червена графика). И "червената" графика, която върви отгоре. Това е "Housekeeper", който работи и чака базата данни да изтрие всички редове, които е задала.
Да вземем някакъв ID на елемент: трябва да изтриете последните 5 хиляди; разбира се, по индекси. Но обикновено наборът от данни е доста голям - базата данни все още го чете от диска и го поставя в кеша, а това е много скъпа операция за базата данни. В зависимост от размера му това може да доведе до определени проблеми с производителността.
Можете да деактивирате Housekeeper по прост начин - имаме познат уеб интерфейс за всички. Настройка в Общите административни настройки (Настройки за „Икономка“) деактивираме вътрешното поддържане за вътрешна история и тенденции. Съответно Housekeeper вече не управлява това:
Какво може да се направи след това? Изключихте го, графиките ви се изравниха ... Какви проблеми може да има в този случай? Какво може да помогне?
Преграждане (разделяне)
Това обикновено се конфигурира за всяка релационна база данни, която съм изброил по различен начин. MySQL има своя собствена технология. Но като цяло те са много сходни, когато става въпрос за PostgreSQL 10 и MySQL. Разбира се, има много вътрешни разлики, как всичко е внедрено и как всичко това се отразява на производителността. Но като цяло създаването на нов дял често също води до определени проблеми.
В зависимост от вашата настройка (колко данни създавате за един ден), те обикновено задават най-минималния - това е 1 ден / дял, а за "тенденции" динамиката на промените е 1 месец / нов дял. Това може да се промени, ако имате много голяма настройка.
Нека веднага да поговорим за размера на настройката: до 5 хиляди нови стойности в секунда (така наречените nvps) - това ще се счита за малка "настройка". Средно - от 5 до 25 хиляди стойности в секунда. Всичко по-горе вече са големи и много големи инсталации, които изискват много внимателна настройка на самата база данни.
При много големи инсталации 1 ден може да не е оптимален. Аз лично видях на MySQL дялове от 40 гигабайта на ден (а може и повече). Това е много голямо количество данни, което може да доведе до някои проблеми. Трябва да се намали.
Защо е необходимо разделяне?
Това, което Partitioning прави, мисля, че всеки знае, е разделянето на таблици. Често това са отделни файлове на диск и span заявки. Той избира един дял по-оптимално, ако е включен в нормалното разделяне.
За Zabbix, по-специално, се използва по диапазон, по диапазон, тоест използваме клеймо за време (обикновено число, време от началото на епохата). Посочвате начало на деня/край на деня и това е разделянето. Съответно, ако имате достъп до данни от преди два дни, всички те се избират от базата данни по-бързо, защото имате нужда само от един файл за зареждане в кеша и показване (вместо голяма таблица).
Много бази данни също ускоряват вмъкването (вмъкване в една дъщерна таблица). Докато говоря абстрактно, но също е възможно. Разделянето често помага.
Elasticsearch за NoSQL
Наскоро, в 3.4, внедрихме решение за NoSQL. Добавена е възможност за писане в Elasticsearch. Можете да напишете някои отделни типове: изберете - или напишете числа, или някои знаци; имаме текст на низ, можете да пишете регистрационни файлове в Elasticsearch ... Съответно, уеб интерфейсът също ще има достъп до Elasticsearch. Това работи добре в някои случаи, но в момента може да се използва.
timescaledb. Хипертаблици
За 4.4.2 обърнахме внимание на едно нещо като TimescaleDB. Какво е? Това е разширение за Postgres, тоест има собствен интерфейс на PostgreSQL. Освен това това разширение ви позволява да работите с данни от времеви серии много по-ефективно и да имате автоматично разделяне. Как изглежда:
Това е хипертаблица - има такова нещо във Timescale. Това е хипертаблица, която създавате и съдържа части. Чънковете са дялове, това са дъщерни таблици, ако не се лъжа. Наистина е ефективен.
TimescaleDB и PostgreSQL
Както уверяват производителите на TimescaleDB, те използват по-правилен алгоритъм за обработка на заявки, по-специално вмъквания, което ви позволява да имате приблизително постоянна производителност с нарастващ размер на вмъкване на набор от данни. Тоест, след 200 милиона реда Postgres започва да пропада много зле и губи производителност буквално до нула, докато Timescale ви позволява да вмъквате вмъквания възможно най-ефективно с произволно количество данни.
Как да инсталирам TimescaleDB? Всичко е просто!
Има го в документацията, описано е - можете да го инсталирате от пакети за всякакви ... Зависи от официалните пакети на Postgres. Може да се компилира ръчно. Така се случи, че трябваше да компилирам за БД.
В Zabbix ние просто активираме разширението. Мисля, че тези, които са използвали Extention в Postgres... Просто активирате Extention, създавате го за Zabbix базата данни, която използвате.
И последната стъпка...
timescaledb. Мигриране на таблици с хронология
Трябва да създадете хипертаблица. Има специална функция за това - Създаване на хипертаблица. В него като първи параметър посочете таблицата, която е необходима в тази база данни (за която трябва да създадете хипертаблица).
Полето за създаване и chunk_time_interval (това е интервалът от парчета (дялове, които ще се използват). 86 400 е един ден.
migrate_data параметър: Ако поставите в true, тогава това мигрира всички текущи данни в предварително създадени парчета.
Аз самият съм използвал migrate_data - отнема прилично време, в зависимост от това колко голяма е вашата база данни. Имах над терабайт - създаването ми отне повече от час. В някои случаи при тестване изтрих историческите данни за текста (history_text) и низа (history_str), за да не прехвърлям - не ми бяха особено интересни.
И ние правим последната актуализация в нашето db_extention: задаваме timescaledb, така че базата данни и по-специално нашият Zabbix да разбере, че има db_extention. Той го активира и използва правилния синтаксис и заявки към базата данни, като вече използва онези „функции“, които са необходими за TimescaleDB.
Конфигурация на сървъра
Използвах два сървъра. Първият сървър е доста малка виртуална машина, 20 процесора, 16 гигабайта RAM. Настройте Postgres 10.8 върху него:
Операционната система беше Debian, файловата система беше xfs. Направих минималните настройки, за да използвам тази конкретна база данни, минус това, което Zabbix ще използва. На същата машина имаше Zabbix сървър, PostgreSQL и агенти за зареждане.
Използвах 50 активни агента, които използват LoadableModule за бързо генериране на различни резултати. Именно те са генерирали низовете, числата и т.н. Напълних базата данни с много данни. Първоначално конфигурацията съдържаше 5 хиляди елемента с данни на хост и почти всеки елемент с данни съдържаше тригер - за да бъде това истинска настройка. Понякога дори е необходимо да се използва повече от един тригер.
Регулирах интервала на актуализиране, самото зареждане, като не само използвах 50 агента (добавя още), но също така използвах динамични елементи от данни и намалих интервала на актуализиране до 4 секунди.
Тест за представяне. PostgreSQL: 36k NVP
Първото изпълнение, първата настройка, която имах, беше на чист PostreSQL 10 на този хардуер (35 хиляди стойности в секунда). Като цяло, както можете да видите на екрана, вмъкването на данни отнема части от секундата - всичко е наред и бързо, SSD дискове (200 гигабайта). Единственото нещо е, че 20 GB се запълват достатъчно бързо.
В бъдеще ще има много такива класации. Това е стандартното табло за управление на производителността на Zabbix сървъра.
Първата графика е броят на стойностите в секунда (синьо, горе вляво), 35 хиляди стойности в този случай. Това (горе в центъра) зарежда процесите на компилация, а това (горе вдясно) зарежда точно вътрешните процеси: history syncers и housekeeper, които тук (долу в центъра) работят от доста време.
Тази графика (долу в центъра) показва използването на ValueCache - колко ValueCache посещения за задействания (няколко хиляди стойности в секунда). Друга важна графика е четвъртата (долу вляво), която показва използването на HistoryCache, за който говорих, който е буфер преди вмъкване в базата данни.
Тест за представяне. PostgreSQL: 50k NVP
След това увеличих натоварването до 50 хиляди стойности в секунда на същия хардуер. При зареждане от Housekeeper, 10 хиляди стойности вече са записани за 2-3 секунди с изчислението. Което всъщност е показано на следната екранна снимка:
Икономката вече започва да ви пречи, но общото използване на трапер за потъване в историята все още е 60% (трета диаграма, горе вдясно). HistoryCache вече по време на работа на "Икономката" започва активно да се запълва (долу вляво). Беше около половин гигабайт, 20% пълен.
Тест за представяне. PostgreSQL: 80k NVP
Допълнително увеличен до 80 хиляди стойности в секунда:
Това бяха около 400 хиляди елемента от данни, 280 хиляди задействания. Вложката, както можете да видите, по отношение на потъващите в историята на зареждане (имаше 30 от тях) вече беше доста висока. След това увеличих различни параметри: мивки на историята, кеш ... На този хардуер натоварването на мивки на историята започна да се увеличава до максимум, почти „до рафта“ - съответно HistoryCache отиде на много високо натоварване:
През цялото това време наблюдавах всички параметри на системата (как се използва процесора, RAM) и установих, че използването на диска е максимално - постигнах максималния капацитет на този диск на този хардуер, в тази виртуална машина. Postgres започна да изхвърля данни доста активно с такава интензивност и дискът вече нямаше време да пише, чете ...
Взех друг сървър, който вече имаше 48 процесора и 128 гигабайта RAM:
Аз също го „настроих“ - инсталирах синхронизатора на историята (60 броя) и постигнах приемлива производителност. Всъщност ние не сме „на рафта“, но това вероятно е границата на производителността, където вече е необходимо да се направи нещо по въпроса.
Тест за представяне. TimescaleDB: 80K NVP
Основната ми задача беше да използвам TimescaleDB. Всяка графика показва спад:
Тези повреди са просто миграция на данни. След това, в Zabbix сървъра, профилът за изтегляне на потъващите в историята, както можете да видите, се е променил много. Тя ви позволява да вмъквате данни почти 3 пъти по-бързо и да използвате по-малко HistoryCache - съответно ще получите данни своевременно. Отново, 80 хиляди стойности в секунда е доста висока скорост (разбира се, не за Yandex). Като цяло това е доста голяма настройка с един сървър.
PostgreSQL Benchmark: 120k NVP
След това увеличих стойността на броя елементи от данни до половин милион и получих изчислена стойност от 125 хиляди за секунда:
И получих тези диаграми:
По принцип това е работеща настройка, може да работи доста дълго време. Но тъй като имах диск от само 1,5 терабайта, го прекарах за няколко дни. Най-важното е, че в същото време бяха създадени нови дялове на TimescaleDB и това беше напълно незабележимо за производителността, което не може да се каже за MySQL.
Разделенията обикновено се създават през нощта, защото това блокира вмъкването и работата с таблици като цяло и може да доведе до влошаване на услугата. В този случай не става! Основната задача беше да се тестват възможностите на TimescaleDB. Оказа се такава цифра: 120 хиляди стойности в секунда.
Има и примери в "общността":
Човекът също включи TimescaleDB и натоварването при използването на io.weight падна върху процесора; и използването на вътрешни елементи на процеса също е намалено чрез включването на TimescaleDB. И това са обикновени палачинкови дискове, тоест обикновена виртуална машина на обикновени дискове (не SSD)!
За някои малки настройки, които са ограничени от производителността на диска, TimescaleDB ми се струва много добро решение. Добра идея е да продължите да работите, преди да мигрирате към по-бърз хардуер за бази данни.
Каня всички вас на нашите събития: Конференция - в Москва, Среща на върха - в Рига. Използвайте нашите канали - Telegram, форум, IRC. Ако имате въпроси, заповядайте на гишето ни, можем да поговорим за всичко.
Въпроси на публиката
Въпрос от публиката (по-нататък - A): - Ако TimescaleDB е толкова лесен за настройка и дава такъв тласък на производителността, тогава може би това трябва да се използва като най-добрата практика за настройка на Zabbix с Postgres? И има ли капани и недостатъци на това решение, или все пак, ако реша да направя Zabbix за себе си, мога спокойно да взема Postgres, да сложа Timescale там веднага, да го използвам и да не мисля за никакви проблеми?
AG: - Да, бих казал, че е добра препоръка да използвате Postgres веднага с разширението TimescaleDB. Както казах, много добри отзиви, въпреки факта, че тази "функция" е експериментална. Но всъщност тестовете показват, че това е страхотно решение (с TimescaleDB) и мисля, че ще се развива! Ние наблюдаваме как се развива това разширение и ще коригираме необходимото.
Ние дори разчитахме на една от добре познатите им „функции“ по време на разработката: там беше възможно да се работи с парчета малко по-различно. Но след това те го изрязаха в следващото издание и трябваше повече да не разчитаме на този код. Бих препоръчал да използвате това решение при много настройки. Ако използвате MySQL... За средни настройки и двете решения работят добре.
A: - В последните класации, които са от общността, имаше класация с "Икономката":
Той продължи да работи. Какво прави Housekeeper с TimescaleDB?
AG: - Сега не мога да кажа със сигурност - ще погледна кода и ще ви кажа по-подробно. Той използва TimescaleDB заявки не за премахване на парчета, но по някакъв начин агрегира. Докато не съм готов да отговоря на този технически въпрос. На щанда днес или утре ще уточним.
A: - Имам подобен въпрос - относно изпълнението на операцията за изтриване във Timescale.
A (отговор от публиката): - Когато изтривате данни от таблица, ако го правите чрез delete, тогава трябва да преминете през таблицата - изтрийте, почистете, маркирайте всичко за бъдещ вакуум. В Timescale, тъй като имате парчета, можете да пуснете. Грубо казано, просто казвате на файла, който е в големите данни: „Изтрий!“
Timescale просто разбира, че вече няма такова парче. И тъй като се интегрира в програмата за планиране на заявки, той закача вашите условия в select или в други операции и веднага разбира, че тази част вече не е - „Няма да отида там отново!“ (няма налични данни). Това е всичко! Тоест, сканирането на таблица се заменя с изтриване на двоичен файл, така че е бързо.
A: - Вече засегнахме темата не SQL. Доколкото разбирам, Zabbix всъщност не трябва да променя данните и всичко това е нещо като дневник. Възможно ли е да се използват специализирани бази данни, които не могат да променят данните си, но в същото време много по-бързо спестяват, натрупват, връщат - Clickhouse, например, нещо като Кафка?.. Кафка също е дънер! Възможно ли е по някакъв начин да ги интегрираме?
AG: - Може да се направи разтоварване. Имаме определена „функция“ от версия 3.4: можете да записвате всички исторически файлове, събития, всичко останало във файлове; и след това изпрати някакъв манипулатор към всяка друга база данни. Всъщност много хора преработват и пишат директно в базата данни. В движение потъващите в историята записват всичко това във файлове, завъртат тези файлове и т.н. и вие можете да прехвърлите това в Clickhouse. Не мога да кажа какви са плановете, но може би допълнителна поддръжка за NoSQL решения (като Clickhouse) ще продължи.
A: – Като цяло се оказва, че можете напълно да се отървете от postgres?
AG: - Разбира се, най-трудната част в Zabbix са историческите таблици, които създават най-много проблеми и събития. В този случай, ако не съхранявате събития за дълго време и съхранявате историята с тенденции в някакво друго бързо хранилище, тогава като цяло мисля, че няма да има проблеми.
A: - Можете ли да прецените колко по-бързо ще работи всичко, ако преминете към Clickhouse например?
AG: - Не съм го тествал. Мисля, че поне същите числа могат да бъдат постигнати съвсем просто, като се има предвид, че Clickhouse има собствен интерфейс, но не мога да кажа със сигурност. По-добре да тествате. Всичко зависи от конфигурацията: колко хоста имате и т.н. Вмъкването е едно, но трябва да вземете и тези данни - Графана или нещо друго.
A: - Тоест говорим за равностойна борба, а не за голямото предимство на тези бързи бази данни?
AG: - Мисля, че когато се интегрираме, ще има по-точни тестове.
A: Къде отиде добрият стар RRD? Какво ви накара да преминете към SQL бази данни? Първоначално всички показатели бяха събрани на RRD.
AG: - В "Zabbix" RRD, може би в много древна версия. Винаги е имало SQL бази данни – класически подход. Класическият подход е MySQL, PostgreSQL (съществуват от много дълго време). Почти никога не сме използвали общ интерфейс за SQL и RRD бази данни.
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com