Как перейти на Zabbix Agent 2 без мифов о скорости

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

Чем Agent 2 отличается от первого агента

Zabbix Agent 2 — отдельная реализация агента, а не волшебная кнопка «ускорить мониторинг». Первый агент написан на C, Agent 2 — на Go с отдельными частями на C. Оба собирают метрики хоста и подключаются к Zabbix Server или Proxy. Поэтому решение о переходе я принимаю по нужным метрикам, поддержке ОС и поведению конкретной нагрузки, а не по номеру поколения в названии.

Главная техническая разница — обработка проверок. Первый агент выполняет активные проверки для одного сервера или прокси последовательно. Agent 2 работает в одном процессе с автоматически создаваемыми потоками; проверки разных плагинов и несколько проверок одного плагина могут идти параллельно. Это не означает, что каждый item получает собственный поток или что график CPU непременно станет ниже. На результат влияют плагины, их лимиты, интервалы опроса, таймауты и сами команды.

У Agent 2 есть собственные плагины для типовых систем, включая Docker, MySQL, PostgreSQL и Redis. Это удобнее, чем поддерживать самодельный сбор данных из десятка скриптов, если нужная метрика уже есть в плагине. У первого агента есть другой путь расширения — пользовательские модули на C. Если инфраструктуре не нужны новые плагины и текущие проверки работают, сам переход может не дать заметной пользы.

В условном примере ООО «Хорда» я сначала сравниваю список проверок, а не обещаю ускорение после замены пакета. Если там важны данные о контейнерах, встроенный Docker-плагин Agent 2 — предметный аргумент. Если задача сводится к стандартным метрикам ОС, переход надо обосновать отдельно.

• Первый агент: активные проверки последовательно
• Agent 2: потоки и плагины
• Docker: встроенный плагин Agent 2
• Скорость зависит от нагрузки и настроек

Когда переход полезен, а когда это просто замена пакета

Я рассматриваю Agent 2, когда нужны поддерживаемые им плагины, параллельная обработка соответствующих проверок или встроенное хранение данных для активных элементов при временной потере связи. Сверяю конкретные item keys и требования плагина с документацией выбранной версии. Название «Docker» само по себе ничего не гарантирует: нужны корректный endpoint, права доступа к нему и подходящий шаблон в Zabbix.

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

Безопасность тоже не аргумент в пользу тезиса «старый агент шифрует только TLS 1.0». Оба агента поддерживают шифрование Zabbix с PSK или сертификатами; доступные версии TLS зависят от криптографической библиотеки и сборки. Сам факт включённого TLS не заменяет проверку настроек на обеих сторонах. Сопоставляйте режим, идентификатор PSK или сертификаты в агенте и сервере/прокси.

Перед обновлением я сверяю совместимость агента с версией сервера по таблице Zabbix. Не скачиваю пакет «самый свежий, потому что свежий»: вендор отдельно описывает, какие сочетания версий совместимы. Также проверяю список поддерживаемых ОС. Для Agent 2 он уже, чем у первого агента, поэтому старый сервер или экзотическая ОС могут быть веской причиной оставить текущий пакет. Самый новый пакет без проверки совместимости — не план обновления, а розыгрыш, где призом будет журнал ошибок.

Что проверить перед миграцией

До установки я записываю версию Zabbix Server/Proxy, дистрибутив и архитектуру узла, версию агента, режимы активных и пассивных проверок, Hostname, адреса Server и ServerActive, пользовательские параметры, подключаемые файлы и настройки TLS. Это короткий инвентарный лист, который обычно экономит больше времени, чем поиск случайного RPM после неудачного обновления.

Для примера с ООО «Хорда» я выбираю один тестовый узел с теми же ролью и ключевыми проверками, что у рабочих машин. В интерфейсе Zabbix завожу для теста отдельное имя узла, чтобы не смешивать данные двух агентов и не получить дублирование активных проверок. На тестовой машине отдельно проверяю системные метрики и только те прикладные метрики, ради которых затеян переход. Никаких процентов ускорения заранее не обещаю: это результат замера, а не свойство названия Agent 2.

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

Отдельно проверяю, как настроен обмен. При пассивных проверках сервер или прокси сам подключается к агенту. При активных проверках агент устанавливает соединение к серверу или прокси. От этого зависят направление правил firewall и то, какую проверку я запускаю после установки. Открывать входящий порт на каждом узле без проверки фактического режима — привычка из серии «пусть будет», которая редко помогает разбору инцидента.

