Високи перформанси и мајчин партиционирање: Zabbix со поддршка за TimescaleDB

Zabbix е систем за следење. Како и секој друг систем, тој се соочува со три главни проблеми на сите системи за следење: собирање и обработка на податоци, складирање на историјата и нејзино чистење.

Фазите на примање, обработка и снимање на податоци бараат време. Не многу, но за голем систем ова може да резултира со големи доцнења. Проблемот со складирањето е проблем со пристапот до податоци. Тие се користат за извештаи, проверки и предизвикувачи. Доцнењето во пристапот до податоци, исто така, влијае на перформансите. Кога базите на податоци растат, ирелевантните податоци треба да се избришат. Отстранувањето е тешка операција која исто така јаде некои ресурси.

Проблемите со доцнење при собирање и складирање во Zabbix се решаваат со кеширање: неколку видови кеш, кеширање во базата на податоци. За да се реши третиот проблем, кеширањето не е соодветно, па Zabbix користеше TimescaleDB. Тој ќе ви каже за тоа Андреј Гушчин - инженер за техничка поддршка Забикс СВР. Андреј го поддржува Zabbix повеќе од 6 години и има директно искуство со перформанси.

Како работи TimescaleDB, какви перформанси може да даде во споредба со обичните PostgreSQL? Каква улога игра Zabbix за базата на податоци TimescaleDB? Како да започнете од нула и како да мигрирате од PostgreSQL и која конфигурација има подобри перформанси? За сето ова под сечењето.

Предизвици за продуктивност

Секој систем за следење се соочува со специфични предизвици за изведба. Ќе зборувам за три од нив: собирање и обработка на податоци, складирање и расчистување на историјата.

Брзо собирање и обработка на податоци. Добриот систем за следење треба брзо да ги прима сите податоци и да ги обработува според изразите на активирањето - според неговите критериуми. По обработката, системот мора брзо да ги зачува овие податоци во базата на податоци за подоцнежна употреба.

Складирање историја. Добриот систем за следење треба да ја складира историјата во база на податоци и да обезбеди лесен пристап до метриката. Историјата е потребна за да се користи во извештаи, графикони, предизвикувачи, прагови и пресметани ставки со податоци за предупредување.

Чистење на историјата. Понекогаш доаѓа ден кога не треба да складирате метрика. Зошто ви се потребни податоци што се собрани пред 5 години, месец или два: некои јазли се избришани, некои хостови или метрики повеќе не се потребни бидејќи се застарени и повеќе не се собираат. Добриот систем за следење треба да складира историски податоци и да ги брише од време на време за да не расте базата на податоци.

Чистењето на застарените податоци е критично прашање што во голема мера влијае на перформансите на базата на податоци.

Кеширање во Zabbix

Во Zabbix, првиот и вториот повик се решаваат со кеширање. RAM меморијата се користи за собирање и обработка на податоци. За складирање - историја во предизвикувачи, графикони и пресметани податочни елементи. На страната на базата на податоци има одредено кеширање за основните селекции, на пример, графикони.

Кеширањето на страната на самиот Zabbix сервер е:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

Размислете за нив подетално.

ConfigurationCache

Ова е главниот кеш каде што складираме метрика, хостови, податочни ставки, предизвикувачи - сè што ни е потребно за претпроцесирање и за собирање податоци.

Сето ова е зачувано во ConfigurationCache за да не се создаваат непотребни прашања во базата на податоци. Откако ќе започне серверот, го ажурираме овој кеш, создаваме и периодично ги ажурираме конфигурациите.

Собирање на податоци

Дијаграмот е доста голем, но главната работа во него е собирачи. Ова се различни „полери“ - процеси на склопување. Тие се одговорни за различни типови на склопување: собираат податоци преку SNMP, IPMI и сето тоа го пренесуваат на PreProcessing.

Колекционерите се оцртани во портокалова боја.

Zabbix ги пресмета збирните ставки што се потребни за да се соберат проверките. Ако ги имаме, ги земаме податоците за нив директно од ValueCache.

Preprocessing HistoryCache

Сите собирачи користат ConfigurationCache за да примаат работни места. Потоа ги префрлаат на PreProcessing.

