Поделиться через

Агенты Менеджера по операциям

В System Center Operations Manager агент — это служба, установленная на компьютере, который ищет данные конфигурации и заранее собирает сведения для анализа и отчетности, измеряет состояние работоспособности отслеживаемых объектов, таких как база данных SQL или логический диск, и выполняет задачи по запросу оператором или в ответ на условие. Он позволяет Operations Manager отслеживать операционные системы Windows, Linux и UNIX, а также компоненты ИТ-службы, установленные на них, например веб-сайт или контроллер домена Active Directory.

Агент Windows

На компьютере с системой Windows, который находится под наблюдением, агент Operations Manager обозначен как служба Microsoft Monitoring Agent (MMA). Служба Microsoft Monitoring Agent собирает данные о событиях и производительности, выполняет задачи и другие рабочие процессы, заданные в пакете управления. Даже если эта служба не может подключиться к серверу управления, которому она подчиняется, она продолжает работать и помещает собранные данные и события в очередь на диске наблюдаемого компьютера. При восстановлении подключения служба Microsoft Monitoring Agent отправляет собранные данные и события на сервер управления.

Примечание.

  • Служба Microsoft Monitoring Agent иногда также называется службой работоспособности.

Служба Microsoft Monitoring Agent также работает на серверах управления. На сервере управления служба запускает рабочие процессы мониторинга и управляет учетными данными. Для выполнения рабочих процессов служба инициирует MonitoringHost.exe процессы с использованием указанных учетных данных. Эти процессы выполняют наблюдение и собирают данные журналов событий, данные инструментария управления Windows (WMI), а также выполняют такие действия, как запуск скриптов.

Взаимодействие между агентами и серверами управления

Агент Operations Manager отправляет данные оповещений и обнаружения на назначенный первичный сервер управления, который записывает данные в операционную базу данных. Кроме того, агент отправляет данные о событиях, производительности и состоянии на основной сервер управления, который одновременно записывает эти данные в рабочую базу данных и в базу данных хранилища данных.

Агент отправляет данные в соответствии с параметрами расписания для каждого правила и монитора. В случае оптимизированных правил сбора данных данные передаются только в том случае, если выборка счетчика отличается от предыдущей выборки на указанную величину допуска, например на 10%. Это помогает сократить сетевой трафик и объем данных, хранящихся в рабочей базе данных.

Кроме того, все агенты регулярно отправляют пакет данных, называемый пульсом, на сервер управления: по умолчанию это происходит каждые 60 секунд. Назначение проверки сердцебиения состоит в проверке доступности агента и связи между агентом и сервером управления. Дополнительные сведения о пульсе см. в статье How Heartbeats Work in Operations Manager (Принципы работы пульса в Operations Manager).

Для каждого агента Operations Manager запускает наблюдатель службы работоспособности, который наблюдает за состоянием удаленной службы работоспособности с точки зрения сервера управления. Агент взаимодействует с сервером управления через TCP-порт 5723.

Иллюстрация взаимодействия агента с сервером управления.

Агент Linux/UNIX

Архитектура агента UNIX и Linux значительно отличается от агента Windows. Агент Windows имеет службу здоровья, ответственную за оценку состояния компьютера, который находится под мониторингом. Агент UNIX и Linux не запускает службу работоспособности; вместо этого он передает информацию в службу работоспособности на сервере управления для её оценки. Сервер управления выполняет все рабочие процессы для мониторинга работоспособности операционной системы, определенной в нашей реализации пакетов управления UNIX и Linux:

  • Диск
  • Процессор
  • Память
  • Сетевые адаптеры
  • Операционная система
  • Процессы
  • Файлы журналов

