Вышел Zabbix 4.2

Интересно, как реализован троттлинг внутри и какие могут быть аффекты при использовании партиционирования: типа того, что выпавшее за пределы текущей партиции значение не будет ли искаться в предыдущей партиции в случае, если оно не найдётся в памяти сервера? И как теперь понять, метрика вообще перестала собираться или это у неё просто значение не меняется?

Относительно JavaScript - честное слово, лучше бы они дали возможность безопасным образом добавлять UserParameter'ы для Zabbix'агента на лету, потому что нынешняя альтернатива в виде EnableRemoteCommands=1 безопов ни в одной нормальной организации не устроит.

Кейс с JS'ом не очень понятен в контексте одной метрики: даже в нашем инфраструктурном мониторинге процентов 60 метрик собираются доморощенными скриптами, а уж в мониторинге приложений почти всё пушится Zabbix Sender'ом. Зачем тогда нужен препроцессинг, если его можно и нужно делать на стороне «собирающего»? Единственный кейс, который я вижу - это допиливание данных веб-мониторинга (со всяких REST API и прочего подобного).

Алексей Владышев пишет на Хабре:

Чаще всего такой подход приводит к тому, что нам необходимо слишком часто опрашивать устройства и собирать данные, что приводит к большей нагрузке на систему мониторинга. Как этого избежать?

Мы реализовали механизм тротлинга (throttling) в правилах препроцессинга. Тротлинг, по сути, даёт нам возможность пропуска одинаковых значений.

В данном контексте (поллинга) наибольшую нагрузку на систему мониторинга создаёт всё-таки сбор данных, а не их обработка. Поэтому, например, создание удобного механизма работы с теми же SNMP-трапами с точки зрения производительности мониторинга и своевременности реакции куда критичнее.

Тротлинг в том виде, в котором он описан, попросту позволит обойти одни проблемы хранения исторических данных, создав тут же при этом другие проблемы.

Сугубо ИМХО, но просто за живое задело. У нас, например, 8 камней «виртуального» zabbix-сервера забиты в лучшем случае на треть, а 32 камня «железной» базы данных - почти всегда на 50-80% заняты, и это после массы кропотливых оптимизаций базы. При этом всякий разный препроцессинг и расчёт перцентилей у нас тоже есть, но на каждый результат одного select'а, затрагивающего history, приходится несоизмеримое просто этому селекту количество вычислений быстрым сишным кодом zabbix-сервера.

расширение для PostgreSQL, того же уровня вещь, что и, например, PostGIS.

спасибо, что зашел) так действительно понятно. у меня опыт в первую очередь с постгрессом и мне логично задуматься об использовании timescale. теперь понятно, где выигрыш. судя по тому, что ты уже ставишь, open source версии вполне достаточно. я так и не понял, какие плюшки в enterprise версии. ну и опять же пока не понятно, смогут ли они коммерчески выжить и остаться на рынке.

Зачем нужен препроцессинг в таких объёмах

гибкости добавляют. обрабатывать данные прямо перед отдачей в скрипте - дело обычное, но, видимо, на сервере через формочки более солидно:)

Тротлинг в том виде, в котором он описан, попросту позволит обойти одни проблемы хранения исторических данных, создав тут же при этом другие проблемы.

Тротлинг нужен для более быстрого обнаружения проблем без внесения дополнительной нагрузки на остальные компоненты. Мне кажется, что это будет основным применением данной этой функциональности.

Относительно JavaScript - честное слово, лучше бы они дали возможность безопасным образом добавлять UserParameter'ы для Zabbix'агента на лету, потому что нынешняя альтернатива в виде EnableRemoteCommands=1 безопов ни в одной нормальной организации не устроит.

Все улучшения в препроцессинге направлены на то, чтобы избавиться от ненужных UserParameters и максимально перенести всю логику обработки данных в шаблоны. А JavaScript позволяет манипулировать данными исключительно гибко.

Кроме того, сейчас любые собранные данные (XML, CVS, plain text, и т.д.) можно без особых усилий использовать для автоматического обнаружения.

