Вышел Zabbix 3.0

Долгожданная версия открытой системы мониторинга Zabbix обещает нам целый ворох новых возможностей, вставая на путь визуального обновления.
Сегодня хочу поделиться с вами тем, что принес релиз, и чем можно начать пользоваться уже сегодня, скачав новую версию с сайта. Мы также будем рады пригласить всех желающих на Zabbix Meetup в Москве, подробности о котором вы найдете в конце статьи.
afea9580809c4eb88f79b1b5418b8fc3.png
Первое, что бросается в глаза — это освежевший веб-интерфейс. Новый дизайн избавился от лишних, нагромождавших элементов, ушли различные ненужные рамки графиков и так далее.

141e25e761d54563afb5c4ea8ee249f5.png

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

5c4617d81d004f5aba24494066dcf721.png

Про остальные изменения интерфейса можно почитать тут.


Теперь Zabbix поддерживает шифрование всех сообщений при необходимости — все общение между сервером, прокси и агентом может быть зашифровано и защищено от посторонних любопытных глаз.
Шифрование также предоставляет и аутентификацию — только при наличии доверенного сертификата или Pre-shared ключа компоненты смогут пообщаться с Zabbix. Аутентификация при этом взаимная, то есть не только Zabbix Server проверяет сертификат агента, но и агент может быть настроен проверять сертификат сервера: кто его выпустил и можно ли им верить.

f14d6441ae16477bbcf3596a862bc865.png

Шифрование при этом полностью опционально, и может быть настроено для каждого компонента отдельно (то есть одни агенты и прокси могут использовать шифрование, а другие продолжать общаться в открытую как и ранее)

569f8ad88e1a488cb3a9cf9d6702980f.png

Если шифрование Вам не нужно или Вы к нему морально не готовы, то просто используйте Zabbix как и прежде (взяв в оборот другие новые возможности конечно! :)) При этом все компоненты 3.0 будут поддерживать шифрование, и его можно будет постепенно включать для отдельных компонентов в удобном для себя темпе:).
И никаких новых портов — как и раньше 10050/10051 используются для всех видов коммуникаций в Zabbix.
Все подробности про шифрование в Zabbix здесь.


Предвидеть проблему до того, как она произойдет? — Теперь да, в Zabbix 3.0.
Говорят, что в 2016 на дисках все еще кончается место иногда. Zabbix может предвидеть такую ситуацию и спасти приложение от падения, предупредив всех заранее и дав время добавить или освободить места как раз до того, как начнутся проблемы.
Просто посмотрите пример, где Zabbix предсказывает, как быстро закончится место на /home, проанализировав исторические значения за последнее время.

2a350e7252a94496a8c59b0ec7c0dc4d.png

Допустим, что нам нужно 10 часов, чтобы отреагировать и добавить или почистить место (как на скриншоте выше). И допустим, что 1 часа собранных данных о свободном месте достаточно, чтобы сделать корректный прогноз. Реальная проблема для нас, когда место на разделе / (vfs.fs.size[/, free]) полностью закончится, т.е. 0 байт. Тогда Zabbix должен поднять аварию, когда прогноз на 10 часов вперед, основанный на собранных данных за предыдущий 1 час будет равен 0, или:

{host:vfs.fs.size[/,free].forecast(1h,,10h)}<=0


или можно поменять местами горизонт прогнозирования (10h) и пороговое значение (0 байт) и использовать другую триггерную функцию:

{host:vfs.fs.size[/,free].timeleft(1h,,0)}<=10h


Статистический анализ под капотом этих функций один и тот же, так что просто выбирайте выражение, которое удобнее.

Узнать про прогнозирование в Zabbix можно здесь и здесь.


Новый элемент данных proc.cpu.util, доступный на Linux и Solaris, позволяет мониторить использование CPU каждым отдельным процессом или группой процессов.
Например, администратору сервера может быть интересно контролировать, как используют CPU различные пользователи. При помощи ключа:

proc.cpu.util[,john]


он сможет увидеть использование CPU всеми процессами, запущенными под john’ом. А если вдруг интересна только java Джона:

proc.cpu.util[java,john]


Кроме имени пользователя и процесса можно и указывать тип утилизации CPU (system, user), имя процесса с путем и другие параметры.
Полную спецификацию можно найти тут.

f9cf2713be2b4c79b391231f81e97db6.png

34ede37c37e64639aaba96c97c34a63c.png


History cache


В 3.0 не забыли и об оптимизации производительности. Например, был серьезно переработан кэш исторических данных (History Cache). Благодаря переработке структуры кэш работает быстро при любом соотношении items/values, даже если всего несколько элементов данных заполняют сервер большим количеством исторических значений.
Индекс (History index) был добавлен, чтобы следить за этим кэшем. Контролировать его можно используя новый внутренний счетчик zabbix[wcache, index,]

f4de6c972f7942378db1a5a2ad011669.png

Например, на графике наглядно видно сколько происходила обработка восемью history syncers 500000 значений для 100 элементов данных до 3.0 и после.
Подробнее по этой и другим внутренним проверкам здесь.

Action cache


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

959393a71e9a46fdacba3812b4844fa4.png


Если что-то было достаточно проверять один раз в день, то невозможно было выбрать точное время. Проверка могла произойти и ночью и в обед, и на это никак нельзя было повлиять.
Ну, а теперь можно.
Например, если нужно собирать данные с офисных компьютеров, то просто выставите расписание сбора с 9 до 6 в будни:

1cbab327496343d8a914e05e44e201e0.png

что позволит нам избежать ненужных аварий о недоступности выключенных компьютеров ночью.
В примере выше проверки будут происходить каждые пять минут (m/5) только в рабочие дни (wd1–5) с 8 до 18 (h9–18), то есть в 9:00, 9:05, 9:10 и так далее.

eec82b4562984f02b0567cc71803fe90.png

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


В Zabbix появились личные карты, комплексные экраны (screens) и слайды.
Это позволяет каждому пользователю создавать свои собственные представления информации, которые будут ему удобны. И админские права совсем не нужны.
При этом картой или экраном можно легко поделиться, сделав его доступным всем пользователям, или только членам определенной группы:

158a0a1d45cf4583b3bec2204a2250ae.png

Интересно? больше здесь.


Давным-давно люди спрашивали про возможность использования макросов низкоуровневого обнаружения (LLD) в названии в группах элементов данных? Да, теперь пожалуйста и это — прототипы групп элементов данных (Applications) теперь доступны наравне с прототипами элементов данных, триггеров, графиков и комплексных экранов.
Например, для сетевых интерфейсов:

058fd09cf9194e1c8963999cd426e7cb.png


Процедура очистки базы данных необходима для удаления старых исторических данных. Если удалить нужно действительно много, то потребуется действительно много системных ресурсов, что может негативно сказаться на остальных процессах Zabbix, которые заняты чем-то поважней и полезней.
В 3.0 добавлена возможность отменить запуск процедуры очистки по расписанию и запускать её вручную, когда это необходимо. Новая возможность поддерживается как Zabbix прокси так и Zabbix сервером. Чтобы воспользоваться ею, необходимо отключить в конфиг-файле исполнение очистки по расписанию:

HousekeepingFrequency=0


И затем очистку базы данных возможно запускать через командную строку:

zabbix_server -R housekeeper_execute


Про выполнение этой и других административных функций (runtime-control) из командной строки читайте тут.
Основные Zabbix процессы теперь могут быть запущены не только как демоны, если использовать ключ -f (--foreground). Кроме других преимуществ это, например, может быть полезно при использовании компонент Zabbix в Docker.
Зависимости между триггерами, которые позволяют получить только одну аварию от роутера, вместо десятка аварий от устройств, которые расположены за ним — в Zabbix уже довольно давно. Но, к сожалению, это не работало для прототипов триггеров. Опять же, в 3.0 это ограничение уходит. Это позволит, например, создавать группу триггеров из прототипов, которые имеют разные пороговые значения и уровень важности (предупреждение и авария) при мониторинге количества свободного места на диске:

dca19ed018114efd8780865faed1226a.png

9484913ce7254b50ab8c16dc981e489b.png

Подробности найдутся тут.

58d141d28d5d47c9b39d062365354d57.png

Те, кто мониторят Windows сервера через Zabbix, должны оценить следующее нововведение — возможность находить все доступные службы в Windows через ключ LLD service.discovery, и создавать для каждой новой службы элементы данных и триггеры. Найденные службы также всегда можно отфильтровать через стандартный механизм фильтров, который есть в низкоуровневом обнаружении.

a66a6e3a03ee4552ba3908223b6a997e.png

89f241ca690647bcbb96d7cd732706cd.png

Подробнее как это настроить можно посмотреть опять таки в обновленной документации по LLD.


Свершилось! Теперь можно делать рассылку уведомлений просто и без проблем: через интерфейс Zabbix настраиваете подключение к почтовому серверу с использованием логина пароля, а также шифрование, если нужно. Больше никаких дополнительных postfix в режиме smarthost или непонимающих взглядов от админа почтовых серверов, кого вы просили разрешать с IP Zabbix сервера слать почту анонимно.

ea1a09f83ee640d881b9787ddeb02f0d.png

Подробнее тут.


Повзрослели и шаблоны. Теперь при загрузке/выгрузке в XML они включают в себя все используемые преобразования значений (value mappings). Загружать /выгружать преобразования можно и отдельно. А еще загрузить value mappings теперь можно и через API.

f6ae54fd97e24b97a9852c67e7bb00a7.png


Появилась отличная возможность принимать решение об обнаружении по SNMP на основе не одного, а нескольких OID.
Например, для интерфейсов мы можем искать сразу ifName, ifAlias, ifDescr и ifOperStatus:

discovery[{#SNMPVALUE},ifOperStatus,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFNAME},1.3.6.1.2.1.31.1.1.1.1,{#IFDESCR},.1.3.6.1.2.1.2.2.1.2,{#IFTYPE},ifType]


И если в описании прототипа триггера указать, например, вот такой список:

Last Discovery Interface info:
ifAlias:{#IFALIAS}
ifName:{#IFNAME}
ifDescr:{#IFDESCR}
ifType:{#IFTYPE}


то при аварии по триггеру мы сможем увидеть подробное описание порта.

a06eb48d9ca449979b0730f53a013e58.png

Можно использовать значения дополнительных OID и в фильтрах LLD, для принятия решения ставить интерфейс на мониторинг или нет, а также использовать значения в названии триггеров, графиков и элементов данных. Или как было сказано выше в названии групп элементов данных (Applications).
Подробнее читайте в обновленном мануале по LLD.


Zabbix 3.0 предлагает более 50 новых возможностей для изучения, со всеми, что не попали в эту статью, такими как API для trends или добавление дополнительных параметров для пользовательских скриптов оповещения можно ознакомиться в релизе здесь.
Приглашаем всех попробовать обновленную систему Zabbix уже сегодня и поделиться с нами своими впечатлениями в сети или лично на Zabbix meetup в Москве, который состоится 12 марта 2016 года, в 11:00, по адресу метро Трубная, Цветной Бульвар, 2. Регистрация на митап будет доступа через две недели.

© Habrahabr.ru