PRTG Network Monitor: агентless-мониторинг для компании без штатного ИТ-отдела

Когда у клиента 30–50 рабочих мест и нет своего системного администратора, вопрос «Zabbix или PRTG» решается не техническими предпочтениями, а простой арифметикой: сколько человеко-часов есть на поддержку самого мониторинга. Я расскажу, как мы у себя в ITfresh настраиваем PRTG Network Monitor агентless-способом для таких клиентов — какие сенсоры и пороги ставим по умолчанию, на каких портах это работает и в какой момент PRTG перестаёт быть выгодным решением и нужно переходить на Zabbix.

Почему агентless — это не компромисс, а осознанный выбор для компании без ИТ-отдела

У клиента без штатного ИТ-специалиста любое решение, требующее установки и последующего апдейта агента на полусотне рабочих станций, обречено на деградацию за 3–6 месяцев: агент перестают ставить на новые машины, забывают обновлять после переустановки Windows, никто не следит за версией. Мы через это проходили на нескольких стендах и с 2026 года по умолчанию для клиентов до 50 РМ без собственного ИТ-отдела берём PRTG Network Monitor именно в агентless-конфигурации — опрос по SNMP, WMI и SSH с одного или двух зондов (probe), без установки чего-либо на пользовательские машины.

Агентless для нас означает не «менее точный», а «менее хрупкий» мониторинг: единственная точка отказа — сам сервер PRTG и учётные записи опроса (доменная учётка с правами на WMI/RPC, community-строка SNMP), а не десятки независимо живущих агентов. Для сети с 1–2 офисами, доменом Active Directory и типовым набором Windows Server + свитчи + принтеры + пара внешних сервисов этого достаточно с запасом.

Есть и обратная сторона: агентless хуже видит то, что происходит внутри процесса — детальные счётчики производительности приложений, кастомные метрики бизнес-логики. Если клиенту это нужно, мы это обсуждаем отдельно и в части случаев всё-таки ставим агент PRTG на конкретный сервер (например, 1С или SQL) — это не догма, а прагматичный выбор по каждому узлу.

Ещё один довод в пользу агентless для нашей практики — юридический и организационный. Установка агента на рабочую станцию сотрудника формально требует согласования (это программное обеспечение, которое остаётся резидентно на машине конечного пользователя), а на предприятиях без ИТ-отдела процедура согласования и учёта установленного софта чаще всего просто отсутствует как процесс. Опрос по SNMP/WMI с одного зонда снимает эту головную боль полностью: конечные пользовательские машины физически не тронуты, изменения происходят только на выделенном сервере мониторинга и в правах доменной сервисной учётной записи.

Архитектура PRTG: core server, зонды, сенсоры и каналы

PRTG строится на трёх сущностях. Core Server — центральная служба (PRTG Core Server Service), которая хранит конфигурацию, историю данных во встроенной базе и отдаёт веб-интерфейс. Probe — процесс, который реально опрашивает устройства; в простейшем случае это Local Probe, встроенный в тот же сервер, что и core. Для второго офиса или сегмента за NAT ставится Remote Probe — отдельная служба, которая инициирует TCP-соединение к core серверу на порт 23560 и тоннелирует через него результаты опроса, поэтому открывать входящие порты на стороне удалённого офиса не нужно — исходящее соединение достаточно.

Каждое измеряемое значение — это сенсор (sensor): пинг, свободное место на диске, загрузка порта коммутатора по SNMP, статус службы Windows через WMI и так далее. По документации Paessler на актуальную линейку PRTG 25.x сенсорная библиотека насчитывает порядка 320 готовых типов сенсоров и более 250 преднастроенных шаблонов под конкретное оборудование и ПО. Внутри сенсора могут быть несколько каналов (channel) — например, сенсор трафика интерфейса свитча отдаёт отдельные каналы «Traffic In» и «Traffic Out», и лимиты (warning/error) настраиваются для каждого канала независимо.

Core Server у нас традиционно ставится на Windows Server (Paessler официально поддерживает установку на Windows Server 2016/2019/2022/2025, а также Windows 10/11 для небольших инсталляций) с требованием .NET Framework версии 4.7.2 или новее. Веб-интерфейс слушает 443/80 с автоматическим фолбэком на 8443/8080/32000+, если основные порты заняты другой службой на том же хосте — это стоит учитывать, если на сервере уже висит IIS или другая веб-панель.

