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

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

Puede supervisar los siguientes aspectos de equipos UNIX y Linux:

• Servicios y aplicaciones

• Archivos de sistema, espacio en disco, espacio de intercambio, memoria del sistema

• Interfaces de red

• Atributos y procesos básicos

• Configuraciones clave

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

1. Importe los módulos de administración descargando las versiones más recientes del Centro de descarga de Microsoft.
2. Cree un grupo de recursos dedicado para supervisar equipos UNIX y Linux.
3. Configure los certificados para cada servidor de administración del grupo.
4. Cree y configure cuentas de ejecución.
5. Instale el agente en UNIX y Linux mediante 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, debe comprobar que se están supervisando correctamente. Después de implementar un agente, las cuentas de ejecución se usan para realizar detecciones en ejecución mediante las reglas de detección aplicables y, después, iniciar la supervisión. Después de varios minutos, en el área de trabajo Administración, vaya a Administración de dispositivos/Equipos UNIX/Linux y compruebe que los equipos no aparecen como Desconocido. 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

Puede proporcionar funcionalidades adicionales de supervisión e interacción con los equipos UNIX y Linux administrados mediante las plantillas de los módulos de administración de UNIX y Linux. Para obtener más información, consulte UNIX or Linux Log File (Archivo de registro de UNIX o Linux) y UNIX or Linux Service (Servicio de UNIX o Linux) en la Guía de creación.

Solución de problemas de la 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 vea 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 certificado y el certificado está vacío. Este error puede deberse a un error de conexión de SSH con el sistema remoto.

Si ve este error, haga lo siguiente:

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

2. Asegúrese de que puede abrir una sesión ssh con el host remoto mediante las credenciales especificadas en el Asistente para detección.

3. Asegúrese de que las credenciales especificadas en el Asistente para detección tengan los privilegios necesarios para la detección. Para más información, vea Credenciales necesarias para tener acceso a equipos UNIX y Linux.

El nombre de certificado y el nombre de host no coinciden

El nombre común 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á el siguiente error al ejecutar el Asistente para detección:

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

Para ver los detalles básicos del certificado del equipo UNIX o Linux, escriba el comando siguiente:

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

Al hacerlo, verá 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  

Valide los nombres de host y las fechas, y asegúrese de que coinciden con el nombre que está resolviendo el servidor de administración de Operations Manager.

Si los nombres de host no coinciden, use 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 de Operations Manager no lo está resolviendo correctamente, modifique la entrada DNS para que coincida con el FQDN correcto o bien agregue una entrada al archivo de hosts del servidor de Operations Manager.

• Si el nombre de host de UNIX o Linux no es correcto, siga uno de los siguientes procedimientos:

  • Corrija el nombre de host en el host de UNIX o Linux y cree un nuevo certificado.

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

Para cambiar el nombre del certificado:

Si el certificado se creó con un nombre incorrecto, puede cambiar el nombre de host y volver a crear el certificado y la clave privada. Para ello, ejecute el siguiente comando en el equipo UNIX o Linux:

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

La opción -f obliga a que se sobrescriban los archivos ubicados en /etc/opt/microsoft/scx/ssl.

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

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

Ejecute el comando siguiente para reiniciar el agente:

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

Para agregar una entrada en el archivo de hosts:

Si el FQDN no está en DNS inverso, puede 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 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, agregue lo siguiente al final del archivo de hosts:

192.168.1.1      newhostname.newdomain.name  

Problemas de módulos de administración

ExecuteCommand no admite los operadores de canalización o los alias

Cuando se utiliza 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 admite 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 tipos de acciones personalizadas siguientes, se 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 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 es compatible con la canalización, los alias y la sintaxis específica del shell.

Nota

El parámetro ExecuteShellCommand utiliza el shell predeterminado del usuario que ejecuta el comando. Si necesita un shell específico, utilice el parámetro ExecuteCommand y agregue un prefijo con el shell requerido a los argumentos de comando.

Los ejemplos siguientes muestran cómo utilizar los parámetros ExecuteCommand y ExecuteShellCommand :

• Para pasar los argumentos de 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 línea de comandos a un proceso de shell que hace 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 utiliza 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>

Logging and Debugging

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:

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

Habilitar el registro de módulos de Operations Manager

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

Nota

Las llamadas realizadas fuera de Administración remota de Windows (WinRM) se realizan mediante SSH/SFTP. Estos componentes se basan en un mecanismo de registro independiente de 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. Cree un archivo en blanco denominado EnableOpsmgrModuleLogging en el directorio Temp de la cuenta de usuario que llama a estos módulos escribiendo en una línea de comandos o un símbolo del sistema 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. Después de crear el archivo en blanco, Operations Manager comenzará inmediatamente a registrar ssh y actividad de certificado en el directorio temp. Los scripts que llaman al registro de módulos SSH para <Scriptname.vbs>.log. El resto de módulos tiene sus propios registros.

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

Habilitar el registro en el agente de UNIX

Estos registros informarán de las acciones de los agentes de UNIX. Si hay un problema con los datos devueltos a Operations Manager, busque en este registro. Puede 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 enumera los valores de parámetro posibles:

Nivel	Descripción
Errors	Registrar solo mensajes de advertencia o error .
Intermedio	Mensajes de información de registro, advertencia y error .
Verbose	Registrar mensajes de información, Advertenciay Error con registro de depuración. Tenga en cuenta que este nivel de registro puede provocar un rápido crecimiento del 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.

Use DebugView para solucionar problemas de detección

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

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

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

3. Inicie la detección de agentes de UNIX. Deberá comenzar a ver los resultados en las ventanas de DebugView.

4. DebugView mostrará un procedimiento detallado del proceso del asistente para detección. Este suele ser el método más rápido para la solución de problemas de detección.

Habilitar el registro de Operations Manager para la Administración remota de Windows

Este método de seguimiento detallado se utiliza para ver las consultas de Administración remota de Windows (WinRM) que Operations Manager utiliza para recopilar datos del agente. Si sospecha 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 está supervisando al agente de UNIX o Linux, abra una ventana de símbolo del sistema.

2. Escriba los comandos siguientes en el símbolo del sistema:

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

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Reproduzca el problema que causa el error en Operations Manager.

4. Escriba los comandos siguientes en el símbolo del sistema:

   1. StopTracing.cmd

   2. FormatTracing.cmd

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

Nota

WinRM también se denomina 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 se encuentra en ese directorio.

Administrar 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, implemente 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 puede configurarse para controlar los archivos de registro que usan los agentes de Operations Manager para UNIX o Linux. Después de girar o modificar los archivos de registro del agente, se 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 rotar 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, modifique la configuración para adecuarla a su entorno y vincule o guarde 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

Si quiere obtener instrucciones adicionales para resolver problemas comunes de implementación de agentes, revise Solución de problemas de Operations Manager 2012: wiki de detección de agentes de UNIX/Linux.