В этом разделе представлены новые и обновленные функции Zabbix 4.2.
Теперь имеется возможность применения предобработки значений элементов данных и значений низкоуровневых обнаружений с использованием JavaScript.
Шаг JavaScript принимает один параметр - не пустой блок кода JavaScript.
При нажатии на поле параметра или при нажатии кнопки просмотр/изменение сразу после поля параметра открывается новое окно, в котором можно ввести этот блок кода.
Добавлены новые опции в предобработку значений элементов данных, которые фокусируются на валидации и троттлинге.
Новые опции валидации такие как определение приемлемого диапазона или какого-либо совпадения регулярному выражению позволяют удалить явно некорректные или мешающие значения, которые могут появится, когда, например, счётчик еще не инициализирован (пустой или 'N/A') или сенсор температуры возвращает +999°C, когда он отключен, хотя нормальный диапазон от -100°C до +100°C. Валидация и пользовательская обработка ошибок позволяют отбросить эти мешающие значения или заменить их на какое-либо значение по умолчанию или по-просту заменить их на сообщение об ошибке, текст которой будет понятен пользователю.
Извлечение сообщения об ошибке из поступающих данных это ещё одна новая функция. Например, JSON объект может содержать поле "error". Если это поле существует, тогда процесс предобработки может извлечь значение поля и задать его сообщеним об ошибке самому элементу данных.
Правила троттлинга позволяют обрабатывать значение только, если оно изменилось, тем самым уменьшая количество поступающих данных, когда эти данные, в основной своей массе, неизменны. Например, зависимые элементы данных могут обновляться с меньшей частотой чем основной элемент данных, если в поступающих данных нет изменений. Если основной элемент данных обновляется каждые 10 секунд, зависимый элемент данных может обновляться каждую минуту.
Для получения более подробный сведений смотрите: Предобработка значений элементов данных.
Ранее элемент данных мог стать неподдерживаемым, если какой-либо из шагов предварительной обработки завершался с ошибкой. Теперь к следующим шагам предобработки добавлена опция пользовательской обработки ошибок:
Если вы отметите опцию Другое при ошибке, элемент данных не станет неподдерживаемым в случае ошибки на шаге предобработки и появится возможность указать опцию пользовательской обработки ошибки, например:
По мере добавления новых шагов предобработки элементов данных цепочка процесса предварительной обработки становится более сложной, шанс допустить ошибки возрастает. Чтобы помочь в составлении корректных шагов, Zabbix предоставляет пользователю способ тестирования настроенных шагов предобработки.
Каждый шаг можно протестировать отдельно, как и протестировать все шаги за раз, с использованием новых кнопок Тест или Тест всех шагов в блоке Действия соответственно.
Смотрите также: Тестирование шагов предобработки.
У всех узлов сети, которые наблюдаются через прокси, все элементы данных (включая правила низкоуровневого обнаружения, зависимые элементы данных) предобработка значений будет выполняться на стороне прокси.
Учитывая новые опции предварительной обработки, такие как Javascript, расширенная валидация и троттлинг, предпроцессинг может стать узким местом для сервера, поэтому предобработка на стороне прокси предлагает необходимую масштабируемость. Так как настройка не является настраиваемой, важно помнить о влиянии на производительность - хотя предварительная обработка на стороне прокси полезна для производительности Zabbix сервера, так как данные от прокси не будут более проходить через менеджера предобработки, самим прокси потребуется больше ресурсов .
Это изменение влияет на процесс обновления на Zabbix 4.2. Пожалуйста просмотрите заметки по обновлению.
Ранее, в случае ошибки предварительной обработки, элемент данных мог стать неподдерживаемым, а в сообщении об ошибке указывался номер ошибочного шага предобоработки вместе с описанием ошибки.
Такой информации не всегда было достаточно, так как реальная проблема могла быть на шаге до шага, к котором говорилось в ошибке. Поэтому, теперь сообщение об ошибке дополняется журналом выполненных шагов, в котором сообщается результат или ошибки каждого из шагов предобработки.
Preprocessing failed for: <value>
1. Result (<custom on fail action>): <value>
2. Result (<custom on fail action>): <value>
3. Failed: <error description>
Обратите внимание, если окончательное сообщение об ошибке длиннее 2048 байт, некоторые начальные шаги могут замениться на '...'. Если заголовок плюс описание последней ошибки превышает 2048 символов, сообщение об ошибке будет обрезано.
Правила низкоуровневого обнаружения теперь отделены от процессов сбора данных в свои собственные процессы обработки данных.
Смотрите: Улучшения в демонах.
Для поддержки предобработки результата низкоуровневого обнаружения и пользовательских путей в значениях макросов низкоуровневого обнаружения (LLD) в JSON документе, изменился формат JSON, который возвращается правилами низкоуровневого обнаружения. Более не ожидается, что JSON вернет объект "data":
Низкоуровневое обнаружение теперь принимает обычный JSON, который содержит массив.
Встроенные ключи обнаружения обновлены и теперь возвращают массивы LLD строк корневым JSON документом. Zabbix автоматически извлечёт макрос и значение, если поле массива использует {#МАКРОС} ключом. Любые новые встроенные проверки обнаружения будут использовать новый синтаксис без "data" элементов. При обработке значения низкоуровневого обнаружения сначала определяется корень (массив $.
или $.data
).
Хотя "data" элемент удален со всех встроенных элементов данных, которые относятся к обнаружению, для обратной совместимости Zabbix будет ещё принимать JSON представление с "data" элементами, хотя их использование не рекомендуется. Если JSON содержит объект только с одним "data" элементом массива, тогда этот массив будет автоматически извлечён из содержимого элемента с использованием JSONPath $.data
.
Правило низкоуровневого обнаружения теперь может быть также и зависимым элементом данных, которое зависит от обычного элемента данных. Правило низкоуровневого обнаружения не может зависеть от другого правила низкоуровневого обнаружения.
Для настройки зависимым элементом данных, просто выберите тип Зависимый элемент данных в 'Тип' и укажите основной элемент данных в 'Основной элемент данных' поле в настройках.
В настройках низкоуровневого обнаружения появились дополнительные опции предобработки результата обнаружения и извлечения пользовательских макросов из результата предобработки. Для лучшего понимания изменений в потоке данных обнаружения давайте сравним его с предыдущими версиями:
Версия | Поток данных LLD |
---|---|
До Zabbix 4.2 | Правило обнаружения → Фильтр правила обнаружения |
В Zabbix 4.2 | Правило обнаружения → Предобработка → Пользовательский макрос → Фильтр правила обнаружения |
Важно понимать, что эта логика работает слва направо, так же как и добавление правила: сначала происходит обнаружения, затем, опционально, к нему применяется предобработа, затем можно извлечь пользовательские макросы и, затем к результату применяются условия фильтрации.
Правила низкоуровневого обнаружения теперь имеют шаг предобработки, который содержит следующие опции:
Для получения более подробных сведений смотрите: Предобработка в правилах низкоуровневого обнаружения.
Правила низкоуровневого обнаружения теперь также допускают извлечение пользовательских значений макросов низкоуровневого обнаружения (LLD) с использованием пользовательского пути, указанного в JSONPath синтаксисе.
Теперь можно задать LLD макрос = карта соответствий JSONPath, где каждый макрос задается при помощи пользовательского JSON пути к размещению значения. Значения, на которые указывает заданный JSON путь, используются для замены макросов в полях прототипом элементов данных, триггерах и т.п.
Для получения более подробных сведений смотрите: Пользовательские макросы в правилах низкоуровневого обнаружения.
Интеграция с Prometheus дает возможность мониторинга любого объекта, который предоставляет метрики в линейном Prometheus формате, включая Kubernetes, Docker, GitLab, Ceph, Collectd, etcd, InfluxDB, InfluxDB Telegraf и другие.
Zabbix испльзует HTTP элементы данных для доступа к Prometheus метрикам и, затем использует предобработку, чтобы запросить необходимые значения по этим метрикам.
Смотрите Prometheus проверки.
Начиная с этой версии Zabbix добавлена поддержка базы данных для хранения временных рядом в режиме экспериментальной поддержки TimescaleDB, решения на основе PostgreSQL базы данных для автоматического партиционирования данных на части на основе времени для поддержки большего уровня производительности.
Для миграции существующих PostgreSQL таблиц в TimescaleDB представление доступен скрипт миграции. Для получения более подробных сведений смотрите: Миграция на TimescaleDB.
В настоящий момент TimescaleDB не поддерживается Zabbix прокси.
Ранее имена новых узлов сети, которые добавлялись в результате сетевого обнаружения, использовали либо DNS имя, либо, при его отсутствии, IP адрес. В новой версии появилась возможность давать обнаруженным узлам сети более наглядные имена, используя значения элемента данных обнаружения, собранных либо от Zabbix агент элементов данных, либо от SNMP агент элементов данных:
Zabbix агент или SNMP агент проверки перечислены в опциях именования в новых полях Имя узла сети и Видимое имя, в дополнение к возможности указать именем узла сети DNS имя или IP адрес.
Возможность указывать событиям теги появилась функцией Zabbix начиная с 3.2.0, однако, ранее, назначение тегов ограничивалось отдельными триггерами. В новой версии назначение тегов можно применять на уровнях шаблона и узла сети:
Теги можно задавать на новой вкладке в диалогах настройки шаблона и узла сети, например, у шаблона:
В настройке триггера теги также теперь вынесены на свою собственную вкладку. Кроме того опция Унаследованные и собственные теги позволяет просматривать теги заданные на уровне шаблона (но не на уровне узла сети), если триггер пришёл из этого шаблона:
Событие, когда происходит, наследует все теги со всей цепочки шаблонов, узлов сети, триггеров. При маркировке события совершенно идентичные комбинации тег:значение
сливаются в одну комбинацию, вместо добавления дубликатов.
Смотрите больше о тегах.
Было сделано несколько улучшений в поведении виджетов в режиме редактирования панели:
Теперь имеется поддержка загрузки анимированных GIF изображений для дальнейшего их использования на Zabbix картах. Для поддержки загрузки анимированных GIF минимально требуемая версия GD библиотеки теперь 2.0.28.
Email оповещения можно теперь отправлять в HTML формате. HTML формат позволяет использовать более многофункциональные email сообщения, содержащие цветные шрифты, нажимаемые ссылки, интерактивные элементы, стиль компании и т.д.
HTML формат можно выбрать в опции Формат сообщения при настройке email способом оповещения в Администрирование → Способы оповещений.
Теперь имеется возможность протестировать как работает добавленный способ оповещения. Чтобы это сделать, в списке со способами оповещений нажмите на Тест в последней колонке.
Откроется окно тестирования, где вы сможете ввести адрес получателя в Отправлять на и отправить тестовое сообщение с телом и опциональной темой, нажав на кнопку Тест.
Сообщение об успешности или наличии ошибки отобразится в этом же окне..
Теперь поддерживается совпадение регулярному выражению при настройке условий для действий на авторегистрацию активного агента. Эта возможность поддерживается, если используются операторы совпадает и не совпадает для условий имени узла сети и метаданных узла сети.
Обратите внимание, что операторы содержит и не содержит, которые поддерживались также и ранее, выполняют только поиск подстроки.
Хотя ранее была возможность получения только заголовков, возможность поиска содержимого в них отсутствовала. Теперь также имеется возможность поиска заголовков по совпадению с регулярным выражением, как в переменных, так и в поле требуемой строки.
Кроме того, в шаги веб-мониторинга добавлена опция Режим получения, которая позволяет:
Опция Режим получения заменяет Загружать только заголовки опцию. Таким образом теперь имеется возможность поиска совпадения содержимого только в теле, только в заголовках или в обоих местах.
В этом разделе представлены различные улучшения в веб-интерфейсе:
Теперь также имеется возможность массового обновления прототипов элементов данных, которые используются в правилах низкоуровневого обнаружения. Для обновления нескольких прототипов элементов данных за раз, отметьте эти прототипы и нажмите на Массовое обновление:
Затем обновите свойства, которые вам необходимо обновить, в диалоге массового обновления, который идентичен тому что имеется для обычных элементов данных.
Теперь в списке шаблонов доступно массовое обновление.
В фильтр к списку триггеров добавлены несколько новых опций. Наиболее важные:
Для получения более подробной информации смотрите детали фильтрации триггеров.
Возможность указать в фильтре несколько узлов сети и групп узлов сети, добавленная в фильтре триггеров (см. выше), также доступна и в фильтре элементов данных.
Если ни один узел сети и ни одна группа узлов сети не указаны в фильтре элементов данных, теперь будут отображаться все элементы данных, вместо пустого списка и сообщения о необходимости выбрать что-либо.
Для получения более подробной информации смотрите детали фильтрации элементов данных.
Теперь в подписях к элементам карты сети, именам URL и значениям URL на картах поддерживается больше макросов:
Новое поддерживаемое место на картах | Макрос | |||
---|---|---|---|---|
Элемент узла сети | Элемент группы узлов сети | Элемент триггера | Элемент карты | |
Элемент подписи | Макросы {HOST.ID} ,{INVENTORY.*} |
Макросы {HOSTGROUP.ID} ,{INVENTORY.*} |
Макросы {TRIGGER.ID} ,{INVENTORY.*} |
{MAP.ID} , {MAP.NAME} |
Имя URL | {HOST.ID} |
{HOSTGROUP.ID} |
{TRIGGER.ID} |
{MAP.ID} |
Имя URL и значение | Макросы {HOST.CONN} , {HOST.DNS} , {HOST.HOST} , {HOST.IP} ,{HOST.NAME} ,{INVENTORY.*} |
{HOST.CONN} , {HOST.DNS} , {HOST.HOST} , {HOST.IP} ,{HOST.NAME} ,{INVENTORY.*} |
Макросы {HOST.CONN} , {HOST.DNS} , {HOST.HOST} , {HOST.ID} ,{HOST.IP} ,{HOST.NAME} ,{INVENTORY.*} |
{MAP.NAME} |
Обратите внимание, в этой таблице перечисляются только новые места. Таким образом, хоть {HOST.ID}
, {HOSTGROUP.ID}
, {TRIGGER.ID}
и {MAP.ID}
перечислены поддерживаемыми в именах URL на картах, они ранее уже поддерживались в значениях к URL. Аналогично, большинство макросов {HOST.*} уже поддерживались в подписях к элементам.
Смотрите также: Все поддерживаемые макросы.
Обработка правил низкоуровневого обнаружения отделена от процессов сбора данных в свою собственную обработку правил, которая состоит из настраиваемого количество "worker" низкоуровневого обнаружения и менеджера низкоуровневого обнаружения. Это изменение значительно снижает влияние низкоуровневого обнаружения на сбор данных (процессы поллер и траппер) и общение с прокси (процессы траппер, прокси поллер). Ранее сбор данных мог задерживаться, так как соответствующие процессы сбора данных могли быть заняты обработкой низкоуровневого обнаружения.
Смотрите также: StartLLDProcessors параметр
Zabbix sender теперь использует все адреса для отправки данных, которые указаны в параметре конфигурации ServerActive агента, вместо использования только первой записи. Если отправка на один адрес завершается ошибкой, sender попытается отправить на другие адреса. Если отправка партии данных завершается ошибкой на один из адресов, тогда следующие партии данных не будут отправляться на этот адрес.