Для клиента с одной локацией нам, как правило, хватает единственного Local Probe — он поднимается автоматически вместе с core-сервером и опрашивает всё, до чего дотягивается по сети напрямую. Remote Probe мы разворачиваем, только когда у клиента реально несколько физических площадок (например, офис плюс склад с отдельным каналом связи) или когда сегмент сети закрыт от core-сервера маршрутизацией и NAT — тогда зонд ставится локально в этом сегменте, а наружу инициирует только исходящее TCP-соединение на 23560, что снимает необходимость пробрасывать входящие правила через периметр клиента.

Установка и автообнаружение — как мы это делаем на объекте клиента

Для компании до 50 РМ мы почти всегда ставим PRTG на отдельную виртуальную машину, а не подселяем на существующий файловый или терминальный сервер — во-первых, чтобы сбой мониторинга не тянул за собой продуктивную нагрузку, во-вторых, чтобы падение прод-сервера не «ослепляло» сам мониторинг. Последовательность у нас такая:

1. Разворачиваем ВМ (обычно 2 vCPU / 4–8 ГБ RAM с запасом — для инсталляции в пределах пары сотен сенсоров этого хватает по нашей практике), ставим Windows Server, накатываем актуальные обновления и .NET Framework 4.7.2+.
2. Открываем на межсетевом экране входящий 443 (веб-интерфейс) внутри LAN/VPN клиента и, если планируется удалённый зонд в другом офисе, — 23560 на core сервере для входящих от Remote Probe.
3. Устанавливаем PRTG Core Server, создаём выделенную сервисную учётную запись домена только для мониторинга (без прав локального администратора на рабочих станциях, только чтение WMI/RPC) и отдельную SNMP community-строку с правами read-only, отличную от заводской public.
4. Запускаем встроенный мастер автообнаружения (Devices → Add Auto-Discovery Group) по диапазону IP или по импорту из Active Directory, указываем шаблон обнаружения — в 90% случаев берём готовый «Standard device with SNMP & WMI» с автоматическим определением типа устройства (Windows-сервер, принтер, управляемый свитч, гипервизор).
5. После первого прохода вручную ревизируем список: убираем сенсоры-дубли и всё, что не несёт диагностической ценности (иначе съедаем бесплатную квоту сенсоров зря), донастраиваем пороги под конкретного клиента.

Открытие портов для Remote Probe оформляем правилом на фаерволе примерно так:

Порт кластерной синхронизации между узлами (если развёрнут failover-кластер) — отдельный, 23570, и его наружу вообще не выводим, он живёт только между core-нодами.

Типовой набор сенсоров и пороги, которые мы ставим по умолчанию

За полтора года практики у нас сложился базовый пресет сенсоров для клиента «одна локация, домен AD, файловый/терминальный сервер, пара коммутаторов, интернет-канал». Это не догма — под конкретную инфраструктуру пороги корректируем, но стартовая точка выглядит так:

Отдельно обращаю внимание: пороги по CPU/RAM/диску — это отправная точка по нашей практике, а не значение из документации Paessler, потому что «правильный» порог всегда зависит от профиля нагрузки конкретного сервера. Для терминального сервера на 20 одновременных RDP-сессий 80% CPU днём — норма, а не авария, и мы это донастраиваем индивидуально в первую неделю эксплуатации, глядя на реальные графики.

Уведомления, эскалация и наш способ довести алерт до живого человека

В PRTG алерт формируется не самим сенсором напрямую, а через notification trigger — правило, привязанное к сенсору, группе или всей инсталляции целиком. По документации Paessler базовый тип — threshold trigger: срабатывает, когда канал сенсора выходит за лимит, заданный в настройках канала (то есть ровно те Warning/Error-границы из таблицы выше). Есть также триггер по смене статуса сенсора (переход в Down/Warning/Unusual) и по длительности состояния — это важно, чтобы не будить ответственного за разовый всплеск пинга на 250 мс.

Из встроенных способов доставки мы у клиентов до 50 РМ используем связку из двух: email на дежурный ящик и HTTP-уведомление (webhook) — PRTG поддерживает метод доставки «HTTP-запрос» с произвольным телом. Мы заворачиваем этот webhook на собственный маленький релей, который транслирует алерт в Telegram-чат клиента и нашей дежурной службы — тот же подход, что мы используем в собственном мониторинге инфраструктуры. Смысл: у ответственного лица (часто это директор или бухгалтер без технического бэкграунда) должно быть одно понятное сообщение в привычном канале, а не письмо с техническим телом SNMP OID.

Эскалацию строим в два уровня: первое уведомление — сразу дежурному инженеру ITfresh, если проблема не закрыта (сенсор не вернулся в Up) в течение заданного окна — повторное уведомление с эскалацией на второго инженера. Это настраивается прямо в правиле notification trigger через параметр повторной отправки (repeat every N minutes until acknowledged), без внешних скриптов.

