10 Заметки по обновлению для 3.2.0

Эти заметки относятся к обновлению с Zabbix 3.0.x до Zabbix 3.2.0. Все заметки сгруппированы в:

• Критические - наиболее критическая информация относящаяся к процессу обновления и изменения в функциональности Zabbix
• Информационные - вся оставшаяся информация, описывающая изменения в функциональности Zabbix

Имеется возможность обновления до Zabbix 3.2.0 с версий до 3.0.0. Обратите анимание на раздел процедуры обновления для получения соответствующих сведений об обновлении с предыдущих версий Zabbix.

Критические

Обновление базы данных

В процессе обновления из соответствующих таблиц истории будут удалены поля history_text.id и history_log.id. В зависимости от размеров таблиц истории такая процедура может быть медленной.

Регистрозависимая база данных MySQL

Регистрозависимая база данных MySQL требует для корректной работы сервера. Рекомендуется создавать регистрозависимую базу данных MySQL во время установки. Если вы создали базу данных MySQL с набором символов utf8 изначально, для поддержки регистрозависимых хранимых данных, вам небоходимо сконвертировать c поддержкой collation utf8_bin.

Информационные

Изменения в эскалациях

Отложенные эскалации на время обслуживания

Изменена логика отложенных оповещений о проблемах на время обслуживания.

В предыдущих версиях Zabbix, имелась возможность пропустить оповещения о проблемах на время периода обслуживания узлов сети, если вы использовали условие действия Состояние обслуживания = не в "обслуживании"). В новой версии старый механизм был удален. Вместо него в настройках действия появилась новая опция Приостановить операции во время обслуживания, которая позволяет поставить на паузу оповещения на стадии обслуживания, если вы этого желаете.

Для того, чтобы гарантировать, что эскалации использующие эту возможность работают корректно после обновления, вам необходимо заново настроить соответствующие действия:

• удалить условие Состояние обслуживания = не в "обслуживании"
• убедиться, что в настройках действия выбрано Приостановить операции во время обслуживания

Параллельные эскалации по каждому из множественных ПРОБЛЕМА событий

До Zabbix 3.2 каждое новое ПРОБЛЕМА событие отменяло эскалацию предыдущего ПРОБЛЕМА события, то есть могла выполняться только одна активная эскалация для триггеров с формированием множественных событий. Теперь процедуры эскалаций выполняются по всем таким событиям параллельно. Это изменение и новые функции корреляции событий и теги событий обеспечивают более гибкий подход к решению нескольких ПРОБЛЕМА событий. Например, в зависимости от настройки, теперь OK событие может либо остановить эскалацию конкретного ПРОБЛЕМА события, либо нескольким событиям или по всем событиям.

Операции восстановления

Операции восстановления представляют собой новый способ выполнения скриптов или получения оповещений на решенные проблемы. Ранее, когда проблемные триггеры переходили в ОК, был только один способ выполнения скрипта, а именно настроить действие, с условием 'Значение триггера = OK', чтобы начать эскалацию. Такой способ более не поддерживается - вместо старого способа теперь необходимо использовать действия с операциями восстановления.

В процессе обновления базы данных действия с простыми условиями обновятся автоматически, а действия со сложными условиями будут деактивированы с соответствующим сообщением в журнале. Деактивированные действия необходимо обновить вручную.

Шаги обновления действий, которые выполняются автоматически:

• Сообщения о восстановления перемещаются в операции восстановления;
• Все действия для триггеров и с внутренним типом, которые имеют типы вычисления 'Или' или 'Пользовательское выражение', деактивируются;
• Действия для триггеров, которые могут обрабатывать как ПРОБЛЕМА события, так и ОК события, деактивируются;
• Действия для триггеров, которые могут обрабатывать только ОК события, но имеют сообщение о восстановлении или более одного шага эскалации, деактивируются;
• Внутренние действия, которые могут обрабатывать любое другое событие за исключением тех, которые соответствуют одному условиям Элемент данных в "неподдерживаемом" состоянии, Правило низкоуровневого обнаружения в "неподдерживаемом" состоянии или Триггер в "неизвестном" состоянии, также деактивируются;
• Условие "Значения триггера" для событий на основе триггеров и условие "Тип события" для внутренних событий - Элемент данных в "нормальном" состоянии, Правило низкоуровневого обнаружения в "нормальном" состоянии, Триггер в "нормальном" состоянии удалены из условий - они более не поддерживаются.

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

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