PreProcessing користи ConfigurationCache за примање чекори за претпроцесирање. Ги обработува овие податоци на различни начини.

Откако ќе ги обработиме податоците користејќи PreProcessing, ги зачувуваме во HistoryCache за обработка. Со ова завршува собирањето податоци и преминуваме на главниот процес во Zabbix - синхронизација на историјата, бидејќи се работи за монолитна архитектура.

Забелешка: Претпроцесирањето е доста тешка операција. Со v 4.2 е преместено во прокси. Ако имате многу голем Zabbix со голем број на податоци и фреквенција на собирање, тогаш ова многу ја олеснува работата.

ValueCache, кеш за историја и трендови

Историскиот синкер е главниот процес кој атомски го обработува секој податочен елемент, односно секоја вредност.

Синхронизацијата за историја зема вредности од HistoryCache и ја проверува конфигурацијата за присуство на предизвикувачи за пресметки. Ако постојат, тоа пресметува.

Синхронизацијата за историја создава настан, ескалација за создавање предупредувања доколку тоа го бара конфигурацијата и записи. Ако има предизвикувачи за последователна обработка, тогаш ја складира оваа вредност во ValueCache за да не пристапи до табелата за историја. Вака ValueCache се полни со податоци кои се неопходни за пресметување на предизвикувачите и пресметаните елементи.

Историскиот синкер ги запишува сите податоци во базата на податоци и ги запишува на дискот. Процесот на обработка завршува тука.

Кеширање во базата на податоци

На страната на базата на податоци има различни кешови кога сакате да гледате графикони или извештаи за настани:

• 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 започнува и брише информации од базата на податоци користејќи ги вообичаените „селектирања“. Ова не е секогаш ефективно, како што може да се види од графиконите за изведба на внатрешните процеси.

Црвениот графикон покажува дека синкерот History е постојано зафатен. Портокаловиот графикон на врвот е Housekeeper, кој постојано работи. Тој чека базата на податоци да ги избрише сите редови што ги навел.

Кога треба да го оневозможите Housekeeper? На пример, постои „ID на ставка“ и треба да ги избришете последните 5 илјади редови во одредено време. Се разбира, ова се случува по индекс. Но, обично сетот на податоци е многу голем, а базата на податоци сè уште чита од дискот и ја става во кешот. Ова е секогаш многу скапа операција за базата на податоци и, во зависност од големината на базата на податоци, може да доведе до проблеми со перформансите.

Домаќин е лесно да се оневозможи. Во веб-интерфејсот има поставка во „Administration general“ за Housekeeper. Го оневозможуваме внатрешното домаќинство за внатрешна историја на трендови и веќе не управува со него.

Домаќинката беше исклучена, графиконите израмнети - какви проблеми може да има во овој случај и што може да помогне во решавањето на третиот предизвик за изведба?

Поделба - партиционирање или партиционирање

Типично, партиционирањето е конфигурирано на различен начин на секоја релациона база на податоци што ја наведов. Секој има своја технологија, но тие се слични во целина. Создавањето нова партиција често доведува до одредени проблеми.

Вообичаено, партициите се конфигурираат во зависност од „поставувањето“ - количината на податоци што се создаваат во еден ден. По правило, поделбата се издава за еден ден, ова е минимум. За трендови на нова серија - 1 месец.

Вредностите може да се променат ако „поставувањето“ е многу големо. Ако малото „поставување“ е до 5 nvps (нови вредности во секунда), средното е од 000 до 5, тогаш големото е над 000 nvps. Ова се големи и многу големи инсталации кои бараат внимателна конфигурација на базата на податоци.

На многу големи инсталации, периодот од еден ден можеби не е оптимален. Сум видел MySQL партиции од 40 GB или повеќе дневно. Ова е многу голема количина на податоци што може да предизвика проблеми и треба да се намалат.

Што дава поделбата?

Табели за преградување. Честопати ова се посебни датотеки на дискот. Планот за пребарување пооптимално избира една партиција. Обично партиционирањето се користи по опсег - ова важи и за Zabbix. Таму користиме „временски печат“ - време од почетокот на ерата. Тоа за нас се обични бројки. Го поставувате почетокот и крајот на денот - ова е партиција.