Честное сравнение: PRTG и Zabbix по критериям, которые реально влияют на выбор

Мы работаем с обоими продуктами (Zabbix — наш стандартный выбор для клиентов с собственным ИТ-специалистом или большой гетерогенной инфраструктурой), поэтому сравниваем не по маркетинговым буклетам, а по тому, что реально требуется на внедрении и в поддержке.

Ключевое наблюдение по нашей практике: у Zabbix стоимость «спрятана» в квалификации специалиста, который должен уметь писать шаблоны, настраивать триггеры на языке выражений Zabbix и администрировать СУБД под нагрузку истории метрик. У PRTG эта стоимость явная и зашита в цену подписки за количество сенсоров — но зато не требует держать в штате (или на аутсорсе на постоянной основе) человека с этой квалификацией just for мониторинг.

Когда PRTG объективно выгоднее Zabbix для компании без ИТ-отдела

Мы рекомендуем PRTG клиенту, когда одновременно верны минимум 3–4 из следующих условий:

• В штате нет системного администратора, и обслуживание мониторинга ложится на нас как на аутсорс — значит, время на внедрение и разбор инцидентов конвертируется в стоимость услуги напрямую, и GUI-мастер PRTG экономит часы по сравнению с ручной настройкой шаблонов Zabbix.
• Инфраструктура преимущественно Windows-центричная: файловый/терминальный сервер, 1С/SQL, домен AD, управляемые свитчи с SNMP — это ровно тот профиль, под который у PRTG есть готовые преднастроенные шаблоны сенсоров без написания кастомных проверок.
• Число объектов мониторинга умещается в пределах пары сотен сенсоров — то есть либо укладывается в бесплатную квоту 100 сенсоров навсегда, либо попадает в первый платный тираж (PRTG 500), где стоимость подписки предсказуема и не требует пересмотра архитектуры.
• Клиенту важна единая точка ответственности за продукт: при проблеме с самим PRTG есть вендорская поддержка Paessler по подписке, а не только наша экспертиза как интегратора.
• Нет требования держать мониторинг on-premises по регуляторным причинам, которое исключало бы Windows-сервер как узел, — здесь ограничений нет, PRTG и так on-premises.

Zabbix мы, наоборот, ставим, если у клиента уже есть штатный админ, инфраструктура гетерогенная (Linux-серверы, контейнеры, сетевое оборудование разных вендоров в количестве, кастомная бизнес-телеметрия), а рост числа хостов будет быстрым и непредсказуемым — тогда открытая лицензия без привязки к числу сенсоров окупает более высокий порог входа.

Есть и промежуточный случай, который на практике встречается чаще, чем кажется: клиент уже пробовал развернуть Zabbix своими силами (обычно по совету знакомого админа или из общей репутации продукта как «бесплатного и мощного»), но инсталляция простаивает без присмотра — сервер Zabbix жив, а шаблоны не донастроены, триггеры не проверены, алерты никуда не доходят. В этой ситуации мы честно считаем трудозатраты на реанимацию существующей инсталляции против переноса на PRTG с нуля: если брошенная инсталляция Zabbix ближе к нулю по полезности, чем к рабочему состоянию, миграция на PRTG с готовыми шаблонами часто оказывается быстрее, чем разбор чужой конфигурации.

Отчётность для руководителя и хранение истории — что реально смотрят наши клиенты

Директору без технического бэкграунда не нужен доступ в консоль мониторинга — ему нужен понятный периодический отчёт. В PRTG эта задача закрыта модулем Reports: отчёт формируется по расписанию за произвольный период и рассылается по email в формате HTML или PDF (есть также выгрузка в CSV и XML для тех, кому нужны сырые данные под собственную аналитику). Мы обычно настраиваем клиенту ежемесячный PDF-отчёт по ключевым сенсорам — аптайм серверов, загрузка интернет-канала, инциденты с указанием длительности простоя — это тот же документ, который потом используется как обоснование при разговоре про апгрейд канала или сервера.

По умолчанию PRTG хранит историю мониторинга 1 год; глубину хранения можно увеличить до 5 лет через Setup → System Administration → System & Website → Data Purging Limits → Historic Data. Для отчётов есть техническое ограничение самого движка: период отчёта не может превышать 500 дней — если задать больше, PRTG автоматически урезает его до 365 дней, а для больших периодов данные усредняются, чтобы не перегружать рендеринг графика. Для среднего клиента до 50 РМ увеличивать хранение сверх заводского года мы рекомендуем только если это нужно для собственного разбора сезонности нагрузки (например, ритейл смотрит пиковые декабрьские нагрузки на канал год к году) — иначе это просто лишний расход дискового пространства на core-сервере без практической пользы.

