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

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 de 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 que o administrador configurou e, em seguida, gera alertas. Um alerta é um indicador de que o problema requer algum tipo de ação.

Uma exibição do operador de Gestão de eventos — Figura 1. Geração de alertas

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, tomar uma ação para ajudar a resolver o problema subjacente ou notificar alguém que possa. Mais tarde neste tutorial, você verá as fases de um processo típico de gerenciamento de alertas.

Prioridade e severidade do alerta

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

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 severidade 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.
Importante	A funcionalidade principal está gravemente prejudicada ou o desempenho foi degradado.
secundário Secundário	Ocorreu perda parcial e não crítica de funcionalidade ou degradação de desempenho.
de Aviso Aviso	É necessário atenção, mesmo que o recurso ainda esteja funcional.
OK OK	Nenhuma severidade. Um alerta é 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, 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, abaixo do 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 nenhum outro roteador. A indisponibilidade do roteador se torna o alerta primário e os alertas gerados no servidor são alertas secundários que estão correlacionados ao alerta do roteador.

Alertas correlacionados — 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 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 os alertas adicionais com o alerta primário. Posteriormente 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 ele 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 sequência. 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.

Uso de CPU — 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 o uso excessivo da CPU. Como o uso da CPU pode variar 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 ou alguém precise 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 repetidas e temporárias. Os limites que o 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.