Troubleshoot gray agent states in System Center Operations Manager

Este artigo descreve como solucionar problemas nos quais um agente, um servidor de gerenciamento ou um gateway está indisponível ou esmaecido no System Center Operations Manager (OpsMgr).

Versão original do produto: Microsoft System Center 2012 Operations Manager
Número original do KB: 2288515

Um agente, um servidor de gerenciamento ou um gateway pode ter um dos seguintes estados, conforme indicado pela cor do nome e do ícone do agente no painel Monitoramento .

Causas de um estado cinza

Um agente, um servidor de gerenciamento ou um gateway podem ficar indisponíveis por um dos seguintes motivos:

• Falha na pulsação
• Configuração inválida
• Falha nos fluxos de trabalho do sistema
• Problemas de desempenho do data warehouse ou do banco de dados do Operations Manager
• Problemas de desempenho do servidor de gerenciamento ou do servidor de gateway
• Problemas de rede ou autenticação
• O serviço de integridade não está em execução

Escopo do problema

Antes de começar a solucionar o problema de esmaecimento do agente, você deve primeiro entender a topologia do Operations Manager e, em seguida, definir o escopo do problema. As perguntas a seguir podem ajudá-lo a definir o escopo do problema:

• Quantos agentes são afetados?
• Os agentes estão enfrentando o problema no mesmo segmento de rede?
• Os agentes se reportam ao mesmo servidor de gerenciamento?
• Com que frequência os agentes entram e permanecem em estado cinza?
• Como você normalmente se recupera dessa situação (por exemplo, reiniciar o serviço de integridade do agente, limpar o cache, confiar na recuperação automática)?
• Os alertas de falha de pulsação são gerados para esses agentes?
• Esse problema ocorre durante uma hora específica do dia?
• Esse problema persiste se você fizer failover desses agentes para outro servidor de gerenciamento ou gateway?
• Quando esse problema começou?
• Foram feitas alterações nos agentes, nos servidores de gerenciamento ou no gateway ou grupo de gerenciamento?
• Os agentes afetados são sistemas em cluster do Windows?
• A pasta Estado do Serviço de Integridade foi excluída da verificação antivírus?

Estratégia de solução de problemas

Sua estratégia de solução de problemas será ditada por qual componente está inativo, onde esse componente se enquadra na topologia e quão difundido é o problema. Considere as seguintes condições:

• Se os agentes que se reportam a um determinado servidor de gerenciamento ou gateway não estiverem disponíveis, a solução de problemas deverá começar no nível do servidor de gerenciamento ou gateway.
• Se os gateways que se reportam a um servidor de gerenciamento específico não estiverem disponíveis, a solução de problemas deverá começar no nível do servidor de gerenciamento.
• Para sistemas sem agente, para dispositivos de rede e para servidores Unix e Linux, a solução de problemas deve começar no agente, servidor de gerenciamento ou gateway que está monitorando esses objetos.
• A solução de problemas geralmente começa no nível imediatamente acima do componente indisponível.

Cenário 1

Apenas alguns agentes são afetados pelo problema. Esses agentes se reportam a diferentes servidores de gerenciamento. Os agentes permanecem indisponíveis regularmente. Embora você possa limpar o cache do agente para ajudar a resolver o problema temporariamente, o problema se repete após alguns dias.

Resolução para o cenário 1

Para resolver o problema nesse cenário, siga estas etapas:

1. Aplique o hotfix apropriado aos sistemas operacionais afetados.
2. Exclua o cache do agente da verificação antivírus. Para obter mais informações, consulte Recomendações para exclusões de antivírus relacionadas ao Operations Manager.
3. Pare o serviço de saúde.
4. Limpe o cache do agente.
5. Inicie o serviço de saúde.

Cenário 2

Apenas alguns agentes são afetados pelo problema. Esses agentes se reportam a diferentes servidores de gerenciamento. Os agentes permanecem inativos constantemente. Embora você possa limpar o cache do agente, isso não resolve o problema.

Resolução para o cenário 2

Para resolver o problema nesse cenário, siga estas etapas:

1. Determine se o serviço de integridade está ativado e está em execução no servidor de gerenciamento ou no gateway. Se o serviço de integridade parou de responder, gere um despejo do ADPlus em um modo de travamento de serviço para ajudar a determinar a causa do problema. Para obter mais informações, consulte Como usar o ADPlus.vbs para solucionar problemas de "travamentos" e "falhas"

