Table of Contents

5 Что нового в Zabbix 3.2.0

5 Что нового в Zabbix 3.2.0

5.1 Корреляция событий

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

Например, в мониторинге журнала вы столкнулись со строками аналогично этим:

Строка1: Приложение 1 остановлено
       Строка2: Приложение 2 остановлено
       Строка3: Приложение 1 перезапущено
       Строка4: Приложение 2 перезапущено

При наличии корреляции событий вы можете совместить проблемное событие из Строки1 к решению в Строке3 и проблемное событие из Строки2 к решению в Строке4 и закрыть эти проблемы по одной:

Строка1: Приложение 1 остановлено
       Строка3: Приложение 1 перезапущено #проблема из Строки1 закрыта
       
       Строка2: Приложение 2 остановлено
       Строка4: Приложение 2 перезапущено #проблема из Строки2 закрыта

Для получения более подробной информации смотрите раздел корреляция событий.

5.2 Теги событий для большей гибкости

В новой версии добавлены пользовательские теги событий. Пользовательские теги событий реализованы как пара из имя тега и значение. Вы можете использовать только имя или вместе со значением.

Эти теги указываются в конфигурации триггера - для триггеров, шаблонных триггеров и прототипов триггеров.

После того, как теги указаны на уровне триггера, соответствующие события маркируются с данными тега.

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

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

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

Для получения более подробной информации смотрите раздел теги событий.

5.3 Более очевидный просмотр проблем

Раздел мониторинга веб-интерфейса Zabbix получил новую отдельную страницу, называемую "Проблемы". Этот раздел используется только для отображения проблем и находится сразу после Мониторинг → ПАНЕЛЬ. Новый раздел предназначен для того, чтобы дать пользователям более очевидный просмотр проблем по сравнению с двумя разделами Мониторинг → Триггеры и Мониторинг → События, которые использовались для этих целей ранее.

Параллельно с добавлением новой страницы, из веб-интерфейса удалена страница Мониторинг → События. Для доступа к деталям событий используйте новый раздел для проблем.

5.4 Ручное закрытие проблем

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

Для получения более подробной информации смотрите: Ручное закрытие проблем.

5.5 Возможность индивидуализации значений макросов

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

regsub - извлечение подстроки по совпадению регулярного выражения (без учета регистра)
iregsub - извлечение подстроки по совпадению регулярного выражения (с учетом регистра)

Эти функции макросов поддерживают значениями макросов {ITEM.VALUE} и {ITEM.LASTVALUE} в именах триггеров, описании триггеров, тегах событий, темах оповещений и в сообщениях оповещений.

Для получения более подробной информации смотрите раздел функции макросов.

5.6 Вложенное представление групп узлов сети

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

Вложенное представление групп узлов сети осуществляется при помощи прямой косой черты '/' для разделения логических уровней групп узлов сети.

Для получения более подробной информации смотрите: Настройка группы узлов сети

Обратите внимание, что функционал вложенных групп узлов сети расширен с Zabbix 3.2.2.

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

5.7 Работа с быстро растущими файлами журналов

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

Для решения этих вопросов имеются два важных улучшения:

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

log.count и logrt.count - два новых элемента данных агента, которые подсчитывают количество совпадающих строк и возвращают полученное число вместо самих строк.

5.8 Более простой гистерезис триггеров

Гистерезис триггеров полезная опция как для избежания "flapping" триггера (слишком частое переключение между проблемой и ОК), так и в ситуациях, когда вам требуется диапазон между значением проблемы и значением ОК. Несмотря на то, что создать триггер с гистерезисом можно было и в предыдущих версиях Zabbix＾используя макрос {TRIGGER.VALUE}, полученное выражение было не самым простым для понимания:

({TRIGGER.VALUE}=0 and {server:temp.last()}>20) or
       ({TRIGGER.VALUE}=1 and {server:temp.last()}>15)

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

Также существует более полный контроль над тем, как будут генерироваться ОК события. Вы можете использовать выражение проблемы как основу (тогда поведение будет таким же как и ранее), выражение восстановления как основу, или даже выбрать 'Нет' в этом случае триггер всегда будет оставаться в состоянии проблема, если он перейдёт в состояние проблема.

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

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

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

Получать оповещения в Zabbix о восстановлении проблемы стало проще. Если ранее можно было слегка запутаться в концепции специального "Сообщения о восстановлении" или возможности создания полной эскалации, когда проблемные триггеры переходили в ОК, теперь всё это объединено в один концепт "Операция восстановления".

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

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

Обратите внимание, что некоторые условия действий были совсем удалены вместе с этой разработкой:

Условия "Значение триггера" для событий по триггерам
Условия "Тип события" для внутренних событий - Элемент данных в "нормальном" состоянии, Правило низкоуровневого обнаружения в "нормальном" состоянии, Триггер в "нормальном" состоянии

