Compartir a través de

Solución de problemas de supervisión de equipos UNIX y Linux

  • Artículo

System Center Operations Manager proporciona supervisión de equipos UNIX y Linux similares a la supervisión de equipos Windows. Puedes supervisar el estado, el rendimiento, obtener informes, ejecutar tareas e implementar instrumentación de supervisión personalizada.

Puedes supervisar los siguientes aspectos de los equipos UNIX y Linux:

  • Servicios y aplicaciones

  • Sistema de archivos, espacio en disco, espacio de intercambio, memoria del sistema

  • Interfaces de red

  • Procesos y atributos principales

  • Configuraciones clave

Para poder supervisar equipos UNIX y Linux, debes completar los pasos siguientes:

  1. Descarga las versiones más recientes del Centro de descarga de Microsoft para importar los módulos de administración.
  2. Crea un grupo de recursos dedicado para supervisar equipos UNIX y Linux.
  3. Configura los certificados para cada servidor de administración del grupo.
  4. Crea y configura cuentas de ejecución.
  5. Instala el agente en UNIX y Linux utilizando el Asistente para detección.
  1. Descarga las versiones más recientes del Centro de descarga de Microsoft para importar los módulos de administración.
  2. Crea un grupo de recursos dedicado para supervisar equipos UNIX y Linux.
  3. Configura los certificados para cada servidor de administración del grupo.
  4. Crea y configura cuentas de ejecución.
  5. Instala el agente en UNIX y Linux utilizando el Asistente para detección.
  1. Descarga las versiones más recientes del Centro de descarga de Microsoft para importar los módulos de administración.
  2. Crea un grupo de recursos dedicado para supervisar equipos UNIX y Linux.
  3. Configura los certificados para cada servidor de administración del grupo.
  4. Crea y configura cuentas de ejecución.
  5. Instala el agente en UNIX y Linux utilizando el Asistente para detección.

Después de completar los pasos anteriores y detectar e implementar correctamente el agente en uno o varios equipos UNIX y Linux, debes comprobar que se están supervisando correctamente. Una vez implementado un agente, las cuentas de ejecución se usan para realizar detecciones que se ejecutan mediante las reglas de detección aplicables para luego iniciar la supervisión. Después de varios minutos, en el área de trabajo de administración, ve a Administración de dispositivos/Equipos UNIX/Linux y comprueba que los equipos no aparecen como Desconocidos. Deben detectarse y mostrar la versión específica del sistema operativo y la distribución.

De forma predeterminada, Operations Manager supervisa los siguientes objetos de sistema operativo:

  • Sistema operativo
  • Disco lógico
  • Adaptadores de red

Puedes proporcionar funcionalidades de supervisión e interacción adicionales con los equipos UNIX y Linux administrados mediante las plantillas del módulo de supervisión de UNIX y Linux. Para obtener más información, consulta Archivo de registro de UNIX o Linux y Proceso de UNIX o Linux en la Guía de creación.

Solución de problemas de supervisión de UNIX y Linux

En la sección siguiente se proporciona información sobre los problemas que pueden producirse con la supervisión de equipos UNIX y Linux en Operations Manager.

Mensaje de error de firma de certificado

Durante la instalación de agentes de UNIX/Linux, es posible que veas el siguiente error.

Event Type: Error  
Event Source: Cross Platform Modules  
Event Category: None  
Event ID: 256  
Date: 4/1/2009  
Time: 4:02:27 PM  
User: N/A  
Computer: COMPUTER1  
Description: Unexpected ScxCertLibException: Can't decode from base64  
; input data is:

Este error se produce cuando se llama al módulo de firma de certificados, pero el propio certificado está vacío. Este error puede deberse a un error de conexión SSH al sistema remoto.

Si ves este error, comprueba lo siguiente:

  1. Asegúrate de que el demonio SSH en el host remoto se está ejecutando.

  2. Asegúrate de que puedes abrir una sesión SSH con el host remoto mediante las credenciales especificadas en el Asistente para detección.

  3. Asegúrate de que las credenciales especificadas en el Asistente para detección tengan los privilegios necesarios para la detección. Para obtener más información, consulta Credenciales que se deben tener para acceder a equipos UNIX y Linux.

