Kerio Connect под Zabbix 7 без агентов

kerio connect zabbix без агентов: что важно знать перед принятием решения.

Разбираем контекст, ключевые критерии, риски и практические шаги без привязки к шаблонным сценариям.

Связка kerio connect zabbix без агентов до недавнего времени существовала только в виде обрывочных обсуждений на форумах. На официальной странице Zabbix Integrations для Kerio вы найдёте только шаблон для Kerio Control — маршрутизатора, по SNMP. Для почтового сервера Kerio Connect официальной интеграции на этой странице нет — вместо этого предлагается заказать кастомную разработку. Собственная документация вендора (Monitoring Kerio Connect Multi-Server with the Zabbix server) предлагает мониторинг редакции Multi-Server через SNMP и Puppet, но Multi-Server — отдельная редакция и доступна не во всех лицензиях.

Дальше начинается народное творчество. На linux.org.ru, например, лежит ветка, где админы пытаются вытаскивать графики из DAT-файлов Kerio регулярными выражениями — решения, доведённого до рабочего состояния, в ветке нет. SNMP-интерфейс в Kerio Connect не реализован в принципе — это отличие от сестринского продукта Kerio Control, где SNMP есть.

В результате у нас на проектах при внедрении Kerio Connect годами стояла дыра в наблюдаемости на уровне приложения. Сервер падает или забивает очередь — узнаёшь от пользователя. У одного клиента мы получили продолжительный простой SMTP именно потому, что в Zabbix не было ни одного триггера, привязанного к Kerio: антивирусная база сломалась после обновления, входящая очередь росла, и до утренней проверки никто не видел этого.

Основной документированный канал для выгрузки статистики у Kerio Connect — JSON-RPC Admin API на порту 4040. Это тот же интерфейс, через который работает веб-консоль администратора. Он отдаёт структурированный JSON и не требует ни SNMP, ни Puppet, ни доступа к файловой системе сервера. На этом API мы построили собственный набор шаблонов под Zabbix 7 и выложили его в открытый репозиторий IT-for-Prof/zabbix-kerio-connect под лицензией MIT.

По нашему опыту, переход с «никак не мониторим» на «два десятка метрик плюс LLD по сервисам» окупается уже на первом инциденте — обычно это рост очереди после ребута антиспама или зависший IMAP-демон под нагрузкой.

Главный архитектурный принцип шаблона — один опрос API за цикл. Если бы каждая из 24 метрик ходила в Kerio Admin API отдельным запросом, мы получили бы лавину логинов и быстрое исчерпание сессий на стороне Kerio. Вместо этого в шаблоне используется один master item kerio.api.master — все параметры (интервал опроса, таймаут) вынесены в YAML файл шаблона.

Master item за один проход делает четыре вызова JSON-RPC: Statistics.get, Services.get, ProductRegistration.getFullStatus и Server.getVersion. Порядок вызовов виден в preprocessing-скрипте master_collector.js: один Session.login, четыре вызова, один Session.logout. На выходе получается компактный JSON-объект в несколько килобайт, который Zabbix сохраняет как сырое значение master-айтема.

Из этого JSON 24 зависимых айтема вытаскивают конкретные значения через JSONPath — например, для очереди сообщений выражение $.result.statistics.queue.total. Описания всех 24 JSONPath-вытяжек и препроцессоров — в docs/api_fields.md. Часть из них считается через preprocessing CHANGE_PER_SECOND — счётчики в Kerio монотонные, и Zabbix сам преобразует их в скорость. Дополнительно стоит шаг IN_RANGE с широким диапазоном и DISCARD_VALUE: если Kerio после рестарта обнулил счётчик и Zabbix получает отрицательную дельту, IN_RANGE отбрасывает аномалию, не порождая фантомного триггера.