2. Examine o log de eventos do Operations Manager no agente para localizar qualquer um dos seguintes eventos:

   ID do Evento: 1102
   Fonte do Evento: HealthService
   Descrição do evento:
   A regra/monitor "%4" em execução, por exemplo, "%3" com id:"%2" não pode ser inicializada e não será carregada. Grupo de gerenciamento "%1"

   ID do Evento: 1103
   Fonte do Evento: HealthService
   Descrição do evento:
   Resumo: %2 regra(s)/monitor(es) falharam e foram descarregados, %3 deles atingiram o limite de falha que impede o recarregamento automático. Grupo de gerenciamento "%1". Esse é o resumo de um único evento. Confira outros eventos com descrições de regras/monitores descarregados.

   ID do Evento: 1104
   Fonte do Evento: HealthService
   Descrição do evento:
   O perfil RunAs no fluxo de trabalho "%4", em execução, por exemplo, "%3" com id:"%2" não pode ser resolvido. O fluxo de trabalho não será carregado. Grupo de gerenciamento "%1"

   ID do Evento: 1105
   Fonte do Evento: HealthService
   Descrição do evento:
   Digite incompatibilidade para o perfil RunAs no fluxo de trabalho "%4", executando, por exemplo, "%3" com id:"%2". O fluxo de trabalho não será carregado. Grupo de gerenciamento "%1"

   ID do Evento: 1106
   Fonte do Evento: HealthService
   Descrição do evento:
   Não é possível acessar o perfil RunAs de texto sem formatação no fluxo de trabalho "%4", executando, por exemplo, "%3" com id:"%2". O fluxo de trabalho não será carregado. Grupo de gerenciamento "%1"

   ID do Evento: 1107
   Fonte do Evento: HealthService
   Descrição do evento:
   A conta para o perfil RunAs no fluxo de trabalho "%4", executada, por exemplo, "%3" com id:"%2" não está definida. O fluxo de trabalho não será carregado. Associe uma conta ao perfil. Grupo de gerenciamento "%1"

   ID do Evento: 1108
   Fonte do Evento: HealthService
   Descrição do evento:
   Uma conta especificada no perfil Executar como "%7" não pode ser resolvida. Especificamente, a conta é usada na Substituição de Referência Segura "%6". %n%n Essa condição pode ter ocorrido porque a Conta não está configurada para ser distribuída a este computador. Para resolver esse problema, é necessário abrir o perfil Executar como especificado a seguir, localizar a entrada Conta definida pelo respectivo SSID e optar por distribuir a Conta a esse computador, se apropriado, ou alterar a configuração no Perfil, de forma que o objeto de destino não utilize a Conta especificada. %n%nManagement Group: %1 %nRun As Profile: %7 %nSecureReferenceOverride name: %6 %nSecureReferenceOverride ID: %4 %nObject name: %3 %nObject ID: %2 %nAccount SSID: %5

   ID do evento: 4000
   Fonte do Evento: HealthService
   Descrição do evento:
   Um host de monitoramento não responde ou falhou. O código de status para a falha do host era %1.

   ID do evento: 21016
   Origem do evento: Conector OpsMgr
   Descrição do evento:
   O OpsMgr não pôde configurar um canal de comunicação para %1 e não há hosts de failover. A comunicação será retomada quando %1 estiver disponível e a comunicação deste computador for permitida.

   ID do evento: 21006
   Origem do evento: Conector OpsMgr
   Descrição do evento:
   O Conector OpsMgr não pôde se conectar a %1:%2. O código de erro é %3(%4). Verifique se há conectividade de rede, se o servidor está em execução e registrou sua porta de escuta e se não há firewalls bloqueando o tráfego para o destino.

   ID do evento: 20070
   Origem do evento: Conector OpsMgr
   Descrição do evento:
   O OpsMgr Connector se conectou a %1, mas a conexão foi fechada imediatamente após a autenticação. A causa mais provável do erro é que o agente não está autorizado a se comunicar com o servidor, ou o servidor não recebeu configuração. Verifique no log de eventos do servidor se há eventos 20000, que indicam que agentes não aprovados estão tentando se conectar.

   ID do evento: 20051
   Origem do evento: Conector OpsMgr
   Descrição do evento:
   O certificado especificado não pôde ser carregado porque o certificado não é válido no momento. Verifique se a hora do sistema está correta e emita novamente o certificado, se necessário%n Hora de início válida do certificado: %1%n Hora de término válida do certificado: %2

   Origem do evento: ESE
   Categoria do evento: Gerenciador de transações
   ID do evento: 623
   Descrição: HealthService (<PID>) O armazenamento de versão da instância <instance>("<name>") atingiu o tamanho máximo do <valor> Mb. É provável que uma transação de execução longa esteja impedindo a limpeza do repositório de versão e fazendo com que ele aumente de tamanho. As atualizações serão rejeitadas até que a transação de longa duração tenha sido completamente confirmada ou revertida. Possível transação de longa duração:
   SessionId: <valor>
   Contexto da sessão: <valor>
   ThreadId: <valor> do contexto da sessão.
   Limpeza: <valor>