Для получения более подробной информации смотрите:

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

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

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

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

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

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

5.11 Возможность просмотра элементов данных, триггеров, графиков созданных при помощи LLD

Объекты, созданные низкоуровневым обнаружением (элементы данных, триггеры, графики), в предыдущих версиях Zabbix были только перечислены. Было невозможно просмотреть их детали или применить к ним массовые операции, такие как активация/деактивация или удаление.

Теперь эти объекты отображаются более удобным для пользователей способом. Имеется возможность просматривать детали таких элементов данных, триггеров и графиков. Флажки позволяют применять массовые операции к таких объектам. Таким образом их можно активировать/деактивировать/удалить.

	Элементы данных созданные низкоуровневым обнаружением до 3.2.0.
	Элементы данных созданные низкоуровневым обнаружением в 3.2.0.

5.12 Импорт/экспорт веб-сценариев

При экспорте узлов сети или шаблонов в XML, веб-сценарии теперь также экспортируются. При импорте узлов сети/шаблонов имеются опции для создания новых, обновления существующих и удаления пропущенных веб-сценариев.

Теперь вы можете легко и быстро обмениваться веб-сценариями на share.zabbix.com. Например, экспортировать шаблон с веб-сценарием в XML и загрузить в share.zabbix.com. Затем другие могут скачать шаблон и импортировать этот XML в Zabbix.

5.13 Улучшения в веб-интерфейсе

5.13.1 Удалено подтверждение событий ОК

Из экрана подтверждения был удален отдельный вариант подтверждения ОК событий вместе с проблемными событиями. Теперь имеется возможность подтверждения только событий о проблемах с выбором подтверждения одного или всех проблемных событий триггера(ов).

5.13.2 Несколько новых фильтров

5.13.2.1 Фильтрация по имени

Группы узлов сети, шаблоны и глобальные скрипты теперь можно искать по имени в:

Настройка → Группы узлов сети
Настройка → Шаблоны
Администрирование → Скрипты

5.13.2.2 Фильтрация по имени и состоянию

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

Настройка → Обслуживания
Настройка → Действия
Настройка → Обнаружения
Администрирование → Прокси
Администрирование → Группы пользователей
Администрирование → Пользователи
Администрирование → Способы оповещения

5.13.3 Обновленные переводы

Китайский (Китай)
Чешский
Английский (Соединенные Штаты Америки)
Французский
Грузинский
Немецкий
Итальянский
Японский
Корейский
Польский
Португальский (Бразилия)
Русский
Словацкий
Испанский
Турецкий
Украинский

5.14 Изменения/улучшения в демонах

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

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

5.14.2 Параметры конфигурации

Гибкие параметры ключей элементов данных для алиасов в конфигурации агента

Параметр Alias в файле конфигурации Zabbix агента теперь поддерживает передачу гибких параметров ключей. К примеру, теперь имеется возможность задать алиас с шаблоном в качестве параметра (alias[*]) и использовать при настройке элемента данных, указывая требуемые корректные параметры ключа как обычно (например, alias[all,avg5]). Другим приемуществом подобной гибкости является то, что сейчас имеется возможность задавать в ключе любые параметры, которые изначально не поддерживаются параметрами. В этом случае заданные параметры будут игнорироваться и будет обрабатываться оригинальный ключ. Такой метод можно использовать при настройке нескольких правил низкоуровневого обнаружения по одному элементу данных.

5.15 Изменения/улучшения в элементах данных

log.count и logrt.count - для мониторинга журналов, добавлены два новых элемента данных вместе с параметром 'максзадержка'. Для получения более подробной информации смотрите: Работа с быстро растущими файлами журналов.

5.16 Улучшения в VMware мониторинге

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

vmware.hv.datacenter.name[<url>,<uuid>]
vmware.vm.datacenter.name[<url>,<uuid>]

В ключи элементов данных vmware.hv.discovery и vmware.vm.discovery, которые используются для обнаружения гипервизора и виртуальных машин, добавлен макрос {#DATACENTER.NAME}.

5.17 Функции триггеров

Функция count() теперь поддерживает операторы regexp и iregexp по всем типам элементам данных. Теперь имеется возможность подсчитывать значения совпадающие с регулярным выражением (обычным или глобальным), собранные за указанный период времени.

Несколько функций теперь вычисляются также и для неподдерживаемых элементов данных:

nodata()
date()
dayofmonth()
dayofweek()
now()
time()

Однако, узел сети и элемент данных должны быть активированы как и ранее.

5.18 Неподдерживаемые элементы данных и неизвестные значения в триггерах/вычисляемых элементах данных

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

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

Польза - логические ИЛИ и И выражения вычисляются, если возможно, с известными значениями. Например:

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

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

5.19 Различные улучшения

5.19.1 Изменения в базе данных

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

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

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

Documentation