Вышел Zabbix 3.2

a3be41a935ec4ede96aed0f5702920b3.png

Хотим сообщить о выходе новой версии open source системы мониторинга Zabbix. Релиз несет принципиально новые возможности такие как:

  • Дополнительные поля событий (тэги)
  • Ручное закрытие проблем
  • Корреляцию событий
  • Вложенные группы узлов сети
  • Определение отдельных условий для создания аварий и их восстановления
  • Non-strict расчет триггерных выражений
  • Интерфейс в подгружаемых модулях для репликации исторических данных во внешнее хранилище

…и многое другое. Под катом кратко расскажем о некоторых нововведениях

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

3d3c99fddaab41608d03aae93b0e8c4e.png

А затем снова сможете увидеть их в новом разделе Мониторинг → Проблемы.
Думайте о тэгах как дополнительных полях событий, которые могут быть также использованы для фильтрации при отображении или в условиях автоматических действий (и условиях отправки уведомлений и их эскалаций), и самое главное — они могут быть использованы для корреляции различных аварий.

Корреляция событий
ec572a6ac5dc43e9af7c140e7431ed70.png

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

Глобальная корреляция
cccec627961c4c41ae3a8ac439eaba3a.png

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

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

ed5a69693092419f9e4133043801c708.png

Это упростит как навигацию, так и управление правами доступа внутри Zabbix.

Новый быстрый экран работы с открытыми проблемами
b52d941a78ae4cafa8b7772c95b2ecdd.png

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

Ручное закрытие аварий
b16c2de8525a4240aa8c178b47668bcf.png

Теперь такое возможно и в Zabbix. Убирайте из списка проблем старые или неактуальные события, а также подтверждайте и закрывайте аварийные сообщения о непрошедшем ночью бекапе (после того как починили конечно же) или ознакомившись в критической ошибкой из лог-файла. При этом закрывать можно будет только те проблемы, чьи триггеры были предварительно отмечены соответствующей галкой при настройке в шаблоне.

Упрощенный гистерезис и отдельное условие восстановления аварии
da02d069e1154e27bace66350f2a9f9f.png

Для борьбы с миганием проблем раньше в Zabbix приходилось прибегать к довольно сложным для понимания триггерным выражениям, например к выражению вида:

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

Оно помогало бороться с дребезгом аварии, когда температура колебалась в районе 20 градусов — авария создавалась при 20 градусах, но восстановление происходило лишь после того, как температура падала ниже 15.

Теперь все проще.

00c5bb24ab464d33a6cb2f59b4bd5528.png

Просто отдельное опциональное окошко в настройках триггера, где может быть объявлен критерий окончания аварии:

И все, и больше никакой вывернутой наизнанку логики с {TRIGGER.VALUE}.

Просмотр элементов данных, триггеров и графиков, созданных через LLD
aa4a1b5bac114e52afb5e2b4baa54baf.png

Маленькая, но очень полезная возможность, которой не хватало — возможность манипулировать с объектами, созданными через низкоуровневое обнаружение (LLD) тоже была реализована. Все только что перечисленное теперь можно удалять, отключать и просматривать также как и обычные объекты.

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

Переработанный экран настройки действий
132d050e7cc94686a0cfc4876388dae4.png

Страница настройки действий была переработана. Теперь, все операции, которые нужно совершить при окончании аварии (будь то оповещение или запуск скрипта) настраивается в отдельной вкладке. Здесь же была переработан механизм работы задержки уведомлений от узлов сети, который находятся в режиме обслуживания.

Импорт/экспорт сценариев веб-мониторига
89a269b19f13457dab9522243ffff6bb.png

После добавления возможности импорт/экспорта преобразований значений (value maps) в 3.0 не выгружаемыми оставались веб-сценарии. Сегодня данная несправедливость устранена, и теперь решения по веб-проверкам могут быть также выгружены в XML со всеми шагами для последующей загрузки на другие сервера Zabbix. Ожидаем появления шаблонов веб-мониторинга на share.zabbix.com

Триггерные функции для NOTSUPPORTED элементов данных
Функция nodata () была переработана, чтобы сделать срабатывание триггеров проще в тех случаях, когда элемент данных становится недоступен.

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

Ну, а самое главное, что теперь триггер не будет уходить в состояние UNKNOWN, пока хотя бы одна часть логического ИЛИ может быть проверена. Это позволит комбинировать несколько различных методов сбора данных для одного и того же события (например, через сбор SNMP-счетчиков и чтение лог-файла), или создать агрегированные аварии, не боясь, что они не будут работать из-за недоступности одного из элемента данных.

Работа с быстрорастущими лог-файлами
Добавлены новые опции для работы с быстрорастущими лог-файлами. Основная проблема с такими файлами заключается в огромном количестве сообщений, которые пишутся в лог в определенных ситуациях.

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

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

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

Поддержка regex в функции count ()
fdad368a957a4a368560d8816573d276.png

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

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

Преобразование значения макроса
64eda93130a24cb1851f127c06c43a77.png
Появилась возможность изменить значение макроса, такого как, например, {ITEM.LASTVALUE}. Используя функции regsub и iregsub можно вытащить, например, часть строки из лог-файла и полученный результат использовать в тэгах событий, или в тексте оповещенияПодробнее
Подробнее с этими и другими нововведениями можно познакомиться, пройдя по ссылкам ниже в документацию:
  • Тэги событий
  • Новый экран Мониторинг→Проблемы
  • Ручное закрытие проблем
  • Преобразование значений макросов
  • Работа с быстрорастущими лог-файлами
  • Упрощенный гистерезис и отдельное условие восстановления аварии
  • Настройка действий при восстановлении
  • Правила эскалаций в режиме обслуживания
  • Просмотр элементов данных, триггеров и графиков, созданных через LLD
  • Импорт/экспорт сценариев веб-мониторига
  • Различные улучшения фронтэнда
  • Улучшения процессов Zabbix
  • Новые элементы данных log.count, logrt.count
  • Новые элементы данных VMware
  • Новые функции триггеров
  • Изменения в БД
  • Non-strict расчет триггерных выражений
  • Исторические модули

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

Комментарии (0)

© Habrahabr.ru