Zabbix 3.4: URL widgets в дашбордах и пересмотренные официальные шаблоны

Zabbix 3.4 вышел осенью 2017-го, и мы несколько месяцев держали клиентские инсталляции на 3.2, поглядывая что происходит. Не из-за страха перед мажорной версией - просто живая production-инсталляция на несколько сотен хостов это не тот объект, на который хочется накатывать обновление в первые недели. Теперь накатили на три из пяти клиентских стеков под нашим управлением, и есть что рассказать.

Что реально изменилось с точки зрения ежедневной работы

Релизноут у Zabbix всегда длинный, но если фильтровать по «что реально упростит нам жизнь каждую неделю», получается три вещи.

Первое - URL widgets в дашбордах. В 3.2 дашборд состоял из фиксированного набора виджетов: графики, последние значения, карты сети, текстовые блоки. Если хотелось вставить ссылку на внешний ресурс - например, на Grafana с дополнительными дашбордами, или на Kibana с логами этого же хоста - приходилось городить текстовый виджет с HTML-ссылкой. Работало, но выглядело криво. В 3.4 появился отдельный тип виджета: URL. Указываешь адрес, виджет рендерит iframe прямо в дашборде. На практике это значит что дежурная смена видит в одном месте и метрики из Zabbix, и дашборд из Grafana, и при необходимости - ещё что-нибудь, без переключения вкладок.

Второе - переработанные официальные шаблоны. Стандартные шаблоны Zabbix 3.2 были немного стыдным местом: местами устаревшие элементы данных, местами триггеры с захардкоженными порогами которые срабатывали как будто для учебной инсталляции, не для реальной нагрузки. В 3.4 команда Zabbix серьёзно пересмотрела шаблоны для Linux, Windows, network-оборудования. Добавили discovery rules для сетевых интерфейсов, дисков, файловых систем с нормальными прототипами элементов. Убрали часть морально устаревших проверок. На новый хост теперь достаточно повесить шаблон - и через пятнадцать минут discovery отработает, элементы создадутся, триггеры встанут на место. Раньше после стандартного шаблона всё равно приходилось идти и доделывать руками.

Третье - value mapping стало удобнее. Value mapping в Zabbix - это возможность преобразовывать числовое значение в человекочитаемую строку. Классический пример: SNMP-датчик ИБП возвращает 1, 2, 3, 4 для разных состояний батареи, и без маппинга дежурный смотрит в дашборд и не понимает что значит «3». В 3.4 value mappings выделены в отдельный раздел администрирования и стали нормально экспортироваться вместе с шаблоном. В 3.2 при импорте шаблона value mappings часто терялись и их приходилось создавать руками отдельно. Это было мелкой но регулярной точкой раздражения при подключении нового хоста.

Как прошло обновление

Процедура обновления с 3.2 на 3.4 документирована в официальном руководстве и принципиально не отличается от предыдущих мажорных переходов: обновить пакеты, запустить zabbix_server с флагом --foreground первый раз - он сам прогонит миграцию схемы БД. Схема мигрирует онлайн, сервер после этого работает штатно.

На первом стеке прошло без сюрпризов. На втором столкнулись с тем что несколько кастомных шаблонов использовали элементы данных типа «Zabbix aggregate» с синтаксисом который чуть изменился в 3.4 - элементы перестали собираться, в проблемах появились ошибки. Не страшно, но потребовало часа работы на диагностику и правку. Урок: перед обновлением стоит пройтись по кастомным шаблонам и проверить aggregate-выражения.

На третьем стеке обновление шло на инсталляции с PostgreSQL, и там обнаружили что после миграции несколько housekeeping-запросов заметно замедлились. Оказалось - нужно перестроить несколько индексов, которые после ALTER TABLE оказались не в оптимальном состоянии. После REINDEX ситуация выровнялась.

URL widgets: что реально получилось

На одном из клиентских объектов - телеком, несколько площадок - дежурная смена давно жаловалась что для понимания состояния сети нужно смотреть в три разных интерфейса. Zabbix для доступности и триггеров, отдельная Grafana с трафиковыми дашбордами (там InfluxDB от другой команды), внутренняя вики с описанием оборудования. После переезда на 3.4 собрали дашборд где основной экран - карта сети из Zabbix, правый нижний виджет - iframe на Grafana с топ-10 загруженных интерфейсов, третий виджет - URL на вики-страницу с дежурными контактами. Выглядит немного пёстро, но задачу закрыло: один экран для первичной диагностики.

Ограничение URL widget которое сразу бросается в глаза: iframe без аутентификации, то есть внешний ресурс должен быть либо публично доступен в пределах сети, либо аутентификация должна быть на уровне сети. Grafana с анонимным доступом в локальной сети - нормально. Kibana без настроенной аутентификации - тоже. Всё остальное потребует отдельных костылей.

Шаблоны: коротко о главном

Новые официальные шаблоны не решают задачу мониторинга прикладных систем - они по-прежнему про железо и ОС. Но именно эту задачу решают заметно лучше. Template OS Linux в 3.4 включает нормальный discovery файловых систем с фильтрацией по типу (tmpfs и devtmpfs по умолчанию выключены - не надо каждый раз убирать их вручную), discovery сетевых интерфейсов с готовыми прототипами графиков входящего и исходящего трафика, триггеры с макросами вместо захардкоженных значений.

На managed-инфраструктуре подключение нового Linux-хоста с шаблонами 3.2 занимало примерно час включая ручную доводку после стандартного шаблона. С шаблонами 3.4 - минут двадцать, остальное discovery делает само. Не революция, но приятно.

Где стоим

Два оставшихся клиентских стека - один с Zabbix 3.0 (там обновление требует двух шагов: сначала до 3.2, потом до 3.4), второй с нестандартной конфигурацией хранилища - пока ждут. Планируем закрыть в марте.

Zabbix 3.4 не переворачивает подход к мониторингу, но по мелочам стало заметно лучше. URL widgets - удобная штука, value mapping заработал нормально, шаблоны стали ближе к тому что можно использовать без немедленной доработки. Для тех кто сидит на 3.2 - обновляться стоит, серьёзных рисков нет.