Solução de problemas de monitoramento de computadores UNIX e Linux

O System Center – Operations Manager fornece um monitoramento de computadores UNIX e Linux semelhante ao monitoramento de computadores Windows. Monitore a integridade e o desempenho, obtenha relatórios, execute tarefas e implemente uma instrumentação de monitoramento personalizada.

É possível monitorar os seguintes aspectos dos computadores UNIX e Linux:

• Serviços e aplicativos

• Sistema de arquivos, espaço em disco, espaço de permuta, memória do sistema

• Adaptadores de rede

• Processos e atributos centrais

• Principais configurações

Antes de monitorar computadores UNIX e Linux, conclua as seguintes etapas:

1. Importe pacotes de gerenciamento baixando as versões mais recentes do Centro de Download da Microsoft.
2. Crie um pool de recursos dedicado para monitorar computadores UNIX e Linux.
3. Configure os certificados para cada servidor de gerenciamento no pool.
4. Criar e configurar contas Executar como.
5. Instale o agente no UNIX e no Linux usando o Assistente de Descoberta.

Depois de concluir as etapas acima e descobrir e implantar com êxito o agente em um ou mais computadores UNIX e Linux, você deve verificar se eles estão sendo monitorados corretamente. Depois de implantar um agente, as contas Executar como são usadas para executar descobertas em execução, usando as regras de descoberta aplicáveis e, em seguida, iniciar o monitoramento. Após vários minutos, no workspace Administração, navegue até computadores Gerenciamento de Dispositivos/UNIX/Linux e verifique se os computadores não estão listados como Desconhecidos. Eles devem ser descobertos e mostrar a versão específica do sistema operacional e da distribuição.

Por padrão, o Operations Manager monitora os seguintes objetos do sistema operacional:

• Sistema operacional
• Disco lógico
• Adaptadores de rede

Você pode fornecer mais recursos de monitoramento e interação com os computadores UNIX e Linux gerenciados usando os modelos de pacote de monitoramento UNIX e Linux. Para obter mais informações, consulte UNIX or Linux Log File (Arquivo de log do UNIX ou do Linux) e UNIX or Linux Process (Processo do UNIX ou do Linux) no Guia de Criação.

Solução de problemas de monitoramento do UNIX e Linux

A próxima seção fornece informações sobre problemas que podem ocorrer com o monitoramento de computadores UNIX e Linux no Operations Manager.

Mensagem de erro de assinatura de certificado

Durante a instalação de agentes UNIX/Linux, você 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:  

Esse erro ocorre quando o módulo de assinatura de certificado é chamado, mas o próprio certificado está vazio. Esse erro pode ser causado por uma falha da conexão SSH com o sistema remoto.

Se você vir esse erro, proceda da seguinte forma:

1. Verifique se o daemon SSH no host remoto está em execução.

2. Verifique se você pode abrir uma sessão SSH com o host remoto usando as credenciais especificadas no Assistente de Descoberta.

3. Verifique se as credenciais especificadas no Assistente de Descoberta têm os privilégios necessários para descoberta. Confira mais informações em Credenciais que você deve ter para acessar computadores UNIX e Linux.

O nome do certificado e o nome do host não coincidem

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

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

Você pode exibir os detalhes básicos do certificado no computador UNIX ou Linux inserindo o seguinte comando:

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

Ao fazer isso, você verá uma saída semelhante à 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 os nomes de host e as datas e assegure que correspondam ao nome sendo resolvido pelo servidor de gerenciamento do Operations Manager.

Se os nomes de host não corresponderem, use uma das seguintes ações para resolve o problema:

• Se o nome de host de UNIX ou Linux estiver correto, mas o servidor de gerenciamento do Operations Manager o estiver resolvendo incorretamente, modifique a entrada DNS para correspondência com o FQDN correto ou adicione um entrada ao arquivo de hosts no servidor do Operations Manager.

• Se o nome de host de UNIX ou Linux estiver incorreto, siga um destes procedimentos:

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

  • Crie um novo certificado com o nome de host desejado.

Para alterar o nome no certificado:

Se o certificado tiver sido criado com um nome incorreto, você poderá alterar o nome de host e criar novamente o certificado e a chave privada. Para fazer isso, execute o seguinte comando no computador UNIX ou Linux:

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

A opção -f força a substituição dos arquivos em /etc/opt/microsoft/scx/ssl.

Você pode também alterar o nome do host e o nome de domínio no certificado usando as opções -h e -d, como no seguinte exemplo:

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

Reinicie o agente executando o seguinte comando:

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

Para adicionar uma entrada ao arquivo de hosts:

Se o FQDN não estiver no DNS reverso, você poderá adicionar uma entrada ao arquivo de hosts localizado no servidor de gerenciamento para fornecer resolução de nomes. O arquivo de hosts está localizado na pasta Windows\System32\Drivers\etc. Uma entrada no arquivo hosts é uma combinação do endereço IP e o FQDN.

Por exemplo, para adicionar uma entrada para o host chamado newhostname.newdomain.name com um endereço IP de 192.168.1.1, adicione o seguinte ao final do arquivo de hosts:

192.168.1.1      newhostname.newdomain.name  

Problemas do pacote de gerenciamento

ExecuteCommand não oferece suporte a operadores de pipeline ou aliases

Quando você usa um alias ou um operador de pipeline com o parâmetro ExecuteCommand , o comando falha. O parâmetro ExecuteCommand não dá suporte ao operador de pipeline, aliases e à sintaxe específica do shell.

Em pacotes de gerenciamento do System Center Operations Manager projetados para gerenciar computadores UNIX e Linux, o parâmetro ExecuteCommand não inicia um processo de shell, fazendo com que a ação personalizada falhe.

Para cada um dos seguintes tipos de ações personalizadas, você especifica como os argumentos de comando são invocados usando os parâmetros ExecuteCommand ou 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 passa os argumentos de linha de comando ao console sem iniciar um processo de shell.

O parâmetro ExecuteShellCommand passa os argumentos de comando a um processo de shell usando o shell padrão do usuário; esse shell oferece suporte ao pipeline, a aliases e à sintaxe específica de shell.

Observação

O parâmetro ExecuteShellCommand usa o shell padrão do usuário que está executando o comando. Se você precisar de um shell específico, use o parâmetro ExecuteCommand e coloque o shell necessário como prefixo dos argumentos de comando.

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

• Para passar os argumentos de linha de comando ao console 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 de linha de comando a um processo de shell que referencia um 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 passar os argumentos de comando a um processo de shell que usa o shell padrão do usuário:

  <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

Esta seção descreve como habilitar ferramentas de log e depuração para solucionar problemas com o monitoramento de computadores UNIX e Linux.

Observação

Você pode alterar as configurações no nível de log sem reinicializar o agente. Saiba mais.

Habilitar o registro em log de módulo do Operations Manager

Os agentes do Operations Manager para UNIX e Linux mantêm vários arquivos de log que podem ser úteis ao solucionar problemas do cliente. Esses arquivos de log estão localizados no computador UNIX ou Linux gerenciado. O nível de log para os arquivos de log do agente pode ser configurado conforme necessário. O log mais detalhado pode ser útil para diagnosticar um problema. Para a operação normal, os níveis de log não devem ser definidos como um valor mais detalhado do que as configurações padrão (Intermediário) para evitar o crescimento excessivo do arquivo de log.

Observação

Chamadas feitas fora do Gerenciamento Remoto do Windows (WinRM) são feitas com o uso de SSH/SFTP. Esses componentes dependem de um mecanismo de registro em log separado do Operations Manager.

Observação

O nível de log do arquivo de log omiserver.log não pode ser alterado do padrão nesta versão dos Agentes do Operations Manager para UNIX e Linux.

1. Crie um arquivo em branco chamado EnableOpsmgrModuleLogging no diretório Temp para a conta de usuário que chama esses módulos digitando em uma linha de comando ou prompt do PowerShell:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Observação

   Em geral, é a conta SYSTEM que faz as chamadas e C:\Windows\Temp é a pasta temporária SYSTEM padrão.