Агенты UNIX и Linux для Operations Manager состоят из диспетчера объектов CIM (то есть сервера CIM) и набора поставщиков CIM. Диспетчер объектов CIM — это "серверный" компонент, реализующий взаимодействие WS-Management, проверку подлинности, авторизацию и диспетчеризацию запросов поставщикам. Поставщики — это ключ к реализации CIM в агенте, определение классов и свойств CIM, взаимодействие с API ядра для получения необработанных данных, форматирование данных (например, вычисление разностных и средних) и обслуживание запросов, отправленных из диспетчера объектов CIM. Начиная с System Center Operations Manager 2007 R2 и до System Center 2012 SP1, диспетчер объектов CIM, используемый в агентах Operations Manager UNIX и Linux, является сервером OpenPegasus. Поставщики, используемые для сбора и отслеживания данных мониторинга, разрабатываются корпорацией Майкрософт и открыты в CodePlex.com.

Иллюстрация архитектуры программного обеспечения агента Operations Manager UNIX/Linux.

Это изменилось в System Center 2012 R2 Operations Manager, где агенты UNIX и Linux теперь основаны на полностью согласованной реализации инфраструктуры управления OMI в качестве менеджера объектов CIM. В случае агентов Operations Manager UNIX/Linux OMI заменяет OpenPegasus. Как и OpenPegasus, OMI — это реализация диспетчера объектов CIM с открытым исходным кодом, легкая и переносимая, хотя она легче и больше подходит для переноски, чем OpenPegasus. Эта реализация продолжает применяться в System Center 2016 — Operations Manager и более поздних версиях.

Схема обновленной архитектуры программного обеспечения агента Operations Manager UNIX/Linux.

Обмен данными между сервером управления и агентом UNIX и Linux разделен на две категории: обслуживание агента и мониторинг работоспособности. Сервер управления использует два протокола для взаимодействия с компьютером UNIX или Linux:

  • Secure Shell (SSH) и протокол SFTP

    Используется для задач обслуживания агента, таких как установка, обновление и удаление агентов.

  • Веб-службы для управления (WS-Management)

    Используется для всех операций мониторинга и обнаружения уже установленных агентов.

Обмен данными между сервером управления Operations Manager и агентом UNIX и Linux использует WS-Man по протоколу HTTPS и интерфейсу WinRM. Все задачи обслуживания агента выполняются через SSH через порт 22. Все мониторинг работоспособности выполняется через WS-MAN через порт 1270. Сервер управления запрашивает данные о производительности и конфигурации через WS-MAN перед оценкой данных для обеспечения состояния работоспособности. Все действия по управлению, такие как поддержка агентов, мониторинг, правила, задачи и восстановительные процессы, устанавливаются для использования предварительно заданных профилей в соответствии с требованием применения непривилегированной или привилегированной учетной записи.

Примечание.

Все учетные данные, указанные в этой статье, относятся к учетным записям, установленным на компьютере UNIX или Linux, а не к учетным записям Operations Manager, настроенным во время установки Operations Manager. Обратитесь к системному администратору для получения учетных данных и сведений о проверке подлинности.

Для поддержки новых улучшений масштабируемости в отношении числа систем UNIX и Linux, которые System Center 2016 — Operations Manager и более поздние версии могут отслеживать на каждом сервере управления, доступны новые API асинхронной инфраструктуры управления Windows (MI) вместо API синхронизации WSMAN, которые используются по умолчанию. Чтобы включить это изменение, необходимо создать новый параметр реестра UseMIAPI, чтобы позволить Operations Manager использовать новые асинхронные API MI на серверах управления, которые мониторят системы Linux и Unix.

  1. Откройте редактор реестра из командной строки с повышенными привилегиями.
  2. Создайте ключ реестра UseMIAPI под HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup.

Если необходимо восстановить исходную конфигурацию с помощью синхронизационных API WSMAN, можно удалить раздел реестра UseMIAPI.

Безопасность агентов

Проверка подлинности на компьютере UNIX/Linux

В Operations Manager системный администратор больше не требуется для предоставления корневого пароля компьютера UNIX или Linux серверу управления. При повышении привилегий непривилегированная учетная запись может принять на себя идентичность привилегированной учетной записи на компьютере с UNIX или Linux. Процесс повышения прав выполняется программами su (superuser) и sudo операционной системы UNIX, которые используют учетные данные, предоставленные сервером управления. Для привилегированных операций обслуживания агента, использующих SSH (например, обнаружение, развертывание, удаление и восстановление агента), предоставляется поддержка повышения прав с помощью su и sudo, а также поддержка проверки подлинности с ключом SSH (с парольной фразой или без нее). Для привилегированных операций WS-Management (например, просмотр безопасных файлов журналов) добавляется поддержка повышения прав с помощью sudo (без пароля).