El nombre del certificado y el nombre de host no coinciden

El nombre común (CN) que se usa en el certificado debe coincidir con el nombre de dominio completo (FQDN) resuelto por Operations Manager. Si el CN no coincide, verás el siguiente error al ejecutar el asistente de detección:

The SSL certificate contains a common name (CN) that doesn't match the hostname

Puedes ver los detalles básicos del certificado en el equipo UNIX o Linux al escribir el siguiente comando:

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates

Al hacerlo, verás una salida similar a la siguiente:

subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
notBefore=Mar 25 05:21:18 2008 GMT  
notAfter=Mar 20 05:21:18 2029 GMT

Valida los nombres de host y las fechas y asegúrate de que coinciden con el nombre que resuelve el servidor de administración del Operations Manager.

Si los nombres de host no coinciden, usa una de las siguientes acciones para resolver el problema:

  • Si el nombre de host de UNIX o Linux es correcto, pero el servidor de administración del Operations Manager lo resuelve incorrectamente, modifica la entrada DNS para que coincida con el FQDN correcto o agrega una entrada al archivo hosts en el servidor del Operations Manager.

  • Si el nombre de host de UNIX o Linux es incorrecto, realiza una de las acciones siguientes:

    • Cambia el nombre de host en el host UNIX o Linux por el correcto y crea un nuevo certificado.

    • Crea un certificado nuevo con el nombre de host deseado.

Cambio del nombre en el certificado:

Si el certificado se ha creado con un nombre incorrecto, puedes cambiar el nombre de host y volver a crear el certificado y la clave privada. Para ello, ejecuta el siguiente comando en el equipo UNIX o Linux:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -v

La opción -f obliga a sobrescribir los archivos de /etc/opt/microsoft/scx/ssl.

También puedes cambiar el nombre de host y el nombre de dominio en el certificado usando los modificadores -h y -d, como en el siguiente ejemplo:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>

Ejecuta el comando siguiente para reiniciar el agente:

/opt/microsoft/scx/bin/tools/scxadmin -restart

Agrega una entrada al archivo de hosts:

Si el FQDN no está en DNS inverso, puedes agregar una entrada al archivo de hosts ubicado en el servidor de administración para proporcionar resolución de nombres. El archivo de hosts se encuentra en la carpeta Windows\System32\Drivers\etc. Una entrada en el archivo de hosts es una combinación de la dirección IP y el FQDN.

Por ejemplo, para agregar una entrada para el host denominado newhostname.newdomain.name con una dirección IP de 192.168.1.1, agrega lo siguiente al final del archivo de hosts:

192.168.1.1      newhostname.newdomain.name

Problema del módulo de administración

ExecuteCommand no admite operadores de canalización ni alias

Cuando se usa un alias o un operador de canalización con el parámetro ExecuteCommand, se produce un error en el comando. El parámetro ExecuteCommand no es compatible con el operador de canalización, los alias y la sintaxis específica del shell.

En los módulos de administración de System Center Operations Manager diseñados para administrar equipos UNIX y Linux, el parámetro ExecuteCommand no inicia un proceso de shell, lo que provoca un error en la acción personalizada.

Para cada uno de los siguientes tipos de acción personalizados, especifica cómo se invocan los argumentos de comando mediante el parámetro ExecuteCommand o el parámetro ExecuteShellCommand:

  • Microsoft.Unix.WSMan.Invoke.ProbeAction

  • Microsoft.Unix.WSMan.Invoke.WriteAction

  • Microsoft.Unix.WSMan.Invoke.Privileged.ProbeAction

  • Microsoft.Unix.WSMan.Invoke.Privileged.WriteAction

El parámetro ExecuteCommand pasa los argumentos de la línea de comandos a la consola sin iniciar un proceso de shell.

El parámetro ExecuteShellCommand pasa los argumentos de comando a un proceso de shell mediante el shell predeterminado del usuario; este shell admite canalización, alias y sintaxis específica del shell.