Проверяю также пользовательские модули и параметры, привязанные к старому агенту. В Agent 2 не переносятся некоторые опции старого агента, например LoadModule/LoadModulePath; не совпадает и управление системным пользователем службы. Это не повод отказаться от миграции, но повод заранее найти модули, пользовательские шаблоны и ключи, которые от них зависят. Я отмечаю каждый такой пункт отдельно и ищу штатный плагин или подтверждённую замену. Если элемент не поддерживается в выбранной версии, он не должен молча исчезнуть при удалении старого пакета.

• Сверить версию сервера и агента
• Сохранить конфиг и секреты безопасно
• Проверить активные и пассивные элементы
• Выбрать тестовый узел и отдельное имя

Как установить Agent 2 на Linux

Сначала выбираю дистрибутив, его выпуск, архитектуру и ветку Zabbix в официальном установщике пакетов. Он формирует инструкции для конкретной системы и добавляет репозиторий в штатный менеджер пакетов. Поэтому я не закрепляю в статье ссылку на один файл .deb или .rpm с номером сборки: адрес и имя пакета зависят от ОС, архитектуры и ветки, а случайная замена в URL не превращает пакет в совместимый.

После того как официальный репозиторий настроен, пакет ставится обычным менеджером. Например, для Debian/Ubuntu и RHEL-подобной системы команды установки выглядят так; до этого шага нужно выполнить инструкции репозитория именно для своей ОС:

sudo apt update
sudo apt install zabbix-agent2

sudo dnf install zabbix-agent2

На системах, где пакет устанавливает стандартный unit, запускаю и проверяю службу через systemd. Имя сервиса у Agent 2 — zabbix-agent2. Если менеджер сообщает, что пакет не найден, сначала проверяю подключённый репозиторий и выбранную ветку, а не скачиваю файл с похожим названием с постороннего сайта.

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

В конфигурации Linux-пакета используется /etc/zabbix/zabbix_agent2.conf. Параметр Server задаёт, от каких узлов принимать пассивные подключения; он не заменяет ServerActive. Последний указывает, куда агент обращается за активными проверками. Hostname должен совпадать с именем узла, настроенным во frontend, если имя не задаётся другим способом. Это три разные задачи, и одна строка с адресом сервера их не решает.

Server=192.0.2.10
ServerActive=zabbix.example.net
Hostname=app-01

Адрес 192.0.2.10 здесь из документационного диапазона, а app-01 — условное имя. Сверяю их с карточкой хоста в Zabbix и фактической схемой сети, затем перезапускаю службу после изменения обычных параметров. Проверку установки веду отдельно от проверки шаблонов: запущенный процесс ещё не означает, что сервер получает именно те значения, которые нужны.

TLS, Docker и пользовательские проверки

Для PSK одного параметра TLSConnect недостаточно, если используются оба направления связи. TLSConnect выбирает шифрование исходящих соединений активных проверок, а TLSAccept — шифрование входящих пассивных подключений. В конфигурации также нужны идентификатор и путь к файлу с ключом; соответствующий режим и тот же ключ настраиваются в интерфейсе Zabbix Server или Proxy. Если используются только активные проверки, не включайте пассивный режим по инерции.

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=app-01
TLSPSKFile=/etc/zabbix/agent2.psk

Ключ можно получить криптографическим генератором OpenSSL, например командой openssl rand -hex 32, затем сохранить в файл, доступный агенту и закрытый от постороннего чтения. Не вставляйте PSK в статью, тикет, общий чат или копию конфига без защиты. Я использую отдельный ключ на узел: при компрометации его можно заменить, не меняя общий секрет на всей группе машин.

Docker-плагин Agent 2 умеет собирать контейнерные метрики без самодельной оболочки вокруг docker stats. Но сначала надо проверить endpoint Docker и права агента. Доступ к Docker socket — привилегированный доступ к управляющему интерфейсу Docker; добавлять системного пользователя агента в широкую группу только ради удобства опасно. Выбирайте поддерживаемый способ доступа и выдавайте ровно те права, которые нужны вашей схеме.