3. Se você localizar os seguintes eventos específicos, siga estas diretrizes:

   • Eventos 1102 e 1103: estes eventos indicam que alguns dos fluxos de trabalho não foram carregados. Se forem os principais fluxos de trabalho do sistema, esses eventos podem causar o problema. Nesse caso, concentre-se na resolução desses eventos.

   • Eventos 1104, 1105, 1106, 1107 e 1108: estes eventos podem fazer com que os Eventos 1102 e 1103 ocorram. Normalmente, isso ocorreria devido a contas Executar como configuradas incorretamente. Por exemplo, as contas Executar como estão configuradas para serem usadas com a classe errada ou não estão configuradas para serem distribuídas ao agente.

   • Evento 4000: esse evento indica que o processo Monitoringhost.exe falhou. Se esse problema for causado por uma incompatibilidade de DLL ou por chaves do Registro ausentes, você poderá resolver o problema reinstalando o agente. Se o problema persistir, tente resolvê-lo usando os seguintes métodos:

     • Execute uma captura do Monitor de Processo até o ponto em que o processo falha. Para obter mais informações, consulte Monitor de Processo v3.53.
     • Gere um despejo do ADPlus no modo de falha. Para obter mais informações, consulte Como usar o ADPlus.vbs para solucionar problemas de "travamentos" e "falhas"

   • ID do evento 21006: esse evento indica que existem problemas de comunicação entre o agente e o servidor de gerenciamento. Se o agente usar um certificado para autenticação mútua, verifique se o certificado não expirou e se o agente está usando o certificado correto. Se o Kerberos estiver sendo usado, verifique se o agente pode se comunicar com o Active Directory. Se a autenticação estiver funcionando corretamente, isso pode significar que os pacotes do agente não estão chegando ao servidor de gerenciamento ou gateway. Tente estabelecer um telnet para a porta 5723 do agente para o servidor de gerenciamento. Além disso, execute um rastreamento de rede simultâneo entre o agente e o servidor de gerenciamento enquanto reproduz as falhas de comunicação. Isso pode ajudá-lo a determinar se os pacotes estão chegando ao servidor de gerenciamento e se algum dispositivo entre os dois componentes está tentando otimizar o tráfego ou está descartando alguns pacotes. Para obter mais informações, consulte Coletar dados usando o Monitor de Rede.

   • ID do Evento 623: esse evento normalmente ocorre em um grande ambiente do Operations Manager no qual um servidor de gerenciamento ou um computador agente gerencia muitos fluxos de trabalho. Para obter mais informações, consulte Um ou mais servidores de gerenciamento e seus dispositivos gerenciados estão esmaecidos no console do Operations Manager.

Cenário 3

Todos os agentes que se reportam a um determinado servidor de gerenciamento ou gateway não estão disponíveis.

Resolução para o cenário 3

Para resolver o problema nesse cenário, siga estas etapas:

1. Tente determinar que tipo de cargas de trabalho o servidor de gerenciamento ou gateway está monitorando. Essas cargas de trabalho podem incluir dispositivos de rede, agentes multiplataforma, transações sintéticas, agentes Windows e computadores sem agente.

2. Determine se o serviço de integridade está em execução no servidor de gerenciamento ou gateway.

3. Determine se o servidor de gerenciamento está sendo executado no modo de manutenção. Se for necessário, remova o servidor do modo de manutenção.

