LINUX.ORG.RU

Вышел Zabbix 4.2

 , , , ,

Вышел Zabbix 4.2

2

1

Состоялся релиз свободной системы мониторинга с открытым исходным кодом Zabbix 4.2. Zabbix – универсальная система для мониторинга производительности и доступности серверов, инженерного и сетевого оборудования, приложений, баз данных, систем виртуализации, контейнеров, ИТ-сервисов, веб-сервисов.

Система реализует полный цикл от сбора данных, их обработки и преобразования, анализа получаемых данных, и заканчивая хранением этих данных, визуализацией и рассылкой оповещений с использованием правил эскалаций. Также система предоставляет гибкие возможности расширения методов сбора данных и оповещений, а также возможности автоматизации через API. Единый веб-интерфейс реализует централизованное управление конфигурациями мониторинга и распределением прав доступа различным группам пользователей. Код проекта распространяется под лицензией GPLv2.

Zabbix 4.2 - это новая не LTS-версия с коротким сроком официальной поддержки. Для пользователей, которые ориентируются на длинный цикл эксплуатации программных продуктов, рекомендуем использовать LTS версии продукта, такие как 3.0 и 4.0.

Основные улучшения версии 4.2:

  • Доступность официальных пакетов для следующих платформ:
    • RaspberryPi, SUSE Enterprise Linux Server 12
    • MacOS агент
    • MSI сборка Windows agenta
    • Docker образы
  • Мониторинг приложений с помощью высокоэффективного сбора данных из экспортеров Prometheus и встроенной поддержкой PromQL, также поддерживается и низкоуровневое обнаружение
  • Высокочастотный мониторинг для сверхбыстрого обнаружения проблем с помощью тротлинга (throttling). Тротлинг позволяет осуществлять проверки со сверхбольшой частотой, не обрабатывая и не храня при этом огромные объёмы данных
  • Валидация входных данных в предварительной обработке по регулярным выражениям, интервалу значений, JSONPath и XMLPath
  • Управление поведением Zabbix при ошибках в шагах предварительной обработки, появилась возможность игнорирования нового значения, возможность установить значение по умолчанию или задать произвольное сообщение об ошибке
  • Поддержка произвольных алгоритмов для предварительной обработки с использованием языка JavaScript
  • Более простое низкоуровневое обнаружение (LLD) с поддержкой произвольно оформленных данных в формате JSON
  • Экспериментальная поддержка высокоэффективного хранилища TimescaleDB с автоматическим партицированием
  • Простое управление тегами на уровне шаблонов и хостов
  • Эффективное масштабирование нагрузки за счёт поддержки предварительной обработки данных на стороне прокси. В комбинации с тротлингом такой подход позволяет выполнять и обрабатывать миллионы проверок в секунду, не нагружая при этом центральный Zabbix сервер
  • Гибкая авторегистрация устройств с фильтрацией имён устройств по регулярному выражению
  • Возможность управления именами устройств при сетевом обнаружении (network discovery) и получения имени устройства из значения метрики
  • Удобная проверка правильности работы препроцессинга прямо из интерфейса
  • Проверка работоспособности способов оповещения прямо из Веб-интерфейса
  • Удалённых мониторинг внутренних метрик Zabbix сервера и прокси (метрик производительности и работоспособности компонентов Zabbix)
  • Красивые e-mail сообщения, благодаря наличию поддержки формата HTML
  • Поддержка новых макросов в пользовательских URL для лучшей интеграции карт с внешними системами
  • Поддержка анимированных GIF изображений на картах для более заметной визуализации проблем
  • Показываем точное время при наведении мышкой на график
  • Удобный новый фильтр в конфигурации триггеров
  • Возможность массового изменения параметров прототипов метрик
  • Возможность извлечения данных, в том числе токенов авторизации, из заголовков HTTP в веб-мониторинге
  • Zabbix Sender теперь отправляет данные по всем IP адресам из конфигурационного файла агента
  • Правило обнаружения может быть зависимой метрикой
  • Реализован более предсказуемый алгоритм для изменения порядка расположения виджетов в dashboard (панели)

Для перехода с более ранних версий необходима лишь установка новых бинарных файлов (сервера и прокси) и нового интерфейса. Zabbix автоматически проведёт процедуру обновления базы данных. Установка новых агентов не потребуется.

С полным списком всех изменений вы можете ознакомиться в документации.

Статья на Хабре предлагает более подробное описание функциональности.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

Ответ на: комментарий от AlexAT

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

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

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

DRVTiny ★★★★★
()
Последнее исправление: DRVTiny (всего исправлений: 2)

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

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

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

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

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

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

DRVTiny ★★★★★
()
Ответ на: комментарий от DRVTiny

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

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

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

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

crypt ★★★★★
()
Ответ на: комментарий от DRVTiny

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

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

alexvl
() автор топика
Ответ на: комментарий от DRVTiny

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

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

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

alexvl
() автор топика
Ответ на: комментарий от alexvl

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

crypt ★★★★★
()
Ответ на: комментарий от DRVTiny

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

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

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

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

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

AlexAT
()
Ответ на: комментарий от alexvl

Yes!

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

AlexAT
()
Ответ на: комментарий от DRVTiny

А можно с вами без злого умысла помериться всякими 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 «пакует» логи).

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 2)

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

AlexAT
()
Ответ на: комментарий от alexvl

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

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

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

DRVTiny ★★★★★
()
Ответ на: комментарий от alexvl

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

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

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

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

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

DRVTiny ★★★★★
()
Ответ на: комментарий от AlexAT

У нас 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 . Сделал сегодня такой тестовый стенд - вроде работает, нужно будет туда каких-то данных напихать.

DRVTiny ★★★★★
()
Ответ на: комментарий от AlexAT

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

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

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

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

Кусок топа

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

LynxChaus
()
Ответ на: комментарий от DRVTiny

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

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от AlexAT

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

crypt ★★★★★
()
Ответ на: комментарий от alexvl

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

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

crypt ★★★★★
()
Ответ на: комментарий от LynxChaus

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

AlexAT
()
Ответ на: комментарий от crypt

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

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

AlexAT
()
Ответ на: комментарий от crypt

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

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 2)
Ответ на: комментарий от DRVTiny

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

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

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

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

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 3)
Ответ на: комментарий от AlexAT

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

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

LynxChaus
()
Ответ на: комментарий от LynxChaus

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 1)
Ответ на: комментарий от LynxChaus

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

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 2)
Ответ на: комментарий от AlexAT

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

crypt ★★★★★
()
Ответ на: комментарий от crypt

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

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

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 4)
Ответ на: комментарий от AlexAT

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

Ага. Хреновый пример. Любые задержки в сети и все поллеры - раком, а итемов - штук 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_* таблицы данные

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

LynxChaus
()
Ответ на: комментарий от LynxChaus

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

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

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

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

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

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

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

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 6)
Ответ на: комментарий от AlexAT

но я уже вижу

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

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

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

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

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

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

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

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

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

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

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

LynxChaus
()
Ответ на: комментарий от LynxChaus

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

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

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

AlexAT
()
Последнее исправление: AlexAT (всего исправлений: 7)
Ответ на: комментарий от AlexAT

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

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

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

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

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 2)
Ответ на: комментарий от crypt

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

AlexAT
()
Ответ на: комментарий от AlexAT

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

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

LynxChaus
()
Ответ на: комментарий от LynxChaus

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

crypt ★★★★★
()
Ответ на: комментарий от AlexAT

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

crypt ★★★★★
()
Ответ на: комментарий от DRVTiny

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

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

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

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

alexvl
() автор топика
Ответ на: комментарий от crypt

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

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

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

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

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

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

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

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

LynxChaus
()
Последнее исправление: LynxChaus (всего исправлений: 1)
Ответ на: комментарий от LynxChaus

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

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

crypt ★★★★★
()
Ответ на: комментарий от LynxChaus

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

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

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

crypt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.