MaxPatrol EDR Getting Started: первый шаг к защите конечных узлов
Диагностика и решение проблем
В этом разделе разберём, как контролировать состояние MaxPatrol EDR, где искать журналы при возникновении проблем, как включать расширенное логирование и как устранять наиболее распространённые неисправности.
Мониторинг состояния системы
Для наблюдения за работоспособностью MaxPatrol EDR — состоянием агентов, модулей и серверных компонентов — используется стек наблюдаемости (observability stack). Он разворачивается автоматически при установке и обеспечивает сбор, хранение и визуализацию трёх типов данных: системных событий, данных трассировки (записей о выполнении операций компонентами) и метрик производительности.
Состав стека наблюдаемости
Grafana: основной интерфейс мониторинга
Основным инструментом для анализа состояния системы является Grafana — веб-интерфейс с готовыми дашбордами, графиками и диаграммами для каждого компонента MaxPatrol EDR.
Как получить доступ:
При стандартной установке веб-интерфейс Grafana доступен на том же IP-адресе, что и управляющий сервер, на порту 3000:
https://<адрес_управляющего_сервера>:3000
Имя пользователя по умолчанию — admin. Пароль находится в манифесте установки в секции params → observability.
Если в манифесте для сервера агентов дополнительно указан компонент observability, метрики этого сервера собираются локально, и Grafana доступна по адресу сервера агентов на том же порту.
Прямые ссылки на Grafana для каждого сервера агентов отображаются в интерфейсе MaxPatrol EDR в разделе Система → Управление серверами агентов. Переход по ссылке автоматически открывает дашборд EDR Agent Server с метриками конкретного сервера.
Состав стека наблюдаемости
Сервис | Роль |
OpenTelemetry | Сбор системных событий, данных трассировки и метрик |
Jaeger | Работа с данными трассировки |
Elasticsearch | Хранение данных трассировки |
VictoriaMetrics | Хранение метрик |
Grafana | Визуализация, мониторинг и анализ системных событий и метрик |
Grafana Loki | Хранение и просмотр журналов событий |
Grafana: основной интерфейс мониторинга
Основным инструментом для анализа состояния системы является Grafana — веб-интерфейс с готовыми дашбордами, графиками и диаграммами для каждого компонента MaxPatrol EDR.
Как получить доступ:
При стандартной установке веб-интерфейс Grafana доступен на том же IP-адресе, что и управляющий сервер, на порту 3000:
https://<адрес_управляющего_сервера>:3000
Имя пользователя по умолчанию — admin. Пароль находится в манифесте установки в секции params → observability.
Если в манифесте для сервера агентов дополнительно указан компонент observability, метрики этого сервера собираются локально, и Grafana доступна по адресу сервера агентов на том же порту.
Прямые ссылки на Grafana для каждого сервера агентов отображаются в интерфейсе MaxPatrol EDR в разделе Система → Управление серверами агентов. Переход по ссылке автоматически открывает дашборд EDR Agent Server с метриками конкретного сервера.
Рисунок 1. Ссылки на переход в Grafana
Дашборды Grafana
После входа перейдите в раздел Dashboards → Manage. Все дашборды сгруппированы в три каталога.
Дашборды Grafana
После входа перейдите в раздел Dashboards → Manage. Все дашборды сгруппированы в три каталога.
Рисунок 2. Дашборды Grafana
Каталог server
Содержит дашборд Node Exporter Full — основной источник системных метрик серверов, на которых развёрнуты компоненты MaxPatrol EDR (управляющий сервер, серверы агентов).
Каталог server
Содержит дашборд Node Exporter Full — основной источник системных метрик серверов, на которых развёрнуты компоненты MaxPatrol EDR (управляющий сервер, серверы агентов).
Рисунок 3. Каталог server
Используется для:
Используется для:
- поиска причин сбоев — проверить, не связаны ли проблемы с нехваткой CPU или памяти;
- планирования масштабирования — оценить, не исчерпаны ли ресурсы при росте числа агентов;
- диагностики узких мест — быстро выявить переполнение диска, задержки в работе, аномалии потребления.
Рисунок 4. Дашборд Node Exporter Full
Каталог components
Содержит вспомогательные дашборды для мониторинга сервисов самого стека наблюдаемости:
Каталог components
Содержит вспомогательные дашборды для мониторинга сервисов самого стека наблюдаемости:
- Elasticsearch
- Jaeger
- VictoriaMetrics
Рисунок 5. Каталог components
Каталог edr
Ключевые дашборды для анализа работы компонентов MaxPatrol EDR:
Каталог edr
Ключевые дашборды для анализа работы компонентов MaxPatrol EDR:
Дашборд | Что показывает |
EDR Agent Server | Потребление ресурсов сервисом vxserver на сервере агентов: CPU, память, дисковая активность, метрики Go runtime |
EDR API Server | Аналогичные метрики для сервиса vxapi на управляющем сервере |
EDR Agents | Показатели работы агентов на конечных устройствах |
EDR Modules | Статистика выполнения модулей |
EDR VXRouter | Размер очередей событий от модулей на сервере агентов |
EDR VXProto | Статистика передачи данных между сервером агентов и агентами |
Рисунок 6. Каталог edr
Как использовать дашборды при диагностике
Единого алгоритма нет — дашборды предоставляют данные для корреляции с наблюдаемыми симптомами. Несколько практических подходов:
Как использовать дашборды при диагностике
Единого алгоритма нет — дашборды предоставляют данные для корреляции с наблюдаемыми симптомами. Несколько практических подходов:
- Резкие скачки потребления ресурсов → возможная проблема в конкретном компоненте или модуле.
- Стабильно высокая нагрузка → сигнал о необходимости масштабирования: добавить ресурсы или развернуть дополнительный сервер агентов.
- Аномальный поток событий от конкретного модуля → повод пересмотреть конфигурацию модуля или добавить исключения.
Расположение файлов журналов
При возникновении проблем первый шаг — знать, где искать подробности. Журналы MaxPatrol EDR хранятся на разных уровнях системы.
Журнал установки
Путь: /var/log/edr_install.log (на сервере с ролью Deployer)
Ведётся с момента запуска установочного скрипта. При каждом повторном запуске дополняется новыми строками — это позволяет отслеживать все этапы установки, обновления и конфигурирования, включая ошибки и предупреждения.
Когда смотреть: при ошибках во время установки или обновления системы.
Журналы управляющего сервера
Путь: /var/log/edr/api-server/api.log (на управляющем сервере)
Компонент api фиксирует все операции, связанные со своей работой. Журналы остальных компонентов управляющего сервера доступны через Docker:
docker logs <имя_контейнера>
Когда смотреть: при ошибках в работе сервисов управляющего сервера или ошибках в пользовательском интерфейсе.
Журналы сервера агентов
Путь: /var/log/edr/agent-server/server.log (на сервере агентов)
Также доступны через Docker. Для удобства при установке MaxPatrol EDR в ОС серверов добавляются псевдонимы команд для работы с Docker — полный перечень доступен в документации.
Когда смотреть:
Журналы агента на конечном устройстве
Windows:
Журнал установки
Путь: /var/log/edr_install.log (на сервере с ролью Deployer)
Ведётся с момента запуска установочного скрипта. При каждом повторном запуске дополняется новыми строками — это позволяет отслеживать все этапы установки, обновления и конфигурирования, включая ошибки и предупреждения.
Когда смотреть: при ошибках во время установки или обновления системы.
Журналы управляющего сервера
Путь: /var/log/edr/api-server/api.log (на управляющем сервере)
Компонент api фиксирует все операции, связанные со своей работой. Журналы остальных компонентов управляющего сервера доступны через Docker:
docker logs <имя_контейнера>
Когда смотреть: при ошибках в работе сервисов управляющего сервера или ошибках в пользовательском интерфейсе.
Журналы сервера агентов
Путь: /var/log/edr/agent-server/server.log (на сервере агентов)
Также доступны через Docker. Для удобства при установке MaxPatrol EDR в ОС серверов добавляются псевдонимы команд для работы с Docker — полный перечень доступен в документации.
Когда смотреть:
- ошибки в работе сервисов сервера агентов;
- проблемы с подключением агентов, в том числе сбои авторизации;
- проблемы с получением или отправкой событий в MaxPatrol 10.
Журналы агента на конечном устройстве
Windows:
- Основной журнал: C:\Program Files\Positive Technologies\EDR Agent\agent.log
- Журнал обновлений: C:\Program Files\Positive Technologies\EDR Agent\upgrader.log
- Основной журнал: /opt/vxagent/logs/agent.log
- Журнал обновлений: /opt/vxagent/logs/upgrader.log
- Когда смотреть: при проблемах с запуском агента, подключением к серверу, выполнением модулей.
Включение расширенного логирования (debug)
Если стандартные логи не дают достаточной информации для диагностики — переключитесь на уровень debug. Он фиксирует подробную отладочную информацию о работе каждого компонента.
⚠️ Debug-логирование увеличивает объём записей и может временно снизить производительность. Включайте его только на время диагностики и сразу отключайте после сбора нужных данных.
Расширенное логирование серверных компонентов
Для сервисов управляющего сервера или сервера агентов уровень логирования задаётся через параметр Logging_Threshold в файле docker-compose.yaml, расположенном в каталоге /opt/edr на соответствующем сервере.
Рассмотрим пример для сервиса vxapi управляющего сервера.
Шаг 1. Откройте файл docker-compose.yaml:
cd /opt/edr
sudo nano docker-compose.yaml
Шаг 2. Найдите описание сервиса vxapi. В секции environment найдите параметр Logging_Threshold и измените его значение с info на debug:
environment:
Logging_Threshold: debug
⚠️ Debug-логирование увеличивает объём записей и может временно снизить производительность. Включайте его только на время диагностики и сразу отключайте после сбора нужных данных.
Расширенное логирование серверных компонентов
Для сервисов управляющего сервера или сервера агентов уровень логирования задаётся через параметр Logging_Threshold в файле docker-compose.yaml, расположенном в каталоге /opt/edr на соответствующем сервере.
Рассмотрим пример для сервиса vxapi управляющего сервера.
Шаг 1. Откройте файл docker-compose.yaml:
cd /opt/edr
sudo nano docker-compose.yaml
Шаг 2. Найдите описание сервиса vxapi. В секции environment найдите параметр Logging_Threshold и измените его значение с info на debug:
environment:
Logging_Threshold: debug
Рисунок 7
Шаг 3. Сохраните файл и перезапустите сервис:
edr-compose up -d
Шаг 4. Воспроизведите проблему или дождитесь её проявления. Сохраните лог для анализа.
Шаг 5. После завершения диагностики верните значение обратно на info и снова выполните edr-compose up -d.
Расширенное логирование агентов
Порядок включения зависит от ОС конечного устройства.
Linux
Добавьте строку DEBUG=true в файл /opt/vxagent/service.env:
sudo nano /opt/vxagent/service.env
# Добавить строку:
DEBUG=true
Перезапустите сервис агента:
sudo systemctl restart vxagent
Windows
В реестре перейдите по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vxagent
Найдите ключ ImagePath и добавьте в конец его значения строку -debug. После этого перезапустите службу vxagent.
⚠️ Перед редактированием реестра на Windows убедитесь, что механизм самозащиты агента отключён — иначе изменения не применятся.
Общий порядок диагностики
Эффективная диагностика строится на понимании архитектуры системы. Прежде чем приступать к анализу логов, убедитесь, что вы:
Имея эту базу, диагностику удобно вести по цепочке взаимодействия — от ближайшего к проблеме компонента к следующему, начиная с самого базового уровня (сетевая доступность) и заканчивая специфическими настройками и логами.
Пример: агент не подключается к серверу агентов
Шаг 3. Сохраните файл и перезапустите сервис:
edr-compose up -d
Шаг 4. Воспроизведите проблему или дождитесь её проявления. Сохраните лог для анализа.
Шаг 5. После завершения диагностики верните значение обратно на info и снова выполните edr-compose up -d.
Расширенное логирование агентов
Порядок включения зависит от ОС конечного устройства.
Linux
Добавьте строку DEBUG=true в файл /opt/vxagent/service.env:
sudo nano /opt/vxagent/service.env
# Добавить строку:
DEBUG=true
Перезапустите сервис агента:
sudo systemctl restart vxagent
Windows
В реестре перейдите по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vxagent
Найдите ключ ImagePath и добавьте в конец его значения строку -debug. После этого перезапустите службу vxagent.
⚠️ Перед редактированием реестра на Windows убедитесь, что механизм самозащиты агента отключён — иначе изменения не применятся.
Общий порядок диагностики
Эффективная диагностика строится на понимании архитектуры системы. Прежде чем приступать к анализу логов, убедитесь, что вы:
- знаете состав компонентов MaxPatrol EDR и сервисы, входящие в каждый из них;
- понимаете, какие Docker-контейнеры отвечают за работу этих сервисов;
- представляете схему взаимодействия компонентов: как агенты обращаются к серверу агентов, как сервер агентов взаимодействует с управляющим сервером;
- учитываете протоколы, порты и типы соединений, задействованных в этом взаимодействии.
Имея эту базу, диагностику удобно вести по цепочке взаимодействия — от ближайшего к проблеме компонента к следующему, начиная с самого базового уровня (сетевая доступность) и заканчивая специфическими настройками и логами.
Пример: агент не подключается к серверу агентов
- Проверить статус службы агента на конечном устройстве.
- Проанализировать журнал агента — там будет первичная информация об ошибке.
- Проверить сетевую доступность сервера агентов по порту 8443.
- Убедиться в отсутствии устройств, подменяющих TLS-сертификат (SSL Inspection, прокси-серверы).
- Проанализировать журнал сервера агентов — для получения деталей ошибки на серверной стороне.
Типовые проблемы и способы их решения
Несмотря на уникальность каждой инфраструктуры, около 80% инцидентов при эксплуатации MaxPatrol EDR связаны с ограниченным набором повторяющихся сценариев. Разберём наиболее распространённые из них.
Дополнительные случаи задокументированы в официальной документации в разделе «Диагностика и решение проблем».
Проблемы при установке MaxPatrol EDR
Основной инструмент диагностики установки — журнал /var/log/edr_install.log на сервере с ролью Deployer.
Рассмотрим несколько самых распространённых ошибок.
Пользователь не добавлен в sudoers
Симптом в логе:
admin is not in the sudoers file.
MODULE FAILURE
Причина: пользователь, указанный в манифесте, не имеет прав на выполнение привилегированных операций.
Решение: добавьте пользователя в группу sudo или внесите запись в /etc/sudoers. После этого повторно запустите установку.
sudo usermod -aG sudo admin
Не установлен пакет sshpass
Симптом в логе:
to use the 'ssh' connection type with passwords,
you must install the sshpass program
Причина: пакет sshpass не был установлен на этапе подготовки к установке.
Решение:
sudo apt update && sudo apt install -y sshpass
После установки повторно запустите установку MaxPatrol EDR.
Несовместимая версия Docker API
Симптом в логе:
client version 1.42 is too old.
Minimum supported API version is 1.44,
please upgrade your client to a newer version
Причина: начиная с Docker CE версии 29, минимальная поддерживаемая версия Docker API повышена до 1.44. Если установлена более старая версия клиента — возникает несовместимость.
Решение: вместо переустановки Docker настройте параметр min-api-version в файле /etc/docker/daemon.json. Укажите версию, которую видите в логе:
{
"min-api-version": "1.42"
}
Перезапустите Docker и проверьте применение изменений:
sudo systemctl restart docker
docker version
После этого повторно запустите установку MaxPatrol EDR.
Агент не подключается: несовместимая версия
Симптом: после установки агент не появляется в интерфейсе MaxPatrol EDR. Другие агенты работают нормально.
Диагностика по шагам:
Шаг 1. Убедитесь, что проблема связана именно с этим агентом, а не с сервером агентов в целом — проверьте статус других агентов в интерфейсе.
Шаг 2. Проверьте статус службы агента на конечном устройстве (Диспетчер задач → вкладка «Службы», или PowerShell, или sc query vxagent). Служба работает.
Дополнительные случаи задокументированы в официальной документации в разделе «Диагностика и решение проблем».
Проблемы при установке MaxPatrol EDR
Основной инструмент диагностики установки — журнал /var/log/edr_install.log на сервере с ролью Deployer.
Рассмотрим несколько самых распространённых ошибок.
Пользователь не добавлен в sudoers
Симптом в логе:
admin is not in the sudoers file.
MODULE FAILURE
Причина: пользователь, указанный в манифесте, не имеет прав на выполнение привилегированных операций.
Решение: добавьте пользователя в группу sudo или внесите запись в /etc/sudoers. После этого повторно запустите установку.
sudo usermod -aG sudo admin
Не установлен пакет sshpass
Симптом в логе:
to use the 'ssh' connection type with passwords,
you must install the sshpass program
Причина: пакет sshpass не был установлен на этапе подготовки к установке.
Решение:
sudo apt update && sudo apt install -y sshpass
После установки повторно запустите установку MaxPatrol EDR.
Несовместимая версия Docker API
Симптом в логе:
client version 1.42 is too old.
Minimum supported API version is 1.44,
please upgrade your client to a newer version
Причина: начиная с Docker CE версии 29, минимальная поддерживаемая версия Docker API повышена до 1.44. Если установлена более старая версия клиента — возникает несовместимость.
Решение: вместо переустановки Docker настройте параметр min-api-version в файле /etc/docker/daemon.json. Укажите версию, которую видите в логе:
{
"min-api-version": "1.42"
}
Перезапустите Docker и проверьте применение изменений:
sudo systemctl restart docker
docker version
После этого повторно запустите установку MaxPatrol EDR.
Агент не подключается: несовместимая версия
Симптом: после установки агент не появляется в интерфейсе MaxPatrol EDR. Другие агенты работают нормально.
Диагностика по шагам:
Шаг 1. Убедитесь, что проблема связана именно с этим агентом, а не с сервером агентов в целом — проверьте статус других агентов в интерфейсе.
Шаг 2. Проверьте статус службы агента на конечном устройстве (Диспетчер задач → вкладка «Службы», или PowerShell, или sc query vxagent). Служба работает.
Рисунок 8
Шаг 3. Проверьте доступность порта 8443 сервера агентов с конечного устройства. Порт доступен.
Шаг 3. Проверьте доступность порта 8443 сервера агентов с конечного устройства. Порт доступен.
Рисунок 9
Шаг 4. Откройте журнал агента и найдите ошибки подключения:
level=warning msg="vxagent: try reconnect"
error="failed to initialize connection: failed to perform the initial connection:
failed to connect to the server: a connection initialization required
(failed to read an init connect response: read channel is closed)"
Агент пытается подключиться, но соединение не устанавливается. Причина в логе агента не раскрывается.
Шаг 5. Из лога агента берём его идентификатор (agent_id) и время попытки подключения. Выгружаем журнал сервиса vxserver на сервере агентов и ищем по идентификатору агента:
edr-logs -t — --since 2026−01−21T14:00:00Z vxserver > vxserver. log
В журнале сервера агентов находим причину:
«error»:"initial connection validation failed: ABH validation failed:
failed to get the ABH for the agent’s binary v4.1.0.9776/windows/amd64:
ABH not found for ABI v4.1.0.9776/windows/amd64″
Сервер отклоняет подключение, поскольку ABH (Agent Binary Hash) — хеш-сумма исполняемого файла агента версии v4.1.0.9776 — не найден в базе поддерживаемых версий.
Решение: скачайте поддерживаемый дистрибутив агента со страницы Дистрибутивы агентов в интерфейсе MaxPatrol EDR и переустановите агент на конечном устройстве.
Потеря событий от агентов
Симптом: в высоконагруженных инсталляциях количество событий в интерфейсе MaxPatrol EDR не соответствует фактическому количеству событий на агентах.
Диагностика:
Откройте дашборд EDR VXRouter в Grafana. В панели фильтрации выберите нужный сервер агентов (server_id) и модуль main (module_name).
Шаг 4. Откройте журнал агента и найдите ошибки подключения:
level=warning msg="vxagent: try reconnect"
error="failed to initialize connection: failed to perform the initial connection:
failed to connect to the server: a connection initialization required
(failed to read an init connect response: read channel is closed)"
Агент пытается подключиться, но соединение не устанавливается. Причина в логе агента не раскрывается.
Шаг 5. Из лога агента берём его идентификатор (agent_id) и время попытки подключения. Выгружаем журнал сервиса vxserver на сервере агентов и ищем по идентификатору агента:
edr-logs -t — --since 2026−01−21T14:00:00Z vxserver > vxserver. log
В журнале сервера агентов находим причину:
«error»:"initial connection validation failed: ABH validation failed:
failed to get the ABH for the agent’s binary v4.1.0.9776/windows/amd64:
ABH not found for ABI v4.1.0.9776/windows/amd64″
Сервер отклоняет подключение, поскольку ABH (Agent Binary Hash) — хеш-сумма исполняемого файла агента версии v4.1.0.9776 — не найден в базе поддерживаемых версий.
Решение: скачайте поддерживаемый дистрибутив агента со страницы Дистрибутивы агентов в интерфейсе MaxPatrol EDR и переустановите агент на конечном устройстве.
Потеря событий от агентов
Симптом: в высоконагруженных инсталляциях количество событий в интерфейсе MaxPatrol EDR не соответствует фактическому количеству событий на агентах.
Диагностика:
Откройте дашборд EDR VXRouter в Grafana. В панели фильтрации выберите нужный сервер агентов (server_id) и модуль main (module_name).
Рисунок 10
Если очередь событий регулярно достигает максимального значения 1000 — события, не попавшие в очередь, отбрасываются.
Важно: кратковременные всплески на графике — норма. Они могут возникать после восстановления связи с сервером агентов (например, после его обновления): агенты в этот момент передают накопленные в локальном кеше события, временно создавая повышенную нагрузку. Проблемой является регулярное заполнение очереди.
Решение:
Добавьте параметр Packet_Receivers_Count в секцию environment сервиса vxapi в файле /opt/edr/docker-compose.yaml на управляющем сервере. Рекомендуется увеличивать значение поэтапно, например до 10 (значение по умолчанию — 5):
environment:
Packet_Receivers_Count: 10
После каждого изменения отслеживайте:
⚠️ Увеличение Packet_Receivers_Count ведёт к росту потребления системных ресурсов сервером агентов. Подобные изменения рекомендуется вносить постепенно и под контролем технической поддержки Positive Technologies.
Если очередь событий регулярно достигает максимального значения 1000 — события, не попавшие в очередь, отбрасываются.
Важно: кратковременные всплески на графике — норма. Они могут возникать после восстановления связи с сервером агентов (например, после его обновления): агенты в этот момент передают накопленные в локальном кеше события, временно создавая повышенную нагрузку. Проблемой является регулярное заполнение очереди.
Решение:
Добавьте параметр Packet_Receivers_Count в секцию environment сервиса vxapi в файле /opt/edr/docker-compose.yaml на управляющем сервере. Рекомендуется увеличивать значение поэтапно, например до 10 (значение по умолчанию — 5):
environment:
Packet_Receivers_Count: 10
После каждого изменения отслеживайте:
- дашборд EDR VXRouter — динамику очередей;
- дашборды EDR Agent Server и Node Exporter Full — потребление CPU и памяти.
⚠️ Увеличение Packet_Receivers_Count ведёт к росту потребления системных ресурсов сервером агентов. Подобные изменения рекомендуется вносить постепенно и под контролем технической поддержки Positive Technologies.
Заключение
Мы научились системно подходить к диагностике: проверять цепочку взаимодействия (агент → сервер агентов → управляющий сервер), начиная с сетевой доступности и заканчивая логами конкретных компонентов. В завершающей статье цикла обсудим обновление и обслуживание системы.
Спасибо за прочтение! До встречи в следующих статьях курса!
Спасибо за прочтение! До встречи в следующих статьях курса!
Может быть интересно