2. Após a criação do arquivo em branco, o Operations Manager começará imediatamente a registrar as atividades SSH e Certificate no diretório Temp. Scripts que chamam o log de módulos SSH para <Scriptname.vbs>.log. Outros módulos têm seus próprios logs.

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

Habilitar o registro em log no agente UNIX

Esses logs irão relatar as ações do agente UNIX. Se houver um problema com os dados retornados ao Operations Manager, examine esse log. Você pode definir a quantidade de informações registradas com o comando scxadmin. A sintaxe desse comando é:

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

A tabela abaixo lista os valores de parâmetro possíveis:

Nível	Descrição
Errors	Registro em log somente de mensagens de Aviso ou de Erro .
Intermediário	Informações de log, aviso e mensagens de erro.
Detalhado	Registrar em log mensagens de Informações, de Avisoe de Erro com log de depuração. Observe que esse nível de log pode causar o rápido crescimento no tamanho dos arquivos de log. É recomendável que essa opção seja usada apenas por curtos períodos de tempo para diagnosticar um problema específico.

Usar DebugView para solucionar problemas de descoberta

DebugView é um método alternativo para EnableOpsmgrModuleLogging para solucionar problemas de descoberta.

1. Baixe o DebugView em: https://go.microsoft.comfwlink/?Linkid=129486.

2. Inicie o DebugView no Servidor de Gerenciamento executando a descoberta.

3. Comece descobrindo os agentes UNIX. Você deve começar a ver a saída nas janelas do DebugView.

4. DebugView apresentará uma leitura passo a passo do processo do assistente de descoberta. Esse é geralmente o método mais rápido de solução de problemas de descoberta.

Habilitar registro em log do Operations Manager para o gerenciamento remoto do Windows

Esse método de rastreamento detalhado é usado para ver as consultas do Gerenciamento Remoto do Windows (WinRM) usadas pelo Operations Manager para coletar dados do agente. Se você suspeitar que há um problema com a conexão WinRM, esse log fornece informações detalhadas que podem ajudar na solução de problemas.

1. No servidor de Gerenciamento que está monitorando o agente UNIX ou Linux, abra um prompt de comando.

2. Insira os seguintes comandos no prompt de comando:

   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. Insira os seguintes comandos no prompt de comando:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Pesquise WS-Man no arquivo TracingGuidsNative.log.

Observação

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

Observação

O comando FormatTracing abre uma janela do Windows Explorer mostrando o diretório C:\Windows\Logs\OpsMgrTrace. O arquivo TracingGuidsNative.log está nesse diretório.

Gerenciar arquivos de Log do Linux e do UNIX

Os Agentes do Operations Manager para UNIX e Linux não limitam o tamanho dos arquivos de log do agente. Para controlar o tamanho máximo dos arquivos de log, implemente um processo para gerenciar os arquivos de log. Por exemplo, o utilitário padrão logrotate está disponível em muitos sistemas operacionais de UNIX e Linux. O utilitário logrotate pode ser configurado para controlar os arquivos de log usados por agentes do Operations Manager para UNIX ou Linux. Após girar ou modificar os arquivos de log do agente, este deve ser avisado de que os logs giraram para retomar o registro em log. O comando scxadmin pode ser usado com o parâmetro – log-rotate com a seguinte sintaxe:

scxadmin -log-rotate all

Arquivo de configuração do Logrotate de exemplo

O exemplo a seguir demonstra um arquivo de configuração para girar os arquivos scx.log e omiserver.log com o utilitário logrotate do Linux. Normalmente, logrotate será executado como um trabalho agendado (com crond) e atuará em arquivos de configuração encontrados em /etc/logrotate.d. Para testar e usar esse arquivo de configuração, modifique a configuração para ser apropriada ao seu ambiente e vincule ou salve o arquivo em /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\
#}  

Próximas etapas

Para obter outras diretrizes para ajudar a resolver problemas comuns de implantação de agente, examine a Wiki de solução de problemas do Operations Manager 2012: Descoberta de agente do UNIX/Linux.