Nota:

El parámetro ExecuteShellCommand usa el shell predeterminado del usuario que ejecuta el comando. Si necesitas un shell específico, usa el parámetro ExecuteCommand y prefija los argumentos de comando con el shell necesario.

En los ejemplos siguientes se muestra cómo usar los parámetros ExecuteCommand y ExecuteShellCommand:

  • Para pasar los argumentos de la línea de comandos a la consola sin iniciar un proceso de shell:

    <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> service syslog status </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

  • Para pasar los argumentos de la línea de comandos a un proceso de shell que haga referencia a un shell explícito:

    <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> /bin/sh ps -ef syslog | grep -v grep </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

  • Para pasar los argumentos de comando a un proceso de shell que usa el shell predeterminado del usuario:

    <p:ExecuteShellCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> uptime |&nbsp; awk '{print $10}' |awk -F"," '{print $1}' </p:Command> <p:timeout>10</p:timeout> </p:ExecuteShellCommand_INPUT>

Registro y depuración

En esta sección se describe cómo habilitar las herramientas de registro y depuración para solucionar problemas con la supervisión de equipos UNIX y Linux.

Nota:

Con Operations Manager 2019 UR3, la configuración de nivel de registro se puede cambiar sin reiniciar el agente. Más información.

Nota:

Puedes cambiar la configuración de nivel de registro sin reiniciar el agente. Más información.

Habilitación del registro de módulos de Operations Manager

Los agentes de Operations Manager para UNIX y Linux mantienen varios archivos de registro que pueden resultar útiles al solucionar problemas de cliente. Estos archivos de registro se encuentran en el equipo UNIX o Linux administrado. El nivel de registro de los archivos de registro del agente se puede configurar según sea necesario. El registro más detallado puede ser útil para diagnosticar un problema. En el caso de la operación normal, los niveles de registro no deben establecerse en un valor más detallado que las configuraciones predeterminadas (intermedias) para evitar un crecimiento excesivo del archivo de registro.

Nota:

Las llamadas realizadas fuera de la administración remota de Windows (WinRM) se realizan mediante SSH/SFTP. Estos componentes se basan en un mecanismo de registro independiente que Operations Manager.

Nota:

El nivel de registro del archivo de registro de omiserver.log no se puede cambiar del valor predeterminado en esta versión de los agentes de Operations Manager para UNIX y Linux.

  1. Crea un archivo en blanco denominado EnableOpsmgrModuleLogging en el directorio Temp de la cuenta de usuario que llama a estos módulos. Para ello, escribe lo siguiente en un símbolo del sistema o de PowerShell:

    COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging

    New-Item "$env:windir\TEMP\EnableOpsMgrModuleLogging"

    Nota:

    Por lo general, es la cuenta SYSTEM que realiza las llamadas y C:\Windows\Temp es la carpeta temporal SYSTEM predeterminada.

  2. En cuanto crees el archivo en blanco, Operations Manager comenzará la actividad de registro de SSH y de certificados en el directorio Temp. Los scripts que llamen a los módulos SSH se registrarán en <Scriptname.vbs>.log. Otros módulos tienen sus propios registros.

En algunos casos, es posible que haya que reiniciar HealthService para que el registro de EnableOpsmgrModuleLogging surta efecto.

Habilitación del registro en el agente UNIX

Estos registros notificarán las acciones del agente UNIX. Si hay un problema con los datos devueltos a Operations Manager, busca en este registro. Puedes establecer la cantidad de información registrada con el comando scxadmin. La sintaxis de este comando es la siguiente:

scxadmin -log-set [all|cimom|provider] {verbose|intermediate|errors}

En la tabla siguiente, se muestran los valores posibles para el parámetro:

Nivel Descripción
Errores Registrar solo mensajes de advertencia o error.
Intermedio Registrar mensajes de información, advertencia y error.
Detallado Registrar mensajes de Información, advertencia y error con el registro de depuración. Ten en cuenta que es probable que este nivel de registro cause un rápido crecimiento en el tamaño de los archivos de registro. Se recomienda que esta opción solo se use durante breves períodos de tiempo para diagnosticar un problema específico.

