Noções Básicas Sobre Correlação de Alertas

Tópico modificado em: 2015-03-09

O Mecanismo de Correlação está no núcleo do Pacote de Gerenciamento de Monitoramento do Microsoft Exchange Server 2010. O mecanismo de correlação foi desenvolvido para reduzir de forma significativa o número de alertas que são emitidos pelo Pacote de Gerenciamento.

No Pacote de Gerenciamento do Exchange 2007, os alertas sempre eram emitidos quando o estado de um monitor mudava de verde para vermelho. Esse tipo de alerta está desativado no Pacote de Gerenciamento do Exchange Server 2010. Em vez disso, o mecanismo de correlação lida com alertas. Ele processa os dados dos monitores do Pacote de Gerenciamento e, em seguida, determina se aciona um alerta. O mecanismo de correlação ajuda o administrador que está monitorando o ambiente do Exchange para focar somente nos alertas que podem requerer uma ação.

Arquitetura

O Mecanismo de Correlação é um serviço autônomo do Windows que usa a interface SDK do Operations Manager para primeiro recuperar o modelo de integridade (ou espaço da instância) e, em seguida, processar os eventos de alteração de estado. Mantendo o modelo de integridade em memória e processando eventos de alteração de estado, o Mecanismo de Correlação é capaz de determinar quando acionar um alerta, baseado no estado do sistema.

O diagrama mostra que, em resposta a um problema, vários monitores alteram o estado e os eventos de alteração de estado correspondentes são encaminhados pelo agente para o Servidor de Gerenciamento Raiz (RMS). Uma vez recebidos pelo RMS, esses eventos são processados pelo Mecanismo de Correlação, que pode acionar um alerta via interface SDK (Software Development Kit) do RMS. Este alerta, em seguida, é visível no Console do Operations Manager.

Classificação de alertas

Os alertas do Pacote de Gerenciamento de Monitoramento do Exchange Server 2010 são classificados em uma de três categorias. Use as diretrizes a seguir para compreender essas classificações de alertas.

• Indicador de Integridade Principal (KHI)   KHIs são problemas que afetam a integridade do serviço. A maioria dos alertas entra nesta categoria (por exemplo, "Um banco de dados de caixa de correio está desmontado".)

• Impacto Não Relacionado ao Serviço (NSI)   Monitores NSI detectam problemas que podem afetar alguns usuários do sistema, não todos. Um bom exemplo de uma situação de NSI são dois usuários com o mesmo endereço de proxy - emails para esse endereço retornarão como não-entregáveis, mas o sistema de transporte como um todo não é prejudicado.

• Forense   Monitores forenses são usados para registrar informações que podem ser relevantes para solucionar um problema, mas não é necessariamente indicativo de uma falha de sistema eminente ou existente. "Atividade de CPU >90% por 5 minutos" é um exemplo de problema forense - pode existir um processo consumindo ciclos de CPU de forma inapropriada, ou o servidor pode ter sido reiniciado e está voltando à atividade normal. Esses monitores são visíveis no campo Contexto do Alerta das propriedades do alerta no Gerenciador de Integridade. Alertas não são gerados para monitores Forenses.

Observação:
O estado não é atualizado quando um único alerta de monitor forense alerta é acionado. No entanto, o estado pode ser atualizado com base na agregação de alertas de monitor forense atual, para cada componente.

Severidade do alerta

Os alertas do Pacote de Gerenciamento de Monitoramento do Exchange Server 2010 também são classificados pela severidade dos alertas, desta forma:

• Alertas de erro   Os alertas de erro indicam um problema sério que exige atenção imediata.

• Alertas de aviso   Alertas de aviso indicam uma condição que pode causar problemas no futuro.

• Alertas informativos   Alertas informativos não são gerados pelo Pacote de Gerenciamento do Exchange 2010.

Fatores de Correlação

As ações tomadas pelo mecanismo de correlação são baseadas em vários fatores, incluindo o seguinte:

