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 que Operations Manager supervise los sistemas operativos de Windows, Linux y UNIX, así como los componentes de un servicio de TI instalado 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 de 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 procesos MonitoringHost.exe mediante credenciales especificadas. Estos procesos supervisan y recopilan datos de registro de eventos, datos de contador de rendimiento, datos del 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 una alerta y datos detectados a su servidor de administración primario 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, que es cada 60 segundos de forma predeterminada. 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 del agente en una comunicación con un servidor de administración.

Agente Linux/UNIX

La arquitectura del agente de 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 de 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 e informar 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 de código abierto, ligero y portátil, aunque es más ligero 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. Todo el seguimiento de 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. Ponte 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 pueden 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án en uso de forma predeterminada. Para aprovechar esta mejora, debes crear la clave del Registro UseMIAPI con el fin de habilitar Operations Manager para que use las nuevas API de MI asincrónica en servidores de administración que supervisen sistemas Linux y Unix.

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

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

Seguridad del agente

Autenticación en equipos UNIX/Linux

En Operations Manager, ya no es necesario el administrador del sistema 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, consulta Establecimiento de 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 solicites 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 de medios de instalación SupportTools\ (amd64 o x86). Debes tener acceso a una entidad de certificación (CA), que puede ser una CA pública como VeriSign o puedes usar los Servicios de servidor 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 de Windows requiere que los puertos TCP de 135 (RPC), intervalo de 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 el:
  • Abrir los 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).
  • Habilitar el uso compartido de archivos e impresora para Networks de Microsoft y el Cliente para los servicios de Networks de Microsoft. (Esto garantiza que el puerto SMB esté activo).
  • Si está habilitada, la configuración de directivas del 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 la dirección IP y subredes de los servidores de administración principales y secundarios para el agente.
  • Una cuenta con derechos de administrador local en el equipo de destino.
  • Windows Installer 3.1. Para instalarlo, consulte el artículo 893803 en Microsoft Knowledge Base https://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á instalado.

Asignación de agentes de Active Directory

System Center Operations Manager te permite aprovechar las ventajas de tu inversión en Servicios de dominio de Active Directory (AD DS) al permitirte 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 Windows 2008 nativo o posterior
  • 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á a Active Directory para obtener información sobre la configuración. Esto es por razones 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 tanto, detecta todos los puntos de conexión del servicio de servidor de administración que están registrados en Active Directory, independientemente de la pertenencia a grupos 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. Al grupo de seguridad de AD DS que se especifica al ejecutar MOMADAdmin.exe se le conceden permisos de lectura y eliminación de elementos secundarios en el contenedor. El SCP contiene información de conexión al servidor de administración, incluido el FQDN y el número de puerto del servidor. Los agentes de Operations Manager pueden detectar automáticamente los servidores de administración consultando los SCP. La herencia no se deshabilita y, como un agente puede leer la información de integración registrada en AD, si fuerzas la herencia para que el grupo Todos lea todos los objetos en el nivel raíz de Active Directory, esto afectará gravemente e interrumpirá esencialmente 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 haces, la integración de AD no funcionará según lo diseñado y no tendrás una asignación de conmutación por error y principal confiable y coherente para los agentes implementados. Además, si tienes 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 la operación normal.

Un administrador de Operations Manager administra la configuración de la asignación de agentes mediante la Asignación de asistentes 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