Zabbix Agent2: Active Checks, TLS-PSK, autoregistration и шаблоны — практическая настройка

Если поставить Zabbix Agent2 «по умолчанию», он часто работает в самом простом режиме: сервер ходит к агенту (passive checks), шифрования нет, хосты приходится заводить вручную. В небольших стендах это терпимо, но в проде быстро всплывают NAT и фаерволы, динамические IP, требования по безопасности и необходимость массового онбординга.

Ниже соберём практичную схему, которая хорошо живёт на реальных серверах: active checks (агент сам инициирует соединение к серверу/прокси), шифрование TLS-PSK, autoregistration и автоматическая привязка templates. Плюс чек-листы, чтобы быстро диагностировать «не едет».

Ключевая идея: почему Agent2 + active checks + TLS-PSK

Zabbix Agent2 — современный агент с плагинной архитектурой. В типовой инфраструктуре чаще всего удобнее строить мониторинг так, чтобы инициатором соединения был сам хост: тогда не нужно открывать вход на 10050, проще жить с NAT/сегментацией, и значительно легче автоматизировать подключение новых узлов.

Active checks особенно полезны, когда:

• хосты находятся за NAT, в приватных подсетях или в сегментах, где входящие соединения на агент нежелательны;
• вы хотите минимизировать открытые порты на прод-серверах;
• планируется автоподключение через autoregistration и массовое развёртывание (cloud-init/Ansible/образ).

TLS-PSK (Pre-Shared Key) — практичный вариант шифрования и аутентификации без PKI и сертификатов. Он проще в запуске, чем TLS с сертификатами, и закрывает типовые риски «агент стучится не туда» и «подмена точки назначения».

PSK — это секрет. Относитесь к нему как к паролю root или токену: минимальные права на файл, исключение утечек в бэкапы/репозитории, понятная процедура ротации.

Что подготовить до настройки (чек-лист)

Перед тем как править конфиги, пройдитесь по базовым условиям: это экономит часы отладки.

• Версии Zabbix Server/Proxy и Agent2 должны быть совместимы (в пределах одной LTS-линейки обычно всё ровно).
• С хоста с агентом разрешён исходящий доступ до сервера/прокси Zabbix на 10051/tcp.
• Время синхронизировано (chrony/NTP). Для PSK это не так критично, как для сертификатов, но важно для триггеров, корреляции и расследований.
• Определитесь с топологией: агент ходит напрямую в Zabbix Server или в Zabbix Proxy. Для распределённых площадок и больших парков почти всегда удобнее прокси.

Если вы как раз подбираете инфраструктуру под мониторинг (отдельный узел под Zabbix Server/Proxy, БД, фронтенд), чаще всего проще и надёжнее держать это на выделенной виртуалке с прогнозируемыми ресурсами. В таком сценарии удобно смотреть тарифы VDS и заранее заложить запас по CPU/RAM и диску под историю и тренды.

Дополнительно по практичному размещению Zabbix на небольшой виртуалке и типовым компромиссам можно подсмотреть в заметке как разместить мониторинг на небольшом VDS.

Генерация PSK: как сделать правильно

PSK — это произвольная последовательность байт; в Zabbix обычно используют hex-строку. На практике удобно генерировать 32 байта (64 hex-символа) на хост или на группу (если у вас строгая сегментация).

Пример генерации на Linux:

openssl rand -hex 32

Сохраните результат в файл, например /etc/zabbix/zabbix_agent2.psk, и заранее придумайте PSK identity (идентификатор ключа), который будет задан одинаково на агенте и на стороне Zabbix.

Практичный подход к PSK identity:

• делайте его уникальным и предсказуемым по имени хоста, например psk-prod-web-01;
• используйте только латиницу/цифры/дефис/подчёркивание, без пробелов;
• не кладите в identity чувствительные данные (пароли/токены/номера заявок).

Настройка Zabbix Agent2: active checks + TLS-PSK

Дальше предполагаем, что Agent2 установлен, а основной конфиг лежит в /etc/zabbix/zabbix_agent2.conf (путь может отличаться в зависимости от дистрибутива/пакета).

1) Куда агент ходит за активными проверками

Для active checks агенту нужен endpoint Zabbix Server/Proxy на порту 10051. Укажите его в ServerActive:

ServerActive=zbx.example.local:10051

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

Hostname=prod-web-01

Про пассивные проверки: полностью «выключать» их не обязательно. Если вы не хотите принимать входящие на 10050, обычно достаточно закрыть порт фаерволом и не экспонировать его наружу. При этом параметр Server можно ограничить локалхостом, если пассив вообще не нужен:

Server=127.0.0.1

2) Включаем TLS-PSK

Для исходящих соединений (active checks) используется TLSConnect. Для входящих (пассив) — TLSAccept. Если вы оставляете пассивный режим на всякий случай, логичнее сразу включить PSK и там, и там.

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=psk-prod-web-01
TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

Создаём файл и выставляем права (файл должен читаться пользователем сервиса, обычно zabbix):

install -o zabbix -g zabbix -m 0600 /dev/null /etc/zabbix/zabbix_agent2.psk

Записываем PSK (вставьте вашу hex-строку):

printf '%s' 'PASTE_HEX_PSK_HERE' > /etc/zabbix/zabbix_agent2.psk

Быстрая проверка, что файл не пустой:

wc -c /etc/zabbix/zabbix_agent2.psk

Перезапускаем агент и смотрим логи:

systemctl restart zabbix-agent2

systemctl status zabbix-agent2

journalctl -u zabbix-agent2 -n 200 --no-pager

Что должно совпасть на стороне Zabbix (и почему «не едет»)

Самая частая причина, почему active checks не стартуют — несоответствие имени хоста и параметров PSK между агентом и объектом хоста на сервере (или тем, что создаётся через autoregistration).

Убедитесь, что на стороне Zabbix совпадают:

• имя хоста: должно совпасть со значением Hostname (или тем, что возвращает HostnameItem);
• тип шифрования: выбран PSK;
• PSK identity: строка один-в-один равна TLSPSKIdentity;
• PSK: значение ключа один-в-один равно содержимому TLSPSKFile.

Если используется Zabbix Proxy, проверьте, что хост «обслуживается» нужным прокси, и что именно для этого хоста/правила вы задали PSK. Логика простая: агент подключается к прокси, но параметры шифрования всё равно должны быть корректны в конфигурации хоста, который создаётся/существует в Zabbix.

Autoregistration: автоматическое появление хостов

Autoregistration позволяет агентам самим «заявляться» на сервер/прокси, после чего Zabbix применяет правила и выполняет операции: создать хост, добавить в группы, привязать шаблоны, проставить теги и (что важно) выставить шифрование.

Не делайте одно глобальное правило «добавлять всех во всё». Разделяйте правила по окружению и роли, иначе легко получить свалку хостов и шаблонов и непредсказуемые триггеры.

HostMetadata: как маршрутизировать автоподключение

Самый практичный способ маршрутизации — заполнить HostMetadata (или HostMetadataItem, если формируете автоматически):

HostMetadata=role=web,env=prod,os=linux

Далее на стороне Zabbix создайте action для autoregistration с условиями вида «Metadata contains role=web» и операциями «Add host», «Add to host groups», «Link templates». Так вы добьётесь того, что новый сервер появляется в правильном месте и сразу начинает слать данные.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Templates: как не утонуть в шаблонах и зависимостях

Шаблоны решают половину проблем мониторинга, но именно они же часто ломают автоподключение: если хост создался, но на нём нет активных items, агент будет получать «no active checks».

Практичная дисциплина шаблонов:

• Базовый шаблон ОС (CPU/RAM/FS/disk/net) — привязывать всегда.
• Сервисные шаблоны (Nginx, PostgreSQL, Redis и т.д.) — привязывать только по роли/тегам/метаданным.
• Для prod — отдельный шаблон с более строгими триггерами и порогами, чтобы dev/stage не шумели.
• При autoregistration не привязывать «всё подряд»: минимальный базовый набор сначала, расширение — отдельными правилами.

Если у вас кастомные шаблоны, проверьте ключи и типы items: часть старых проверок и UserParameter могла быть написана «под старый агент» и потребует адаптации под Agent2/плагины.

Проверка: active checks действительно работают

Быстрая проверка обычно укладывается в три вопроса:

• есть ли сетевой доступ к ServerActive на 10051;
• совпали ли PSK и identity (TLS-рукопожатие проходит);
• отдаёт ли сервер список активных элементов и отправляет ли агент данные.

На хосте можно посмотреть установившееся исходящее соединение на 10051:

ss -tnp | grep 10051

Главное — логи агента. В норме вы увидите сообщения о получении списка активных проверок и регулярной отправке данных. Сообщение «no active checks» чаще означает не сетевую проблему, а несоответствие имени хоста, шифрования или отсутствие активных items в привязанных шаблонах.

Типовые ошибки и быстрая диагностика

No active checks on server

Обычно означает одно из трёх:

• хост на сервере ещё не существует, а autoregistration не сработал;
• имя хоста не совпало: Hostname у агента отличается от имени хоста в Zabbix;
• хост есть, но ему не назначены items типа Zabbix agent (active) или не привязаны шаблоны с такими items.

Практика: сначала сверяйте имя, затем смотрите, какие шаблоны привязались по action, и есть ли в них активные элементы.

TLS handshake fails / PSK identity not found

Почти всегда это рассинхрон между TLSPSKIdentity и тем, что ожидает Zabbix для данного хоста, либо ключ в файле содержит лишние символы.

• На стороне Zabbix выбран тип шифрования PSK для хоста (или выставляется операцией в autoregistration action).
• Identity совпадает посимвольно.
• PSK совпадает посимвольно.
• Файл TLSPSKFile читается пользователем zabbix и имеет права типа 0600.

Агент подключается, но часть метрик «красная»

Это уже не TLS и не active checks, а прикладной уровень:

• не хватает прав на чтение системных файлов/сокетов (особенно для сервисных шаблонов);
• в контейнерах/изоляции не видны нужные подсистемы и метрики требуют отдельного подхода;
• старые UserParameter не перенесены под Agent2 или требуют включения/настройки плагинов.

Удобный порядок: проверьте базовые элементы (например, доступность агента, uptime), затем раскручивайте конкретный шаблон и его зависимости.

Эксплуатация: хранение PSK и ротация без простоя мониторинга

Самый безопасный вариант — индивидуальный PSK на каждый хост: компрометация одного сервера не раскрывает весь парк. Цена — дисциплина хранения и автоматизация (Ansible, секрет-хранилище).

Если вы используете общий PSK на группу, делайте хотя бы разные ключи для разных окружений (prod/stage/dev) и сегментов (web/db/cache), чтобы ограничить радиус поражения.

Ротация без «падения» мониторинга обычно выглядит так:

1. подготовить новые значения PSK на стороне Zabbix (для конкретного хоста или правила autoregistration);
2. заменить файл ключа на агенте;
3. убедиться по логам и Latest data, что активные проверки идут;
4. удалить/отозвать старые значения и обновить документацию/политику.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Итоговая схема (коротко)

• На агенте заданы ServerActive и Hostname.
• Для шифрования включены TLSConnect=psk и (опционально) TLSAccept=psk.
• Заданы TLSPSKIdentity и TLSPSKFile, файл ключа с правами 0600.
• Указан HostMetadata для маршрутизации autoregistration.
• На стороне Zabbix настроено действие autoregistration: группы, шаблоны, теги, шифрование.
• После регистрации хост сразу начинает отдавать метрики через active checks по защищённому каналу TLS-PSK.

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