Monitorar eventos de mudança de estado  Monitores coletam informações diagnósticas do ambiente do Exchange de fontes tais como mensagens do log de eventos, limites de contadores de desempenho, e eventos de saída de tarefa do PowerShell. Monitores registram eventos de mudança de estado quando eles detectam que um problema ocorreu ou limpou (ou seja, mudou de vermelho para verde ou de verde para vermelho). Monitores também registram mudanças de estado quando um servidor de Exchange não pode ser contatado ou quando um servidor de Exchange fica disponível. Finalmente, os monitores registram mudanças de estado quando um servidor de Exchange é colocado em modo de manutenção ou removido do modo de manutenção. No Pacote de Gerenciamento do Exchange 2007, os alertas sempre eram acionados quando o estado de um monitor mudava de verde para vermelho. No Pacote de Gerenciamento do Exchange 2010, os alertas não são automaticamente acionados pelas alterações de estado do monitor. O mecanismo de correlação determina se deve acionar um alerta. O Pacote de Gerenciamento do Exchange 2010 inclui uma regra de alerta para cada monitor. Isto permite que o pessoal do monitoramento use o console de operações para acessar as propriedades de cada monitor no Pacote de Gerenciamento. Eles podem inserir observações específicas da empresa para um dado monitor no campo de Conhecimento de empresa mesmo quando o monitor não gerar alertas por si só.

Modelo de integridade   A hierarquia de classes importada no gerenciador de operações pelo Pacote de Gerenciamento do Exchange 2010 inclui os relacionamentos de classe que definem as dependências do componente no sistema. A definição dessas dependências ajuda o Pacote de Gerenciamento do Exchange 2010 para entender a integridade da organização do Exchange. Por exemplo, se o Pacote de Gerenciamento do Exchange 2010 identifica o Active Directory como offline, ele também reportará que o sistema de mensagens do Exchange não está totalmente funcional.

Intervalo   O Mecanismo de Correlação funciona em intervalos de 90 segundos. Quando eventos de alteração de estado para vários monitores entram ao mesmo tempo, o mecanismo de correlação espera para ver se mais alguma coisa possivelmente relacionada à falha é detectada, para que possa determinar a causa raiz de forma mais efetiva.

Algoritmo de Correlação

Visão geral do processo do Mecanismo de Correlação

1. O mecanismo de correlação conecta ao serviço do Operations Manager SDK para fazer o download da hierarquia do modelo de integridade e estado de instância. Isto ocorre somente na inicialização do serviço, ou quando necessário devido a erros.

2. Em seguida, busca no Operations Manager os eventos de alteração de estado mais recentes, relacionados às entidades no Pacote de Gerenciamento do Exchange.

3. Se novas alterações de estado de não-serviço impactante são detectadas, o mecanismo de correlação aciona alertas para eles.

4. O mecanismo de correlação isola os dados de todos os monitores de indicador chave de integridade que estão no estado vermelho. O mecanismo de correlação organiza esses dados em agrupamentos lógicos que mostram cada processo em relação aos que ele depende e aqueles que dependem dele. Esses agrupamentos são comumente referidos como "cadeias de indicador chave de integridade". Cada cadeia indica onde uma dependência falhou e está afetando um ou mais processos dependentes.

5. O mecanismo de correlação gera um alerta para cada cadeia de indicador chave de integridade. Cada alerta que o mecanismo de correlação gera identifica a causa raiz de cada problema.

6. O mecanismo de correlação aguarda 90 segundos e, em seguida, recomeça na etapa 2.

Informações adicionais sobre o processo do mecanismo de correlação

• Se a cadeia de KHIs incluir monitores de erro e de aviso, o alerta é acionado como um erro, independente da classe do monitor da causa raiz. Por exemplo, se um processo de nível-top define um monitor de erro para capturar casos de falhas, e se está correlacionado a um monitor de aviso em uma dependência, o alerta será acionado contra a dependência. Mas vai ser marcado como um erro em vez de um aviso.

• Nem todo relacionamento de classe é usado para correlação de alerta. Consulte o Apêndice: Hierarquia de classe, posteriormente neste guia, para ver os relacionamentos específicos usados pelo Mecanismo de Correlação.

• A cadeia KHI, incluindo quaisquer monitores forenses, é incluída no campo Contexto do alerta, disponível nas propriedades do alerta final. Isto permite que o administrador reveja os monitores que correlacionam como o alerta dado. Alertas gerados de monitores de dependência devem ser revistos para determinar a falha específica referenciada pelo alerta.

O que é e não é afetado pela correlação de alertas

É importante enteder o que o mecanismo de correlação afeta e o que não afeta.

A funcionalidade seguinte é diferente no Pacote de Gerenciamento do Exchange 2010 devido à adição do mecanismo de correlação:

• Monitores não alertam automaticamente quando ocorrem eventos de alteração de estado. O mecanismo de correlação pode determinar o melhor alerta a ser acionado.

• O Pacote de Mecanismo do Exchange 2010 não aciona alertas que correspondem à integridade do ambiente do Exchange quando o mecanismo de correlação é parado. Se o mecanismo de correlação é parado, um alerta geral é acionado para notificar que o mecanismo de correlação não está sendo executado.