Для собственной проверки используется UserParameter в конфигурации агента: ключ item сопоставляется с командой или скриптом. Например, UserParameter=app.health,/usr/local/bin/check-app-health — это описание проверки, а не отдельный каталог с именем UserParameter. Сначала запускаю скрипт от имени системного пользователя агента и убеждаюсь, что он возвращает значение в пределах таймаута. Передавать в такую команду произвольные параметры без проверки — значит самостоятельно создавать дыру в мониторинге.

Agent 2 умеет перечитать параметры UserParameter и Include командой runtime control zabbix_agent2 -R userparameter_reload; это не горячая перезагрузка всего конфига. Для TLS, адресов, портов и других параметров служба должна перечитать конфигурацию при перезапуске. EnableRemoteCommands=1 не включаю ради отладки: удалённое выполнение ограничивают точными правилами AllowKey/DenyKey. В Agent 2 прежний параметр LogRemoteCommands заменён настройкой Plugins.SystemRun.LogRemoteCommands; она включает журналирование, но сама не разрешает system.run.

• TLSConnect: исходящие активные проверки
• TLSAccept: входящие пассивные проверки
• Docker: проверить endpoint и права
• UserParameter: ключ плюс команда

Как проверить результат и переключить узлы

После установки я проверяю сначала локальную работу агента, затем связь с Zabbix и лишь потом итоговые данные на графиках. Локальный тест помогает отделить ошибку item от проблемы сети или TLS. Для пассивной проверки с узла, где установлен zabbix_get, указывают адрес контролируемого хоста, а не адрес Zabbix-сервера: например, zabbix_get -s 192.0.2.20 -p 10050 -k system.uptime. Эта команда уместна только при включённых пассивных проверках и разрешённом доступе к агенту.

Если используются активные проверки, я смотрю, получил ли агент список active checks, совпадает ли Hostname и доступен ли сервер или прокси по исходящему направлению. Для TLS отдельно сверяю PSK identity или сертификат и режим соединения на обеих сторонах. В логах ищу первую ошибку подключения, а не последнюю строку после нескольких неудачных повторов. Открытый порт без совпадающего режима шифрования связи не восстановит.

Дальше сравниваю одинаковые метрики и интервалы: CPU, память, диски, важные прикладные элементы, а для Docker — контейнерные ключи плагина. Сравнение провожу на тестовом узле и за одинаковый рабочий период, отмечаю пропуски и ошибки в Latest data и логах. До получения таких данных фразы «стало на сорок процентов быстрее» или «пропуски упали вдвое» — просто цифры без измерения.

Переключаю узлы постепенно. На первом рабочем хосте проверяю item и триггеры, затем переношу конфигурацию на следующий узел. Старый агент отключаю после подтверждения новых данных, а не сразу после успешного systemctl status. Конфиг и пакет для отката сохраняю до завершения согласованного периода наблюдения. Если новая служба не подключилась, возвращаю прежний пакет и разбираю конкретную ошибку без параллельного изменения нескольких настроек.

У пассивного агента стандартный TCP-порт — 10050; он нужен для входящих подключений сервера или прокси и доступен только с доверенных адресов. Активный агент сам подключается к серверу или прокси, обычно на TCP 10051. Поэтому в firewall разрешаю только нужное направление и только между нужными узлами. Порт 10050 не надо открывать в интернет ради того, чтобы мониторинг заработал.

В случае ООО «Хорда» решение о полном переходе я бы принимал по трем наблюдаемым признакам: тестовые метрики приходят, Docker-проверки показывают ожидаемые контейнеры, журнал не фиксирует ошибок TLS или таймаутов. Если эти условия выполнены и новая функция действительно нужна, перевожу остальные узлы по одному. Если единственный итог — новый пакет с теми же метриками, можно оставить рабочий агент и вернуться к обновлению тогда, когда появится техническая причина.

При разборе отказа я иду от простого к конкретному: состояние службы и журнал systemd, затем DNS/маршрут, выбранный тип проверок, порт и TLS. Если TCP-соединение проходит, но хост в интерфейсе недоступен, проверяю имя узла и режим шифрования. Если узел доступен, но нет одной метрики, сравниваю ключ item с перечнем поддерживаемых Agent 2 и проверяю команду UserParameter отдельно от сетевого обмена. Такой порядок не смешивает сразу несколько причин. Иначе в конфиге уже три «исправления», а никто не помнит, какое из них помогло.

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

Частые вопросы