Агент мониторинга: Пошаговые решения для администраторов по установке, обновлению и обслуживанию

Пошаговые решения для администраторов, которые устанавливают, обновляют и обслуживают агент мониторинга Proceset.

Поэтапное обновление агента мониторинга

Контекст: вы хотите обновить агент на большом парке станций (компьютеров сотрудников), но сначала проверить новую версию на небольшой группе.

Вам понадобится:

• доступ к серверу мониторинга;
• права на редактирование конфигурации;
• список станций для тестовой группы.

Этапы:

1. Выберите небольшую группу станций, на которых хотите протестировать новую версию агента, — например, отдел ИТ или несколько добровольцев.
2. Убедитесь, что эту группу можно однозначно выделить по имени компьютера (например, все имена начинаются на it-). Если это не так, для раскатки лучше использовать групповые политики или систему управления ПО, а не этот механизм.
3. На сервере мониторинга откройте конфигурационный файл сервиса (для Windows — каталог C:\ProgramData\Infomaximum\, для Linux/Docker — /var/lib/infomaximum/config/) и добавьте блок:

{
    "phased_agent_upgrade": {
        "stable_version": "2.6.41",
        "host_masks": [".+\\.it\\.example\\.com"]
    }
}

В примере выше 2.6.41 — версия-порог: станции с версией агента этой или ниже получат обновление, только если подходят под маску (то есть входят в тестовую группу); тем, у кого версия агента уже выше, обновление придёт в любом случае.

Маска в примере — это как раз имена станций тестовой группы.

ВАЖНО! Не забудьте экранировать точку в имени домена символом \\., иначе маска сработает на большее число станций, чем ожидалось.

1. Сохраните файл и перезапустите службу сервера мониторинга.

1. Дождитесь, пока тестовая группа обновится, и понаблюдайте за её работой несколько дней.
2. Если всё в порядке — удалите блок phased_agent_upgrade из конфигурации и снова перезапустите службу. Обновление будет разослано на весь парк станций.

Инвентаризация парка станций по ОС и версии агента через ClickHouse

Контекст: перед обновлением нужно понять, какие операционные системы и версии агента вообще есть в вашем парке.

Вам понадобится:

• доступ к хранилищу ClickHouse, куда попадают диагностические записи о станциях, включая версию операционной системы и версию агента;
• любой SQL-клиент для ClickHouse.

Этапы:

1. Подключитесь к ClickHouse с помощью вашего привычного SQL-клиента, используя те же реквизиты доступа, что и для других отчётов системы.
2. Выполните запрос к таблице monitoring_agent_inspector_log, чтобы получить список станций с их ОС и версией агента:

SELECT
    host_name,
    os_info,
    agent_version
FROM monitoring_agent_inspector_log
GROUP BY host_name, os_info, agent_version

1. Получившийся список удобно использовать, чтобы решить, какие станции включить в тестовую группу при поэтапном обновлении (см. раздел «Поэтапное обновление агента мониторинга» этой статьи).

Адаптация агента мониторинга под устаревшую версию ОС

Контекст: агент не устанавливается или не запускается на старой версии операционной системы.

Вам понадобится:

• лог установки со станции, где была зафиксирована проблема;
• обращение в техническую поддержку.

Шаги:

1. Если агент отказывается устанавливаться или падает сразу после запуска на станции со старой версией ОС — вероятная причина в том, что в этой версии ОС не хватает системных компонентов, на которые рассчитан агент.
2. Соберите лог установки со станции и передайте его в техническую поддержку — по нему можно точно определить, каких компонентов не хватает.
3. Для ряда старых ОС существует отдельная сборка агента, рассчитанная именно на них — поддержка подскажет, подходит ли она для вашего случая.
4. Прежде чем раскатывать такую сборку на весь парк станций с этой ОС, проверьте её на одной-двух станциях — как в разделе «Поэтапное обновление агента мониторинга» этой статьи.

Устранение ошибки установки агента из-за самоподписанного сертификата сервера

Контекст: установка агента прерывается, выдаётся ошибка доверия к сертификату сервера мониторинга.

Вам понадобится:

• браузер с доступом к серверу мониторинга;
• права администратора на станции (или в групповой политике).

Этапы вручную, на одной станции:

1. Откройте адрес сервера мониторинга в браузере.
2. Нажмите на значок замка рядом с адресной строкой и откройте сведения о сертификате.

1. Экспортируйте сертификат в файл (кнопка «Копировать в файл» / «Экспортировать», формат — Base-64).
2. Откройте оснастку «Сертификаты» (выполните certmgr.msc для текущего пользователя или certlm.msc для всей станции) и импортируйте файл в раздел «Доверенные корневые центры сертификации».
3. Повторите установку агента — ошибка доверия к сертификату больше не должна возникать.

Если станций много — через групповую политику:

1. Экспортируйте сертификат так же, как в шаге 3 выше.
2. В редакторе групповой политики перейдите: «Конфигурация компьютера» → «Конфигурация Windows» → «Параметры безопасности» → «Политики открытого ключа» → «Доверенные корневые центры сертификации».
3. Импортируйте туда тот же файл сертификата. Эта политика применится ко всем станциям, к которым привязана групповая политика, без необходимости ручных действий на каждой из них.

