Compartir a través de

Agentes de Operations Manager

  • Artículo

En System Center Operations Manager, un agente es un servicio instalado en un equipo que busca datos de configuración y recopila de forma proactiva información para el análisis y los informes, mide el estado de mantenimiento de objetos supervisados, como una base de datos SQL o un disco lógico, y ejecuta tareas a petición por un operador o en respuesta a una condición. Permite a Operations Manager supervisar los sistemas operativos Windows, Linux y UNIX y los componentes de un servicio de TI instalados en ellos como un sitio web o un controlador de dominio de Active Directory.

Agente de Windows

En un equipo de Windows supervisado, el agente Operations Manager aparece como el servicio de Microsoft Monitoring Agent (MMA). El servicio Microsoft Monitoring Agent recopila datos de eventos y de rendimiento, ejecuta tareas y otros flujos de trabajo definidos en un módulo de administración. Incluso cuando el servicio no puede comunicarse con el servidor de administración al que debe informar, este continúa ejecutándose y pone en cola los datos y eventos recopilados en el disco del equipo supervisado. Cuando se restaura la conexión, el servicio Microsoft Monitoring Agent envía los datos y eventos recopilados al servidor de administración.

Nota:

  • El servicio Microsoft Monitoring Agent se conoce a veces como servicio de mantenimiento.

El servicio Microsoft Monitoring Agent también se ejecuta en servidores de administración. En un servidor de administración, el servicio ejecuta flujos de trabajo de supervisión y administra las credenciales. Para ejecutar flujos de trabajo, el servicio inicia MonitoringHost.exe procesos mediante credenciales especificadas. Estos procesos supervisan y recopilan datos de registro de eventos, datos de contador de rendimiento, datos de Instrumental de administración de Windows (WMI) y ejecutan acciones como scripts.

Comunicación entre agentes y servidores de administración

El agente de Operations Manager envía datos de alerta y detección a su servidor de administración principal asignado, que escribe los datos en la base de datos operativa. El agente también envía datos de eventos, rendimiento y estados al servidor de administración principal para ese agente, que escribe los datos en las bases de datos operativas y de almacenamiento de datos simultáneamente.

El agente envía datos según los parámetros de programación de cada regla y monitor. En el caso de las reglas de recopilación optimizadas, los datos solo se transmiten si una muestra de un contador difiere de la muestra anterior en una tolerancia especificada, como el 10 %. Esto ayuda a reducir el tráfico de red y el volumen de datos almacenados en la base de datos operativa.

Además, todos los agentes envían un paquete de datos, denominado latido, al servidor de administración según una programación normal, de forma predeterminada cada 60 segundos. El propósito del latido es validar la disponibilidad del agente y la comunicación entre el agente y el servidor de administración. Para obtener más información sobre los latidos, vea Cómo funcionan los latidos en Operations Manager.

Para cada agente, Operations Manager ejecuta un monitor de servicio de mantenimiento, que supervisa el estado del Servicio de mantenimiento remoto desde la perspectiva del servidor de administración. El agente se comunica con un servidor de administración a través del puerto TCP 5723.

Ilustración de la comunicación del agente al servidor de administración.

Agente Linux/UNIX

La arquitectura del agente UNIX y Linux difiere significativamente de un agente de Windows. El agente de Windows tiene un Servicio de mantenimiento responsable de evaluar el estado del equipo supervisado. El agente de UNIX y Linux no ejecuta un servicio de mantenimiento; en su lugar, pasa información al Servicio de mantenimiento de un servidor de administración para que la evalúe. El servidor de administración ejecuta todos los flujos de trabajo para supervisar el estado del sistema operativo definido en nuestra implementación de los módulos de administración de UNIX y Linux:

  • Disco
  • Procesador
  • Memoria
  • Adaptadores de red
  • Sistema operativo
  • Procesos
  • Archivos de registro

Los agentes UNIX y Linux para Operations Manager constan de un Administrador de objetos CIM (es decir, servidor CIM) y un conjunto de proveedores CIM. El Administrador de objetos CIM es el componente de servidor que implementa la comunicación WS-Management, la autenticación, la autorización y el envío de solicitudes a los proveedores. Los proveedores son la clave de la implementación CIM en el agente, la definición de las clases y propiedades CIM, la interacción con las API de kernel para recuperar datos sin procesar, dar formato a los datos (por ejemplo, calcular deltas y promedios) y atender las solicitudes enviadas desde el Administrador de objetos CIM. Desde System Center Operations Manager 2007 R2 a System Center 2012 SP1, el Administrador de objetos CIM usado en los agentes UNIX y Linux de Operations Manager es el servidor OpenPegasus. Los proveedores que se usan para recopilar y notificar datos de supervisión son desarrollados por Microsoft y de código abierto en CodePlex.com.

