Uma visão geral dos alertas para Gestão de eventosoperadores

Como um Gestão de eventosoperador, 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 em Gestão de eventostutorial.

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 em vigor, como o Microsoft System Center Operations Manager (SCOM), Nagios, SolarWinds e assim por diante. Quando ocorre um problema na sua rede, como um computador inoperante ou uma falha no banco de dados, as ferramentas de monitoramento de eventos são enviadas eventos para seu ServiceNowinstância. . Gestão de eventosa aplicação processa o. 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.

Figura 1. Geração de alertas

Como um Gestão de eventossua função é exibir alertas e, dependendo de como Gestão de eventosfor implementado em sua organização, execute uma ação para ajudar a resolver o problema subjacente ou notifique alguém que possa. Mais adiante neste tutorial, você verá as fases de um processo típico de gestão de alertas.

Gravidade e prioridade do alerta

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

• . 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 Gestão de eventoso administrador pode configurar o algoritmo que o. Gestão de eventosa aplicação usa para calcular a prioridade.
• . 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 gravidade com o evento, que é transferido para o 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.
  Grave	A funcionalidade principal está gravemente prejudicada ou o desempenho foi degradado.
  Secundário	Ocorreu perda parcial e não crítica de funcionalidade ou degradação de desempenho.
  Aviso	É necessária atenção, mesmo que o recurso ainda esteja funcional.
  OK	Nenhuma gravidade. 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 conetado ao roteador. Todos esses alertas estão relacionados, ou correlacionado . Para ajudar você a gerenciar alertas correlacionados, Gestão de eventospode 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 alertas secundários , no alerta primário. Ao exibir alertas, os alertas primários se destacam por padrão para que você saiba em qual alerta se concentrar sem se distrair com os alertas secundários.

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

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

Dependendo da sua organização Gestão de eventosos alertas podem ser agrupados automaticamente com base nas regras de correlação configuradas pelo administrador. Sua instância também pode aprender como melhorar a forma como correlaciona alertas com base nessas regras. 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 adiante no tutorial, você aprenderá como fazer isso.

Neste tutorial, você aprenderá como correlacionar alertas manualmente.

Alerta piscando

Um alerta pode disparar, o que significa que ele recebe vários eventos de abertura-fechamento em rápida sucessão. Bater indica que Gestão de eventosnão sabe se os eventos subjacentes são genuínos 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. Alerta piscando

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, levando ao alerta a ser colocado no estado de oscilação. Como operador, pode ser necessário 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 momentâneas e repetidas. Os limites configurados pelo administrador podem não ser ideais para este tipo de alerta e. Gestão de eventoso considera um alerta flutuante.

Continue o tutorial

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