Utilización de DebugView para solucionar problemas de detección

DebugView es un método alternativo a EnableOpsmgrModuleLogging para solucionar problemas de detección.

  1. Descarga DebugView desde: https://go.microsoft.comfwlink/?Linkid=129486.

  2. Inicia DebugView en el servidor de administración que realiza la detección.

  3. Empieza a detectar los agentes de UNIX. Deberías empezar a ver la salida en las ventanas de DebugView.

  4. DebugView presentará una lectura paso a paso del proceso del Asistente para detección. Este suele ser el método más rápido para solucionar problemas de detección.

Habilitación del registro de Operations Manager para la administración remota de Windows

Este método de seguimiento detallado se usa para ver las consultas de Administración remota de Windows (WinRM) usadas por Operations Manager para recopilar datos del agente. Si sospechas que hay un problema con la conexión WinRM, este registro proporciona información detallada que puede ayudar con la solución de problemas.

  1. En el servidor de administración que supervisa el agente UNIX o Linux, abre un símbolo del sistema.

  2. En el símbolo del sistema, escribe los siguientes comandos:

    1. cd C:\Program Files\Microsoft System Center\Operations Manager\Tools

    2. StopTracing.cmd

    3. StartTracing.cmd VER

  3. Reproduce el problema con errores en Operations Manager.

  4. En el símbolo del sistema, escribe los siguientes comandos:

    1. StopTracing.cmd

    2. FormatTracing.cmd

  5. Busca WS-Man en el archivo TracingGuidsNative.log.

Nota:

WinRM también se conoce como WS-Management (WS-Man).

Nota:

El comando FormatTracing abre una ventana del Explorador de Windows que muestra el directorio C:\Windows\Logs\OpsMgrTrace. El archivo TracingGuidsNative.log está en ese directorio.

Administración de archivos de registro de UNIX y Linux

Los agentes de Operations Manager para UNIX y Linux no limitan el tamaño de los archivos de registro del agente. Para controlar el tamaño máximo de los archivos de registro, implementa un proceso para administrar los archivos de registro. Por ejemplo, la utilidad estándar logrotate está disponible en muchos sistemas operativos UNIX y Linux. La utilidad logrotate se puede configurar para controlar los archivos de registro utilizados por los agentes de Operations Manager para UNIX o Linux. Después de girar o modificar los archivos de registro del agente, se le debe indicar al agente que los registros se han girado para reanudar el registro. El comando scxadmin puede utilizarse con el parámetro -log-rotate con la sintaxis siguiente:

scxadmin -log-rotate all

Archivo de configuración de Logrotate de ejemplo

En el ejemplo siguiente se muestra un archivo de configuración para girar los archivos de scx.log y omiserver.log con la utilidad logrotate de Linux. Normalmente, logrotate se ejecutará como un trabajo programado (con crond) y actuará en los archivos de configuración que se encuentran en /etc/logrotate.d. Para probar y usar este archivo de configuración, modifica la configuración para que sea adecuada para tu entorno y vincula o guarda el archivo en /etc/logrotate.d.

#opsmgr.lr  

#Rotate scx.log  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all  
endscript  
}

#Rotate scx.log for the monitoring user account named: monuser  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/monuser/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all
endscript  
}  

#Optionally, rotate omiserver.log. This requires that OMI be stopped and started to prevent  
#impact to logging. Monthly rotation, retain two weeks of compressed logs  
#Uncomment these lines if rotation of omiserver.log is needed  

#/var/opt/microsoft/scx/log/omiserver.log{  
#        rotate 2  
#        monthly  
#        compress  
#        missingok  
#        notifempty  
#        prerotate  
#        /usr/sbin/scxadmin -stop  
#        endscript  
#        postrotate  
#        /usr/sbin/scxadmin -start  
#        endscript\
#}

Pasos siguientes

Para obtener instrucciones adicionales para ayudar a resolver problemas comunes de implementación de agentes, consulta la Solución de problemas de Operations Manager 2012: Wiki de detección del agente de UNIX/Linux.