4. Examine o log de eventos do Operations Manager no agente para qualquer um dos eventos listados no Cenário 2. Se houver a ID de evento 21006, siga as mesmas diretrizes mencionadas em Resolução para o cenário 2. Além disso, nesse caso, esse evento indica que o servidor de gerenciamento ou gateway não pode se comunicar com seu servidor pai. Para um gateway, o servidor pai pode ser qualquer servidor de gerenciamento. (Consulte a etapa 3 no Resolução para o cenário 2.)

5. Examine o log de eventos do Operations Manager quanto aos seguintes eventos. Esses eventos geralmente indicam que existem problemas de desempenho no servidor de gerenciamento ou no Microsoft SQL Server que está hospedando o OperationsManager banco de dados or OperationsManagerDW :

   ID do Evento: 2115
   Fonte do Evento: HealthService
   Descrição do evento:
   Uma fonte de dados de associação no grupo de gerenciamento %1 postou itens no fluxo de trabalho, mas não recebeu uma resposta em %5 segundos. Isso indica um problema funcional ou de desempenho com o fluxo de trabalho.%n ID do fluxo de trabalho: %2%n Instância: %3%n ID da instância: %4%n

   ID do evento: 5300
   Fonte do Evento: HealthService
   Descrição do evento:
   O serviço de saúde local não é saudável. O fluxo de alteração de estado da entidade é interrompido com confirmação pendente. %n%nGrupo de Gerenciamento: %2 %nID do Grupo de Gerenciamento: %1

   ID do Evento: 4506
   Fonte do Evento: HealthService
   Descrição do evento: Operations Manager
   Os dados foram descartados devido a muitos dados pendentes na regra "%2" em execução, por exemplo, "%3" com id:"%4" no grupo de gerenciamento "%1".

   ID do Evento: 31551
   Origem do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Falha ao armazenar dados no Data Warehouse. A operação será repetida.%rException '%5': %6 %n%nUm ou mais fluxos de trabalho foram afetados por isso. %n%nNome do fluxo de trabalho: %2 %nNome da instância: %3 %nID da instância: %4 %nGrupo de gerenciamento: %1

   ID do evento: 31552
   Origem do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Falha ao armazenar dados no Data Warehouse.%rException '%5': %6 %n%nUm ou mais fluxos de trabalho foram afetados por isso. %n%nNome do fluxo de trabalho: %2 %nNome da instância: %3 %nID da instância: %4 %nGrupo de gerenciamento: %1

   ID do evento: 31553
   Origem do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Os dados foram gravados na área de preparo do Data Warehouse, mas o processamento falhou em uma das operações subsequentes.%rException '%5': %6 %n%nUm ou mais fluxos de trabalho foram afetados por isso. %n%nNome do fluxo de trabalho: %2 %nNome da instância: %3 %nID da instância: %4 %nGrupo de gerenciamento: %1

   ID do evento: 31557
   Origem do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Falha ao obter informações de estado do processo de sincronização do banco de dados do Data Warehouse. A operação será repetida.%rException '%5': %6 %n%nUm ou mais fluxos de trabalho foram afetados por isso. %n%nNome do fluxo de trabalho: %2 %nNome da instância: %3 %nID da instância: %4 %nGrupo de gerenciamento: %1

6. A ID do evento 3155X também pode ser registrada devido a configurações incorretas da conta Executar como ou permissões ausentes para as contas Executar como.

Cenário 4

Todos os agentes que se reportam a um servidor de gerenciamento específico alternam intermitentemente entre estados íntegros e cinzas. Ou, todos os agentes do ambiente alternam intermitentemente entre estados saudáveis e cinzentos.

Resolução para o cenário 4

Para resolver o problema, primeiro determine a causa do problema. As causas comuns de indisponibilidade temporária do servidor incluem o seguinte:

• O servidor pai dos agentes está temporariamente offline.
• Os agentes estão inundando o servidor de gerenciamento com dados operacionais, como alertas, estados, descobertas e assim por diante. Isso pode causar um aumento no uso de recursos do sistema no banco de dados do Operations Manager e nos servidores do Operations Manager.
• As interrupções de rede causaram uma falha temporária de comunicação entre o servidor pai e os agentes.
• Ocorreram alterações no pacote de gerenciamento (MP). No console do Operations Manager, essas alterações exigem uma configuração do Operations Manager e uma redistribuição de MP para os agentes. Se a alteração afetar uma base de agentes maior, isso poderá causar maior uso do uso de recursos do sistema no banco de dados do Operations Manager e nos servidores do Operations Manager.

