Solucionar problemas de estados de agente cinza no System Center Operations Manager

Este artigo descreve como solucionar problemas em que um agente, um servidor de gerenciamento ou um gateway não está disponível ou esmaecido no OpsMgr (System Center Operations Manager).

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

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

Causas de um estado cinza

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

• Falha nos batimentos cardíacos
• Configuração inválida
• Falha nos fluxos de trabalho do sistema
• Problemas de desempenho do banco de dados ou do data warehouse 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 saúde não está em execução

Escopo de problema

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

• Quantos agentes foram 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 um estado cinza?
• Como você normalmente se recupera dessa situação (por exemplo, reinicie o serviço de integridade do agente, desmarque o cache, dependa da 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 persistirá se você falhar sobre esses agentes em 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 no grupo de gerenciamento?
• Os agentes afetados são sistemas clusterizados do Windows?
• A pasta Estado do Serviço de Saúde é excluída da verificação de 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 está dentro da topologia e o quão generalizado é o problema. Considere as seguintes condições:

• Se os agentes que relatam para 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 do gateway.
• Se os gateways que relatam para 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 normalmente 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ê seja capaz de limpar o cache do agente para ajudar a resolve o problema temporariamente, o problema se repetirá após alguns dias.

Resolução para o cenário 1

Para resolve o problema neste cenário, siga estas etapas:

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

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ê seja capaz de limpar o cache do agente, isso não resolve o problema.

Resolução para o cenário 2

Para resolve o problema neste 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 tiver parado 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 ADPlus.vbs para solucionar problemas de "travas" 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:
   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 rule(s)/monitor(s) falhou e foi descarregado, %3 delas atingiu o limite de falha que impede o recarga automática. Grupo de gerenciamento "%1". Este é apenas um evento de resumo, consulte outros eventos com descrições de regra descarregada(s)/monitor(s).

   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:
   Incompatibilidade de tipo para o perfil RunAs no fluxo de trabalho "%4", em execução 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 simples no fluxo de trabalho "%4", em execução 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", em execução 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 para este computador. Para resolve esse problema, você precisa abrir o Perfil Executar como especificado abaixo, localizar a entrada conta conforme especificado por seu SSID e optar por distribuir a Conta para este computador, se apropriado, ou alterar a configuração no Perfil para que o objeto de destino não use a Conta especificada. %n%nManagement Group: %1 %nRun Como Perfil: %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 respondeu ou falhou. O código status para a falha do host foi %1.

   ID do evento: 21016
   Fonte do evento: Conector OpsMgr
   Descrição do evento:
   O OpsMgr não pôde configurar um canal de comunicação como %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
   Fonte 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, o servidor está em execução e registrou sua porta de escuta e não há firewalls bloqueando o tráfego para o destino.

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

   ID do evento: 20051
   Fonte 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 Tempo de início válido do certificado : %1%n Tempo de término válido do certificado : %2

   Fonte do evento: ESE
   Categoria de Evento: Gerenciador de Transações
   ID do evento: 623
   Descrição: PID> (<HealthService) O repositório de versões para instância><("<name>") atingiu o tamanho máximo do <valor> Mb. É provável que uma transação de longa duração esteja impedindo a limpeza do repositório de versões e fazendo com que ela seja acumulada em tamanho. Atualizações será rejeitada até que a transação de longa duração tenha sido completamente confirmada ou revertida. Possível transação de longa execução:
   SessionId: <valor>
   Contexto de sessão: <valor>
   ThreadId de contexto de sessão: <valor>.
   Limpeza: <valor>

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

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

   • Eventos 1104, 1105, 1106, 1107 e 1108: Esses 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 são configuradas para serem usadas com a classe errada ou não estão configuradas para serem distribuídas ao agente.

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

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

   • ID do evento 21006: este 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 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 atingindo o servidor de gerenciamento ou o gateway. Tente estabelecer uma 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 você reproduz as falhas de comunicação. Isso pode ajudá-lo a determinar se os pacotes estão atingindo o servidor de gerenciamento e se qualquer dispositivo entre os dois componentes está tentando otimizar o tráfego ou está soltando 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 ambiente grande do Operations Manager no qual um servidor de gerenciamento ou um computador agente gerencia muitos fluxos de trabalho. Para obter mais informações, confira Um ou mais servidores de gerenciamento e seus dispositivos gerenciados sã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 resolve o problema neste cenário, siga estas etapas:

1. Tente determinar que tipo de cargas de trabalho o servidor de gerenciamento ou o gateway está monitorando. Essas cargas de trabalho podem incluir dispositivos de rede, agentes entre plataformas, 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 no gateway.

3. Determine se o servidor de gerenciamento está em execução 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 do evento 21006, siga as mesmas diretrizes mencionadas na Resolução para o cenário 2. Além disso, nesse caso, esse evento indica que o servidor de gerenciamento ou o gateway não podem se comunicar com o servidor pai. Para um gateway, o servidor pai pode ser qualquer servidor de gerenciamento. (Consulte a etapa 3 na Resolução para o cenário 2.)

5. Examine o log de eventos do Operations Manager para os eventos a seguir. Esses eventos normalmente indicam que existem problemas de desempenho no servidor de gerenciamento ou no Microsoft SQL Server que está hospedando o OperationsManager banco de dados ouOperationsManagerDW:

   ID do evento: 2115
   Fonte do evento: HealthService
   Descrição do evento:
   Uma fonte de dados bind no grupo de gerenciamento %1 postou itens no fluxo de trabalho, mas não recebeu uma resposta em %5 segundos. Isso indica um problema de desempenho ou funcional com a ID do fluxo de trabalho.%n : %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 está paralisado com o reconhecimento pendente. %n%nManagement Group: %2 %nManagement Group ID: %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
   Fonte do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Falha ao armazenar dados no Data Warehouse. A operação será retried.%rException '%5': %6 %n%nOne ou mais fluxos de trabalho foram afetados por isso. %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   ID do evento: 31552
   Fonte do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Falha ao armazenar dados no Data Warehouse.%rException '%5': %6 %n%nOne ou mais fluxos de trabalho foram afetados por isso. %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   ID do evento: 31553
   Fonte do evento: Módulos do Serviço de Integridade
   Descrição do evento:
   Os dados foram gravados na área de preparo Data Warehouse, mas o processamento falhou em uma das operações subsequentes.%rException '%5': %6 %n%nOne ou mais fluxos de trabalho foram afetados por isso. %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   ID do evento: 31557
   Fonte 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 Data Warehouse banco de dados. A operação será retried.%rException '%5': %6 %n%nOne ou mais fluxos de trabalho foram afetados por isso. %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %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ários 4

Todos os agentes que relatam a um servidor de gerenciamento específico alternam intermitentemente entre estados saudáveis e cinzas. Ou, todos os agentes no ambiente alternam intermitentemente entre estados saudáveis e cinzas.

Resolução para o cenário 4

Para resolve o problema, primeiro determine a causa do problema. As causas comuns da 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 maior uso de recursos do sistema no banco de dados do Operations Manager e nos servidores do Operations Manager.
• Interrupções de rede causaram uma falha de comunicação temporária 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 de recursos do sistema no banco de dados do Operations Manager e nos servidores do Operations Manager.

A chave para solucionar problemas nesses cenários é entender a duração da indisponibilidade do servidor e a hora do dia durante a qual ocorreu. Isso ajudará você a reduzir rapidamente o escopo do problema.

Solução de problemas de desempenho do servidor de gerenciamento e do gateway

Servidor de gerenciamento

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

Para a coleta de dados operacionais, os gargalos normalmente são causados pela CPU. A E/S do disco também pode estar em 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 (reconhecimentos) de volta aos agentes ou gateways depois de receber dados operacionais e usa a fila de disco para armazenar temporariamente esses ACKs de saída.

Gateway

O gateway está vinculado à CPU e ao limite de 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 descompressão, compactação, criptografia e descriptografia dos dados de entrada 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 de disco pesado. Esse uso pode ser significativo quando o gateway é retirado temporariamente offline e, em seguida, 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 para cada servidor de gerenciamento ou gateway afetado:

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

• Número de processadores

• Quantidade de RAM

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

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

  Observação

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

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

• Número de discos usados para o RAID

• Se o cache de gravação com suporte à bateria está habilitado no controlador de matriz

Solução de problemas SQL Server desempenho

Banco de dados operacional (OperationsManager)

Para o OperationsManager banco de dados, o gargalo mais provável é a matriz de disco. Se a matriz de disco não estiver na capacidade máxima de E/S, o próximo gargalo mais provável será a CPU. O banco de dados sofrerá desacelerações ocasionais e tempestades 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 pequena explosão 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 para gravações. O uso da CPU é causado por SQL Server rotatividade. Isso pode ocorrer quando você tem consultas grandes e complexas, inserção de dados pesados e o preparo de tabelas grandes (que, por padrão, ocorre à meia-noite). Normalmente, o preparo de eventos grandes e tabelas de dados de desempenho não consome recursos excessivos de CPU ou disco. No entanto, o preparo das tabelas de alterações de estado e alerta pode ser intensivo em CPU para tabelas grandes.

O banco de dados também está vinculado à CPU quando lida com explosões 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 Config consulta o banco de dados para nova configuração de 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 OperationsManagerDW banco de dados, o gargalo mais provável é a matriz de disco. Isso geralmente ocorre devido a grandes inserções de dados operacionais. Nesses casos, os discos estão em sua maioria ocupados executando gravações. Normalmente, os discos estão executando poucas leituras, exceto para lidar com exibições de relatórios geradas manualmente porque essas consultas de execução no data warehouse.

O uso da CPU é causado por SQL Server rotatividade. Picos de CPU podem ocorrer durante uma atividade de partição pesada (quando as tabelas se tornam grandes e depois são particionadas), 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 para cada servidor de gerenciamento ou gateway afetado:

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

• Número de processadores

• Quantidade de RAM

• Quantidade de memória alocada para SQL Server

• Se SQL Server é de 32 bits e está habilitado para AWE

  Você pode encontrar a maioria dessas informações no SQL Server Management Studio ou no gerenciador de SQL Server Enterprise. Para fazer isso, abra a janela Propriedades do servidor e selecione as guias Geral e Memória . A guia Geral inclui a versão 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 SQL Server. No Microsoft SQL Server 2008, a guia Memória também inclui a opção AWE.

  Se o sistema operacional for de 32 bits e a RAM for 4 GB ou maior, marcar se os /pae switches ou /3gb existem no Boot.ini. arquivo. Essas opções poderiam ser configuradas incorretamente se o servidor fosse originalmente instalado com 4 GB ou menos de RAM e se a RAM fosse atualizada posteriormente.

  Para servidores de 32 bits que têm 4 GB de RAM, a opção /3gb em Boot.ini aumenta a quantidade de memória que 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 em Boot.ini pode realmente limitar a quantidade de memória que SQL Server pode resolver. Para esses sistemas, adicione a opção /pae a Boot.ini e habilite a AWE em SQL Server.

  Em um sistema multiprocessador, marcar a configuração Max Degree of Parallelism (MAXDOP). No SQL Server 2008, essa opção está na guia Avançado na caixa de diálogo Propriedades para o servidor.

  O valor padrão é 0, o que significa que todos os processadores disponíveis serão usados. Uma configuração de 0 é boa para servidores que têm oito ou menos processadores. Para servidores com mais de oito processadores, o tempo necessário SQL Server para coordenar o uso de todos os processadores pode ser contraproducente. Portanto, para servidores com mais de oito processadores, você geralmente deve definir 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 data warehouse, Operations Manager DB e Tempdb

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

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

• Tipo de armazenamento (SAN ou local)

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

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

• Se o pacote de gerenciamento do Exchange 2007 convertido 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 da 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 esses contadores de disco físico para todas as unidades que contêm dados SQL ou arquivos de log:

• % Tempo ocioso: quanto tempo ocioso do disco está sendo relatado. Qualquer coisa abaixo de 50% pode indicar um gargalo de disco.

• Comprimento da fila de disco: esse valor não deve exceder o dobro do número de eixos 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 RAID e no número de discos na configuração RAID:

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

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

  • RAID 1: metade dos discos estão funcionando; Portanto, apenas metade delas pode ser contada em direção à fila de disco

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

  • RAID 10: metade dos discos estão "fazendo trabalho"; Portanto, apenas metade delas pode ser contada em direção à 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 RAID 5

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

  • Avg. Disco s/Transfer: o número de segundos necessários para concluir uma E/S de disco

  • Avg. Disco s/Leitura: o tempo médio, em segundos, para ler dados do disco

  • Avg. Disco s/Gravação: o tempo médio, em segundos, para gravar dados no disco

    Os últimos três contadores desta lista devem ter valores de aproximadamente .020 (20 ms) ou inferiores e nunca devem exceder .050 (50 ms). Veja a seguir os limites 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
    • Maior que 50 ms: gargalo sério de E/S

  • Bytes de disco/s: o número de bytes que estão sendo transferidos para ou do disco por segundo

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

  Quando % Idle Time é baixo (10% ou menos), isso significa que o disco é totalmente utilizado. Nesse caso, os dois últimos contadores nesta lista (Bytes de Disco/s e Transferências de Disco/s) fornecem uma boa indicação da taxa de transferência máxima da unidade em bytes e no IOPS, respectivamente. A taxa de transferência de uma unidade SAN é altamente variável, dependendo do número de eixos, da velocidade das unidades e da velocidade do canal. A melhor aposta é marcar com o fornecedor san para descobrir quantos bytes e IOPS a unidade deve dar suporte. Se % Idle Time for baixo e os valores desses dois contadores não atenderem à taxa de transferência esperada da unidade, envolva o fornecedor de SAN para solucionar problemas.

SQL Server guia de solução de problemas de desempenho fornece uma visão mais profunda sobre a solução de problemas SQL Server desempenho.

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

Contadores de desempenho gerais

Esses contadores indicam o desempenho geral do gateway:

Contadores de desempenho genéricos 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 gerais

Esses contadores indicam o desempenho geral do servidor de gerenciamento:

Contadores de desempenho genéricos 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: