PatchMon: мониторинг обновлений парка Linux-серверов на своём сервере

PatchMon мониторинг обновлений Linux-серверов ведёт централизованно: это self-hosted платформа корпоративного уровня для смешанных парков серверов. Инструмент предоставляет единую панель управления состоянием пакетов через лёгких агентов, которые передают данные исходящими соединениями без открытия входящих портов на защищаемых хостах.

Вместо ручного перебора систем через SSH решение агрегирует данные о доступных обновлениях для apt, dnf, yum и других менеджеров пакетов в реальном времени.

PatchMon — self-hosted платформа корпоративного класса для мониторинга обновлений и безопасности парка Linux-серверов, с поддержкой агентов FreeBSD и Windows. Это не сканер уязвимостей и не система раскатки конфигураций, а «единая панель», которая отвечает на один вопрос: какие пакеты и на каких хостах отстают от репозитория прямо сейчас.

Для парка Linux-серверов это закрывает боль, знакомую любому админу: инвентарь пакетов живёт в голове, а не в системе. Когда серверов 10, помнить, где сидит устаревший openssl и где не обновлён ядерный linux-image, ещё реально. Когда их 50+, ручной обход через apt list --upgradable или dnf check-update по SSH превращается в регулярную рутину, в которой легко пропустить отдельный хост — а пропущенный хост и остаётся уязвимым.

PatchMon решает это через лёгкий агент, который сам ходит на сервер по расписанию и отчитывается о состоянии пакетов. Один и тот же агент и панель управления работают с Linux (apt, dnf, yum, apk, pacman), FreeBSD (pkg) и Windows — редкий случай, когда смешанный парк не требует держать три разные системы мониторинга.

Ценность такой платформы удобно измерять не «красотой дашборда», а временем ответа на конкретный запрос: «покажи все хосты, где не обновлён sudo». В PatchMon это один фильтр в UI, в самописной инвентаризации на Ansible-фактах — отдельный playbook и его прогон по парку.

Проект живой: репозиторий на GitHub собрал несколько тысяч звёзд и активно развивается.

PatchMon честно называет себя платформой видимости, а не автоматизации: он показывает, что нужно обновить, но раскаткой занимаетесь вы — руками, Ansible или скриптом. Этот угол разобран ниже: заменять им Ansible смысла нет, а дополнять — стоит.

PatchMon разворачивается через Docker — это рекомендованный способ быстрого старта, а сам сервер поставляется как один Go-бинарник с встроенным React-фронтендом в единственном контейнере, без Node runtime на этапе развёртывания — это заявлено в README проекта отдельным пунктом «Single binary, bundled UI». Именно из-за этой упаковки развёртывание сводится к паре команд, а не к бэклогу «поставить Node, поднять nginx, подключить БД» — достаточно Docker Compose и одного файла окружения.

Быстрый старт из README PatchMon сводится к скачиванию установочного скрипта Docker и его запуску (полная процедура и параметры — в официальной документации PatchMon):

PatchMon отличается от Ansible, Zabbix и Open-AudIT архитектурой outbound-only агента без входящих портов на хостах и упаковкой сервера в один контейнер с бинарником и UI внутри. Это не «ещё один мониторинг», а узкоспециализированный инструмент, и путать его с соседями по стеку — распространённая ошибка при выборе.

Ansible — это движок исполнения задач, а не система наблюдения. Playbook apt upgrade умеет обновить парк, но не отвечает на вопрос «что было доступно вчера и что появилось сегодня» без внешнего хранилища состояний. Дашборд обновлений можно собрать на ansible-facts + ELK, но это отдельный проект со своей настройкой и сопровождением. PatchMon даёт эту функциональность из коробки, а Ansible остаётся там, где он сильнее — в раскатке.

Zabbix — универсальный мониторинг метрик и состояний. Через шаблоны для apt/dnf он тоже умеет показывать доступные обновления, но каждый пакет-элемент превращается в отдельный item, дашборд быстро распухает, а группировка «покажи все хосты с уязвимым sudo» требует ручных запросов. PatchMon изначально спроектирован под сущность «пакет × хост», а не «метрика × время», поэтому те же вопросы решаются проще. Zabbix при этом продолжает следить за CPU, диском, сервисами; PatchMon отвечает за пакеты.

