Zabbix Agent: active/passive checks и безопасная установка

Zabbix Agent устанавливается на наблюдаемый узел и получает локальные сведения об ОС, ресурсах, процессах, службах и приложениях. Но сам факт установки пакета не создает полезный мониторинг. Нужно выбрать модель связи, правильно сопоставить Hostname, ограничить доверенные стороны, защитить канал, подключить подходящий шаблон и проверить, что события приводят к действиям.

Эта статья посвящена подключению узлов к уже существующему Zabbix. Установка Zabbix Server, базы данных, web-интерфейса и проектирование высокой доступности являются отдельными задачами.

Компоненты и их роли

Пассивные и активные проверки

Один агент может использовать оба режима для разных items. Выбор задается не только параметрами файла конфигурации, но и типом item в Zabbix. Если шаблон содержит пассивные items, одного ServerActive недостаточно.

Для узла за firewall активные проверки часто проще: входящее соединение к агенту не требуется. Однако нужно контролировать, куда агент отправляет данные, как подтверждается его идентичность и сколько значений удерживается при временной недоступности приемника.

Параметры, которые чаще всего путают

Для активного агента Hostname является частью протокола сопоставления. Если в frontend создан host srv-1, а агент отправляет SRV-1.example.local, сервер не начнет принимать значения только потому, что IP совпадает.

Когда нужен Zabbix Proxy

• в филиале несколько узлов и не хочется открывать каждый из них центральному серверу;
• канал периодически пропадает, но данные нужно буферизовать локально;
• проверки должны выполняться изнутри площадки;
• центральный server находится далеко и прямой опрос создает лишнюю задержку;
• нужно разделить нагрузку сбора между площадками;
• сетевая политика разрешает один контролируемый канал между proxy и server.

Proxy не является невидимым транспортом. Его база, очередь, процессы, диск, время и связь с server должны мониториться. Отказ proxy способен скрыть целую площадку, поэтому центральная система должна отличать проблему proxy от одновременной аварии всех узлов за ним.

Защита канала

Zabbix поддерживает TLS с сертификатами или pre-shared key. PSK проще для небольшого числа управляемых узлов, но требует уникальной идентичности, случайного ключа, защищенного хранения и процедуры ротации. Один PSK на всех клиентах превращает компрометацию одного узла в общий риск.

• не передавайте PSK в заявках, чатах и открытых конфигурационных репозиториях;
• ограничивайте права на файл ключа учетной записью агента;
• не используйте один и тот же PSK для независимых клиентов;
• проверяйте обе стороны: что агент принимает нужный тип соединения, а host в frontend настроен соответственно;
• при выводе узла из эксплуатации отзывайте его идентичность и ключ;
• если применяется PKI, контролируйте срок сертификата, цепочку доверия и процедуру перевыпуска.

Шифрование канала не заменяет firewall и минимальные права агента. Не нужно публиковать агент в интернет только потому, что включен TLS.

Права процесса и пользовательские параметры

Агент должен работать с минимальными правами, достаточными для выбранных items. UserParameter, system.run и удаленные команды расширяют возможности, но одновременно увеличивают риск. Их нельзя включать глобально ради одной проверки.

Проверка мониторинга должна быть безопаснее наблюдаемого сервиса. Скрипт, который ради метрики меняет данные или создает административную сессию, требует отдельного пересмотра.

Шаблон нужно адаптировать, а не просто привязать

1. Сверить версию Zabbix и совместимость шаблона.
2. Проверить discovery rules: какие файловые системы, интерфейсы и службы будут обнаружены.
3. Установить macro для емкости, задержек и исключений по фактической роли узла.
4. Отключить items, которые не имеют владельца или действия.
5. Добавить проверки бизнес-сервиса поверх метрик ОС.
6. Настроить зависимости, чтобы отказ proxy или гипервизора не создавал лавину событий.
7. Проверить maintenance для плановых работ.
8. Зафиксировать локальные изменения шаблона и способ обновления.

Зеленый host может быть бесполезным, если контролируются только CPU и память. Для файлового сервера важны доступность SMB, место, задержки диска, backup и критичные события. Для базы - соединение, состояние службы, очередь, блокировки и пользовательский тест.

Установка пакета: почему нет одной вечной команды

Название пакета, Agent или Agent 2, официальный репозиторий, service name и пути зависят от версии Zabbix и дистрибутива. Перед установкой нужно открыть актуальную инструкцию Zabbix, выбрать поддерживаемую ветку и конкретную ОС. Пакет из базового репозитория дистрибутива может отличаться от версии сервера и нужного шаблона.

Команды ниже оставлены как безопасный каркас для тестового стенда Ubuntu/Debian-like: обновление индекса, установка агента, резервная копия конфигурации, ручное редактирование и запуск службы. Они не открывают firewall и не задают вымышленные ключи. Для production используйте точные команды из официальной документации выбранной версии.

Как проверить подключение

1. Сверить Hostname в конфигурации агента и Host name в frontend.
2. Проверить время на agent, proxy и server.
3. Посмотреть журнал агента сразу после запуска.
4. Для пассивной модели проверить маршрут и соединение только от назначенного server/proxy.
5. Для активной модели убедиться, что агент получил список active checks и отправляет значения нужному приемнику.
6. Открыть Latest data и проверить свежесть нескольких разных items.
7. Создать безопасное тестовое условие, например низкий тестовый порог, и проверить событие, уведомление и recovery.
8. Перезапустить агент и убедиться, что конфигурация поднимается автоматически.
9. Кратковременно разорвать допустимый тестовый канал и проверить буферизацию/событие по архитектуре.
10. Задокументировать версию, template, proxy, тип соединения и владельца реакции.

Типовые ошибки

• открыть порт агента для любой сети;
• указать только ServerActive при шаблоне с пассивными items;
• перепутать Host name и Visible name;
• назначить host центральному server, а агент отправлять на proxy;
• включить незашифрованный канал через недоверенную сеть;
• использовать общий PSK для всех клиентов;
• запустить агент с root/Administrator ради одного нестандартного item;
• подключить большой шаблон и не разобрать лавину unsupported items;
• не мониторить proxy и сам Zabbix Server;
• считать появление зеленого индикатора завершенной приемкой.

Официальная документация Zabbix

• Agent: активные и пассивные проверки
• Zabbix Proxy и распределенный сбор
• TLS с pre-shared keys
• Установка из пакетов

Для общего выбора платформы смотрите сравнение систем мониторинга. Эта инструкция предполагает, что Zabbix уже выбран и нужно безопасно включить узлы в эксплуатацию.

Итог: подключение агента считается завершенным, когда выбран активный или пассивный путь, идентичность совпадает, канал ограничен и защищен, шаблон соответствует роли, тестовое событие прошло полный цикл, а состояние агента и proxy тоже наблюдается.

# Примерный каркас для тестового стенда Ubuntu/Debian.
# Для production всегда сверяйте репозиторий и версии с официальной документацией Zabbix.

sudo apt update
sudo apt install -y zabbix-agent

sudo cp /etc/zabbix/zabbix_agentd.conf /etc/zabbix/zabbix_agentd.conf.backup
sudoedit /etc/zabbix/zabbix_agentd.conf

# Минимальные параметры, которые нужно указать в конфиге:
# Server=<ip_zabbix_server>
# ServerActive=<ip_zabbix_server>
# Hostname=<unique_host_name>

sudo systemctl enable --now zabbix-agent
sudo systemctl status zabbix-agent --no-pager