Эксперты в подборе IT-оборудования
Разница между двумя подходами сводится к тому, откуда смотрят на систему. Агентный мониторинг ставит на сервер программу, которая собирает данные изнутри. Безагентный опрашивает сервер снаружи по стандартным протоколам, ничего на него не устанавливая. Похоже на камеру внутри помещения против камеры, снимающей его с улицы: первая видит больше, вторую проще повесить.
Агентный мониторинг предполагает установку специального программного обеспечения (агента) непосредственно на отслеживаемые системы. Агент собирает данные изнутри и передаёт их на центральный сервер мониторинга. Отчасти так устроен и SNMP: на самом устройстве работает встроенный агент (демон snmpd), который отдаёт метрики по запросу, - почему SNMP как агентный мониторинг считают отдельным случаем, разбираем в отдельной статье.
Безагентный мониторинг работает без установки дополнительного ПО. Центральная система собирает данные, используя стандартные протоколы и интерфейсы - SNMP, WMI, WinRM, SSH, API - или анализируя сетевой трафик.
Казалось бы, безагентный подход звучит привлекательнее: меньше хлопот с установкой, ниже нагрузка на системы. Но агентный никуда не делся, и причина у этого конкретная.
| Критерий | Агентный | Безагентный |
|---|---|---|
| Глубина метрик | процессы, системные вызовы, файловые операции, метрики приложений | то, что отдают стандартные интерфейсы: CPU, память, диск, сеть |
| Нагрузка на систему | есть, обычно небольшая | нет на самой системе, но есть от обработки запросов |
| При обрыве связи | копит данные локально и досылает | слепая зона за весь период |
| Скорость реакции | событие отправляется сразу | не быстрее интервала опроса |
| Развёртывание | установка и обновление на каждой машине | настройка только на сервере мониторинга |
| Динамические среды | каждая новая машина требует агента | новые узлы подхватываются сами |
| Права доступа | агент работает локально, часто с повышенными правами | учётная запись с минимально нужными правами |
| Поверхность атаки | плюс один компонент на каждой машине | лишнего кода нет, но нужны открытые порты и учётки |
| Локальные действия | может перезапустить службу, почистить диск | только сообщить |
Дальше - что за этими строками стоит.
Главное преимущество агентов - доступ к глубинным метрикам.
Агент работает внутри операционной системы и видит то, что недоступно снаружи: детальную информацию о процессах, системных вызовах, файловых операциях. Он отслеживает события локально, без постоянного опроса из центра. И продолжает собирать данные при проблемах с сетью, сохраняя их локально до восстановления связи.
Откуда берётся разница во времени обнаружения. Безагентный мониторинг узнаёт о проблеме не раньше следующего опроса. Поставили интервал в минуту - в худшем случае теряете минуту, поставили пять - теряете пять. Агент отправляет событие в момент, когда оно произошло. На бумаге разница выглядит несущественной, но она складывается с временем реакции алертинга, и вот уже отсчёт идёт не на секунды. Уменьшать интервал опроса до секунд можно, но тогда вы упираетесь в нагрузку на сеть и на опрашиваемые системы - ровно то, ради чего безагентный подход и выбирали.
Есть и класс задач, где снаружи не видно ничего в принципе. Классический пример - когда две фоновые операции пересекаются во времени: ночной бэкап накладывается на перестроение индексов, и база на несколько минут перестаёт отвечать. Снаружи видно только «сервер недоступен». Изнутри видно, какие именно процессы в этот момент держали диск, и совпадение обнаруживается за один просмотр графиков.
Агенты обычно умеют и реагировать: перезапустить упавшую службу, очистить временные файлы, выполнить сценарий восстановления. Безагентная система в такой ситуации может только сообщить.
Из популярных инструментов оба режима поддерживает Zabbix - и через собственного агента, и опросом по SNMP; установку и настройку Zabbix разбираем отдельно. В связке Prometheus и Grafana роль агента играют экспортеры, которые ставятся на наблюдаемые машины.
Первое и очевидное: агенты нужно установить, настроить и поддерживать на каждой системе. В инфраструктуре из десяти серверов это разовая задача на вечер. В облачной среде с сотнями машин, которые создаются и уничтожаются по расписанию, - уже отдельный процесс со своей автоматизацией.
Второе: агент потребляет ресурсы наблюдаемой системы. На обычном сервере это незаметно. На встраиваемом устройстве, сетевом оборудовании или виртуальной машине с гигабайтом памяти каждый мегабайт уже на счету - и там агента чаще не ставят вовсе.
Третье: совместимость и стабильность. Агент - это дополнительный код, который работает в вашей системе рядом с рабочими приложениями. Конфликты редки, но случаются, а искать их тяжело: симптом проявляется в приложении, а причина лежит в стороннем компоненте, на который никто не думает.
Четвёртое: безопасность. Каждый агент - это ещё один процесс с сетевым доступом и обычно с повышенными правами. Он расширяет поверхность атаки, и его тоже надо обновлять. Как это учитывается в общей картине защиты, смотрите в разборе SIEM и IDS.
Безагентный подход привлекателен простотой внедрения. Не нужно ничего устанавливать на контролируемые системы: настраиваете центральный сервер, указываете цели, и система сама начинает сбор данных через стандартные протоколы.
Это особенно ценно в динамических средах - облаках, контейнерных кластерах, микросервисных архитектурах. Новые экземпляры систем попадают под мониторинг автоматически. А поскольку дополнительных компонентов на контролируемых системах нет, исключаются проблемы совместимости.
Нагрузки на наблюдаемую систему безагентный мониторинг почти не создаёт - кроме обработки самих запросов. Это критично для высоконагруженных серверов и устройств с ограниченными ресурсами: встроенных систем, IoT-устройств, сетевого оборудования.
Риски безопасности тоже ниже. Безагентный мониторинг обычно работает под учётной записью с минимальным набором прав, а отсутствие агентов означает отсутствие дополнительных уязвимостей на каждой машине.
«Стандартные протоколы» - формулировка, за которой прячется вполне конкретный список. И от того, какой протокол вы используете, зависит и объём метрик, и то, что придётся открыть на межсетевом экране. Какие метрики вообще имеет смысл собирать и что отслеживать на сервере в первую очередь - в обзорной статье.
| Механизм | Где применяется | Порты | Что даёт |
|---|---|---|---|
| SNMP | сетевое оборудование, серверы, ИБП, СХД | UDP 161, ловушки 162 | счётчики интерфейсов, датчики, базовые метрики системы |
| WMI через DCOM | Windows | TCP 135 плюс динамический диапазон 49152-65535 | подробные данные Windows: службы, диски, события |
| WinRM | Windows | TCP 5985 (HTTP) или 5986 (HTTPS) | то же, что WMI, но дружелюбнее к межсетевому экрану |
| SSH | Linux и BSD | TCP 22 | выполнение любых команд, значит - почти любые метрики |
| IPMI | серверное железо | UDP 623 | температуры, вентиляторы, питание, состояние независимо от ОС |
| Redfish | серверы последних поколений | HTTPS 443 | то же, что IPMI, но по REST и с телеметрией |
| API гипервизора или облака | vSphere, Proxmox, oVirt, облачные платформы | HTTPS | метрики виртуальных машин со стороны платформы |
Два практических следствия.
Windows: выбирайте WinRM, а не WMI, если есть возможность. WMI работает поверх DCOM: клиент сначала стучится на порт 135, а тот перенаправляет его на случайный порт из диапазона 49152-65535. Через межсетевой экран это означает либо открыть весь диапазон, либо отдельно ограничивать диапазон RPC на каждой машине. WinRM обходится двумя фиксированными портами, работает по WS-Management поверх HTTP или HTTPS и рекомендован самой Microsoft. Разница особенно заметна, когда мониторинг стоит в другом сегменте сети.
IPMI и Redfish - это безагентный мониторинг, который переживает саму операционную систему. Контроллер управления работает независимо от ОС и на дежурном питании, поэтому температуры, обороты вентиляторов и состояние блоков питания видны, даже когда сервер выключен или не грузится. Ни один агент внутри системы этого не покажет.
Отдельная история - контейнеры и виртуализация. «Безагентно» там означает не то же самое, что на железе: метрики отдаёт не сам контейнер, а среда, в которой он работает - API гипервизора или API оркестратора. Внутрь контейнера по-прежнему не видно, и если нужны метрики самого приложения, без агента или экспортера рядом не обойтись. Подробнее - в статье про мониторинг виртуальных машин и контейнеров.
Главный недостаток безагентного подхода - ограниченная видимость. Без агента внутри системы вы ограничены тем, что предоставляют стандартные интерфейсы. Часто это базовые метрики - загрузка CPU, использование памяти, дискового пространства - но без понимания внутренних процессов.
Многие специфические для приложений метрики просто недоступны. Очередь в брокере сообщений, время отклика конкретного эндпоинта, размер пула соединений к базе - всё это живёт внутри приложения, и снаружи его никто не отдаст.
Ещё один существенный недостаток - зависимость от сетевого соединения. Если связь с системой прервана, безагентный мониторинг остаётся слеп. Агент в это время копит данные локально и досылает их после восстановления связи; безагентная система теряет период недоступности целиком - а это ровно тот период, который потом интереснее всего разбирать.
И наконец, частый опрос из центра создаёт периодическую нагрузку на сеть и на сами системы. В небольших масштабах это незаметно, в инфраструктуре из тысяч устройств становится значимым фактором.
Слепая зона опаснее отсутствия метрики. Отсутствие данных мониторинг обычно показывает как «нет данных», и это заметно. Хуже, когда система рисует ровный график, потому что опрос идёт раз в пять минут, а всплеск длился минуту. Формально мониторинг есть, фактически проблему он не увидит - и об этом стоит помнить, когда выбираете интервал.
Агентный мониторинг подходит, когда:
Безагентный подход лучше работает, когда:
Есть ещё одна развилка, о которой вспоминают позже всего: кто это будет обслуживать. Агентная схема требует, чтобы кто-то следил за версиями агентов и за тем, что они вообще запущены. Безагентная - чтобы кто-то следил за учётными записями и правами доступа на всех целевых системах. Работа в обоих случаях есть, просто разная.
В сложных инфраструктурах обычно сочетают оба подхода. Безагентный мониторинг даёт широкий охват и базовый уровень видимости по всем системам, а агенты ставят на критически важные серверы, где нужны детальные метрики.
Схема получается такая: безагентный подход обнаруживает и берёт под базовый контроль новые системы, а дальше по мере необходимости добавляются агенты для глубокого анализа. Это даёт и масштабируемость, и детальность там, где она нужна.
Большинство платформ мониторинга поддерживают оба режима из коробки, так что выбирать метод можно для каждой системы отдельно.
Пересматривать выбор со временем - нормально. Инфраструктура меняется, и схема мониторинга меняется вместе с ней: то, что начиналось как десяток серверов с агентами, через два года может оказаться кластером, где агенты разумно оставить только на узлах баз данных.
Что бы вы ни выбрали, отдельной настройки потребуют оповещения - иначе система начнёт будить дежурного по любому поводу. Как этого избежать, разбираем в статье про настройку оповещений без ложных срабатываний.
Местом сбора данных. Агентный ставит программу внутрь системы, и она видит процессы, файловые операции и метрики приложений. Безагентный опрашивает систему снаружи по SNMP, WinRM, SSH или API и получает то, что эти интерфейсы отдают. Отсюда все остальные различия: глубина, нагрузка, поведение при обрыве связи.
Безагентный меньше расширяет поверхность атаки: на наблюдаемых машинах не появляется дополнительного кода. Но он требует открытых портов и учётных записей с правами на всех целевых системах, и эти учётки сами по себе становятся целью. Так что «безопаснее» зависит от того, что в вашей модели угроз весит больше.
Для сетевого оборудования, ИБП и базового контроля серверов - вполне. Как только появляется задача следить за метриками самого приложения (очереди, время отклика, пулы соединений), безагентного подхода перестаёт хватать.
Формально агентный: на устройстве работает демон snmpd, то есть агент. Но устанавливать его обычно не нужно - он уже встроен в прошивку сетевого оборудования и в поставку серверных ОС. Поэтому SNMP обычно относят к безагентным методам, хотя технически это не совсем так.
WinRM, если есть выбор. WMI работает через DCOM и требует открыть порт 135 плюс динамический диапазон 49152-65535, что через межсетевой экран неудобно. WinRM обходится портами 5985 или 5986 и рекомендован Microsoft.
На обычном сервере - в пределах погрешности. Разговор становится предметным на устройствах с ограниченной памятью и на машинах, которые уже работают на пределе: там стоит сначала померить, а потом ставить.
Собрать инфраструктуру, за которой удобно следить
Выбор подхода к мониторингу упирается в железо не меньше, чем в софт: у сервера с нормальным контроллером управления температуры и питание видны без всякого агента, а у сборки на десктопном железе - нет. Мы 11+ лет на рынке серверов и подбираем конфигурации с учётом того, как машину потом эксплуатировать.
Расскажите про инфраструктуру и задачи - подберём серверное оборудование под нагрузку и обоснуем каждую позицию.
Телефон: +7 (800) 551-80-12
Почта: info@ittelo.ru