Open-AudIT ближе всего по нише — это инвентаризация железа и ПО. Но он собирает срез «что установлено», а не «что отстаёт от репозитория» с фокусом на пакетном менеджере. Плюс Open-AudIT традиционно тянет за собой PHP-стек и MySQL, тогда как PatchMon — один контейнер, который проще держать в актуальном состоянии.

Отдельно про сеть: PatchMon поддерживает apt, dnf, yum, apk и pacman на Linux, а также pkg на FreeBSD и Windows одним и тем же агентом и панелью управления. У Ansible это отдельные модули, у Zabbix — отдельные шаблоны, у Open-AudIT — отдельные коллекторы. Для смешанного парка это принципиальная разница в трудозатратах на поддержку.

Практический вывод: patchmon мониторинг обновлений linux не отменяет ни Ansible, ни Zabbix — он снимает с них ту задачу, для которой они не оптимизированы, и делает её дешевле в поддержке.

Для интеграций у PatchMon есть REST API /api/v1 с JWT-аутентификацией и документацией Swagger/OpenAPI, а также отдельный Integration API — так заявлено в README проекта. Связка с Zabbix и тикет-системой строится вокруг того, что агент ходит только исходящими соединениями — источник событий один: сам сервер PatchMon, а не десятки хостов. Это упрощает архитектуру: не нужно настраивать сбор алертов с каждой ноды, достаточно подключить одну систему к одной шине.

Практичная схема для аутсорсинга — треугольник PatchMon → Zabbix → тикет-система. PatchMon держит источник истины «какие обновления доступны и где». Zabbix отвечает за расписание проверки и триггеры (например, «критические обновления доступны более 7 дней»). Тикет-система принимает готовую задачу на обновление с привязкой к конкретному хосту и списку пакетов.

Связку с Zabbix удобно делать внешней проверкой: небольшой скрипт на управляющем узле опрашивает API сервера PatchMon и отдаёт Zabbix метрику вида «количество критических обновлений на хост X». Дальше — обычная логика триггеров Zabbix, которую администратор уже знает: пороги, зависимости, тихие часы. Никакой магии, но и никакой параллельной системы алертов, которую нужно отдельно сопровождать.

Фрагмент Zabbix-шаблона с внешней проверкой. Для импорта шаблону нужны ещё version, uuid и группы, а скрипт patchmon.pending должен лежать в каталоге ExternalScripts Zabbix-сервера:

PatchMon мониторинг обновлений Linux в аутсорсинге упрощает именно тем, что агент ходит исходящими соединениями на сервер PatchMon — не нужно открывать входящие порты в клиентских сетях, договариваться про VPN или пробивать корпоративные фаерволы. Для аутсорсинга это ключевое архитектурное отличие от схемы на Ansible.

Сервер PatchMon удобно держать в инфраструктуре подрядчика, а не у клиента. Так решается вопрос доступа: инженер дежурной смены видит все клиентские парки в одной панели и не переключается между десятком VPN-подключений.

Хосты удобно делить по клиентам через теги и группы. Это принципиально: без чёткой тегизации через месяц дашборд превращается в свалку из 50+ строк, где невозможно понять, чей веб-сервер отстаёт. Схема простая: client:<name>, env:<prod|stage>, role:<web|db|app>. Дальше любой отчёт — «показать все prod-БД клиента X с отсутствующими критическими обновлениями» — становится вопросом одного фильтра.

Расписание проверок имеет смысл разносить по клиентам: для критичных систем — чаще, для внутренних систем малого бизнеса — реже. PatchMon позволяет задавать расписание опроса на агенте; разнесённое расписание не создаёт одновременного пика исходящих соединений от всех хостов — это и полосу экономит, и сервер разгружает.

Не полагайтесь только на дашборд: раз в неделю полезно сверять список хостов из PatchMon со списком хостов из CMDB. Расхождения ловят типовую проблему: агент упал после ребута и не поднялся, либо новый сервер добавили в парк, но забыли поставить агента. Без этой сверки такие хосты пропадают из радара молча.

Из данных PatchMon удобно собирать для клиента ежемесячный отчёт: сколько обновлений было доступно, сколько установлено в SLA-окне, сколько отложено с обоснованием. Это тот случай, когда self-hosted инструмент напрямую конвертируется в отчётность — и в вопрос «за что мы платим аутсорсеру» получает конкретный ответ.