A chave para a solução de problemas nesses cenários é entender a duração da indisponibilidade do servidor e a hora do dia em que ela ocorreu. Isso ajudará você a restringir rapidamente o escopo do problema.

Troubleshooting management server and gateway performance

Servidor de gerenciamento

Durante uma intermitência de atualização de configuração (causada pela importação e descoberta de MP), os gargalos típicos são, primeiro, a CPU e, segundo, a E/S do disco de instalação do Operations Manager. O servidor de gerenciamento é responsável por encaminhar arquivos de configuração para os agentes de destino.

Para coleta de dados operacionais, os gargalos normalmente são causados pela CPU. A E/S do disco também pode estar na capacidade máxima, mas isso não é tão provável. O servidor de gerenciamento é responsável por descompactar e descriptografar dados operacionais de entrada e inseri-los no banco de dados operacional. Ele também envia ACKs (confirmações) de volta para os agentes ou gateways depois de receber dados operacionais e usa a fila de disco para armazenar temporariamente essas ACKs de saída.

Gateway

O gateway é associado à CPU e à E/S. Quando o gateway está retransmitindo uma grande quantidade de dados, as operações de CPU e E/S podem mostrar alto uso. A maior parte do uso da CPU é causada pela descompactação, compactação, criptografia e descriptografia dos dados recebidos e também pela transferência desses dados. Todos os dados recebidos pelo gateway e pelos agentes são armazenados em uma fila persistente no disco, para serem lidos e encaminhados ao servidor de gerenciamento pelo serviço de Integridade do gateway. Isso pode causar uso intenso do disco. Esse uso pode ser significativo quando o gateway é colocado temporariamente offline e deve lidar com dados acumulados do agente que os agentes geraram e tentaram enviar quando o gateway ainda estava offline.

Para solucionar o problema nessa situação, colete as seguintes informações de cada servidor de gerenciamento ou gateway afetado:

• Versão, edição e número de build exatos do Windows

• Número de processadores

• Quantidade de RAM

• Unidade que contém a pasta Estado do Serviço de Integridade

• Se o software antivírus está configurado para excluir o repositório do Serviço de Integridade

  Observação

  Para obter mais informações, consulte Recomendações para exclusões de antivírus relacionadas ao Operations Manager.

• Nível de RAID (0, 1, 5ou 1+00+1 ) para a unidade usada pelo Estado do Serviço de Integridade

• Número de discos usados para o RAID

• Se o cache de gravação com bateria está habilitado no controlador de array

Troubleshooting SQL Server performance

Banco de dados operacional (OperationsManager)

Para o banco de dados OperationsManager, o gargalo mais provável é a matriz de discos. Se a matriz de discos não estiver na capacidade máxima de E/S, o próximo gargalo provável será a CPU. O banco de dados terá lentidão ocasional e excesso de dados operacionais (altas incidências de eventos, alertas e dados de desempenho ou alterações de estado que persistem por um tempo relativamente longo). Uma breve intermitência normalmente não causa nenhum atraso significativo por um longo período de tempo.

Durante a inserção de dados operacionais, os discos de banco de dados são usados principalmente em gravações. O uso da CPU é causado pela rotatividade do SQL Server. Isso pode ocorrer quando você tem consultas grandes e complexas, inserção de dados pesados e limpeza de tabelas grandes (por padrão, ocorre à meia-noite). Normalmente, a limpeza de eventos grandes e tabelas de dados de desempenho não consome recursos excessivos de CPU ou disco. No entanto, a limpeza das tabelas de alerta e de alteração de estado pode fazer uso intensivo de CPU em tabelas grandes.

O banco de dados também é associado à CPU quando lida com intermitências de redistribuição de configuração, que são causadas por importações de MP ou por uma grande alteração de espaço de instância. Nesses casos, o serviço de Configuração consulta o banco de dados para a nova configuração do agente. Isso geralmente faz com que picos de CPU ocorram no banco de dados antes que o serviço envie as atualizações de configuração para os agentes.

