Хотим сообщить о выходе новой версии open source системы мониторинга Zabbix. Релиз несет принципиально новые возможности такие как:
- Дополнительные поля событий (тэги)
- Ручное закрытие проблем
- Корреляцию событий
- Вложенные группы узлов сети
- Определение отдельных условий для создания аварий и их восстановления
- Non-strict расчет триггерных выражений
- Интерфейс в подгружаемых модулях для репликации исторических данных во внешнее хранилище
…и многое другое. Под катом кратко расскажем о некоторых нововведениях
Тэги событий
В новой версии появился базис для отображения, фильтрации и других действий над событиями триггеров — тэги. Первый раз вы наткнетесь на них при настройке триггеров:
А затем снова сможете увидеть их в новом разделе Мониторинг -> Проблемы.
Думайте о тэгах как дополнительных полях событий, которые могут быть также использованы для фильтрации при отображении или в условиях автоматических действий (и условиях отправки уведомлений и их эскалаций), и самое главное — они могут быть использованы для корреляции различных аварий.
Корреляция событий
Теперь появилась возможность использовать один элемент данных для отслеживания множества не связанных между собой событий. Уникальным идентификатором в Zabbix будет как раз выступать значение тэга, что позволит соединить вместе Возникновение конкретной проблемы с событием, оповещающим о ее окончании. Так что ничего страшного, если несколько приложений пишут в один лог-файл — аварии каждого приложения будут создаваться и восстанавливаться ничуть не мешая друг другу. Другое полезное применение данного функционала — обработка SNMP-трапов.
Глобальная корреляция
Появилась и возможность связывать между собой события, возникшие из совершенно различных триггеров и даже на различных узлах сети. Новый раздел конфигурации «Корреляция событий» не позволит критической аварии, той самой аварии, что вы хотите увидеть, и требующей действий, утонуть в потоке посыпавшейся симптоматики. Все избыточные поступающие события будут скоррелированы и убраны с глаз долой. И да, это тоже настраивается на основе тэгов.
Вложенные группы узлов сети
Вложенные группы узлов сети позволят создать иерархию объектов мониторинга,
Это упростит как навигацию, так и управление правами доступа внутри Zabbix.
Новый быстрый экран работы с открытыми проблемами
Все текущие и актуальные проблемы теперь доступны в новом разделе Мониторинг-Проблемы (вместо Мониторинг-События). История проблем в базе данных переехала, и в новой версии лежит отдельно от текущих проблем, что дало отличный прирост производительности. Гибкий фильтр даст возможность быстро найти нужную информацию, а таймлайн поможет ориентироваться во времени.
Ручное закрытие аварий
Теперь такое возможно и в Zabbix. Убирайте из списка проблем старые или неактуальные события, а также подтверждайте и закрывайте аварийные сообщения о непрошедшем ночью бекапе ( после того как починили конечно же) или ознакомившись в критической ошибкой из лог-файла. При этом закрывать можно будет только те проблемы, чьи триггеры были предварительно отмечены соответствующей галкой при настройке в шаблоне.
Упрощенный гистерезис и отдельное условие восстановления аварии
Для борьбы с миганием проблем раньше в Zabbix приходилось прибегать к довольно сложным для понимания триггерным выражениям, например к выражению вида:
({TRIGGER.VALUE}=0 and {server:temp.last()}>20) or
({TRIGGER.VALUE}=1 and {server:temp.last()}>15)Оно помогало бороться с дребезгом аварии, когда температура колебалась в районе 20 градусов — авария создавалась при 20 градусах, но восстановление происходило лишь после того, как температура падала ниже 15.
Теперь все проще.
Просто отдельное опциональное окошко в настройках триггера, где может быть объявлен критерий окончания аварии:
И все, и больше никакой вывернутой наизнанку логики с {TRIGGER.VALUE}.
Просмотр элементов данных, триггеров и графиков, созданных через LLD
Маленькая, но очень полезная возможность, которой не хватало — возможность манипулировать с объектами, созданными через низкоуровневое обнаружение(LLD) тоже была реализована. Все только что перечисленное теперь можно удалять, отключать и просматривать также как и обычные объекты.
Думаю, что многим это сэкономит пару кликов мыши при настройке, так как и упростит удаление различного мусора, который мог просочиться через фильтр обнаружения LLD.
Переработанный экран настройки действий
Страница настройки действий была переработана. Теперь, все операции, которые нужно совершить при окончании аварии (будь то оповещение или запуск скрипта) настраивается в отдельной вкладке. Здесь же была переработан механизм работы задержки уведомлений от узлов сети, который находятся в режиме обслуживания.
Импорт/экспорт сценариев веб-мониторига
После добавления возможности импорт/экспорта преобразований значений (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()
Совсем небольшое, но приятное добавление. Функция count() обзавелась возможностью использовать операторов regexp и iregexp для всех типов элементов данных.
Таким образом, теперь возможно подсчитать количество значений, собранных за определенный период времени, которые соответствуют регулярному выражению.
Преобразование значения макроса
Появилась возможность изменить значение макроса, такого как, например, {ITEM.LASTVALUE}. Используя функции regsub и iregsub можно вытащить, например, часть строки из лог-файла и полученный результат использовать в тэгах событий, или в тексте оповещения
Подробнее
Подробнее с этими и другими нововведениями можно познакомиться, пройдя по ссылкам ниже в документацию:
- Тэги событий
- Новый экран Мониторинг->Проблемы
- Ручное закрытие проблем
- Преобразование значений макросов
- Работа с быстрорастущими лог-файлами
- Упрощенный гистерезис и отдельное условие восстановления аварии
- Настройка действий при восстановлении
- Правила эскалаций в режиме обслуживания
- Просмотр элементов данных, триггеров и графиков, созданных через LLD
- Импорт/экспорт сценариев веб-мониторига
- Различные улучшения фронтэнда
- Улучшения процессов Zabbix
- Новые элементы данных log.count, logrt.count
- Новые элементы данных VMware
- Новые функции триггеров
- Изменения в БД
- Non-strict расчет триггерных выражений
- Исторические модули
Версия уже доступна для скачивания здесь. Процедура обновления очень простая, с ней можно ознакомиться здесь. Дополнительные действия могут понадобиться лишь тем, кто используют партицирование в MySQL и PostgreSQL — внесенные изменения в схему в новой версии могут быть не совместимы с текущими настройками разделения таблиц.
Комментарии (51)
banzayats
14.09.2016 14:34+1Отличная новость!
Может подскажете как обновиться с версии 3.0? Пока что в репозитарии что доступна только предыдущая версия:
# yum info zabbix-server-mysql
Installed Packages
Name : zabbix-server-mysql
Arch : x86_64
Version : 3.0.4
Release : 1.el7
Size : 3.3 M
Repo : installed
From repo : zabbix
Summary : Zabbix server for MySQL or MariaDB database
URL : http://www.zabbix.com/
License : GPLv2+
Description : Zabbix server with MySQL or MariaDB database support.
kerberos464
14.09.2016 15:04в репозитории обновления позже выкладывают, обычно надо пару дней подождать.
satter
14.09.2016 17:06при обновлении получил ошибку:
current database version (mandatory/optional): 03010000/03010000
required mandatory version: 03020000
starting automatic database upgrade
[Z3005] query failed: [1091] Can't DROP 'id'; check that column/key exists [alter table history_log drop column id]
database upgrade failed
руками добавил поле в таблицу history_log и перезапустил сервер, дальше он сам справился
alexvl
14.09.2016 17:16Вот похожая ситуация. Или, возможно, используете нестандартную схему базы данных. Например, когда-то удалили колонки 'id' из вышеперечисленных таблиц.
satter
14.09.2016 17:20да, у меня точно так же:
24288:20160914:154628.741 Got signal [signal:15(SIGTERM),sender_pid:24323,sender_uid:0,reason:0]. Exiting…
Gabalino
15.09.2016 11:10Подскажите, как Вы это сделали?
satter
15.09.2016 11:41просто обновил zabbix-release и затем yum update
если речь про добавление стобца, то
alter table history_log add column id bigint(20);
Gabalino
15.09.2016 13:14У меня это поле есть, но БД с партиционированием, вот и не получается
describe history_log;
+------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+-------+
| id | bigint(20) unsigned | NO | MUL | NULL | |
| itemid | bigint(20) unsigned | NO | MUL | NULL | |
| clock | int(11) | NO | | 0 | |
| timestamp | int(11) | NO | | 0 | |
| source | varchar(64) | NO | | | |
| severity | int(11) | NO | | 0 | |
| value | text | NO | | NULL | |
| logeventid | int(11) | NO | | 0 | |
| ns | int(11) | NO | | 0 | |
+------------+---------------------+------+-----+---------+-------+Gabalino
15.09.2016 13:28Не обратил внимания, у меня другая ошибка
[Z3005] query failed: [1091] Can't DROP 'history_log_2'; check that column/key exists [drop index history_log_2 on history_log]
Merlyel
14.09.2016 17:29Про вложенные группы читайте внимательно релизноты и описание тикета — там не всегда все очевидно. Например, узел может быть в подгруппе, но не быть в общей группе
neiroman2k
14.09.2016 18:53+1В русской документации по установке 3.2 из репозитория везде указаны пути к версии 3.0
stanr
14.09.2016 19:30Ссылки и команды в мануале (wiki) на версию 3.2 кривые
Сейчас:
http://repo.zabbix.com/zabbix/3.2/ubuntu/pool/main/z/zabbix/zabbix-release_3.2.0-1+xenial_all.deb
dpkg -i zabbix-release_3.2.0-1+xenial_all.deb
Должно быть:
http://repo.zabbix.com/zabbix/3.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.2-1+xenial_all.deb
dpkg -i zabbix-release_3.2-1+xenial_all.deb
AlexGluck
14.09.2016 22:44Как можно проследить появление такого функционала как параллельная обработка действий? На митапе было обсуждение что alerter однопоточен и при большом количестве уведомлений он не успевает своевременно прогнать все уведомления.
alexvl
15.09.2016 09:08Весьма вероятно, что это сделаем в 3.4. Проблема вот в чём. Не все методы отправки сообщений способны принимать запросы параллельно. Простейший пример — это GSM модемы. Поэтому реализация параллельной обработки действий не такая простая, как может показаться.
Lelik13a
15.09.2016 06:43Спасибо, будем изучать.
Сейчас для Debian Jessie нет *release* пакета с необходимым ключом, когда будет?
И есть ли в планах пакеты сервера для CentOS 6?alexvl
15.09.2016 09:11+2Действительно, пакетов сервера для CentOS 6 нет. Узнаю у коллег в чём тут дело.
alexvl
15.09.2016 14:20Вот что я узнал. Проблема в том, что в CentOS 6 старая неподдерживаемая версия PHP, а может и ещё что. Поэтому нет возможности создать пакеты которые не будут зависимы от сторонних репозиториев. Вот так. Переходите на CentOS 7.
Lelik13a
15.09.2016 17:01Дак в CentOS не проблема поставить нужный php, есть даже соответствующие репозитории (тот же SCL (Red Hat Software Collections)). Можно выпустить пакеты, а зависимости — проблема пользователя.
Перейти на CentOS 7 не всегда возможно.
subvillion
15.09.2016 10:34Эх, web мониторинг снова обошли стороной. Ждал, что можно будет, наконец, выдергивать хотя бы url сбойного шага в оповещении.
AlexeevEugene
16.09.2016 17:46+1Огромное спасибо за продукт! С каждый таким релизом, все чаще посещают мысли о скорой смене монетизации продукта :)
RicoX
На сколько я понял из описания, то в таблицах истории удалили history_text.id и history_log.id, но не пойму каким образом это может повлиять на партицирование?
Пользуясь случаем, хочу спросить, как можно поставить таймаут для SNMP запросов более 30 секунд, дело в том, что при использовании LLD на БРАС, у которых десятки тысяч интерфейсов, SNMP не успевает опросить их все, хотя по фильтру используется на мониторинге менее десятка (остальные не будут добавлены, но все равно опрашиваются при LLD), можно ли поднять этот таймаут чтоб не получать ошибку из-за закончившегося времени на запрос, либо добавить какую-то проверку, что если данные приходят, а не подвисли, то ждать окончания передачи.
alexvl
Дело в том, что процедура обновления создаёт и удаляет некоторые индексы. В зависимости от способа партиционирования это может стать небольшой проблемой.
freejoins
А будет ли решение проблемы апгрейда, для людей использующих партиционирование? Или придется через дамп->восстановление без партиций->обновление до 3.2->дамп->партиционирование->восстановление с партиционированием?
alexvl
Постараемся эту ситуацию описать в документации как можно раньше. Там ничего сложного не будет.