Брзо отстранување - DELETE. Се избира една датотека/подтабела, наместо избор на редови за бришење.

Значително го забрзува пронаоѓањето податоци SELECT - користи една или повеќе партиции, наместо целата табела. Ако пристапувате до податоци стари два дена, тие се повлекуваат од базата на податоци побрзо бидејќи треба да вчитате само една датотека во кешот и да ја вратите, а не голема табела.

Честопати многу бази на податоци се исто така забрзани INSERT — вметнувања во детската маса.

TimescaleDB

За v 4.2, го свртевме вниманието кон TimescaleDB. Ова е екстензија за PostgreSQL со мајчин интерфејс. Екстензијата работи ефикасно со податоци од временски серии, без губење на придобивките од релационите бази на податоци. TimescaleDB исто така се поделува автоматски.

TimescaleDB има концепт хипертабела (хипертаблила) што ја создавате. Содржи парчиња - партиции. Парчињата се автоматски управувани фрагменти од хипертабели кои не влијаат на другите фрагменти. Секој дел има свој временски опсег.

TimescaleDB наспроти PostgreSQL

TimescaleDB работи навистина ефикасно. Производителите на екстензијата тврдат дека користат поправилен алгоритам за обработка на прашања, особено inserts . Како што расте големината на вметнувањето на базата на податоци, алгоритмот одржува постојани перформанси.

По 200 милиони редови, PostgreSQL обично почнува значително да попушта и ги губи перформансите на 0. TimescaleDB ви овозможува ефикасно да вметнувате „инсерти“ за која било количина на податоци.

Инсталација

Инсталирањето на 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.20 GHz процесори, 16 GB RAM и 200 GB SSD.

На него инсталирав PostgreSQL 10.8 со Debian 10.8-1.pgdg90+1 OS и xfs датотечен систем. Конфигурирав сè минимално за да ја користам оваа конкретна база на податоци, минус она што самиот Zabbix ќе го користи.

На истата машина имаше сервер Zabbix, PostgreSQL и агенти за оптоварување. Имав 50 активни агенси кои користеа LoadableModuleза многу брзо генерирање различни резултати: броеви, низи. Ја пополнив базата со многу податоци.

Првично конфигурацијата содржела 5 елементи податоци по домаќин. Речиси секој елемент содржеше активирач за да биде сличен на реалните инсталации. Во некои случаи имаше повеќе од еден предизвикувач. За еден мрежен јазол имаше 3-000 предизвикувачи.

Интервал на ажурирање на податочната ставка − 4-7 секунди. Самиот товар го регулирав со користење не само 50 агенти, туку додавајќи повеќе. Исто така, користејќи податочни елементи, динамички го прилагодив оптоварувањето и го намалив интервалот за ажурирање на 4 секунди.

PostgreSQL. 35 nvps

Моето прво извршување на овој хардвер беше на чист PostgreSQL - 35 илјади вредности во секунда. Како што можете да видите, вметнувањето податоци трае делови од секунда - сè е добро и брзо. Единственото нешто е што SSD диск од 200 GB брзо се полни.

Ова е стандардна табла за перформанси на серверот Zabbix.

Првиот син графикон е бројот на вредности во секунда. Вториот график од десната страна е вчитување на процесите на градење. Третиот е вчитување на внатрешните процеси на градење: синхрони за историја и Housekeeper, кој работи овде подолго време.

Четвртиот графикон го прикажува користењето на HistoryCache. Ова е еден вид бафер пред да се вметне во базата на податоци. Зелениот петти график ја покажува употребата на ValueCache, односно колку ValueCache погодува за предизвикувачи - ова е неколку илјади вредности во секунда.

PostgreSQL. 50 nvps

Потоа го зголемив оптоварувањето на 50 илјади вредности во секунда на истиот хардвер.

При вчитување од Housekeeper, вметнувањето на 10 илјади вредности траеше 2-3 секунди.

Домаќинката веќе почнува да се меша во работата.