Параллельно работает правило Low-Level Discovery kerio.services.discovery с фильтром EXCLUDE. LLD читает раздел Services.get из того же JSON-блоба, что и master, и для каждого обнаруженного сервиса (SMTP, IMAP, POP3, Submission, LDAP, Webmail, XMPP, антивирус, антиспам и т. д.) создаёт айтем-прототип service.status[#SERVICE]. Логика LLD реализована в отдельном файле src/lld_services.js. Период обновления LLD дольше интервала master-опроса — фиксированное значение см. в YAML. Фильтр EXCLUDE позволяет точечно исключить, например, POP3, если он отключён политикой.

Такая компоновка решает сразу две задачи. Во-первых, нагрузка на Kerio минимальна — один сеанс вместо двух десятков подключений. Во-вторых, при сбое API мы получаем ровно один nodata-триггер на master item, а не лавину однотипных алертов на каждой метрике. На наших проектах эта схема стабильно работает на инсталляциях от 50 до 1500 ящиков без заметной нагрузки на сервер.

Главный сценарий, ради которого мы и собирали этот шаблон, — kerio connect zabbix без агентов. Zabbix 7 умеет тип элемента данных HTTP Agent, который ходит на произвольный HTTPS-эндпоинт прямо со стороны сервера или прокси. На целевую машину с Kerio ставить ничего не нужно: всё, что требуется, — сетевая доступность порта 4040 из Zabbix proxy и аккаунт администратора (точнее, аккаунт с ролью Auditor — об этом ниже).

Минимальная проверка доступности API делается одной командой curl с POST-телом JSON-RPC: метод Session.login, поля userName и password от вашего Auditor-пользователя, плюс блок application с именем клиента. Эндпоинт — https://<kerio>:4040/admin/api/jsonrpc/, флаг -c cookies.txt сохраняет cookie-сессию. Если ответ содержит поле result — шаблон будет работать. Готовая команда для копирования с корректным экранированием — в файле docs/setup.md репозитория.

После успешного логина curl сохранит cookie сессии в cookies.txt. Теми же cookie дальше дёргается Statistics.get — если ответ корректный, Zabbix HTTP Agent точно справится.

Развёртывание шаблона на стороне Zabbix занимает буквально пять шагов: импорт YAML-файла шаблона из репозитория, создание хоста с интерфейсом-«пустышкой» (HTTP Agent его не использует, но Zabbix всё равно требует наличие интерфейса), привязка шаблона, заполнение макросов {$KERIO.URL}, {$KERIO.USER}, {$KERIO.PASSWORD} и проверка master item. Через минуту в Latest Data появятся все 24 значения, ещё через десять — обнаруженные сервисы из LLD.

Особенность HTTP Agent в Zabbix 7 — нативная поддержка сценариев с несколькими запросами через preprocessing-скрипт на JavaScript. Логин, четыре вызова, логаут выполняются внутри одного JS-обработчика master-айтема, и наружу выходит уже склеенный JSON. Это и есть ответ на «как получить статистику kerio без snmp»: HTTPS + JSON-RPC, никаких бинарей на сервере Kerio.

Сам Kerio при этом видит всего одного «логинящегося клиента» раз в минуту от имени учётной записи Auditor. Для аудита безопасности это даже удобнее, чем агент: понятно, кто и зачем ходит.

HTTP Agent покрывает 95 % сценариев, но есть случаи, когда мы переключаем клиентов на второй вариант — Zabbix agent с самописным скриптом-коллектором. Типичные причины: Kerio Connect стоит во внутреннем сегменте без прямого сетевого доступа от Zabbix proxy, политика безопасности запрещает обращения на 4040 извне, или нужно обернуть запрос в дополнительные проверки (например, прогреть TLS-сессию через mTLS-прокси, которого нет в Zabbix HTTP Agent).

Скрипт kerio_collector.py лежит в каталоге src/ репозитория. Он делает ровно то же, что и JS-обработчик master-айтема: один Session.login, четыре вызова Kerio Admin API, один logout, печать собранного JSON в stdout. Zabbix agent с типом элемента UserParameter забирает этот вывод и отдаёт серверу как значение того же kerio.api.master. Дальше всё работает идентично HTTP-варианту: те же 24 зависимых айтема, та же LLD, те же триггеры.

Внутри скрипта стандартный паттерн requests.Session(): первый POST с Session.login сохраняет cookie, затем цикл по четырём методам (Statistics.get, Services.get, ProductRegistration.getFullStatus, Server.getVersion) собирает результаты в один словарь, который печатается как JSON. Полный исходник, примерно 80 строк, — в файле src/kerio_collector.py репозитория.

UserParameter в конфиге агента оформляется одной строкой вида UserParameter=kerio.api.master,/usr/bin/python3 /opt/kerio_collector.py. Таймаут на стороне агента нужно поднять до 30 секунд — иначе тяжёлый Statistics.get иногда не успевает уложиться.

У одного клиента мы вынужденно ушли в этот вариант после того, как ИБ ввела политику «только локальные обращения к 4040». HTTP Agent перестал ходить с прокси, скрипт же стартует прямо на хосте Kerio (под Windows — через Zabbix agent для Windows и python.exe), и трафик не покидает машину. По функциональности результат идентичен, по нагрузке — на ~30 МБ ОЗУ дороже за счёт интерпретатора Python.

Шаблон везёт с собой 7 триггеров верхнего уровня, завязанных на nodata по master-айтему. Плюс к ним за счёт LLD-прототипа добавляется триггер на каждый обнаруженный сервис — на типичной инсталляции их два и получается совокупно девять активных алертов сразу после привязки шаблона.

Корневой триггер — nodata(kerio.api.master, 5m). Если он сработал, это значит, что API Kerio не отвечает, и любые дочерние триггеры формально становятся бессмысленными: данных нет, скорости нет, разбираться в SMTP-очереди не на чем. Поэтому все остальные триггеры в шаблоне объявлены как dependent на этот корневой. Zabbix при подавлении родителя автоматически глушит детей — оператор получает один алерт «Kerio API недоступен», а не семь одновременных «SMTP-очередь не растёт / IMAP-сессии нулевые / антивирус молчит».

Оставшиеся триггеры закрывают типовые проблемы Kerio Connect, которые мы видели в продакшене: рост очереди сообщений выше порога (kerio.queue.total), резкий всплеск ошибок SMTP-аутентификации (kerio.smtp.auth.failures — обычно это брутфорс), отсутствие активности антивируса (kerio.av.scanned не растёт несколько циклов), занятость диска выше критического порога (kerio.disk.pct), uptime меньше суток (свежий перезапуск, иногда нежелательный), статус регистрации продукта и срок лицензии.

Триггеры LLD-прототипов читают значение service.status[#SERVICE] и срабатывают, если сервис не в состоянии running. Они тоже зависят от master, поэтому в момент API-сбоя весь каскад идёт в подавление.

В YAML это записывается через стандартные функции Zabbix: корневой триггер на nodata(/Kerio Connect/kerio.api.master, 5m) = 1 с приоритетом high, дочерние — last(...) > порог с явным depends_on на корневой. Полный список девяти триггеров с порогами и экспрешенами — в файле YAML шаблона в репозитории.

По нашему опыту, наиболее «шумным» оказывается триггер на очередь — он любит ложно срабатывать, если у заказчика идёт массовая рассылка. Мы выводим его за пределы 24/7-нотификации, оставляя в дневном плановом мониторинге, а ночью держим только три критичных: API недоступен, диск > 90 %, ошибки аутентификации более 50 за пять минут.

За время эксплуатации шаблона на разных инсталляциях мы собрали короткий список граблей, на которые наступает каждый, кто пытается мониторить Kerio через JSON-RPC. Если разобрать их заранее, шаблон стартует с первого раза.

Первое — учётка для опроса. Не используйте полноценного администратора, как делают во всех туториалах. Заведите отдельного пользователя и присвойте ему роль Auditor. Эта роль даёт доступ на чтение через Admin API без права что-либо менять, что закрывает риск компрометации Zabbix-сервера. На вопрос  «зачем auditor в kerio admin» ответ простой: это единственная встроенная read-only роль, через которую Statistics.get и Services.get отдают данные. Полные права просто не нужны — на наших проектах это закрытый по аудиту вопрос.

Второе — обнуление счётчиков. Все счётчики в Statistics.get (сообщения SMTP, спам, антивирус, ошибки аутентификации) монотонно растут до перезапуска службы. После рестарта Kerio они стартуют с нуля. Если Zabbix посчитает CHANGE_PER_SECOND между большим предыдущим значением и нулём, он получит огромное отрицательное число. Поэтому в шаблоне после CHANGE_PER_SECOND стоит шаг IN_RANGE: 0–10 000 000. Всё за пределами диапазона отбрасывается, и фантомных пиков на графике не возникает.

Не делайте автоматический рестарт служб Kerio из реакций Zabbix — мы сталкивались с ситуацией, когда нестабильный антивирус «лечился» автоматическим рестартом каждые 15 минут, и Kerio накапливал в очереди десятки тысяч сообщений между перезапусками. Лечение оказалось хуже болезни: симптом гасили, корневая причина (повреждённая база ClamAV) оставалась.

Третье — таймаут 30 секунд. Почему zabbix таймаут 30 секунд именно такой: Statistics.get на крупных инсталляциях (от ~1000 ящиков, большой архив) может отрабатывать 10–15 секунд, особенно сразу после рестарта Kerio, когда кеши холодные. Стандартные 3 секунды Zabbix приведут к гарантированному nodata раз в сутки. Десять — рискованно. Тридцать — с двойным запасом, и при этом master-айтем всё ещё успевает уложиться в минутный интервал опроса.

Четвёртое — TLS. Веб-консоль Kerio по умолчанию использует самоподписанный сертификат. В HTTP Agent отключайте проверку TLS только если сам Kerio стоит во внутреннем сегменте; в открытом контуре лучше подложить корректный сертификат Let’s Encrypt — Kerio это поддерживает штатно.

Шаблон Kerio закрывает только сам почтовый стек. Здоровье операционной системы под Kerio Connect мы всегда довешиваем стандартным OS-шаблоном Zabbix — Linux by Zabbix agent для Linux-инсталляций или Windows by Zabbix agent для Windows. Это не дублирование: метрики операционной системы и метрики приложения дают разный сигнал. Очередь Kerio может расти при свободном CPU (антивирус упёрся в одно ядро), а диск может заполниться при нулевой активности SMTP (логи раздулись).

Из OS-шаблона мы внимательно смотрим четыре группы значений. CPU per-core — Kerio antispam и antivirus однопоточны, и упор в одно ядро прекрасно видно именно в разрезе ядер, а не в среднем по системе. RAM с разделением на used/cached — Kerio любит память под индексы поиска, и «занятая» в общем смысле память может на 60 % быть кешем, который ОС высвободит мгновенно. Дисковая подсистема — обязательно отдельно /var/spool/kerio (или каталог Store на Windows), потому что общий диск может быть на 30 %, а партиция со Store — на 95 %. Сеть — счётчики пакетов и ошибки на интерфейсе, поверх которого ходит SMTP.

Триггеры мы оставляем стандартные, без агрессивного тюнинга: Free disk space is less than 20 %, High CPU utilization (95 % за 15 минут), Lack of free swap space. Дополнительно поднимаем критичность триггера на partition со Store до high — это единственное место, где исчерпание диска моментально валит почту.

Проверка занятости каталога Store на Linux делается одной командой df -h /opt/kerio/mailserver/store плюс du -sh ... с сортировкой по размеру для top-20 крупнейших папок внутри. На Windows этот же подход реализуется через PowerShell с Get-PSDrive и Get-ChildItem ... -Recurse | Sort Length.

На одной инсталляции у нас был опыт, когда OS-шаблон поймал инцидент за двое суток до того, как его увидел бы шаблон Kerio: на сервере росло количество zombie-процессов от kerio-fts (полнотекстовый поисковик), CPU полз вверх по 2 % в день. Сам Kerio при этом работал, очередь не росла, метрики Statistics.get выглядели прилично — и только график system.cpu.util показал тренд. Перезапуск службы решил проблему за две минуты, до того как у пользователей начались тайм-ауты на поиске в IMAP.

Сводно по обоим шаблонам в типичной SMB-инсталляции у нас получается 35–40 активных метрик и 12–15 триггеров — этого достаточно, чтобы закрывать 99 % инцидентов с Kerio Connect без ручных проверок.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на мониторинге высоконагруженных почтовых систем и автоматизации инфраструктуры. Более 10 лет опыта в интеграции Zabbix с проприетарными API.