Resolver problemas de monitorização de computadores UNIX e Linux

System Center - Operations Manager fornece monitorização de computadores UNIX e Linux semelhantes à monitorização de computadores Windows. Pode monitorizar o estado de funcionamento, o desempenho, obter relatórios, executar tarefas e implementar a instrumentação de monitorização personalizada.

Pode monitorizar os seguintes aspetos dos computadores UNIX e Linux:

• Serviços e aplicações

• Sistema de ficheiros, espaço em disco, espaço de comutação, memória do sistema

• Interfaces de rede

• Processos principais e atributos

• Configurações chave

Antes de poder monitorizar computadores UNIX e Linux, tem de concluir os seguintes passos:

1. Importe pacotes de gestão ao transferir as versões mais recentes do Centro de Transferências da Microsoft.
2. Crie um conjunto de recursos dedicado para monitorizar computadores UNIX e Linux.
3. Configure os certificados para cada servidor de gestão no conjunto.
4. Criar e configurar contas Run As.
5. Instale o agente no UNIX e linux com o Assistente de Deteção.

Depois de concluir os passos acima e detetar e implementar com êxito o agente num ou mais computadores UNIX e Linux, deve verificar se estão a ser monitorizados corretamente. Após a implementação de um agente, as contas Run As são utilizadas para realizar deteções em execução com as regras de deteção aplicáveis e, em seguida, iniciar a monitorização. Após vários minutos, na área de trabalho Administração, navegue para computadores Gestão de Dispositivos/UNIX/Linux e verifique se os computadores não estão listados como Desconhecidos. Devem ser detetadas e mostrar a versão específica do SO e a distribuição.

Por predefinição, o Operations Manager monitoriza os seguintes objetos do sistema operativo:

• Sistema Operativo
• Disco lógico
• Adaptadores de Rede

Pode fornecer capacidades adicionais de monitorização e interação com os computadores UNIX e Linux geridos, utilizando os modelos de pacotes de monitorização para UNIX e Linux. Para obter mais informações, veja Ficheiro de Registo UNIX ou Linux e Processo UNIX ou Linux no Guia de Criação.

Resolver problemas de monitorização de UNIX e Linux

A secção seguinte fornece informações sobre problemas que podem ocorrer com a monitorização de computadores UNIX e Linux no Operations Manager.

Mensagem de Erro de Assinatura do Certificado

Durante a instalação de agentes UNIX/Linux, poderá ver o seguinte erro.

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 erro ocorre quando o módulo de assinatura do certificado é utilizado, mas o certificado propriamente dito está vazio. Este erro pode ser causado por uma falha de ligação SSH ao sistema remoto.

Se este erro ocorrer, efetue o seguinte:

1. Certifique-se de que o daemon SSH no anfitrião remoto está em execução.

2. Certifique-se de que pode abrir uma sessão SSH com o anfitrião remoto com as credenciais especificadas no Assistente de Deteção.

3. Certifique-se de que as credenciais especificadas no Assistente de Deteção têm os privilégios necessários para a deteção. Para obter mais informações, veja Credenciais Que Tem de Ter para Aceder a Computadores UNIX e Linux.

Nome do Certificado e Nome de Anfitrião não Coincidem

O nome comum (CN) utilizado no certificado tem de corresponder ao nome de domínio completamente qualificado (FQDN) que é resolvido pelo Operations Manager. Se o CN não corresponder, verá o seguinte erro ao executar o Assistente de Deteção:

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

Pode visualizar os detalhes básicos do certificado no computador UNIX ou Linux, introduzindo o seguinte comando:

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

Quando o fizer, verá um resultado semelhante ao seguinte:

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 as datas e os nomes de anfitriões e certifique-se de que os ficheiros coincidem com o nome a ser resolvido pelo servidor de gestão do Operations Manager.

Se os nomes de anfitrião não corresponderem, utilize uma das seguintes ações para resolver o problema:

• Se o nome de anfitrião UNIX ou Linux estiver correto, mas o servidor de gestão do Operations Manager estiver a resolvê-lo incorretamente, modifique a entrada de DNS de forma a coincidir ao FQDN correto ou adicione uma entrada ao ficheiro de anfitriões no servidor do Operations Manager.

• Se o nome de anfitrião UNIX ou Linux estiver incorreto, efetue um dos seguintes procedimentos:

  • Altere o nome de anfitrião no anfitrião UNIX ou Linux para o correto e crie um novo certificado.

  • Crie um novo certificado com o nome de anfitrião desejado.