Третиот графикон покажува дека, генерално, оптоварувањето на траперите и синкерите за историја е сè уште на 60%. Во четвртиот графикон, HistoryCache веќе почнува да се пополнува доста активно за време на операцијата Housekeeper. Полна е 20%, што е околу 0,5 GB.

PostgreSQL. 80 nvps

Потоа го зголемив товарот на 80 илјади вредности во секунда. Ова се приближно 400 илјади податочни елементи и 280 илјади предизвикувачи.

Цената за вчитување на триесет синхрони за историја е веќе доста висока.

Зголемив и различни параметри: синхрони за историја, кешови.

На мојот хардвер, вчитувањето на синкерите за историја се зголеми до максимум. HistoryCache брзо се наполни со податоци - податоците за обработка беа акумулирани во баферот.

Сето ова време набљудував како се користат процесорот, RAM меморијата и другите системски параметри и открив дека искористувањето на дискот е максимум.

Ја постигнав употребата максимални можности на дискот на овој хардвер и на оваа виртуелна машина. Со таков интензитет, PostgreSQL почна доста активно да ги чисти податоците, а дискот веќе немаше време да пишува и чита.

Втор сервер

Зедов друг сервер, кој веќе имаше 48 процесори и 128 GB RAM. Го наместив - го поставив на 60 history syncer и постигнав прифатливи перформанси.

Всушност, ова е веќе граница на продуктивност каде нешто треба да се направи.

TimescaleDB. 80 nvps

Мојата главна задача е да ги тестирам можностите на TimescaleDB против оптоварувањето на Zabbix. 80 илјади вредности во секунда се многу, фреквенцијата на собирање метрика (освен Yandex, се разбира) и прилично големо „поставување“.

Има пад во секој график - ова е токму миграцијата на податоците. По неуспесите во серверот Zabbix, профилот за вчитување на синхронизацијата на историјата многу се промени - падна три пати.

TimescaleDB ви овозможува да вметнувате податоци речиси 3 пати побрзо и да користите помалку HistoryCache.

Соодветно на тоа, ќе добивате податоци навремено.

TimescaleDB. 120 nvps

Потоа го зголемив бројот на податочни елементи на 500 илјади. Главната задача беше да ги тестирам можностите на TimescaleDB - добив пресметана вредност од 125 илјади вредности во секунда.

Ова е работна „поставка“ која може да работи долго време. Но, бидејќи мојот диск беше само 1,5 ТБ, го наполнив за неколку дена.

Најважно е што во исто време беа креирани нови TimescaleDB партиции.

Ова е сосема незабележливо за перформансите. Кога се креираат партиции во MySQL, на пример, сè е различно. Ова обично се случува ноќе бидејќи го блокира општото вметнување, работата со табели и може да создаде деградација на услугата. Ова не е случај со TimescaleDB.

Како пример, ќе прикажам еден графикон од многумина во заедницата. На сликата, TimescaleDB е овозможено, благодарение на што оптоварувањето на користењето на io.weight на процесорот падна. Се намали и употребата на внатрешни процесни елементи. Покрај тоа, ова е обична виртуелна машина на обични дискови за палачинки, а не SSD.

Наоди

TimescaleDB е добро решение за мали „поставки“, што влијае на перформансите на дискот. Тоа ќе ви овозможи да продолжите да работите добро додека базата на податоци не се префрли на хардвер што е можно побрзо.

TimescaleDB е лесно да се конфигурира, дава придобивки во перформансите, работи добро со Zabbix и има предности во однос на PostgreSQL.

Ако користите PostgreSQL и не планирате да го промените, препорачувам користете PostgreSQL со екстензијата TimescaleDB во врска со Zabbix. Ова решение ефикасно функционира до средно „поставување“.

Кога велиме „високи перформанси“ мислиме HighLoad ++. Нема да треба долго да чекате за да дознаете за технологиите и практиките кои овозможуваат услугите да опслужуваат милиони корисници. Список извештаи за 7 и 8 ноември веќе составивме, но еве состаноци може да се предложи повеќе.

Претплатете се на нашата билтен и телеграма, во која ги откриваме карактеристиките на претстојната конференција и дознаваме како да го извлечете максимумот од неа.

Извор: www.habr.com