вот бы еще дизайнер интерфейса добрался до Administration->General->Images там все в одну кучу:(

1. Не уверен, поскольку код не читал, но по логике вещей - да, будет искаться

Впрочем, мы партиционирование совсем недавно выкинули нафиг в пользу TokuDB на SSD.

2. Кейс с JS'ом очень понятен в контексте одной метрики: вы выгребаете с вашего IPMI например одним заходом кучу всякой шляпы по SDR, и далее JS'ом превращаете в удобоваримый формат для каждой метрики, которые dependent. Без JS'а придётся костылить.

Ещё более он понятен в контексте дискавери - очень много чего не умеет в понятный заббиксу JSON на выходе.

Ну и да, больше как раз таки можно во многих случаях сендером ничего не пушить - собирать агентом сырые данные и всё. Заодно лог этих сырых данных вести.

Yes!

Теперь можно поллить раз в минуту например, а хранить только раз в сутки и/или при изменениях.

А можно с вами без злого умысла помериться всякими vps?

Один сервер под XenServer на 12 ядер, Zabbix и MariaDB совмещены. Партиционирования больше нет, база на SSD, хистори в TokuDB.

Number of hosts (enabled/disabled/templates) 11509 9009 / 2382 / 118

Number of items (enabled/disabled/not supported) 419592 266312 / 147150 / 6130

Number of triggers (enabled/disabled [problem/ok]) 226439 116031 / 110408 [855 / 115176]

Number of users (online) 29 2

Required server performance, new values per second 1656.02

Кусок топа

https://pastebin.com/pARZDy2Z

«Честная» нагрузка по графикам составляет процентов 20 по каждому из ядер, с кратковременными выплесками на 1-2 ядра (TokuDB «пакует» логи).

Очень печалит конечно нарастающее обилие Foreign Keys в базе - мы хотели ещё также огромнющие event / problem history выкинуть в TokuDB, но оно не умеет FK...

Тротлинг нужен для более быстрого обнаружения проблем без внесения дополнительной нагрузки на остальные компоненты

При том, что идея очень здравая, уверен на 150%, что троттлинг будет использоваться для сокращения объёмов history и «повышения производительности» на самых обычных метриках.

Хотя сама по себе долбёжка каждую секунду куда бы то ни было - часто следствие отсутствия возможности получить «оттуда» данные оперативно в режиме прерываний (через zabbix-трапперы или ловушки snmp-трапов), т.е. есть вероятность, что такой интенсивный поллинг - следствие неверно выстроенной архитектуры сторонней системы.

Все улучшения в препроцессинге направлены на то, чтобы избавиться от ненужных UserParameters и максимально перенести всю логику обработки данных в шаблоны

Алексей, со всем уважением, UserParameters всё-таки про сбор данных, а не про их обработку (ну т.е. можно конечно и обрабатывать, но тут и правда можно с таким же успехом на стороне сервера). Добавление интерпретатора JS никак не решает проблему того, что ни одна система мониторинга не может самостоятельно собирать сама абсолютно любые данные, везде так или иначе нужен запуск скриптов. UserParameter'ы во многом снимают остроту проблемы благодаря тому, что там можно вписать прямиком bash-скрипт: некрасиво конечно, но так оно работает. В более сложных случаях через UserParameter'ы запускаются внешние perl/python/etc скрипты. Которые конечно приходится разливать независимым от системы мониторинга способом (тем же ansible).

Собственно, я и говорил о том, что коль скоро львиная доля метрик собирается внешними средствами, то и форматировать вывод могут они же.

Но, безусловно не всегда.

С JavaScript'ом вопросы скорее к тому, как это реализовано, что за интерпретатор встроен в zabbix и насколько этому решению можно доверять: возможны утечки памяти, возможны проблемы с подвисшими процессами интерпретатора, блокирующими препроцессинг на шаге JavaScript и т.д. Я бы пока пользовался столь мощным функционалом с большой степенью осторожности.

У нас 3 системы мониторинга примерно такого плана:

Number of hosts (enabled/disabled/templates)	2243	1850 / 165 / 228
Number of items (enabled/disabled/not supported)	117499	93032 / 17700 / 6767
Number of triggers (enabled/disabled [problem/ok])	72491	56221 / 16270 [151 / 56070]
Number of users (online)	151	19
Required server performance, new values per second	1384.28	

Т.е. в принципе трава пониже, дым пожиже конечно, чем у вас. Но правда и не TokuDB. Всё работает на MySQL Enterprise. Фронт отделён (php-fpm + apache), zabbix-сервер отдельно тоже.

Думаем переходить на Postgresql 11 + TimescaleDB 1.2 . Сделал сегодня такой тестовый стенд - вроде работает, нужно будет туда каких-то данных напихать.

помериться всякими vps?

А смысл меряться ничего не значащими показометрами? Смысел vps в том, что оно считает только те итемы, которые сервер опрашивает сам, а то что он не умеет (трапперы скажем) они и не считает.

Партиционирования больше нет

Зачем так? TokuDB хорошо партиционируется. А вот за таблицу event я бы бил разработчиков ногами и больно.

Кусок топа

ухты, кто-то еще апачу использует. nginx+php-fpm7.3+opcache не модно?

вы переходить будете, получается, с потерей накопленных данных? или есть хорошие средства mysql->pgsql? там и схема может быть разной...

имхо, php вебморду всегда надо где-то отдельно размещать. она дает всплески нагрузки. кажется, la и небольшой, а дернули морду, начал график строится - система перестает быть отзывчивой.

Вышел Zabbix 4.2 (комментарий)

истинно так. заббикс без клея в виде скриптов потеряет одно из своих самых больших преимуществ. не [дубоватый] веб интерфейс является этим преимуществом.

Смысл мериться есть, и дело не в «пожиже погуще». Это очень хороший, если не единственный способ, оценить сравнимую производительность своей системы, для обеих сторон. В какую сторону смотреть, конечно, детально сравнение не скажет - у всех условия разные, но общее представление даст.

Спасибо!

Ну... пока смысла не вижу, нагрузка от вёбморды не существенная, несмотря на обилие клиентов «трея» (трей-тулзы, которая смотрит за эвентами).

А графики у нас как раз вытащены на отдельный сервер - и этим самым мы уменьшили размер хистори по целому вагону метрик. База хистори по int/float читается регулярно, запихивается в RRD, и там уже хранится долгосрочно (в разрезе нескольких лет), с агрегацией данных по далёким периодам, конечно :)