Para Alterar o Nome no Certificado:

Se o certificado foi criado com um nome incorreto, pode alterar o nome de anfitrião e voltar a criar o certificado e a chave privada. Para tal, execute o seguinte comando no computador UNIX ou Linux:

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

A opção -f força os ficheiros em /etc/opt/microsoft/scx/ssl a serem substituídos.

Também pode alterar o nome de anfitrião e o nome de domínio no certificado com os comutadores -h e -d , tal como no exemplo seguinte:

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

Reinicie o agente ao executar o seguinte comando:

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

Para adicionar uma entrada ao ficheiro de anfitriões:

Se o FQDN não estiver no DNS Inverso, pode adicionar uma entrada ao ficheiro de anfitriões localizado no servidor de gestão para fornecer a resolução de nomes. O ficheiro de anfitriões está localizado na pasta Windows\System32\Drivers\etc. Uma entrada no ficheiro de anfitriões é uma combinação do endereço IP e do FQDN.

Por exemplo, para adicionar uma entrada para o anfitrião com o nome newhostname.newdomain.name com um endereço IP de 192.168.1.1, adicione o seguinte ao final do ficheiro de anfitriões:

192.168.1.1      newhostname.newdomain.name  

Problemas do pacote de gestão

ExecuteCommand não Suporta Operadores de Pipeline ou Aliases

Quando utiliza um alias ou um operador de pipeline com o parâmetro ExecuteCommand , o comando falha. O parâmetro ExecuteCommand não suporta o operador de pipeline, os aliases e a sintaxe específica da shell.

Nos pacotes de gestão do System Center Operations Manager concebidos para gerir computadores UNIX e Linux, o parâmetro ExecuteCommand não inicia um processo de shell, o que faz com que a ação personalizada falhe.

Para cada um dos seguintes tipos de ações personalizadas, especifique como os argumentos de comando são invocados através do parâmetro ExecuteCommand ou do 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

O parâmetro ExecuteCommand transmite os argumentos da linha de comandos para a consola sem iniciar um processo de shell.

O parâmetro ExecuteShellCommand transmite os argumentos de comando para um processo de shell com a shell predefinida do utilizador; esta shell suporta pipeline, aliases e sintaxe específica da shell.

Nota

O parâmetro ExecuteShellCommand utiliza a shell predefinida do utilizador que está a executar o comando. Se precisar de uma shell específica, utilize o parâmetro ExecuteCommand e prefixe os argumentos de comando com a shell necessária.

Os exemplos seguintes mostram como utilizar os parâmetros ExecuteCommand e ExecuteShellCommand :

• Para passar os argumentos da linha de comandos para a consola sem iniciar um processo 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 passar os argumentos da linha de comandos para um processo de shell que referencia uma shell explícita:

  <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 passar os argumentos de comando para um processo de shell que utiliza a shell predefinida do utilizador:

  <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>

Registo e Depuração

Esta secção descreve como ativar as ferramentas de registo e depuração para resolver problemas com a monitorização de computadores UNIX e Linux.

Nota

Pode alterar as definições ao nível do registo sem o reinício do agente. Saiba mais.

Ativar o Registo de Módulos do Operations Manager

Os Agentes do Operations Manager para UNIX e Linux mantêm vários ficheiros de registo que podem ser úteis ao resolver problemas do cliente. Estes ficheiros de registo estão localizados no computador UNIX ou Linux gerido. O nível de registo dos ficheiros de registo do agente pode ser configurado conforme necessário. Para diagnosticar problemas, poderá ser útil um registo mais verboso. Para uma operação normal, os níveis de registo não devem ser definidos para um valor mais verboso do que as configurações predefinidas (Intermédios), de modo a evitar o crescimento excessivo do ficheiro de registo.

Nota

As chamadas efetuadas fora da Gestão Remota do Windows (WinRM) são efetuadas utilizando SSH/SFTP. Estes componentes dependem de um mecanismo de registo separado, diferente do Operations Manager.

Nota

O nível de registo do ficheiro de registo omiserver.log não pode ser alterado a partir da predefinição nesta versão dos Agentes do Operations Manager para UNIX e Linux.

1. Crie um ficheiro em branco com o nome EnableOpsmgrModuleLogging no diretório Temp para a conta de utilizador que chama estes módulos ao escrever numa linha de comandos ou numa linha de comandos do PowerShell:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Nota

   Geralmente, é a conta SYSTEM que faz as chamadas e C:\Windows\Temp é a pasta temporária do SISTEMA predefinida.