Ilustración de la arquitectura de software del agente UNIX/Linux de Operations Manager.

Esto cambió en System Center 2012 R2 Operations Manager, donde los agentes de UNIX y Linux ahora se basan en una implementación totalmente coherente de Open Management Infrastructure (OMI) como su ADMINISTRADOR de objetos CIM. En el caso de los agentes UNIX/Linux de Operations Manager, OMI reemplaza a OpenPegasus. Al igual que OpenPegasus, OMI es una implementación del Administrador de objetos CIM portátil, ligero y de código abierto, aunque es más ligero en peso y más portátil que OpenPegasus. Esta implementación continúa aplicándose en System Center 2016 Operations Manager y versiones posteriores.

Diagrama de la arquitectura de software actualizada del agente UNIX/Linux de Operations Manager.

La comunicación entre el servidor de administración y el agente UNIX y Linux se divide en dos categorías: mantenimiento del agente y supervisión de estado. El servidor de administración usa dos protocolos para comunicarse con el equipo UNIX o Linux:

  • Secure Shell (SSH) y Secure Shell File Transfer Protocol (SFTP)

    Se usa para tareas de mantenimiento del agente, como instalar, actualizar y quitar agentes.

  • Servicios web para la administración (WS-Management)

    Se usa para todas las operaciones de supervisión e incluye la detección de agentes que ya estaban instalados.

La comunicación entre el servidor de administración de Operations Manager y el agente unix y Linux usa WS-Man a través de HTTPS y la interfaz WinRM. Todas las tareas de mantenimiento del agente se realizan a través de SSH en el puerto 22. Toda la supervisión del estado se realiza a través de WS-MAN en el puerto 1270. El servidor de administración solicita datos de rendimiento y configuración a través de WS-MAN antes de evaluar los datos para proporcionar el estado de mantenimiento. Todas las acciones, como el mantenimiento del agente, monitores, reglas, tareas y recuperaciones, están configuradas para usar perfiles predefinidos según sus necesidades de una cuenta con privilegios o sin privilegios.

Nota:

Todas las credenciales a las que se hace referencia en este artículo pertenecen a las cuentas establecidas en el equipo UNIX o Linux, no a las cuentas de Operations Manager configuradas durante la instalación de Operations Manager. Póngase en contacto con el administrador del sistema para obtener información de credenciales y autenticación.

Para admitir las nuevas mejoras de escalabilidad con el número de sistemas UNIX y Linux System Center 2016 Operations Manager y versiones posteriores puede supervisar por servidor de administración, las nuevas API asincrónicas de Infraestructura de administración de Windows (MI) están disponibles en lugar de las API de sincronización de WSMAN, que está en uso de forma predeterminada. Para habilitar este cambio, debe crear la nueva clave del Registro UseMIAPI para permitir que Operations Manager use las nuevas API de MI asincrónicas en servidores de administración que supervisan sistemas Linux/Unix.

  1. Abra el Editor del Registro desde un símbolo del sistema con privilegios elevados.
  2. Cree la clave del Registro UseMIAPI en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup.

Si necesita restaurar la configuración original mediante las API de sincronización de WSMAN, puede eliminar la clave del Registro UseMIAPI .

Seguridad del agente

Autenticación en equipos UNIX/Linux

En Operations Manager, el administrador del sistema ya no es necesario para proporcionar la contraseña raíz del equipo UNIX o Linux al servidor de administración. Ahora por elevación, una cuenta sin privilegios puede asumir la identidad de una cuenta con privilegios en el equipo UNIX o Linux. El proceso de elevación lo realizan los programas su (superusuario) y sudo UNIX que usan las credenciales que proporciona el servidor de administración. Para las operaciones de mantenimiento del agente con privilegios que usan SSH (por ejemplo, detección, implementación, actualizaciones, desinstalación y recuperación del agente), se proporciona compatibilidad con su, elevación de sudo y compatibilidad con la autenticación de clave SSH (con o sin frase de contraseña). Para las operaciones con privilegios de WS-Management (como ver archivos de registro seguros), se agrega compatibilidad con la elevación de sudo (sin contraseña).

Para obtener instrucciones detalladas sobre cómo especificar credenciales y configurar cuentas, consulte How to Set Credentials for Accessing UNIX and Linux Computers (Cómo establecer credenciales para acceder a equipos UNIX y Linux).

Autenticación con un servidor de puerta de enlace

Los servidores de puerta de enlace se usan para habilitar la administración de agentes de equipos que están fuera del límite de confianza de Kerberos de un grupo de administración. Dado que el servidor de puerta de enlace reside en un dominio que no es de confianza para el dominio en el que está el grupo de administración, se deben usar certificados para establecer la identidad, el agente, el servidor de puerta de enlace y el servidor de administración de cada equipo. Esta disposición satisface el requisito de Operations Manager para la autenticación mutua.

Esto requiere que solicite certificados para cada agente que informe a un servidor de puerta de enlace e importe esos certificados en el equipo de destino mediante la herramienta MOMCertImport.exe, que se encuentra en el directorio SupportTools\ (amd64 o x86). Debe tener acceso a una entidad de certificación (CA), que puede ser una ENTIDAD de certificación pública como VeriSign, o puede usar Los servicios de certificados de Microsoft.

Implementación de agentes

Los agentes de System Center Operations Manager se pueden instalar mediante uno de los tres métodos siguientes. La mayoría de las instalaciones usan una combinación de estos métodos para instalar los distintos conjuntos de equipos, según corresponda.

Nota:

  • MMA no se puede instalar en un equipo en el que el ya se haya instalado el servidor de administración de Operations Manager, el servidor de puerta de enlace, la consola de operaciones, la base de datos operativa, la consola web, System Center Essentials o System Center Service Manager, ya que estos tienen instalada la versión integrada de MMA.
  • Solo puede usar MMA o el agente de Log Analytics (versión de la extensión de máquina virtual).
  • La detección e instalación de uno o varios agentes desde la consola de Operations. Esta es la forma más común de instalación. Un servidor de administración debe poder conectar el equipo con RPC y la cuenta de acción del servidor de administración u otras credenciales proporcionadas deben tener acceso administrativo al equipo de destino.
  • Inclusión en la imagen de instalación. Se trata de una instalación manual en una imagen base que se usa para la preparación de otros equipos. En este caso, la integración de Active Directory se puede usar para asignar automáticamente el equipo a un servidor de administración tras el primer inicio.
  • Instalación manual. Este método se usa cuando no se puede instalar el agente por alguno de los otros métodos; por ejemplo, cuando la llamada a procedimiento remoto (RPC) no está disponible debido a un firewall. La configuración se ejecuta de manera manual en el agente o se implementa a través de una herramienta de distribución de software existente.

Los agentes que se instalan mediante el Asistente para detección se pueden administrar desde la consola del operador, como actualizar versiones del agente, aplicar revisiones y configurar el servidor de administración al que informa el agente.

Al instalar el agente mediante un método manual, las actualizaciones del agente también se deben realizar manualmente. Podrá usar la integración de Active Directory para asignar agentes a grupos de administración. Para obtener más información, consulte Integración de Active Directory y Operations Manager.

Selecciona la pestaña necesaria para obtener más información sobre la implementación de agentes en sistemas Windows y UNIX y LINUX:

La detección de un sistema Windows requiere que los puertos TCP 135 (RPC), RPC y TCP 445 (SMB) permanezcan abiertos y que el servicio SMB esté habilitado en el equipo agente.

  • Una vez detectado un dispositivo de destino, se puede implementar un agente en él. La instalación del agente requiere:
  • Apertura de puertos RPC a partir del asignador de puntos de conexión TCP 135 y el puerto tcp/UDP 445 del bloque de mensajes del servidor (SMB).
  • Habilitación del uso compartido de archivos e impresoras para redes de Microsoft y el cliente para los servicios de redes de Microsoft. (Esto garantiza que el puerto SMB esté activo).
  • Si está habilitada, la configuración de directiva de grupo de Firewall de Windows para Permitir la excepción de administración remota y Permitir el uso compartido de archivos e impresoras debe establecerse en Permitir mensajes entrantes no solicitados desde a la dirección IP y subredes de los servidores de administración principal y secundario para el agente.
  • Una cuenta que tenga derechos de administrador local en el equipo de destino.
  • Windows Installer 3.1. Para instalarlo, consulte el artículo 893803 en Microsoft Knowledge Basehttps://go.microsoft.com/fwlink/?LinkId=86322.
  • Microsoft Core XML Services (MSXML) 6 en el medio de instalación de productos de Operations Manager en el subdirectorio \msxml. La instalación del agente de inserción instala MSXML 6 en el dispositivo de destino si aún no está instalada.

Asignación de agentes de Active Directory

System Center Operations Manager le permite aprovechar las ventajas de su inversión en Servicios de dominio de Active Directory (AD DS) al permitirle usarlo para asignar equipos administrados por agente a grupos de administración. Esta característica se usa normalmente con el agente implementado como parte de un proceso de compilación de implementación de servidor. Cuando el equipo se pone en línea por primera vez, el agente de Operations Manager consulta Active Directory para su asignación del servidor de administración de conmutación por error y principal e inicia automáticamente la supervisión del equipo.

Para asignar equipos a grupos de administración mediante AD DS:

  • El nivel funcional de los dominios de AD DS debe ser nativo o superior de Windows 2008.
  • Los equipos administrados por agente y todos los servidores de administración deben estar en el mismo dominio o en dominios de confianza bidireccionales.

Nota:

Un agente que determina que está instalado en un controlador de dominio no consultará Active Directory para obtener información de configuración. Esto se debe a motivos de seguridad. La integración de Active Directory está deshabilitada de forma predeterminada en controladores de dominio porque el agente se ejecuta en la cuenta del sistema local. La cuenta del sistema local en un controlador de dominio tiene derechos de administrador de dominio; por lo tanto, detecta todos los puntos de conexión de servicio del servidor de administración registrados en Active Directory, independientemente de la pertenencia al grupo de seguridad del controlador de dominio. Como resultado, el agente intenta conectarse a todos los servidores de administración de todos los grupos de administración. Los resultados pueden ser imprevisibles, lo que supone un riesgo de seguridad.

La asignación del agente se realiza mediante un punto de conexión de servicio (SCP), que es un objeto de Active Directory para publicar información que las aplicaciones cliente pueden usar para enlazar a un servicio. Esto lo crea un administrador de dominio que ejecuta la herramienta de línea de comandos MOMADAdmin.exe para crear un contenedor de AD DS para un grupo de administración de Operations Manager en los dominios de los equipos que administra. El grupo de seguridad de AD DS que se especifica al ejecutar MOMADAdmin.exe se conceden permisos de lectura y eliminación de elementos secundarios al contenedor. El SCP contiene información de conexión al servidor de administración, incluido el FQDN del servidor y el número de puerto. Los agentes de Operations Manager pueden detectar automáticamente los servidores de administración consultando los SCP. La herencia no está deshabilitada y, dado que un agente puede leer la información de integración registrada en AD, si fuerza la herencia para que el grupo Todos lea todos los objetos en el nivel raíz de Active Directory, esto afectará gravemente y, básicamente, interrumpirá la funcionalidad de integración de AD. Si fuerza explícitamente la herencia en todo el directorio al conceder permisos de lectura al grupo Todos, debe bloquear esta herencia en el contenedor de integración de AD de nivel superior, denominado OperationsManager, y en todos los objetos secundarios.  Si no lo hace, la integración de AD no funcionará según lo diseñado y no tendrá una asignación de conmutación por error y principal confiable y coherente para los agentes implementados. Además, si tiene más de un grupo de administración, todos los agentes de ambos grupos de administración también se hospedarán en varios hogares. 

Esta característica funciona bien para controlar la asignación de agentes en una implementación de grupo de administración distribuida, para evitar que los agentes informen a servidores de administración dedicados a grupos de recursos o servidores de administración en un centro de datos secundario en una configuración de espera activa para evitar la conmutación por error del agente durante el funcionamiento normal.

Un administrador de Operations Manager administra la configuración de la asignación de agente y el Asistente para conmutación por error para asignar equipos a un servidor de administración principal y un servidor de administración secundario.

Nota:

La integración de Active Directory está deshabilitada para los agentes que se instalaron desde la consola del operador. De forma predeterminada, la integración de Active Directory está habilitada para los agentes instalados manualmente mediante MOMAgent.msi.

Pasos siguientes