Базы хистори настолько в доску просты, что перейти и без потерь накопленных данных особых проблем нет. Главное правильно соотнести itemid в новой и старой системах.

С эвентами посложнее, конечно, но тоже не рокет сайнс.

Собственно, я и говорил о том, что коль скоро львиная доля метрик собирается внешними средствами, то и форматировать вывод могут они же

Это да, но представьте себе, что вам надо изменить формат по каким-то причинам. И придётся гонять ансибл или что там у вас по куче нод, если он есть, а если его нет - это вагон ручной работы.

Есть ещё более весёлые приключения, когда на формат вывода вы влиять не можете :) Обычно для этих целей костылились тормозные External Check'и, каждый из которых форк и с которыми надо жить очень осторожно, а теперь можно делать просто препроцессинг.

Ещё есть например железки разных версий, которые одно и то же отдают немножко по-разному. Раньше надо было для каждой свой темплейт, и за версиями следить, а теперь можно в том же JS сдетектить формат вывода например.

И даже для единичных метрик годится: есть например у нашего IT пара принтеров HP соседних моделей. Один отдаёт нужное для мониторинга поле просто как строку, а второй - как hex (binary)... Ну, вы поняли :) OID один и тот же. Обычным препроцессингом hex назад в строку (ну, практически), да ещё с обрезкой нулей в конце, не перегнать. JS - вообще без проблем. При этом даже разных шаблонов не нужно, внутри JS и детектим, что нам там прилетело.

Смысл мериться есть

Нету. Это показометр сколько ты запихиваешь в базу. А запихивать туда можно хоть охреннилион, но нагрузку как-раз создают таки триггеры с всеми любимым .last() который может закопаться в историю в прошлое тысячилетие и построение графиков. А если не строить графики и не использовать триггеры - то банальный flatfile может оказаться быстрей sql'я.

Так пусть закапывается, индексы для кого придумали. Кроме того, в zabbix есть value cache. Ну и если last слишком часто и глубоко закапывается в базу - что-то определённо не так сделано.

Это ещё и показометр нагрузки на поллеры, к примеру.

Зачем так? TokuDB хорошо партиционируется.

Партиционирование надо менеджить регулярно, ежедневных партиций в TokuDB надолго не наделаешь - количество open files у движка уйдёт в небеса, на партиционировании из рук вон плохо работает встроенный хаускипинг. Переход на SSD для хранения позволил полностью отказаться от партиционирования, и даже включить назад регулярный хаускипинг, не поимев при этом проблем.