Переход агента мониторинга с EXE- на MSI-установку

Контекст: вы хотите управлять установкой агента через групповые политики вместо ручного запуска установщика.

Вам понадобится:

• права администратора домена / групповых политик;
• MSI-пакет агента.

Этапы:

1. Через групповую политику (или сценарий запуска) выполните «тихое удаление» через консоль уже установленной EXE-версии агента на станциях.
2. Опубликуйте MSI-пакет агента через групповую политику (раздел «Установка программ» в конфигурации компьютера) — так он автоматически развернётся на всех станциях, к которым привязана политика.
3. При необходимости передайте MSI-пакету параметры установки (например, адрес сервера мониторинга) через свойства (properties) в командной строке msiexec.
4. Проверьте результат на нескольких станциях, прежде чем раскатывать политику на весь домен.

Отображаемая версия агента не меняется после установки обновления

Контекст: агент обновился и работает на новой версии, но в свойствах службы Windows по-прежнему показана старая версия.

Вам понадобится:

• доступ к проблемной станции;
• конфигуратор агента.

Шаги:

1. На самом деле обновление применилось — сама служба уже работает на новой версии, просто отображаемое значение в свойствах не обновилось автоматически.
2. Откройте конфигуратор агента на станции.

1. Примените настройки заново через конфигуратор — это заставит систему перечитать и обновить отображаемую версию.
2. Перезапустите службу агента и проверьте свойства ещё раз.

Диагностика конфликта агента мониторинга с офисными приложениями

Контекст: после установки агента какое-то другое приложение на станции начинает работать нестабильно, и не сразу понятно, агент ли тому причина.

Что понадобится:

• станция, где воспроизводится проблема;
• обращение в техническую поддержку.

Этапы:

1. Зафиксируйте, при каких именно действиях в проблемном приложении возникает сбой, и убедитесь, что проблема воспроизводится стабильно, пока агент запущен.
2. Временно остановите службу агента и повторите те же действия. Если проблема исчезла — это подтверждает, что причина связана с агентом, и стоит обратиться в поддержку с этим наблюдением.
3. Поддержка подготовит тестовую сборку агента с дополнительным журналированием вокруг подозрительного места конфликта.
4. Установите тестовую сборку на той же станции и повторите проблемные действия — журнал поможет локализовать точную причину.
5. По результатам поддержка предложит и проверит исправление; при необходимости шаг повторяется до полного устранения конфликта.

Последовательное обновление системы через промежуточные версии

Контекст: текущая версия агента на станциях сильно устарела, и обновление сразу до последней версии не проходит.

Вам понадобится:

• станции с текущей версией агента;
• обращение в техническую поддержку.

Шаги:

1. При очень большом версионном отставании обновление напрямую до последней версии не всегда возможно: часть версий по пути вносит изменения (например, в формате хранения настроек), которые нельзя применить, пропустив хотя бы одну версию в цепочке обновлений.
2. Уточните у технической поддержки, через какие промежуточные версии нужно пройти именно из вашей текущей версии до целевой.
3. Устанавливайте версии строго по порядку цепочки, не пропуская ни одной обязательной промежуточной версии.
4. Каждый шаг цепочки желательно проверять на тестовой группе станций, как в разделе «Поэтапное обновление агента мониторинга» этой статьи, прежде чем переходить к следующему шагу на всём парке станций.

Пересборка прикладного пакета диагностики агентов при обновлении версии

Контекст: после обновления версии агента вспомогательный диагностический пакет перестаёт корректно импортироваться.

Вам понадобится:

• доступ к системе управления пакетами;
• новая версия диагностического пакета от поддержки.

Этапы:

1. Если поставить новую версию диагностического пакета поверх старой, не удаляя её полностью, импорт может завершиться конфликтом из-за пересечения старых и новых компонентов пакета.
2. Перед установкой новой версии полностью удалите предыдущую версию пакета.
3. Только после этого установите новую версию пакета, полученную от поддержки.
4. Проверьте, что импорт прошёл без ошибок и пакет отображается корректно.

Диагностика избыточного потребления памяти агентом мониторинга

Контекст: кажется, что агент мониторинга со временем потребляет всё больше памяти, как будто «утекает».

Вам понадобится:

• диспетчер задач / монитор ресурсов на станции;
• информация о разрядности установленного агента (32 или 64 бита).

Этапы:

1. Проверьте, какая сборка агента установлена на станции — 32-битная или 64-битная.
2. У 32-битного процесса есть предел доступной памяти (около 2–4 ГБ, в зависимости от системы). Это ограничение самой 32-битной адресации памяти, не связанное с поведением конкретной программы. На станциях с большим объёмом собираемых данных достижение этого предела может выглядеть как утечка памяти, хотя агент работает штатно — он просто упирается в архитектурное ограничение.
3. Если на станции установлена 32-битная сборка и вы наблюдаете такое поведение — перейдите на 64-битную сборку агента. У 64-битного процесса этого ограничения нет.
4. После перехода понаблюдайте за потреблением памяти в течение нескольких дней, чтобы убедиться, что рост потребления не возобновился.