Вышел Zabbix 4.2

Отличный релиз, спасибо. Препроцессинг на JavaScript - это то, чего не хватало всё это время. Ну и тротлинг данных наконец-то, объём базы хистори у нас теперь станет намного меньше.

релиз, конечно, хороший. но блин, лор. четвертый релиз хоть как-то комментировали:( а тут тишина. DRVTiny нету:( только какие-то придурковатые комментарии о греп.(

Если что, поддержка TimescaleDB - это просто охренеть, реально прорыв невиданных масштабов, уже ставлю расширение сие и PostgreSQL 11 конечно тоже (раньше у нас всё на MySQL Enterprise было).

Очень хорошо, что теперь можно внутренние метрики работы zabbix смотреть извне, раньше их приходилось извлекать как-то через одно место просто (создавая хост и вешая соотв метрики, что таки да, неудобно в данном случае :))

Зачем нужен препроцессинг в таких объёмах и что за треш такой со встроенным JavaScript (это просто ОМГ, честное слово) - я не знаю, но раз это сделали, значит, это кому-то нужно.

Изменение дефолтной структуры JSON для LLD - непонятно, зачем, но вроде обратную совместимость сохранили, и на том спасибо.

Автообнаружение хостов - вот это просто бомба! Наконец-то, спустя столько лет, zabbix сможет создавать хосты с назначаемым по результатам «проверки» именем (snmp, dns). Я уже давно запилил под это дело костыльный скрипт, а тут такое счастье!

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

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

P.S. К zabbix 4.4 очень жду хоть каких-то положительных изменений в IT Services.

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

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

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

Относительно 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 на выходе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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