Кодировка соединения с IBM DB2

При подключении к IBM DB2 базе данных Zabbix сервер, прокси веб-интерфейс теперь будут подстраховываться в том, что сервер базы данных ожидает текст в UTF-8 кодировке. Ранее IBM DB2 сервер интерпретировал текстовую информацию от Zabbix полностью полагаясь на настройки локализации (LC_ALL, LANG, LC_CTYPE и другие переменные окружения) Zabbix сервера/прокси или веб-сервера. Если переменные окружения не были настроены должным образом, текст содержащий не-ASCII символы сохранялся в базе данных некорректно. В таких ситуациях, после обновления, не-ASCII символы будут отображаться в Zabbix некорректно. Эта проблема может легко не проявить себя, если локаль была одинаково некорректно настроена для Zabbix сервера и веб-сервера, на котором запущен Zabbix веб-интерфейс, и количество не-ASCII символов было слишком маленьким, чтобы привести к ошибкам "Value too long...". Пожалуйста, проверьте содержимое базы данных перед обновлением.

Проверка данных доступности узлов сети, обнаружения, авторегистрации и истории

Когда Zabbix сервер получал ошибочные данные доступности узлов сети, обнаружения и авторегистрации, он обычно записывал предупреждение в файл журнала по каждой ошибочной записи. Теперь в случае наличия ошибочных записей, будет отбросит весь пакет с данными и запишет в журнал строку наподобии proxy "<proxy name>" at "<proxy IP>" returned invalid host availability data[: <detailed error message>] (для пассивных прокси) или received invalid host availability data from proxy "<proxy name>" at "<proxy IP>": <detailed error message> (для активных прокси). Также, если пассивный прокси например вернет ошибочные данные доступности узлов сети, сервер пропуститобработку данных обнаружения, истории и авторегистрации от этого прокси. Как и прежде, Zabbix будет пытаться обработать как можно больше данных истории от прокси и активных агентов настолько, насколько это возможно, и будет по-тихому игнорировать ошибочные записи. Если весь пакет ошибочен в журнал будет записано сообщение содержащее имя, IP адрес и описание ошибки. Это поможет отследить проблемы настройки, когда поллер прокси подключается к траппер порту сервера или к агенту вместо прокси.

Разное

• Настраиваемый период времени отображения решенных проблем/ОК триггеров и мигание при изменении состояния триггера ограничено 86400 секундами (24 часа) в Администрирование → Общие → Опции отображения триггеров.

Изменения в журналировании

Изменились сообщения записываемые в файлы журналов о завершении синхронизации данных динамики изменения.

Изменились следующие сообщения:

syncing trends data... → syncing trend data...
       syncing trends data done → syncing trend data done

Изменения в элементах данных

Элемент данных system.sw.os[name] может иметь разные значения на Linux системах. Теперь по умолчанию используется PRETTY_NAME параметр из файла /etc/os-release. Только, если os-release не поддерживается системой, тогда для получения имени системы будет использоваться файл /etc/issue.net.

Изменения в вычислении выражений триггеров и вычисляемых элементов данных

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

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

В логических операциях такие неизвестные значения могут превратиться в "известные" значения, например:

• '1 or Неподдерживаемый_элемент_данных1.какая_то_функция()' будет теперь вычислено как '1' (Правда)
• '0 and Неподдерживаемый_элемент_данных1.какая_то_функция()' будет теперь вычислено как '0' (Ложь)

Также функции триггеров nodata(), date(), dayofmonth(), dayofweek(), now() и time() теперь вычисляются также и для неподдерживаемых элементов данных.

Смотрите Выражения с неподдерживаемыми элементами данных и неизвестные значения.

Изменения в графиках после изменения типа данных элемента данных

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

Смотрите также

• Изменения в шаблонах