Trabalhando com alertas e eventos

No serviço IBM Cloud Monitoring, é possível configurar alertas únicos e alertas de várias condições para notificar sobre problemas que podem exigir atenção. Quando um alerta é acionado, é possível ser notificado por meio de um ou mais canais de notificação. Uma definição de alerta pode gerar notificações de vários canais.

Um alerta é um evento de notificação que pode ser usado para avisar sobre situações que requerem atenção. Cada alerta tem um status de severidade. Esse status informa sobre o grau de severidade das informações sobre as quais ele relata.

Ao definir um alerta, deve-se definir a condição que aciona a notificação e um ou mais canais de notificação pelos quais você deseja ser notificado. Deve-se também definir a severidade e o tipo de alerta. Para obter mais informações sobre como configurar um alerta, consulte Configurando um alerta.

Por padrão, a severidade é configurada como warning. É possível configurar a severidade de um alerta para qualquer um dos valores a seguir: emergency, alert, critical, error, warning, notice, informational, debug*

É possível definir um alerta em uma única métrica ou em um conjunto de métricas para notificar sobre eventos ou problemas que você deseja monitorar.

  • É possível definir um alerta de condição única.
  • É possível definir um alerta com várias condições. O limite de alerta é configurado usando condições complexas.
  • É possível definir como os dados são agregados.
  • É possível usar a lógica booleana para definir alertas que relatam várias métricas.
  • Você recebe uma notificação quando a condição de alerta é atendida.
  • É possível configurar vários canais de notificação por alerta.
  • Os alertas são executados em um minuto ou menos após o recebimento, com a opção de configurar o tempo de espera do acionador por hora ou por dia.
  • Opcionalmente, é possível configurar um tempo de espera de 0 minutos somente para os alertas PromQL.

É possível ativar alertas predefinidos, modificar alertas e criar alertas customizados na IU da web e usando a API do IBM Cloud Monitoring.

Você gerencia alertas na visualização Alertas da IU da web. É possível configurar as colunas da tabela que são exibidas na visualização Alertas. As opções de coluna válidas são Nome, Escopo, Alertar quando, Segmentar por, Notificações, Ativado, Modificado, Capturas, Canais, Criado, Descrição, Destinatários de e-mail, Para pelo menos, OpsGenie, PagerDuty, Gravidade, Slack, WebHook, Tipo e VictorOps.

Tipos de alertas

O serviço IBM Cloud Monitoring inclui alertas predefinidos que podem ser ativados. Além disso, é possível configurar alertas customizados por meio de painéis em um painel, usando a API de REST ou na seção Alertas da IU da web.

No serviço IBM Cloud Monitoring, é possível definir qualquer um dos seguintes tipos de alertas:

  • Tempo de inatividade: use esse tipo de alerta para monitorar origens e para alertar quando elas estiverem inativas, por exemplo, um metal bare.

  • Métrica: use esse tipo de alerta para monitorar métricas de série temporal e para alertar quando elas atingirem os limites definidos.

  • PromQL: use esse tipo de métrica para monitorar métricas usando uma consulta PromQL.

  • Evento: use esse tipo de alerta para monitorar ocorrências de eventos específicos e para alertar quando eles atingirem os limites definidos. Por exemplo, é possível usar esse alerta para monitorar quando várias solicitações de acesso não autorizado são relatadas.

  • Detecção de anomalia: use esse tipo de alerta para monitorar hosts com base em comportamentos históricos e para alertar quando eles se desviarem do padrão esperado.

    Esse tipo de alerta está obsoleto. Você só pode gerenciar alertas existentes desse tipo.

  • Valor discrepante de grupo: use esse tipo de alerta para monitorar hosts e ser notificado quando um deles agir de forma diferente do restante.

    Esse tipo de alerta está obsoleto. Você só pode gerenciar alertas existentes desse tipo.

Canais de notificações

Um canal de notificação define onde você deseja receber informações quando um alerta é acionado.

Ao configurar um alerta, é possível especificar um ou mais canais de notificação.

Por padrão, quando um alerta é acionado, você recebe uma notificação na seção Eventos.

É possível configurar qualquer um dos seguintes canais de notificação:

  • E-mail
  • IBM Event Notifications
  • Equipes da Microsoft
  • OpsGenie
  • PagerDuty
  • Slack
  • E- mail de equipes
  • VictorOps
  • WebHook

Eventos

Um evento é uma notificação que informa sobre algo que ocorre em qualquer um dos nós que encaminham dados para sua instância do Monitoring. Use eventos para revisar, rastrear e resolver problemas.

A lista a seguir descreve diferentes tipos de eventos:

  • Eventos de alerta são aqueles acionados por alertas configurados pelo usuário.
  • Eventos baseados em infraestrutura são aqueles coletados dos nós do Docker e do Kubernetes. Por padrão, o agente de monitoramento descobre e coleta automaticamente dados de um grupo de eventos selecionado. É possível editar o arquivo de configuração do agente para permitir mais eventos.
  • Eventos customizados configurados por meio de qualquer uma das integrações a seguir: Slackbot, scripts Python pré-construídos, scripts Python customizados criados pelo usuário ou solicitações de cURL.

Por padrão, um evento tem um estado:

  • Ativo: esse estado indica que as circunstâncias que acionaram o evento permanecem em vigor, por exemplo, um nó continua inativo.
  • OK: esse estado indica que a situação está de volta ao normal, por exemplo, um nó está funcionando.

Você gerencia eventos na seção Eventos da IU da web.

  • É possível visualizar eventos de alerta por meio da guia Eventos de alerta.
  • É possível visualizar eventos baseados em infraestrutura por meio da guia Eventos customizados.
  • É possível visualizar eventos customizados por meio da guia Eventos customizados.
  • É possível enviar eventos customizados para qualquer uma de suas equipes usando o token de API para essa equipe. Para mais informações, veja Eventos personalizados).
  • É possível configurar o evento como Resolvido para notificar outros usuários de que o problema foi endereçado em vez de esperar que o status seja configurado como OK.