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

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

Puede 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, 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. 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 y, a continuación, 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 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

Puede 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, consulte 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 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 certificados, pero el propio certificado está vacío. Este error puede deberse a un error de conexión SSH al 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 obtener más información, consulte Credenciales que debe 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á el siguiente error al ejecutar el Asistente para detección:

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

Puede ver los detalles básicos del certificado en el equipo UNIX o Linux escribiendo el siguiente comando:

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 resuelve 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 lo resuelve incorrectamente, modifique la entrada DNS para que coincida con el FQDN correcto o agregue una entrada al archivo hosts en el servidor de Operations Manager.

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

  • Cambie el nombre de host en el host DE UNIX o Linux por el correcto y cree un nuevo certificado.

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

Cambie el nombre en el 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 sobrescribir los archivos de /etc/opt/microsoft/scx/ssl.

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

/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  

Agregue una entrada al 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 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  

Problema del paquete 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 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 siguientes tipos de acción personalizados, especifique 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 necesita un shell específico, use el parámetro ExecuteCommand y prefijo 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:

Puede 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. 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 la creación del archivo en blanco, Operations Manager comenzará inmediatamente a registrar la actividad SSH y Certificate en el directorio Temp. Los scripts que llaman al registro de módulos SSH en <Scriptname.vbs>.log. Otros módulos tienen sus propios registros.

En algunos casos, es posible que sea necesario reiniciar HealthService para que el registro 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, 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 enumeran los posibles valores de parámetro:

Nivel	Descripción
Errores	Registre solo mensajes de advertencia o error .
Intermedio	Información de registro, advertencia y mensajes de error.
Verbose	Información de registro, advertencia y mensajes de error con el registro de depuración. Tenga 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.

Uso de DebugView para solucionar problemas de detección

DebugView es un método alternativo a EnableOpsmgrModuleLogging para solucionar 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. Empiece a detectar los agentes DE UNIX. Debería empezar a ver la salida en las ventanas 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 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 supervisa el agente UNIX o Linux, abra un símbolo del sistema.

2. Escriba los siguientes comandos 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 con errores en Operations Manager.

4. Escriba los siguientes comandos 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 conoce como WS-Management (WS-Man).

Nota:

El comando FormatTracing abre una ventana del Explorador de Windows que muestra el C:\Windows\Logs\OpsMgrTrace directorio. 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, 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 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, el agente debe indicarse 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 que sea adecuada para 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

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