Вышел Zabbix 3.2

в 9:54, , рубрики: monitoring, zabbix, Блог компании Zabbix, Серверное администрирование, системное администрирование

Вышел Zabbix 3.2 - 1

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

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

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

Тэги событий

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

Вышел Zabbix 3.2 - 2

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

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

Вышел Zabbix 3.2 - 3

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

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

Вышел Zabbix 3.2 - 4

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

Вложенные группы узлов сети

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

Вышел Zabbix 3.2 - 5

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

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

Вышел Zabbix 3.2 - 6

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

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

Вышел Zabbix 3.2 - 7

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

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

Вышел Zabbix 3.2 - 8

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

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

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

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

Вышел Zabbix 3.2 - 9

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

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

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

Вышел Zabbix 3.2 - 10

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

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

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

Вышел Zabbix 3.2 - 11

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

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

Вышел Zabbix 3.2 - 12

После добавления возможности импорт/экспорта преобразований значений (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()

Вышел Zabbix 3.2 - 13

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

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

Преобразование значения макроса

Вышел Zabbix 3.2 - 14
Появилась возможность изменить значение макроса, такого как, например, {ITEM.LASTVALUE}. Используя функции regsub и iregsub можно вытащить, например, часть строки из лог-файла и полученный результат использовать в тэгах событий, или в тексте оповещения

Подробнее

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

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

Автор: Zabbix

Источник

Поделиться новостью

* - обязательные к заполнению поля