A seguinte funcionalidade não será alterada pela adição do mecanismo de correlação:

• Substituições ainda funcionam como esperado. Certos valores podem ser mudados ou monitores desativados como são atualmente.

• Monitores/objetos em modo de manutenção são ignorados pelo mecanismo de correlação. Nenhuma consideração especial é requerida porque os monitores não acionam eventos de alteração de estado.

• Outros pacotes de gerenciamento não são afetados pela presença do mecanismo de correlação.

Observações operacionais

O mecanismo de correlação deve manter o espaço de instância do grupo de gerenciamento em memória para determinar monitores e alertas relacionados. Além disso, quanto mais servidores do Exchange e bases de dados você possui, mais memória o mecanismo de correlação irá requerer.

O mecanismo de correlação requer aproximadamente 5 megabytes de memória por servidor monitorado do Exchange. Existem fatores que podem impulsionar este número para cima ou para baixo, mas é um bom ponto de partida para entender o impacto do recurso no servidor que hospeda o serviço.

Redefinição automática de monitores de eventos no Pacote de Gerenciamento do Exchange 2010

No Pacote de Gerenciamento do Exchange 2010, a maioria dos monitores de evento é reiniciada automaticamente pelo Mecanismo de Correlação. A redefinição automática foi incluída em alguns monitores de eventos para que problemas não sejam perdidos na próxima vez em que acontecerem. A tabela a seguir lista os monitores de eventos que não são redefinidos automaticamente.

Nome do monitor
Um erro ocorreu enquanto o agente de registro no diário estava carregando informações de configuração.
Uma falha está mantendo uma mensagem em uma fila de entrega.
A configuração do serviço de descoberta automática não é segura. Para corrigir esse problema, desabilite o acesso anônimo no diretório virtual de descoberta automática.
Exchangenão foi possível criar o diretório de arquivo de log. Arquivos de log não serão gerados até que a razão da falha seja corrigida. O componente fonte e a causa do erro são especificados na descrição do evento.
Exchange não foi possível criar um novo arquivo de log. Arquivos de log não serão gerados até que a razão da falha seja corrigida. O componente fonte e a causa do erro são especificados na descrição do evento.
Arquivos somente leitura foram encontrados no diretório de recebimento.
O serviço de transporte do Microsoft Exchange detectou um erro de armazenamento crítico e tomou uma ação de recuperação automática movendo a base de dados.
Serviço de Distribuição de Arquivos: Falha ao ler o descritor de segurança do Active Directory para o catálogo de endereços offline.
Aviso ExBPA.
Erro ExBPA.
Não foi possível mover a caixa de correio.
A DLL DsProxy é necessária, mas não pode ser carregada.
Não foi possível inicializar os contadores de desempenho do proxy NSPI.
O índice está danificado na cópia do banco de dados local. Propague o catálogo usando o cmdlet Update-MailboxDatabaseCopy cmdlet com o parâmetro -CatalogOnly.
Impossível de carregar os contadores de desempenho para o serviço de envio de mensagens do Microsoft Exchange. O objeto de desempenho relacionado é denominado MSExchangeMail Submission.
O servidor de topologia local não pertence a nenhum site do Active Directory.
O Serviço de envio de mensagens do Microsoftt encontrou uma exceção ao tentar carregar informações de topologia.
Exchange A descoberta de topologia não pode encontrar o servidor local do Exchange no Active Directory.
Uma falha está mantendo uma mensagem na fila de envio.
Uma cópia de base de dados encontrou um sério erro de fluxo perdido que pode ter afetado todas as cópias da base de dados.
Uma cópia de base de dados ativa encontrou um sério erro de fluxo perdido que pode ter afetado todas as cópias da base de dados.
Uma cópia de base de dados local encontrou um sério erro de fluxo perdido que pode ter afetado todas as cópias da base de dados.
O mecanismo de banco de dados consumiu 99% do recurso de "b-trees" (87048 usados de um máximo de 87696) do banco de dados.
Arquivos de propagação incremental da cópia de um banco de dados não puderam ser removidos.
Falha ao remover arquivos de replicação contínua para uma cópia do banco de dados.
O processo de restauração de página única começou corrigindo um erro em uma cópia do banco de dados.
O processo de restauração de página única corrigiu corretamente um erro em uma cópia do banco de dados.
Falha ao remover um arquivo de log de banco de dados. O arquivo está em uso ou o serviço não possui permissões suficientes.
O valor do intervalo de correlação especificado é menor do que o mínimo valor permitido.
O valor do intervalo de correlação especificado é menor do que o mínimo valor permitido.