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 ён вынесены на проксі. Калі ў вас вельмі вялікі 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 звяртаецца ў базу даных і атрымлівае неабходныя дадзеныя для графікаў, справаздач, спісаў падзей і апошніх праблем.
Для візуалізацыі - Графана. Сярод нашых карыстальнікаў гэтае папулярнае рашэнне. Яна ўмее напрамую адпраўляць запыты праз 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 400.
Трэці параметр - 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 nvps
Мая галоўная задача – праверыць магчымасці TimescaleDB ад нагрузкі Zabbix. 80 тыс значэнняў у секунду - гэта шмат, частата збору метрык (акрамя Яндэкса, вядома) і досыць вялікі «setup».
На кожным графіку ёсць правал - гэта як раз міграцыя дадзеных. Пасля правалаў у Zabbix-серверы профіль загрузкі history syncer вельмі моцна змяніўся - зваліўся ў тры разы.
TimescaleDB дазваляе ўстаўляць дадзеныя практычна ў 3 разы хутчэй і выкарыстоўваць менш HistoryCache.
Адпаведна, у вас своечасова будуць пастаўляцца дадзеныя.
TimescaleDB. 120 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