В новой версии системы мониторинга zabbix (1.6) появилось много разных новшеств. Одно из них — механизм zabbix-прокси. Как следует из названия это такие процессы, которые берут на себя обязанности по опросу zabbix-агентов, сбору с них информации, её хранению и передаче zabbix-серверу. Процессы zabbix-proxy не занимаются обработкой информации, поэтому не отбирают много машинных ресурсов.

Когда можно использовать zabbix-прокси?

• Когда есть сетка за файерволом (а точнее, в адресном пространстве без прямой маршрутизации). Одним из таких случаев является связка “веб сервер — sql сервер”, устанавливаемая на колокейшене. Для экономии и для безопасности довольно часто sql сервер убирают за второй интерфейс веб сервера и мониторить состояние sql сервера напрямую становится сложно (но возможно, о чём ниже).
• Когда есть система территориально распределённых серверов, имеет смысл наиболее удалённые или расположенные за слабыми каналами мониторить не напрямую, а через прокси. В этом случае даже при временном перерыве связи данные мониторинга не потеряются, что позволит иметь как актуальную информаци, так и историю после восстановления связи.

Установка zabbix-прокси

При сборке zabbix (а машину, на которой мы будем ставить прокси, мы ведь тоже будем мониторить, не так ли?) указываем желаемые компоненты: zabbix-proxy, zabbix-agent. Даём следующую команду на конфигурирование:

./configure --enable-agent --enable-proxy --with-sqlite3

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

Так же, как и у сервера, в зависимости от количества агентов, можно использовать разные типы баз данных. Например, если агентов немного (несколько штук), можно использовать sqlite3 (библиотека для организации баз данных в файле). Это не требует специального сервера баз данных и не нагружает дополнительно машину прокси. А если агентов на обслуживании много, то ставьте MySQL, Postgress или даже Oracle 🙂

После конфигурирования приступаем к сборке:

make && make install

Всё, можно настраивать и запускать!

Настройка zabbix-прокси

Так же, как и у агента, для прокси нужно указать IP-адрес опрашивающего сервера. Именно по нему будет производится ограничение доступа. Адрес указывается в конфигурационном файле /etc/zabbix/zabbix_proxy.conf. Здесь же указывается имя прокси-сервера Hostname=. Имя — важный параметр, который впоследствии нам понадобится. Задаём параметры доступа к базе данных (DBHost, DBName, DBUser, DBPassword). Они настраиваются так же, как и на zabbix-сервере. А вот с созданием базы в  есть определённые различия. В руководстве описаны команды по созданию структуры в базе данных. Однако, для sqlite, если процесс zabbix-прокси не находит структуру, он создаёт её сам. Я попробовал создавать всё вручную — процедура эта несложная, и отнимает совсем немного времени. Рассмотрим её на примере базы данных на SQLite:

shell> cd /usr/src/zabbix-1.6.2/create/schema
shell> cat sqlite.sql | sqlite3 /var/lib/sqlite/zabbix.db

Всё, база данных создана! Теперь заводим пользователя zabbix, если его ещё нет в нашей системе:

useradd zabbix

И запускаем прокси:

zabbix_proxy

Анализируя логи, удостоверяемся, что прокси начал свою работу:

15491:20081216:163537 Starting zabbix_proxy. ZABBIX 1.6.1.
15491:20081216:163537 **** Enabled features ****
15491:20081216:163537 SNMP monitoring:        NO
15491:20081216:163537 WEB monitoring:        YES
15491:20081216:163537 ODBC:                   NO
15491:20081216:163537 IPv6 support:           NO
15491:20081216:163537 **************************
15492:20081216:163537 server #1 started [Configuration syncer]
15493:20081216:163537 server #2 started [Datasender]
15494:20081216:163537 server #3 started [Poller. SNMP: NO]
15495:20081216:163537 server #4 started [Poller. SNMP: NO]
15496:20081216:163537 server #5 started [Poller. SNMP: NO]
15497:20081216:163537 server #6 started [Poller. SNMP: NO]
15498:20081216:163537 server #7 started [Poller. SNMP: NO]
15499:20081216:163537 server #8 started [Trapper]
15500:20081216:163537 server #9 started [Trapper]
15501:20081216:163537 server #10 started [Trapper]
15502:20081216:163537 server #11 started [Trapper]
15503:20081216:163537 server #12 started [Trapper]
15504:20081216:163538 server #13 started [ICMP pinger]
15505:20081216:163538 server #14 started [Housekeeper]
15505:20081216:163538 Executing housekeeper
15506:20081216:163538 server #15 started [Poller for unreachable hosts. SNMP: NO]
15507:20081216:163538 server #16 started [HTTP Poller]
15508:20081216:163538 server #17 started [HTTP Poller]
15509:20081216:163538 server #18 started [HTTP Poller]
15505:20081216:163538 Deleted 0 records from history [0.003847 seconds]
15510:20081216:163538 server #19 started [HTTP Poller]
15511:20081216:163538 server #20 started [HTTP Poller]
15512:20081216:163538 server #21 started [Discoverer. SNMP: NO]
15491:20081216:163538 server #0 started [Heartbeat sender]

Теперь регистрируем прокси на сервере. Это можно сделать в разделе Configuration – Hosts – Proxies. Нажимаем кнопку “Create Proxy”, указываем имя (то самое, что задали в конфигурационном файле zabbix_proxy.conf). На этом можно пока расслабиться. И послушать, как вообще работают прокси-сервера.

Работа

Zabbix-прокси опрашивают своих агентов (список агентов им поставляет zabbix-сервер) и принимая от них данные, складывают их в базу. Периодически прокси пытается соединиться со своим сервером. Насколько это ему удаётся, можно увидеть в разделе конфигурации прокси, там где мы его регистрировали. В списке прокси-серверов есть столбец “Last seen (age)” — время последнего сеанса с прокси с сервером. Если прокси настроен правильно и нет проблем с каналом, время это не превышает нескольких секунд. При удачном соединении zabbix-прокси передаёт скопившиеся у него данные агентов. Соответственно, сервер принимает эти данные, заносит в свою базу и при необходимости выставляет нужные триггеры со всеми вытекающими последствиями (действия, оповещения).

Добавим теперь zabbix-агента за прокси. Он добавляется так же, как и обычный агент (Configuration – Hosts – Hosts), с той лишь разницей, что в параметрах задействуется поле “Monitored by proxy”, где выбирается уже заданный нами zabbix-proxy. Естественно, что для успешной работы агент должен быть доступен с прокси (не с сервера!): его DNS-имя должно резолвиться, IP-aдрес пинговаться и порт 10050 не должен быть закрыт фаерволом.

… и несколько дружеских советов напоследок

• Будьте готовы к тому, что изменения в конфигурации (добавление новых айтемов) агентов, находящихся за прокси, вступают в силу не сразу, а через некоторое время (может достигать минут 5-10). И данные по новым параметрам тоже появятся не сразу. Не путайте с изменением значения параметра. Тут, если со связью всё в порядке, изменяется всё вовремя.
• Обратите внимание, что агенты, находящиеся за прокси, в конфигураторе Hosts отображаются не как активные, а как Unknown
• Наверное, это сугубо моё субъективное мнение, но я считаю, что городить прокси из-за одной машины не стоит. Можно попробовать выкрутиться “подручными средствами”, например, с помощью проброса портов DNAT или используя xinetd. Вот примерный конфиг для него /etc/xinetd.d/zabbix:

service zabbix_redirector
{
port = 10052
bind = 172.16.1.130
socket_type = stream
protocol = tcp
user = nobody
redirect = 1.1.1.2 10050
type = UNLISTED
wait = no
only_from = 15.23.7.2
}

Соответственно, с порта 10052 на внешнем адресе 172.16.1.130 проброс будет осуществляться на адрес 1.1.1.2 порт 10050 (стандартный порт zabbix-агента) но для безопасности только для адреса 15.23.7.2.