PatchMon не только показывает, что нужно обновить, но и ставит обновления сам: по README в нём есть пробный прогон (dry-run) с планом пакетной транзакции, установка после одобрения в один клик и политики запуска — сразу, в окно обслуживания или с отложенной раскаткой. В README проект честно позиционируется как «единая панель для мониторинга, патчинга и защиты парка», но сложную оркестрацию — волны, проверки сервисов, автоматический откат — README не описывает, и здесь он не заменяет корпоративные системы вроде Red Hat Satellite, Canonical Landscape или связки Ansible AWX + собственные политики.

Первое ограничение — сложная оркестрация. Установку по одобрению и по расписанию PatchMon выполняет сам, но если нужно раскатить обновление на 200 хостов волнами по 20 машин с автоматическим откатом при падении сервиса — такого в README нет, это работа для Ansible, Salt или Satellite.

Второе ограничение — согласование. В корпоративной среде обновление — это change management: заявка, окно, откат-план, подпись стейкхолдера. PatchMon фиксирует, кто и когда одобрил запуск, и ставит обновления в окно обслуживания, но заявку, план отката и согласование со стейкхолдерами не ведёт — подключать его как единственный источник истины про изменения рискованно. Надёжнее держать тикет-систему первичным носителем change-процесса, а PatchMon — техническим датчиком.

Третье — специфика вендорских стеков. Для парков на Astra Linux, РЕД ОС или ALT Linux пакетные менеджеры формально совместимы (apt, dnf), и агент должен работать, но вопрос сертифицированных обновлений безопасности решается их собственными репозиториями и утилитами. PatchMon покажет доступность пакета, но не заменит официальный канал уведомлений от вендора о критических патчах — это два разных источника, и оба нужны.

Не пытайтесь строить на PatchMon compliance-отчётность для регулятора. Формулировки «на дату X все критические обновления установлены» требуют не только факта установки, но и доказательной цепочки — журнал, подпись, версия пакета до и после. Это задача связки CMDB + системы установки + подписанных логов, и PatchMon в этой цепочке — только один элемент.

Практический критерий: если из парка обновляется вручную больше двух-трёх серверов в неделю, PatchMon оправдан как система видимости. Если вам нужно автоматически обновлять 200 хостов по расписанию с гарантией отката — это уже другая категория инструмента, и её надо ставить рядом, а не вместо.

Self-hosted PatchMon бесплатен под лицензией AGPL v3 и разрешён к бесплатной установке в вашей инфраструктуре, а managed-версия доступна как PatchMon Cloud — условия на странице тарифов. Конкретные тарифы облачной версии в источниках не зафиксированы, поэтому сравнение честнее вести не «рубли против рублей», а «часы поддержки против абонплаты».

Стоимость self-hosted складывается не из лицензии, а из инфраструктуры и обслуживания. Виртуалка под сервер PatchMon — небольшая: сервер это один Go-бинарник и React-UI в контейнере, без Node runtime и без тяжёлого стека. Минимальные требования к серверу приведены в README проекта (раздел Minimum Server Specs).

Дальше — люди. На поддержку self-hosted инстанса уходит время инженера: обновления сервера, ротация бэкапов БД, продление TLS-сертификата, разбор инцидентов. Если на эту работу нет времени инженера, сравните его стоимость с облачным тарифом.

Логика выбора получается такая. Внутренняя команда с сильным Linux-инженером и уже стоящим self-hosted стеком (Zabbix, GitLab, Nextcloud) — берите бесплатную self-hosted версию, добавление ещё одного контейнера ничего не меняет. Продуктовая команда без выделенного DevOps, для которой сервер — «чёрный ящик» — берите Cloud, там управляемая инфраструктура закрывает те самые «дни в месяц».

При аутсорсинге один self-hosted сервер подрядчика обслуживает парки нескольких клиентов, и стоимость мониторинга обновлений удобно включать в пакет администрирования вместо отдельной подписки. Клиент при этом видит в отчёте конкретную работу, а не абстрактную «поддержку».

Практический совет: не ставьте PatchMon PRO/Cloud на том основании, что «PRO звучит серьёзнее». AGPL v3-версия — это тот же продукт, а не урезанная демка. Начинайте с self-hosted, а к Cloud приходите только когда сопровождение сервера начинает мешать основной работе.

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

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