Отдельно у PRTG есть модуль Maps — интерактивная карта инфраструктуры с виджетами статусов, которую можно вывести на отдельный монитор в серверной или у ответственного сотрудника как дашборд «всё зелено / что-то красное» без необходимости разбираться в интерфейсе целиком. Для клиентов, где физически есть выделенный экран на посту охраны или у офис-менеджера, это самый дешёвый способ дать «первую линию» реагирования не ИТ-специалисту.

Наш чек-лист внедрения и типичные ошибки клиентов при самостоятельной настройке

Часть клиентов пытается развернуть PRTG своими силами (обычно офис-менеджер или приходящий разово специалист) и потом зовёт нас разгребать последствия. Повторяющиеся ошибки:

• Не учитывают лимит бесплатной версии. После 100 активных сенсоров freeware-редакция не блокируется полностью, но интервал сканирования принудительно увеличивается — мониторинг фактически теряет оперативность именно в тот момент, когда инфраструктура выросла и стала сложнее.
• Не чистят автообнаружение. Мастер автодискавери честно создаёт сенсоры на всё, что нашёл, включая принтеры-призраки и давно выключенные тестовые машины — это съедает квоту сенсоров и создаёт фоновый шум ложных Down-алертов.
• Держат PRTG на единственном сервере без плана отказоустойчивости. Core Server — это и есть точка отказа: если он лёг, никто не узнает о проблеме именно тогда, когда она возникла. Для клиентов, где простой критичен, мы предлагаем failover-кластер (мастер-узел плюс до четырёх failover-узлов по документации Paessler) либо хотя бы дублирующий канал уведомлений через внешний heartbeat-сервис.
• Не разделяют пороги Warning и Error по смыслу. Частая ошибка — ставить одинаковый порог для «предупредить» и «звонить ночью», из-за чего дежурный либо игнорирует все алерты (alert fatigue), либо просыпается от некритичных событий.
• Оставляют заводскую SNMP community-строку public с правом записи или используют доменную учётку с избыточными правами для WMI-опроса — это лишняя поверхность атаки, которую мы всегда закрываем read-only учётками на этапе внедрения.

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

Сколько сенсоров реально нужно компании на 30–50 рабочих мест?

По нашей практике для одной локации с доменом AD, файловым/терминальным сервером, парой управляемых свитчей и интернет-каналом уходит от 60 до 150 сенсоров в зависимости от глубины мониторинга принтеров и рабочих станций. Это значит, что часть таких клиентов укладывается в бесплатную квоту PRTG (до 100 сенсоров навсегда), а часть переходит в первый платный тираж подписки.

Можно ли начать на бесплатной версии PRTG и потом расширяться без переустановки?

Да, лицензия меняется вводом ключа подписки в той же инсталляции без переноса конфигурации — сенсоры, пороги и уведомления сохраняются. Мы обычно и стартуем на freeware, чтобы клиент увидел работающий мониторинг до того, как платить за подписку.

PRTG агентless — значит ли это, что рабочие станции сотрудников тоже под наблюдением без установки ПО?

Рабочие станции можно мониторить по WMI без установки агента (доступность, диск, критические события), но для детальной телеметрии конкретного приложения на станции агентless-подход даёт меньше данных, чем установленный агент. Для 50 РМ без ИТ-отдела мы обычно мониторим не каждую станцию персонально, а инфраструктуру, от которой зависит работа всех: серверы, свитчи, каналы связи, печать.

Что произойдёт, если сам сервер с PRTG выйдет из строя?

Мониторинг остановится вместе с ним — это его единственная точка отказа при однонодовой установке. Для критичных клиентов мы разворачиваем failover-кластер PRTG (мастер-узел плюс резервные узлы) либо настраиваем внешний heartbeat-сервис, который отдельно проверяет доступность самого PRTG.

Стоит ли переходить с Zabbix на PRTG, если у клиента появился ИТ-специалист?

Не всегда. Если специалист один и загружен другими задачами, GUI-мастер PRTG всё равно экономит его время на рутинной настройке. Переход на Zabbix имеет смысл, когда инфраструктура становится гетерогенной и растёт быстрее, чем укладывается в предсказуемую подписку по числу сенсоров — тогда открытая лицензия окупает более высокий порог входа.