Data warehouse (OperationsManagerDW)

Para o banco de dados OperationsManagerDW, o gargalo mais provável é a matriz de discos. Geralmente, isso ocorre devido a grandes inserções de dados operacionais. Nesses casos, os discos estão em sua maioria ocupados executando gravações. Em geral, os discos estão executando algumas leituras, exceto para manipular modos de exibição Relatórios gerados manualmente porque executam consultas no data warehouse.

O uso da CPU é causado pela rotatividade do SQL Server. Picos de CPU podem ocorrer durante a atividade de particionamento pesado (quando as tabelas se tornam grandes e depois são particionadas) e a geração de relatórios complexos e grandes quantidades de alertas no banco de dados, com os quais o data warehouse deve sincronizar constantemente.

Solução de problemas gerais

Para solucionar o problema nessa situação, colete as seguintes informações de cada servidor de gerenciamento ou gateway afetado:

• Versão, edição e número de build exatos do Windows

• Número de processadores

• Quantidade de RAM

• Quantidade de memória alocada para o SQL Server

• Se o SQL Server tem 32 bits e o AWE está habilitado

  Você pode encontrar a maioria dessas informações no SQL Server Management Studio ou no SQL Server Enterprise Manager. Para fazer isso, abra a janela Propriedades do servidor e selecione as guias Geral e Memória. A guia Geral inclui a versão do SQL Server, a versão do Windows, a plataforma, a quantidade de RAM e o número de processadores. A guia Memória inclui a memória alocada para o SQL Server. No Microsoft SQL Server 2008, a guia Memória também inclui a opção do AWE.

  Se o sistema operacional for de 32 bits e a RAM for de 4 GB ou superior, verifique se a opção /pae ou /3gb existe no Boot.ini. arquivo. Essas opções podem estar com a configuração incorreta se o servidor foi instalado originalmente com 4 GB ou menos de RAM e se a RAM foi atualizada depois.

  Para servidores de 32 bits que têm 4 GB de RAM, a opção /3gb no Boot.ini aumenta a quantidade de memória que o SQL Server pode resolver (de 2 GB para 3 GB). Para servidores de 32 bits que têm mais de 4 GB de RAM, a opção /3gb no Boot.ini pode limitar de fato a quantidade de memória que o SQL Server pode resolver. Para esses sistemas, adicione a opção /pae ao Boot.ini e habilite o AWE no SQL Server.

  Em um sistema de vários processadores, verifique a configuração do MAXDOP (Grau Máximo de Paralelismo) . No SQL Server 2008, essa opção está na guia Avançado na caixa de diálogo Propriedades do servidor.

  O valor padrão é 0, o que significa que todos os processadores disponíveis serão usados. Uma configuração 0 é ideal para servidores que têm oito ou menos processadores. Para servidores com mais de oito processadores, o tempo que o SQL Server leva para coordenar o uso de todos os processadores pode ser contraproducente. Portanto, para servidores com mais de oito processadores, você geralmente deve definir o Grau Máximo de Paralelismo como um valor de 8. Para fazer isso, execute o seguinte comando no Analisador de Consultas SQL:

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• Letras de unidade que contêm arquivos de data warehouse, banco de dados do Operations Manager e Tempdb

• Se o software antivírus está configurado para excluir dados do SQL e arquivos de log (a verificação de arquivos de banco de dados do SQL Server com software antivírus pode prejudicar o desempenho.)

• Quantidade de espaço livre em unidades que contêm arquivos de data warehouse, banco de dados do Operations Manager e Tempdb

• Tipo de armazenamento (SAN ou local)

• Nível RAID (0, 1, 5, 0+1 ou 1+0) para unidades usadas pelo SQL Server

• Se o armazenamento SAN é usado: número de eixos em cada LUN usado pelo SQL Server

• Se o pacote de gerenciamento convertido do Exchange 2007 estiver sendo usado ou já tiver sido usado: número de linhas na LocalizedText tabela no banco de dados do Operations Manager e na EventPublisher tabela no banco de dados do data warehouse

  Para determinar os valores de linha, execute os seguintes comandos:

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

Contadores para identificar a pressão de memória

Contadores para identificar a pressão do disco

Capture estes contadores de disco físico para todas as unidades que contêm dados do SQL ou arquivos de log:

• % de Tempo de Ociosidade: quanto tempo de ociosidade do disco está sendo relatado. Abaixo de 50% pode indicar um gargalo de disco.

• Comprimento Médio da Fila de Disco: esse valor não deve exceder o dobro do número de eixos que estão em um LUN. Por exemplo, se um LUN tiver 25 eixos, um valor de 50 será aceitável. No entanto, se um LUN tiver 10 eixos, um valor de 25 será muito alto. Você pode usar as seguintes fórmulas com base no nível do RAID e no número de discos na configuração do RAID:

  • RAID 0: todos os discos estão funcionando em um conjunto do RAID 0

  • Comprimento< médio da fila de disco= # (Discos na matriz) *2

  • RAID 1: metade dos discos estão funcionando; portanto, apenas metade deles pode ser contada na fila de disco

  • Comprimento< médio da fila de disco= # (Discos na matriz/2) *2

  • RAID 10: metade dos discos "estão funcionando"; portanto, apenas metade deles pode ser contada na fila de disco

  • Comprimento< médio da fila de disco= # (Discos na matriz/2) *2

  • RAID 5: todos os discos estão funcionando em um conjunto do RAID 5

  • Comprimento< médio da fila de disco= # Discos na matriz *2

  • Média de segundos do Disco/Transferência: o número de segundos necessários para concluir uma E/S de disco

  • Média de segundos do Disco/Leitura: o tempo médio, em segundos, para ler dados no disco

  • Média de segundos do Disco/Gravação: o tempo médio, em segundos, para gravar dados no disco

    Os últimos três contadores nessa lista devem ter valores de aproximadamente 0,020 (20 ms) ou menos e nunca devem exceder 0,050 (50 ms). Os seguintes limites estão documentados no guia de solução de problemas de desempenho do SQL Server:

    • Menos de 10 ms: muito bom
    • Entre 10 e 20 ms: ok
    • Entre 20 e 50 ms: lento, precisa de atenção
    • Mais de 50 ms: gargalo sério de E/S

  • Bytes de Disco/segundo: o número de bytes sendo transferidos para/do disco por segundo

  • Transferências de Disco/segundo: o número de IOPS (operações de entrada e saída por segundo)

  Quando a % de tempo ocioso é baixa (10 por cento ou menos), isso significa que o disco está totalmente utilizado. Nesse caso, os dois últimos contadores nessa lista (Bytes de Disco/segundo e Transferências de Disco/segundo) fornecem uma boa indicação da taxa de transferência máxima da unidade em bytes e em IOPS, respectivamente. A taxa de transferência de uma unidade de SAN é altamente variável, dependendo do número de eixos, da velocidade das unidades e da velocidade do canal. A melhor aposta é verificar com o fornecedor de SAN para descobrir quantos bytes e IOPS a unidade deve aceitar. Se a % de tempo de ociosidade for baixa e os valores desses dois contadores não atenderem à taxa de transferência esperada da unidade, entre em contato com o fornecedor de SAN para que ele solucione o problema.

O guia de solução de problemas de desempenho do SQL Server fornece informações mais detalhadas sobre a solução de problemas de desempenho do SQL Server.

Contadores de desempenho do Operations Manager

As seções a seguir descrevem os contadores de desempenho que você pode usar para monitorar e solucionar problemas de desempenho do Operations Manager.

Função de servidor de gateway

Contadores de desempenho geral

Esses contadores indicam o desempenho geral do gateway:

Contadores de desempenho genérico do processo do Operations Manager

Esses contadores indicam o desempenho geral dos processos do Operations Manager no gateway:

Contadores de desempenho específicos do Operations Manager

Esses contadores são contadores específicos do Operations Manager que indicam o desempenho de aspectos específicos do Operations Manager no gateway:

Função de servidor de gerenciamento

Contadores de desempenho geral

Esses contadores indicam o desempenho geral do servidor de gerenciamento:

Contadores de desempenho genérico do processo do Operations Manager

Esses contadores indicam o desempenho geral dos processos do Operations Manager no servidor de gerenciamento:

Contadores de desempenho específicos do Operations Manager

Esses contadores são contadores específicos do Operations Manager que indicam o desempenho de aspectos específicos do Operations Manager no servidor de gerenciamento: