Agentes de Operations Manager

  • Artículo

Importante

Esta versión de Operations Manager ha llegado al final del soporte técnico. Se recomienda actualizar a Operations Manager 2022.

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 e 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 de Microsoft Monitoring Agent recopila datos de rendimiento y eventos, 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 informa, el servicio continúa ejecutándose y pone en cola los datos y eventos recopilados, en el disco del equipo supervisado. Cuando la conexión se restaura, el servicio Microsoft Monitoring Agent envía los datos y eventos recopilados al servidor de administración.

Nota

  • En ocasiones, el servicio Microsoft Monitoring Agent se denomina “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 los procesos de MonitoringHost.exe mediante credenciales especificadas. Estos procesos supervisan y recopilan datos de registro de eventos, datos del contador de rendimiento, datos del instrumental de administración de Windows (WMI), y ejecutan acciones como, por ejemplo, los scripts.

Comunicación entre agentes y servidores de administración

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

El agente envía datos de acuerdo con los parámetros de programación de cada regla y monitor. En las reglas de recopilación optimizada, los datos solo se transmiten si la muestra de un contador se diferencia de la muestra anterior en una tolerancia especificada, por ejemplo, 10%. Esto permite reducir el tráfico en la 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 de acuerdo a una programación periódica, de forma predeterminada, cada 60 segundos. La finalidad 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 acerca de los latidos, vea How Heartbeats Work in Operations Manager (Funcionamiento de los latidos en Operations Manager).

Para cada agente, Operations Manager ejecuta un monitor de servicio de mantenimientopara supervisar el estado del servicio de mantenimiento desde la perspectiva del servidor de administración. El agente se comunica con un servidor de administración sobre el puerto TCP 5723.

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

Agente de Linux/UNIX

La arquitectura del agente de UNIX y Linux difiere significativamente de la de un agente de Windows. El agente de Windows tiene un servicio de mantenimiento responsable de evaluar el estado del equipo supervisado. El agente unix y Linux no ejecutan un servicio de mantenimiento; en su lugar, pasa información al servicio de mantenimiento en un servidor de administración que se va a evaluar. 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, el servidor CIM) y un conjunto de proveedores de 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 para la implementación de CIM en el agente, al definir las propiedades y las clases de CIM, interactuar con las API del kernel para recuperar los datos sin procesar, dar formato a los datos (por ejemplo, calculando deltas y promedios) y atender las solicitudes enviadas desde el administrador de objetos CIM. Desde System Center Operations Manager 2007 R2 pasando por System Center 2012 SP1, el administrador de objetos CIM usado en los agentes de UNIX y Linux de Operations Manager es el servidor de OpenPegasus. Los proveedores solían recopilar la información, Microsoft desarrolla los datos de supervisión y se muestran como código libre 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 se basan ahora en una implementación totalmente coherente de Open Management Infrastructure (OMI) como el Administrador de objetos CIM. En el caso de los agentes de UNIX/Linux de Operations Manager, OMI está reemplazando a OpenPegasus. Al igual que OpenPegasus, OMI es una implementación de 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 protocolo de transferencia de archivos de shell seguro (SFTP)

    Se usa para tareas de mantenimiento de agente, como la instalación, actualización y eliminación de agentes.

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

    Todas las operaciones de supervisión usan estos servicios. Incluyen la detección de agentes que ya estaban instalados.

La comunicación entre el servidor de administración de Operations Manager y el agente de UNIX y Linux se realiza mediante WS-Man sobre HTTPS y la interfaz de WinRM. Todas las tareas de mantenimiento de agente se realizan a través de SSH en el puerto 22. Toda la supervisión 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 los monitores, las reglas, las tareas, las recuperaciones y el mantenimiento de agentes, se configuran para usar perfiles predefinidos según sus requisitos de cuenta sin privilegios o con privilegios.

Nota

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

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

  1. Abra el Editor del Registro desde un símbolo del sistema con privilegios elevados.
  2. Cree la clave del Registro UseMIAPI bajo .

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

Seguridad del agente

Autenticación en equipo UNIX o Linux

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

Para obtener instrucciones detalladas para especificar credenciales y configurar cuentas, veaCómo establecer las credenciales para obtener acceso a equipos de Linux y UNIX.

Autenticación con servidor de puerta de enlace

Los servidores de puerta de enlace se usan para habilitar la administración con agente de equipos que están fuera del límite de confianza 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 se encuentra 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 autenticación mutua de Operations Manager.

Esto exige solicitar certificados para cada agente que se notificarán a un servidor de puerta de enlace e importar dichos certificados en el equipo de destino utilizando la herramienta MOMCertImport.exe, que se encuentra en el directorio SupportTools\ (amd64 o x86) del medio de instalación. 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 servicios de certificados de Microsoft.

Implementación de agentes

Los agentes de System Center Operations Manager pueden instalarse 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

  • No se puede instalar MMA en un equipo, donde se instala operations Manager management server, gateway server, operations console, operational database, web console, System Center Essentials o System Center Service Manager, ya que tienen su versión integrada de MMA ya instalada.
  • Solo puede usar MMA o el agente de Log Analytics (versión de la extensión de máquina virtual).
  • Detección e instalación de uno o más agentes desde la Consola del operador. Se trata de la forma más común de instalación. Un servidor de administración debe ser capaz de 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 de una imagen base que se usa para preparar otros equipos. En este caso, la integración de Active Directory puede usarse para asignar automáticamente el equipo a un servidor de administración en la instalación inicial.
  • Instalación manual. Este método se usa cuando uno de los otros métodos no puede instalar el agente, por ejemplo, cuando la llamada a procedimiento remoto (RPC) no está disponible debido a un firewall. La instalación se ejecuta manualmente en el agente o se implementa a través de una herramienta de distribución de software existente.

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

Si instala el agente con un método manual, las actualizaciones del agente también deben realizarse 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.

Seleccione 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 135 (RPC), intervalo de RPC, y TCP 445 (SMB) estén abiertos, y que el servicio SMB esté habilitado en el equipo agente.

  • Se puede implementar un agente en un dispositivo de destino una vez éste ha sido detectado. La instalación del agente requiere:
  • Abrir los puertos RPC, empezando por el asignador de puntos finales TCP 135 y el puerto de bloques de mensajes de servidor (SMB) TCP/UDP 445.
  • Habilitar los servicios Compartir impresoras y archivos para redes Microsoft y Cliente para redes Microsoft. (Esto garantiza que el puerto SMB esté activo).
  • Si está activa, la configuración de la directiva de grupos del Firewall de Windows para Permitir excepción de administración remota y Permitir la excepción compartir impresoras y archivos debe ser Permitir mensajes entrantes no solicitados de: para la dirección IP y las subredes de los servidores de administración principal y secundario del agente.
  • Una cuenta que tenga derechos de administrador local en el equipo de destino.
  • Windows Installer 3.1. Para instalar, 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 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 permite aprovechar la inversión en Active Directory Domain Services (AD DS) ya que permite emplearlo 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. La primera vez que se conecta el equipo, el agente de Operations Manager consulta a Active Directory para la asignación de su servidor de administración primario y de conmutación por error e inicia automáticamente la supervisión del equipo.

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

  • El nivel de funcionalidad de dominios AD DS debe ser Windows 2008 nativo o superior.
  • 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 es por motivos de seguridad. La integración de Active Directory está deshabilitada de forma predeterminada en los controladores de dominio porque el agente se ejecuta bajo la cuenta Sistema local. La cuenta Sistema local en un controlador de dominio tiene derechos de administrador de dominio; por lo 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 en todos los grupos de administración. Los resultados pueden ser impredecibles, por lo que representan un riesgo de seguridad.

La asignación de agente se efectúa 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. Lo crea un administrador de dominios mediante la ejecución de 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 especificado al ejecutar MOMADAdmin.exe se le conceden permisos De lectura y eliminación 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 mediante una consulta de 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 principal y coherente y coherente para los agentes implementados. Además, si resulta que tiene más de un grupo de administración, todos los agentes de los grupos de administración también tendrán hosts múltiples. 

Esta característica funciona bien para controlar la asignación de agentes en una implementación de grupo de administración distribuida, para impedir que los agentes informen a los 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 de agente durante el funcionamiento normal.

Un administrador de Operations Manager gestiona la configuración de la asignación de agentes con el Asistente para asignación de agente y conmutación por error para asignar equipos a un servidor de administración principal y a 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