2. Após a criação do ficheiro em branco, o Operations Manager começará imediatamente a registar a atividade SSH e Certificado no diretório Temp. Os scripts que chamam o registo dos módulos SSH para <Scriptname.vbs>.log. Outros módulos têm os seus próprios registos.

Em alguns casos, poderá ser necessário reiniciar o HealthService para que o registo EnableOpsmgrModuleLogging entre em vigor.

Activar o Registo no Agente UNIX

Estes registos irão comunicar as acções do agente UNIX. Se houver um problema com os dados devolvidos ao Operations Manager, procure neste registo. Pode definir a quantidade de informações registadas com o comando scxadmin. A sintaxe para este comando é:

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

A tabela seguinte lista os valores de parâmetros possíveis:

Level	Description
Erros	Regista apenas mensagens de Aviso ou Erro .
Intermédio	Informações de Registo, Aviso e Mensagens de erro.
Verboso	Regista mensagens de Informação, Avisoe Erro com registo de depuração. Tenha em atenção que é provável que este nível de registo leve ao crescimento rápido do tamanho dos ficheiros de registo. Recomenda-se que esta opção seja utilizada apenas por curtos períodos de tempo para diagnosticar um problema específico.

Utilizar DebugView para Resolver Problemas de Detecção

DebugView é um método alternativo a EnableOpsmgrModuleLogging de resolução de problemas de deteção.

1. Transferir DebugView a partir de: https://go.microsoft.comfwlink/?Linkid=129486.

2. Inicie o DebugView no Servidor de Gestão que irá efetuar a deteção.

3. Comece a detetar os Agentes UNIX. Deve começar a ver resultados nas janelas do DebugView.

4. O DebugView apresentará uma leitura passo a passo do processo do assistente de deteção. Geralmente, este é o método mais rápido de resolução de problemas de deteção.

Ativar o Registo do Operations Manager para Gestão Remota do Windows

Este método de rastreio verboso é utilizado para ver as consultas da Gestão Remota do Windows (WinRM) utilizadas pelo Operations Manager para reunir dados do agente. Se suspeitar que existe um problema com a ligação WinRM, este registo fornece informações detalhadas que podem ajudar na resolução de problemas.

1. No Servidor de Gestão que está a monitorizar o agente UNIX ou Linux, abra uma linha de comandos.

2. Introduza os seguintes comandos na linha de comandos:

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

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Reproduza o problema de falha no Operations Manager.

4. Introduza os seguintes comandos na linha de comandos:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Procure WS-Man no ficheiro TracingGuidsNative.log.

Nota

WinRM também é conhecido como WS-Management (WS-Man).

Nota

O comando FormatTracing abre uma janela do Explorador do Windows que apresenta o C:\Windows\Logs\OpsMgrTrace diretório. O ficheiro TracingGuidsNative.log está nesse diretório.

Gerir Ficheiros de Registo do UNIX e do Linux

Os Agentes do Operations Manager para UNIX e Linux não limitam o tamanho dos ficheiros de registo do agente. Para controlar o tamanho máximo dos ficheiros de registo, implemente um processo para geri-los. Por exemplo, o utilitário logrotate padrão está disponível em muitos sistemas operativos UNIX e Linux. Este utilitário pode ser configurado para controlar os ficheiros de registo utilizados pelos Agentes do Operations Manager para UNIX ou Linux. Após rodar ou modificar os ficheiros de registo do agente, o agente tem de ser avisado de que os registos foram rodados para retomar o registo. O comando scxadmin pode ser utilizado com o parâmetro -log-rotate com a seguinte sintaxe:

scxadmin -log-rotate all

Ficheiro de configuração Logrotate de exemplo

O exemplo seguinte demonstra um ficheiro de configuração para rodar os ficheiros scx.log e omiserver.log com o utilitário logrotate do Linux. Normalmente, o logrotate será executado como uma tarefa agendada (com crond) e atuará em ficheiros de configuração encontrados no /etc/logrotate.d. Para testar e utilizar este ficheiro de configuração, modifique a configuração para ser adequada para o seu ambiente e ligue ou guarde o ficheiro no /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\
#}  

Passos seguintes

Para obter orientações adicionais para ajudar a resolver problemas comuns de implementação do agente, veja a Resolução de Problemas do Operations Manager 2012: UNIX/Linux Agent Discovery Wiki.