Uma visão geral de alertas para operadores Gestão de eventos

Como um operador Gestão de eventos, você precisa entender como um alerta é gerado a partir de um evento, o que procurar em um alerta e como os alertas podem ser agrupados.

Esta é a primeira lição do tutorial Gestão de eventos.

Lição 1		Uma visão geral de eventos e alertas
Lição 2		Uma visão geral dos serviços de aplicações
Lição 3		Gestão de eventos espaços do operador
Lição 4		O que os operadores fazem

Sua organização já tem uma ferramenta de monitoramento de eventos, como Microsoft System Center Operations Manager (SCOM), Nagios, SolarWinds e assim por diante. Quando ocorre um problema em sua rede, como um computador inativo ou uma falha no banco de dados, as ferramentas de monitoramento de eventos enviam eventos para sua instância ServiceNow. A aplicação Gestão de eventos processa os eventos de acordo com as configurações definidas pelo administrador e, em seguida, gera alertas. Um alerta é um indicador de que o problema requer algum tipo de ação.

Figura 1. Geração de alerta

Como um operador Gestão de eventos, sua função é exibir alertas e, dependendo de como Gestão de eventos é implementado em sua organização, executar uma ação para ajudar a resolver o problema subjacente ou notificar alguém que possa. Posteriormente neste tutorial, você verá as fases de um processo típico de gerenciamento de alertas.

Prioridade e gravidade do alerta

As duas características mais comuns de um alerta são a prioridade e a gravidade.

• A prioridade de um alerta é uma pontuação que ajuda a determinar a importância do impacto para os serviços de aplicações. Vários fatores determinam a pontuação de prioridade do alerta. Seu administrador Gestão de eventos pode configurar o algoritmo que a aplicação Gestão de eventos usa para calcular a prioridade.
• A gravidade de um alerta é um indicador da gravidade do problema subjacente. A ferramenta de monitoramento de eventos em sua organização geralmente envia valores de severidade com o evento, que são transportados no alerta. Estes são os tipos de severidade padrão que você verá neste tutorial:

  Gravidade	Descrição
  Crítico	O recurso não está funcional ou há problemas críticos iminentes.
  principal	A funcionalidade principal está gravemente prejudicada ou o desempenho foi degradado.
  secundário Secundário	Ocorreu uma perda parcial e não crítica de funcionalidade ou degradação do desempenho.
  de aviso Aviso	É necessário atenção, embora o recurso ainda esteja funcional.
  OK	Sem gravidade. Um alerta foi criado. O recurso ainda está funcional.
  Limpar	O alerta não precisa mais de ação.

Alertas correlacionados

Alguns alertas estão relacionados entre si. Por exemplo, se um roteador ficar inativo, vários alertas separados poderão ser gerados, um para cada servidor conectado ao roteador. Todos esses alertas estão relacionados ou correlacionados. Para ajudá-lo a gerenciar alertas correlacionados, o Gestão de eventos pode agrupá-los automaticamente e estabelecer uma hierarquia de dois níveis com um alerta raiz, chamado de alerta primário, na parte superior e outros alertas relacionados, chamados de alertas secundários, sob o alerta primário. Quando você exibe alertas, os alertas primários se destacam por padrão para que você saiba em qual alerta se concentrar sem se perder nos alertas secundários.

Em nosso exemplo, se um roteador ficar inativo em sua rede, a comunicação de rede também será afetada para os servidores conectados, supondo que eles não possam acessar outros roteadores. A indisponibilidade do roteador se torna o alerta primário e os alertas gerados no servidor são alertas secundários correlacionados ao alerta do roteador.

Figura 2. Geração de alerta secundário

Dependendo da implementação Gestão de eventos da sua organização, os alertas podem ser agrupados automaticamente com base nas regras de correlação que o administrador configura. Sua instância também pode aprender a melhorar a maneira como ela correlaciona alertas com base nessas regras e no feedback que você pode fornecer. Como operador, você ainda deve verificar a precisão da correlação e, se necessário, correlacionar manualmente alertas adicionais com o alerta primário. Mais tarde no tutorial, você aprenderá a fazer isso.

Neste tutorial, você aprenderá a correlacionar alertas manualmente. Em um tópico avançado, você aprenderá a fornecer feedback ao sistema, para que seu sistema possa melhorar o processo de correlação automática de alertas.

Oscilação de alerta

Um alerta pode oscilar, o que significa que ele obtém vários eventos de abertura-fechamento em rápida sucessão. A oscilação indica que Gestão de eventos não sabe se os eventos subjacentes são verdadeiros ou não. Os eventos podem indicar pequenos problemas com a forma como os ICs são configurados ou problemas maiores, como indisponibilidades de rede.

Figura 3. Oscilação de alerta

Por exemplo, se um servidor que hospeda um serviço Web tiver muitos processos ativos, ele poderá acionar um evento sobre uso excessivo da CPU. Como o uso da CPU pode flutuar rapidamente dependendo das solicitações de serviço Web, vários eventos podem ser acionados, fazendo com que o alerta seja colocado no estado de oscilação. Como operador, talvez você precise criar um incidente para que o servidor seja reiniciado, alguém pode precisar reconfigurar a CPU ou possivelmente fazer uma mudança de hardware no dispositivo.

Como outro exemplo, considere um cabo de rede solto que causa indisponibilidades de rede temporárias e repetidas. Os limites que o seu administrador configura podem não ser ideais para este tipo de alerta e Gestão de eventos o considera um alerta oscilante.

Continuar o tutorial

Prossiga para a próxima lição: Serviços de aplicações para operadores Gestão de eventos.