Подробные инструкции по указанию учетных данных и настройке учетных записей см. в разделе "Настройка учетных данных для доступа к компьютерам UNIX и Linux".

Проверка подлинности с помощью сервера шлюза

Серверы шлюзов используются для управления компьютерами с помощью агентов, которые находятся за пределами границы доверия Kerberos управляемой группы. Поскольку сервер шлюза находится в домене, которому не доверяет домен группы управления, необходимо использовать сертификаты для установления подлинности каждого компьютера, агента, сервера шлюза и сервера управления. Данная схема удовлетворяет требованию Operations Manager к взаимной проверке подлинности.

Для этого необходимо запросить сертификаты для каждого агента, который будет сообщать серверу шлюза и импортировать эти сертификаты на целевой компьютер с помощью средства MOMCertImport.exe, расположенного в каталоге поддержки установочного носителя\ (amd64 или x86). У вас должен быть доступ к центру сертификации (ЦС), который может быть общедоступным ЦС, например VeriSign, или использовать службы сертификатов Майкрософт.

Развертывание агента

Агенты System Center Operations Manager можно установить одним из следующих трех способов. Чтобы установить разные типы компьютеров соответствующим образом, в большинстве установок используется сочетание этих методов.

Примечание.

  • Нельзя установить MMA на компьютере с установленным сервером управления Operations Manager, сервером шлюза, консолью управления, рабочей базой данных, веб-консолью, System Center Essentials или System Center Service Manager, так как в них уже установлена встроенная версия MMA.
  • Вы можете использовать либо MMA, либо агент аналитики (версия расширения виртуальной машины).
  • Обнаружение и установка одного или нескольких агентов из консоли управления. Это наиболее распространенный способо установки. Сервер управления должен иметь доступ к компьютеру с помощью RPC. При этом учетная запись действия сервера управления или другие предоставленные учетные данные должны иметь административный доступ к целевому компьютеру.
  • Включение в установочный образ. Это ручная установка базового образа, который используется для подготовки других компьютеров. В этом случае для автоматического назначения компьютера серверу управления при первоначальном запуске может использоваться интеграция Active Directory.
  • Установка вручную. Этот способ используется в том случае, если агент не удалось установить иным способом, например когда удаленный вызов процедур (RPC) недоступен из-за брандмауэра. Программа установки вручную запускается на агенте или развертывается с помощью существующего инструмента распространения программного обеспечения.

Агентами, установленными с помощью мастера обнаружения, можно управлять через консоль управления, например, обновлять версии агентов, применять исправления и настраивать сервер управления, которому подчиняется агент.

При установке агента вручную его обновление также должно выполняться вручную. Вы сможете использовать интеграцию Active Directory для назначения агентов группам управления. Дополнительные сведения см. в разделе "Интеграция Active Directory и Operations Manager".

Выберите требуемую вкладку, чтобы узнать больше о развертывании агента в системах Windows, UNIX и Linux:

Для обнаружения системы Windows требуется, чтобы порты TCP 135 (RPC), диапазон RPC и TCP 445 (SMB) оставались открытыми, и служба SMB включена на компьютере агента.

  • После обнаружения целевого устройства на него можно установить агент. Для установки агента требуется:
  • Открытие портов RPC начиная с маппера конечных точек TCP 135 и порта TCP/UDP 445 для протокола SMB.
  • Включение общего доступа к файлам и принтерам для сетей Майкрософт и клиента для служб Microsoft Networks. (Это гарантирует, что порт SMB активен.)
  • Если этот параметр включен, в параметрах групповой политики брандмауэра Windows для исключений "Разрешить удаленное администрирование" и "Разрешить общий доступ к файлам и принтерам" необходимо установить разрешение на получение незапрашиваемых входящих сообщений с IP-адресов и подсетей основных и вторичных серверов управления для агента.
  • Учетная запись с правами администратора на целевом компьютере.
  • Установщик Windows 3.1. Сведения об установке см. в статье 893803 в базе знаний Майкрософт https://go.microsoft.com/fwlink/?LinkId=86322
  • Microsoft Core XML Services (MSXML) 6 на носителе установки продукта Operations Manager в подкаталоге \msxml. Установка push-агента устанавливает MSXML 6 на целевом устройстве, если он еще не установлен.

Назначение агента Active Directory

System Center Operations Manager позволяет воспользоваться преимуществами инвестиций в службы домен Active Directory (AD DS), позволяя использовать его для назначения управляемых агентом компьютеров группам управления. Эта функция обычно используется с агентом, развернутым в процессе сборки сервера. При первом подключении к сети агент Operations Manager выполняет запрос к Active Directory, чтобы определить назначение основного сервера управления и сервера для отработки отказов, и автоматически начинает мониторинг компьютера.

Чтобы назначить компьютеры управляющим группам с помощью доменных служб Active Directory (AD DS), следуйте описанному ниже способу.

  • Функциональный уровень доменов AD DS должен быть собственным или более высоким для Windows 2008
  • Управляемые агентом компьютеры и все серверы управления должны находиться в одном домене или в доменах с двухсторонним доверием.

Примечание.

Агент, который определяет, что он установлен на контроллере домена, не запрашивает Active Directory для получения сведений о конфигурации. Это связано с соображениями безопасности. Интеграция Active Directory по умолчанию отключена на контроллерах домена, так как агент выполняется под учетной записью локальной системы. Учетная запись локальной системы на контроллере домена имеет права администратора домена; Таким образом, он обнаруживает все точки подключения службы сервера управления, зарегистрированные в Active Directory, независимо от членства в группе безопасности контроллера домена. В результате агент пытается подключиться ко всем серверам управления во всех группах управления. Результаты могут быть непредсказуемыми, что приводит к риску безопасности.

Назначение агента выполняется с помощью точки подключения службы (SCP), которая является объектом Active Directory для публикации сведений, которые клиентские приложения могут использовать для привязки к службе. Это создается администратором домена, на котором запущено средство командной строки MOMADAdmin.exe для создания контейнера AD DS для группы управления Operations Manager в доменах управляемых компьютеров. Группе безопасности AD DS, указанной при выполнении MOMADAdmin.exe, предоставляются разрешения на чтение и удаление дочерних элементов в контейнере. SCP содержит сведения о подключении к серверу управления, включая полное доменное имя сервера и номер порта. Агенты Operations Manager могут автоматически обнаруживать серверы управления, запрашивая SCPs. Наследование не отключено, и поскольку агент может считывать сведения об интеграции, зарегистрированные в AD, если вы принудительно разрешите наследование для группы "Все" для чтения всех объектов на корневом уровне в Active Directory, это будет серьёзно нарушать и фактически прерывать функциональность интеграции AD. Если явным образом применить принудительное наследование во всем каталоге, предоставив группе "Все" разрешения на чтение, необходимо заблокировать данное наследование на уровне корневого контейнера интеграции AD с именем OperationsManager и всех дочерних объектов.  Если этого не сделать, интеграция с AD не будет работать как задумано, и у вас не будет надежного и согласованного назначения основного и резервирования для установленных агентов. Кроме того, если у вас несколько групп управления, все агенты в обеих группах управления также будут многодомными. 

Эта функция хорошо подходит для управления назначением агентов в развертывании распределенной группы управления, чтобы предотвратить подключение агентов к серверам управления, предназначенным для пулов ресурсов или серверам управления во вторичном центре обработки данных в конфигурации с теплым резервированием, чтобы избежать переключения агентов при обычной эксплуатации.

Настройкой назначения агентов управляет администратор Operations Manager, использующий мастер назначения агентов и отработки отказов для назначения компьютеров на основной сервер управления и серверу вторичного управления.

Примечание.

Для агентов, установленных из консоли управления, отключена интеграция с Active Directory. По умолчанию интеграция с Active Directory включается для агентов, установленных вручную с помощью MOMAgent.msi.

Следующие шаги