Zabbix 1.8 с Zabbix Proxy: мониторинг трёх площадок без боли с NRPE через WAN

Nagios у нас работает не первый год, и в целом претензий немного. Но у одного клиента с тремя площадками - центральный офис, региональный склад и небольшой производственный цех - NRPE через WAN превратился в хроническую головную боль. Каналы нестабильные, особенно в цех идёт VPN через 3G-резервирование, и check_nrpe там периодически вываливает timeout. Nagios честно пишет CRITICAL, мы разбираемся - а хост на самом деле живой, просто пакет не дошёл. Ложные алерты ночью несколько раз уже были.

На Zabbix 1.8 смотрели давно, но повод потрогать серьёзно появился именно сейчас: вышла стабильная версия с поддержкой Zabbix Proxy, и это ровно то, что нужно для распределённых площадок.

Как устроен Zabbix Proxy

Идея простая. На каждой удалённой площадке поднимается лёгкий процесс - Zabbix Proxy. Он сам опрашивает хосты на своём сегменте, складывает данные локально в небольшую БД и пачками отправляет их на центральный Zabbix Server. Канал между площадкой и центром нужен только для синхронизации данных, а не для каждого отдельного check'а.

Разница с NRPE принципиальная. При классическом Nagios каждая проверка - это TCP-соединение от сервера мониторинга до агента. Если канал плохой или пакеты теряются - проверка падает. Zabbix Proxy буферизует: даже если WAN лёг на пару минут, данные за этот период сохранятся локально и уедут на сервер, когда канал поднимется. История не рвётся.

Что развернули

На каждую площадку поставили Ubuntu Server (благо только что вышла 10.04 LTS, удобный момент) с Zabbix Proxy 1.8 и SQLite в качестве локального хранилища. SQLite здесь оправдан - объём данных небольшой, отдельный сервер БД на удалённой точке был бы избыточен.

На хосты поставили zabbix-agent. На Windows-серверах это тот же агент, только собранный под Win32, - устанавливается как служба, конфигурируется через zabbix_agentd.conf. По сравнению с возней с NSClient++ и allow_arguments разница ощутимая: агент Zabbix по умолчанию умеет то, что нам нужно, без включения небезопасных опций вручную.

Центральный Zabbix Server поднят на отдельной машине в центральном офисе с MySQL. Веб-интерфейс работает на Apache с PHP.

Конфигурация проксирования

В конфиге прокси главное - два параметра:

• Server - адрес центрального Zabbix Server, куда проксируем данные.
• Hostname - уникальное имя прокси, под которым он будет зарегистрирован на сервере.

В веб-интерфейсе Zabbix Server прокси добавляется в Administration - DM (Distributed Monitoring), там же видно время последней синхронизации и задержку. Хосты площадки привязываются к конкретному прокси - и всё, сервер больше не ходит к ним напрямую.

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

Что с API

Zabbix 1.8 привёз переработанный JSON-RPC API. Мы пока не интегрировались с внешними системами, но покрутили его руками - создание хостов, получение данных последних значений, управление тригерами. API адекватный, документация в wiki есть, хотя местами неполная. Для автоматизации добавления хостов через скрипт при вводе нового сервера в эксплуатацию это выглядит рабочим вариантом.

Что не понравилось

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

Второе - шаблоны. Концепция шаблонов в Zabbix мощная, но стандартные шаблоны из коробки покрывают не всё. Шаблон для Windows пришлось дорабатывать под нужные нам счётчики производительности. Не драма, но время потратили.

Третье - веб-интерфейс. Работает, но местами медленнее, чем хотелось бы, особенно на экранах с большим количеством хостов и графиков.

Промежуточный итог

На три площадки с нестабильными каналами Zabbix Proxy подошёл лучше, чем Nagios с NRPE. Ложных алертов из-за потери пакетов стало значительно меньше - а это главное, ради чего затевали переезд. На стабильных каналах разница была бы менее очевидной, и, честно говоря, менять работающий Nagios ради смены ради смены не стоит.

Для сопровождения инфраструктуры с географически распределёнными точками - вариант, который стоит рассматривать всерьёз.