Zabbix 2.4: обновились с 2.2, привязали systemd через UserParameter

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

Граф-просмотрщик стал заметно удобнее

В 2.2 с графиками была одна постоянная мелкая боль: чтобы посмотреть несколько метрик за разные периоды, нужно было либо открывать несколько вкладок, либо каждый раз перерисовывать один и тот же граф. В 2.4 переработали просмотрщик графов - теперь можно выделять период прямо на графике мышкой и зумиться в него, а кнопки для перемотки назад/вперёд появились прямо над графиком без перехода на другую страницу.

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

Value mapping: наконец-то нормально

Value mapping в Zabbix был и раньше, но в 2.4 его переработали в интерфейсе - теперь маппинги проще создавать и привязывать к элементам данных через шаблоны. Суть простая: item возвращает число, а в интерфейсе показывается человекочитаемое значение. Классика - статус сервиса: 0 значит Down, 1 значит Up, 2 значит Unknown.

Мы использовали это несколько по-другому: у одного клиента мониторится статус железных компонентов через SNMP, и железо возвращает коды из своей внутренней документации - что-то вроде 4 = degraded, 5 = failed, 6 = recovering. Без value mapping в интерфейсе было просто число, и на дашборде у дежурного красовался триггер с «значение = 5» без объяснений что это значит. Теперь там написано «failed» и сразу понятно о чём речь.

Мониторинг systemd-юнитов: залатали давний пробел

С переходом части клиентских серверов на CentOS 7 и работой с systemd у нас повис вопрос: как нормально мониторить состояние юнитов в Zabbix. Встроенного item-типа для systemctl is-active в Zabbix нет - это не Windows Services с готовым шаблоном, тут нужен свой подход.

Решение через UserParameter оказалось прямолинейным. В конфиг агента на клиентской стороне добавляется строка вида:

UserParameter=systemd.unit.status[*],systemctl is-active $1 | grep -c '^active$'

Логика проста: systemctl is-active возвращает строку active если юнит работает и что-то другое (inactive, failed, activating) если нет. grep -c '^active$' превращает это в 1 или 0 - число, которое Zabbix умеет проверять триггером.

В Zabbix добавляется item с ключом systemd.unit.status[nginx] или systemd.unit.status[postgresql-9.3] - и дальше обычный триггер: если значение равно 0, значит юнит не активен. Value mapping сразу к делу: 1 = Running, 0 = Not running.

Одна особенность, на которую наткнулись: systemctl is-active на юнит, которого вообще не существует (опечатка в имени), тоже возвращает ненулевой exit code, но строку unknown. В нашей схеме с grep -c это тоже даст 0 - то есть несуществующий юнит неотличим от упавшего. Обходим тем, что при добавлении нового мониторинга сначала руками проверяем что юнит вообще есть на сервере, а не доверяем Zabbix обнаруживать опечатки.

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

Пара слов про обновление с 2.2

Обновление само по себе прошло без неожиданностей - стандартный путь через репозиторий zabbix.com, обновление пакетов, zabbix_server сам прогоняет миграцию схемы базы данных при первом запуске. Рекомендуем делать дамп базы перед обновлением, хотя за всё время ни разу не пригодился - просто гигиена.

Из реально важного: в 2.4 изменилось поведение некоторых встроенных проверок агента - стоит после обновления агентов пройтись по шаблонам и убедиться что значения всё ещё имеют смысл. У нас на одном шаблоне слетел item для мониторинга сетевых интерфейсов - возвращал 0 вместо реального трафика. Оказалось, изменился формат ключа net.if.in для некоторых версий агента. Починили за 10 минут, но без проверки могли бы не заметить несколько дней.

Где сейчас

На обновлённом Zabbix 2.4 сейчас работает мониторинг всех клиентов из управляемой инфраструктуры. Мониторинг systemd-юнитов через UserParameter раскатали на все серверы с CentOS 7 - покрыли критичные сервисы: nginx, postgresql, приложения клиентов. Видимость стала лучше: раньше нужно было идти на сервер и руками проверять systemctl status, теперь это триггер в Zabbix как любой другой.

Следующее что хочется - автоматическое добавление проверок при появлении нового юнита через LLD. Но это задача на потом, когда разберёмся с текущими приоритетами.