этот ответ не понял. что за «базы хистори»? таблица хистори? так ее одну нет смысла копировать из-за fk. там вся структура базы повязана fk.

Сюрприз: на хистори нет FK. Но FK тут и не особо актуально: вся база завязана через различные ID, что с FK, что без FK.

Поэтому естественно, если копировать хистори на совсем другую инсталляцию - то с умом, сопоставляя и заменяя itemid на актуальные. Это не тривиальная задача.

С моей т.з. проще будет перенести на другой движок всю базу без схемы, просто в виде набора данных для INSERT, выключив на время заливки все FK (нет, можно конечно заливать в порядке зависимостей - но это жуткий геморрой, проще FK выключить-включить). Даже если схема чуть-чуть отличается, выправить набор данных не должно быть сильно проблематично.

Это ещё и показометр нагрузки на поллеры, к примеру.

Ага. Хреновый пример. Любые задержки в сети и все поллеры - раком, а итемов - штук 100 на весь ультанитрагигасервер.

Партиционирование надо менеджить регулярно

Для этого у mariadb/mysql есть шедулер. Собственно который уже лет с 5 занимается дерганьем каждый день встроенной процедуры с созданием-удалением таблиц.

# echo 'show create table history_uint\G' | mysql -B zabbix | egrep -c 'PARTITION .* VALUES LESS THAN'
366
# ls -1 /proc/$(pidof mysqld)/fd/ | wc -l
4375

ежедневных партиций в TokuDB надолго не наделаешь - количество open files у движка уйдёт в небеса

Родной, XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось, проснись.

# cat /proc/sys/fs/file-max 
3273658

Хоть упартиционируйся.

на партиционировании из рук вон плохо работает встроенный хаускипинг.

Как написан - так и работает.

Поэтому естественно, если копировать хистори на совсем другую инсталляцию - то с умом, сопоставляя и заменяя itemid на актуальные. Это не тривиальная задача.

Обалдеть, 3 запроса - это уже нетривиальная задача?

• зарезервировать в таблице ids дырку себе под нужное количество items
• скопировать из общей помойки zabbix.items итем на нужным itemid
• скопировать из history_* таблицы данные

можно даже не останавливая сервер.

XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось

Дело там не в лимите, его-то можно раздуть, но я уже вижу - вы тему MySQL и партиционирования дальше пары команд (если не вообще) не щупали.

Если очень просто - любой запрос, не ограниченный range'м из партиции, приведёт к открытию тредом всего мегатонного блока таблиц партиций. Открытие таблицы - это очень далеко не просто открытие файла. В случае TokuDB я не зря упомянул, что у него файлов до фига - там кроме табличного файла ещё открываются все файлы индексов. С чтением/инициализацией структур для каждого. На время собственно открытия и чтения метаданных мы имеем полный read-only lock на таблице. Что для хистори - ну, не фатал, но очень плохо.

А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()/avg()/whatever... Если, не приведи разум, по каким-то причинам в таком запросе появился row lock... в общем, на все эти грабли нормально понаступали, и решили, что лучше без, чем с.

Обалдеть, 3 запроса - это уже нетривиальная задача?

Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)

Если копируем только хистори - итемы копировать не надо. Если копируем итемы - лучше копировать всё целиком, там оно настолько друг на друга гвоздями прибито, что отдельно например от дискавери и хостов с темплейтами лучше даже и не пытаться.

Снова видно, что совсем не щупали. Прекращаю, потому что получается демагогия ради демагогии.

но я уже вижу

Виделку протри, запылилась. Я для чего привел количество открытых дескрипторов у mysqld ? Для того, чтоб ты сыграл в бабушку Вангу и промахнулся? Я тебя расстрою - они (патриции) у меня - НЕ ЗАКРЫВАЮТСЯ. Прикинь, я знаю как настраивать mysql.

А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада.

Опять-же - у вас. У меня zabbix_server немного пропатчен и отучен лазать по каждому чиху в данные годовалой старости.

Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)

НИГДЕ. у тебя 64bit integer. прибавь себе к каждому itemid по 4294967296 и радуйся. Если вдруг в таблице items нашлось изначально больше 4294967296 итемов - то у вас проблемы больше, чем row-lock и history (точнее self-made value cache) populating trash.

Если копируем только хистори - итемы копировать не надо.

А нахрен нужно то history в который ты никак не посмотришь? Место на дисках занимать?

Если копируем итемы - лучше копировать всё целиком

Ага-ага. Сходи почитай, зачем в таблице items поле flags. Думаю - откроешь для себя очень много нового.

Прекращаю, потому что получается демагогия ради демагогии.

Правильно, прекращай позориться. И ванговать не умеешь и в заббиксе не в зуб ногой.

У меня zabbix_server немного пропатчен и отучен лазать

Не, ну я не спорю, костылинг тоже имеет право на жизнь. Костылинг (патчинг левой задней ногой) для компенсации ахтунгов другого костылинга (партиционирования хистори) - тем более. А у нас всё и без костылинга теперь неплохо живёт.

Всего доброго.

Сюрприз: на хистори нет FK.

сюрприза нет, я видел базу. а в 2014 админил несколько инсталяций больше твоей. FK по сути в другой форме, как хочешь называй, но

Это не тривиальная задача.

об этом я и говорю. не будешь ты несколько тысяч хостов по itemid сводить и без переноса всех связанных данных в базе ты не обойдешься.

Согласен, лучше целиком перетаскивать. Свести itemid через пару запросов к API проблем особых нет, но зачем :)

костылинг тоже имеет право на жизнь.

Ага. Zabbix зовется. Без патчей малофункциональное нечто, для зарабатывания денег. Впрочем - это и хорошо, что оно кривое из коробки.

имхо, это ни о чем. заббикс, ес-но, имеет пачку недоделок, при этом он ставит галочки в очень большом чек-листе функций. по соотношению цена-эффективность он крут. а уж спорить как решаеть его проблемы, смысла нет. можно предложить способ, но наставить на том, что он единственно правильный - глупо.

:) жаль, что я сейчас не админю заббикс. это увлекательное занятие. будет новый релиз - приходи еще в тред. я хоть буду чуть-чуть в курсе, какие новые финты и костыли появились с 2014.)

UserParameters всё-таки про сбор данных, а не про их обработку

Всё верно. Я говорил не о замене, а о снижении количества UserParameters за счёт того, что логика обработки перекладывается на сторону сервера.

С JavaScript'ом вопросы скорее к тому, как это реализовано...

Мы обо всём подумали. Есть ограничения и по памяти и по времени выполнения. Фактически JavaScript выполняется в безопасной песочнице и не требует сторонних библиотек. Поэтому мы и не выбрали embedded Python, например.

при этом он ставит галочки в очень большом чек-листе функций.

какие такие галочки?

Посчитай своим заббиксом некое количество значений x=y с интервалом не менее t за время Tmax, и если это количество больше 3 - то дерни триггер.

Для простоты понимания - пусть это будет результат от icmp.ping[], x = 0, время t пока не пингуется - 180 секунд (считаем, что что-то там у нас перезагружается) Tmax - 1 час. Если отказов больше 3х за час и никто об этом не узнал - «очко переходит в зрительный зал» премии нет и не будет.

по соотношению цена-эффективность он крут.

Для хипсторов? Или при наличии «бесплатного отдела программистов» ?

Они блин, даже документацию написать не могут по человечески, не говоря уже про фичи.

Вот где в документации написано, что javascript в момент препроцессинга discovery получает одной строкой ВСЁ, что нашел discovery и пользователю надо разобрать json строку в объект, сделать с ним что надо и собрать опять объект в строку?

какие такие галочки?

ты всегда с перерывом в 10 дней продолжаешь дискуссию? мне вот делать нефиг, рассказывать тебе. я несколько лет проработал _выделенным_ специалистом по заббиксу. мне интересно обсудить его с теми, кто работает с ним сейчас. а ты нафиг никому не интересен.

на случай, если ты решишь сказать, что ты с ним работаешь. ты с ним работаешь, как дежурная мартышка, на которую свалили этот самый заббикс без ее желания. в нормальной ситуации я бы просто тебе сказал: не нравится заббикс - используй другую СМ. но ты ведь не можешь принимать такого решения в своей компании.

Для простоты понимания

какой-то поток сознания. цель сначала формулируй.