Partilhar via

Solucionar problemas de monitoramento de computadores UNIX e Linux

  • Artigo

O System Center - Operations Manager fornece monitoramento de computadores UNIX e Linux semelhante ao monitoramento de computadores Windows. Você pode monitorar a integridade e o desempenho, obter relatórios, executar tarefas e implementar 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, você deve concluir 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. Crie e configure contas Executar como.
  5. Instale o agente no UNIX e no Linux usando o Assistente de Descoberta.
  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. Crie e configure contas Executar como.
  5. Instale o agente no UNIX e no Linux usando o Assistente de Descoberta.
  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. Crie e configure 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 que um agente é implantado, 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 alguns minutos, no espaço de trabalho Administração, navegue até Gerenciamento de Dispositivos/Computadores 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.

Solucionar problemas de monitoramento de UNIX e Linux

A seção a seguir 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. Certifique-se de que o daemon SSH no host remoto esteja em execução.

  2. Certifique-se de que você possa abrir uma sessão SSH com o host remoto usando as credenciais especificadas no Assistente de Descoberta.

  3. Certifique-se de que as credenciais especificadas no Assistente de Descoberta tenham os privilégios necessários para descoberta. Para obter mais informações, consulte 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 resolver 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.

Altere 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 os arquivos em /etc/opt/microsoft/scx/ssl a serem substituídos.

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

/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

Adicione uma entrada ao arquivo hosts:

Se o FQDN não estiver no DNS reverso, você poderá adicionar uma entrada ao arquivo hosts localizado no servidor de gerenciamento para fornecer resolução de nomes. O arquivo 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 hosts:

192.168.1.1      newhostname.newdomain.name

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

Nos 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ção personalizada, especifique como os argumentos de comando são invocados usando o parâmetro ExecuteCommand ou o 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 passa os argumentos de linha de comando para o console sem iniciar um processo de shell.

O parâmetro ExecuteShellCommand passa os argumentos de comando para um processo de shell usando o shell padrão do usuário; esse shell dá suporte a pipeline, aliases e sintaxe específica do 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 prefixe os argumentos de comando com o shell necessário.

Os exemplos a seguir 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>

Registro em log e depuração

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

Observação

Com o Operations Manager 2019 UR3, as configurações de nível de log podem ser alteradas sem a reinicialização do agente. Saiba mais.

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

    Geralmente, é 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 a atividade SSH e Certificado no diretório Temp. Os scripts que chamam os módulos SSH registram em <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 este 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 Registrar informações, avisos 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 o 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 fornecerá 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. Procure por 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 exibindo o C:\Windows\Logs\OpsMgrTrace diretório. O arquivo TracingGuidsNative.log está nesse diretório.

Gerenciar arquivos de log do UNIX e do Linux

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, o logrotate será executado como um trabalho agendado (com crond) e atuará nos arquivos de configuração encontrados no /etc/logrotate.d. Para testar e usar esse arquivo de configuração, modifique-a para que seja apropriada ao seu ambiente e vincule ou salve o arquivo 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\
#}

Próximas etapas

Para obter diretrizes adicionais para ajudar a resolver problemas comuns de implantação de agentes, consulte a Solução de problemas do Operations Manager 2012: Wiki de descoberta de agentes UNIX/Linux.