Este documento descreve os adiamentos, que permitem impedir que o Cloud Monitoring crie alertas e emita notificações durante períodos específicos. É possível criar e gerenciar as suspensões usando o console Google Cloud , a Google Cloud CLI e a API Cloud Monitoring.
Quando suspender políticas de alertas
Crie um adiamento quando quiser impedir temporariamente a criação de alertas e o envio de notificações ou para evitar o envio de notificações repetidas sobre um alerta aberto. Por exemplo, você pode criar uma soneca nas seguintes situações:
- Você tem uma manutenção planejada.
- Você tem uma interrupção cada vez mais grave e quer evitar mais alertas e notificações.
Como as sonecas funcionam
Quando um adiamento de uma política de alertas está ativo, o Monitoring não envia notificações nem cria alertas para a política de alertas adiada. Quando você aplica uma suspensão a uma política de alertas com base em métricas ou SQL, o Monitoring também encerra todos os alertas relacionados a essa política.
Para criar uma soneca, faça o seguinte:
Para aplicar o adiamento a várias políticas de alertas, crie-o na página Alertas, na CLI gcloud ou na API Cloud Monitoring. Você também pode escolher quando o adiamento começa e definir a duração dele.
Aplicar a suspensão a várias políticas de alertas pode ser útil quando você tem uma manutenção programada e precisa que a suspensão comece em um horário específico e dure por um período predeterminado.
Para adiar um alerta específico, crie a opção na página Detalhes do alerta de um alerta aberto. Nesse caso, todos os campos de adiamento são pré-configurados, exceto a duração.
Aplicar a suspensão de um alerta específico pode ser útil quando você tem uma interrupção crescente e precisa suspender imediatamente uma política de alertas até que os problemas relacionados sejam resolvidos.
Componentes de adiamentos
Uma ação de adiar tem os seguintes componentes:
Um nome. Recomendamos que você use esse campo para descrever a finalidade da suspensão.
Um período que determina quando o adiamento está ativo. Ele é especificado por um horário de início e uma duração. Um adiamento ativo impede que o Monitoring crie alertas e emita notificações para políticas de alertas que correspondam aos critérios do adiamento. Fora do período ativo, a suspensão fica inativa. Um adiamento inativo não afeta a criação de alertas e o envio de notificações.
Critérios para o adiamento, que incluem o seguinte:
Uma lista de políticas de alertas a que a suspensão se aplica.
Um filtro opcional com base em rótulo que pode ser usado quando o adiamento se aplica a uma única política de alertas. Você define os rótulos do filtro para adiar alertas com rótulos correspondentes. Por exemplo, suponha que um filtro inclua um rótulo para um ID de instância de máquina virtual (VM) específico e que a suspensão esteja ativa. A política de alertas ainda pode criar alertas para todas as VMs, exceto a listada no filtro.
Um filtro com base em rótulos pode incluir rótulos de recursos e métricas. Quando a política de alertas não é baseada em PromQL, o filtro também pode incluir rótulos de metadados.
Como as suspensões afetam as condições da política de alertas
A tabela a seguir descreve a relação entre o status de uma condição em uma política de alertas de condição única e quando os alertas são criados e as notificações são enviadas:
| Estado | Ação |
|---|---|
| A condição não foi atendida | Comportamento atual Quando um alerta estiver aberto, feche-o e envie notificações de fechamento de alerta. |
| A condição é atendida e a política não está associada a uma suspensão ativa |
Comportamento atual Quando um alerta não existir, crie um e envie notificações. |
| A condição é atendida e A política está associada a uma suspensão ativa |
|
Quando um adiamento é aplicado a uma política de alertas que contém várias condições, as regras para combinar as condições são aplicadas primeiro. Em seguida, as regras associadas aos adiamentos são aplicadas.
Como criar uma ação de adiar é diferente de desativar uma política
Para evitar notificações de uma coleção de políticas de alertas por um curto período, desative manualmente cada uma política de alertas ou crie uma soneca:
Se você desativar manualmente as políticas de alertas, não se esqueça de reativar cada uma delas ao final do intervalo. Além disso, só é possível programar essas ações se você usar a API Cloud Monitoring e configurar algo para emitir a chamada de API em um horário específico.
Se você criar uma suspensão, poderá programar o período ativo, e a suspensão poderá ser aplicada a várias políticas de alertas. Quando o adiamento está inativo ou termina, as políticas de alertas associadas a ele funcionam normalmente. Ou seja, essas políticas de alerta podem criar alertas e enviar notificações.
Quando você tem janelas de manutenção periódicas, para cada uma delas, é possível desativar e ativar manualmente as políticas de alertas que não devem enviar notificações. No entanto, se você criar uma suspensão para uma janela de manutenção, poderá copiar essa suspensão e atualizar o horário de início e a duração da cópia. Ou seja, ao criar uma ação de adiar e copiá-la, é possível programar uma série de adiamentos futuros para a mesma coleção de políticas de alerta.
Para ver um registro de quando as políticas de alertas são desativadas ou ativadas, consulte os registros de auditoria do projeto Google Cloud . No entanto, quando você cria uma soneca, ela é adicionada ao registro histórico de sonecas do seu projeto Google Cloud . Para conferir o registro histórico, que mostra os adiamentos passados, ativos e futuros, use o console do Google Cloud .
Restrições
A duração de uma soneca precisa ser um único intervalo que seja um múltiplo de minutos.
É possível adiar apenas 16 políticas de alerta.
Os critérios de um adiamento não podem ser modificados.
Ao aplicar uma suspensão a uma política de alertas com uma condição baseada em PromQL, não é possível usar rótulos de metadados no filtro.