O alerta proporciona reconhecimento oportuno de problemas nos seus aplicativos em nuvem para que você possa resolvê-los rapidamente.
No Cloud Monitoring, uma política de alertas descreve as circunstâncias em que você quer ser alertado e como quer ser notificado. Esta página contém uma visão geral das políticas de alerta.
As políticas de alertas usadas para rastrear os dados de métricas coletados pelo Cloud Monitoring são chamadas de políticas de alertas com base em métricas. A maior parte da documentação do Cloud Monitoring sobre políticas de alertas pressupõe que você esteja usando políticas de alertas baseadas em métricas. Para saber como configurar uma política de alertas baseada em métrica, consulte o Guia de início rápido do Compute Engine.
Também é possível criar políticas de alertas com base em registros que notificam você quando uma mensagem específica aparece nos seus registros. Essas políticas não são baseadas em métricas. Este conteúdo não se aplica a políticas de alertas baseadas em registros. Para informações sobre políticas de alertas baseadas em registros, consulte Como monitorar registros.
Como os alertas funcionam
Cada política de alertas especifica o seguinte:
Condições que descrevem quando um recurso, ou um grupo de recursos, está em um estado que exige que você responda. Por exemplo, você pode configurar uma condição da seguinte maneira:
The HTTP response latency is higher than two seconds for at least five minutes.
Neste exemplo, a condição monitora a métrica Latência de resposta HTTP e é acionada quando todas as medições de latência em um período de cinco minutos forem maiores que dois segundos.
Há três tipos de condição:
- As condições de limite de métrica são acionadas quando as medições violam um limite.
- As condições de ausência de métrica são acionadas quando há ausência de medições.
- As condições de previsão preveem o comportamento futuro das medidas usando dados anteriores. Essas condições são acionadas quando há uma previsão de que uma série temporal violará o limite em uma janela de previsão.
Uma política de alertas precisa ter pelo menos uma condição. No entanto, é possível configurar uma política para conter várias condições.
Canais de notificação que descrevem quem será notificado quando a ação for necessária. É possível incluir vários canais de notificação em uma política de alertas. O Cloud Monitoring é compatível com o Cloud Mobile App e o Pub/Sub, além de canais de notificação comuns. Para uma lista completa de canais compatíveis e informações sobre como configurar esses canais, consulte Opções de notificação.
Por exemplo, é possível configurar uma política de alertas para enviar
my-support-team@example.compor e-mail e postar uma mensagem do Slack no canal#my-support-team.Documentação que você quer incluir em uma notificação. O campo de documentação é compatível com texto simples, Markdown e variáveis.
Por exemplo, inclua na política de alertas a seguinte documentação:
## HTTP latency responses This alert originated from the project ${project}, using the variable $${project}.
Depois que uma política de alertas baseada em métrica é configurada, o Monitoring monitora continuamente as condições dessa política. Não é possível configurar as condições a serem monitoradas somente por determinados períodos.
Quando as condições de um gatilho da política de alertas são acionadas, o Monitoring cria um incidente e envia uma notificação sobre a criação do incidente. Essa notificação inclui informações resumidas sobre o incidente, um link para a página Detalhes da política para que você possa investigar o incidente e qualquer documentação. que você especificou.
Se um incidente estiver aberto e o Monitoring determinar que as condições da política com base em métricas não são mais atendidas, ele será automaticamente fechado e enviará uma notificação sobre o encerramento.
Exemplo
Implante um aplicativo da Web em uma instância de máquina virtual (VM) do Compute Engine que executa um aplicativo da Web. Embora você espere que a latência da resposta HTTP varie, é importante que sua equipe de suporte responda quando o aplicativo tiver alta latência por um período significativo.
Para garantir que a equipe de suporte seja notificada quando o aplicativo sofrer altas latências, crie a seguinte política de alertas:
If the HTTP response latency is higher than two seconds for at least five minutes, then open an incident and send an email to your support team.
Nessa política de alertas, a condição de limite de métrica está monitorando a latência na resposta HTTP. Se essa latência for maior que dois segundos continuamente por cinco minutos, a condição será acionada e um incidente será criado. Um pico transitório na latência não faz com que a condição seja acionada ou um incidente seja criado.
Seu aplicativo da Web é popular e a latência de resposta aumenta além de dois segundos. Veja como sua política de alertas responde:
O Monitoring inicia um timer de cinco minutos quando recebe uma medição de latência HTTP superior a dois segundos.
Se cada medida de latência recebida durante os próximos cinco minutos for maior que dois segundos, o timer expirará. Quando o timer expira, a condição é acionada, e o Monitoring abre um incidente e envia um e-mail para a equipe de suporte.
Sua equipe de suporte recebe o e-mail, faz login no console do Google Cloud e confirma o recebimento da notificação.
Seguindo a documentação no e-mail de notificação, a equipe de suporte pode tratar da causa da latência. Em alguns minutos, a latência da resposta HTTP cai para menos de dois segundos.
Quando o Monitoring recebe uma medição de latência HTTP menos de dois segundos, ele fecha o incidente e envia uma notificação para sua equipe de suporte informando que o incidente foi encerrado.
Se a latência aumentar para mais de dois segundos e permanecer acima desse limite por cinco minutos, um novo incidente será aberto e uma notificação será enviada.
Como adicionar uma política de alertas
É possível adicionar uma política de alertas baseada em métricas ao seu projeto do Google Cloud usando o console do Google Cloud, a API Cloud Monitoring ou a Google Cloud CLI:
Ao usar o console do Google Cloud, é possível ativar um alerta recomendado ou criar um alerta começando na página Alertas do Cloud Monitoring. Para informações, consulte Criar políticas de alertas baseadas em métricas usando o console do Google Cloud.
Os alertas recomendados estão disponíveis para alguns produtos do Google Cloud. Esses alertas exigem configuração mínima, como a adição de canais de notificação. Por exemplo, a página Tópicos do Pub/Sub Lite é vinculada a alertas configurados para notificá-lo quando você atingir o limite de uma cota. Da mesma forma, a página Instâncias de VM no Monitoring vincula a políticas de alertas configuradas para monitorar a utilização de memória e a latência da rede dessas instâncias.
Qualquer política que você criar usando o console do Google Cloud, também poderá modificar e visualizar usando o console do Google Cloud ou a API Cloud Monitoring. A API Cloud Monitoring permite criar políticas de alerta que monitoram proporções de métricas. Quando essas políticas usam filtros do Monitoring, não é possível visualizá-los ou modificá-los usando o console do Google Cloud.
Ao usar a API Cloud Monitoring diretamente ou ao usar a Google Cloud CLI, é possível criar, visualizar e modificar políticas de alerta. Para mais informações, consulte Criar políticas de alertas usando a API Cloud Monitoring ou a Google Cloud CLI.
É possível criar condições que monitorem uma única métrica, várias métricas ou uma proporção de métricas. Com a API Cloud Monitoring, é possível especificar a proporção usando a linguagem de consulta do Monitoring (MQL, na sigla em inglês) ou os filtros do Monitoring. Para ver um exemplo de uma política que usa filtros do Monitoring, consulte Proporção da métrica.
O Cloud Monitoring é compatível com uma linguagem expressiva baseada em texto que pode ser usada com o console do Google Cloud e a API Cloud Monitoring. Para mais informações sobre como usar essa linguagem com alertas, consulte Como criar políticas de alertas usando a linguagem de consulta de monitoramento (MQL, na sigla em inglês).
É possível adicionar uma política de alertas baseada em registros ao seu projeto do Google Cloud usando o Explorador de registros no Cloud Logging ou a API Monitoring. Este conteúdo não se aplica a políticas de alertas baseadas em registros. Para informações sobre políticas de alertas baseadas em registros, consulte Como monitorar seus registros.
Como gerenciar políticas de alertas
Para saber como ver uma lista das políticas de alertas com base em métricas do seu projeto e como modificar essas políticas, consulte os seguintes artigos:
- Como gerenciar políticas de alertas usando o console do Google Cloud
- Como gerenciar políticas de alertas usando a API Cloud Monitoring ou a Google Cloud CLI
Para informações sobre como gerenciar políticas de alertas baseadas em registros, consulte Como usar alertas baseados em registros.
Autorização necessária para criar políticas de alertas
Para receber as permissões necessárias para criar e modificar políticas de alertas usando o console do Google Cloud, peça ao administrador para conceder a você o papel de IAM de Editor do Monitoring (roles/monitoring.editor) no projeto.
Para mais informações sobre como conceder papéis, consulte
Gerenciar o acesso.
Para receber as permissões necessárias para criar e modificar políticas de alertas usando a API Cloud Monitoring, peça ao administrador para conceder a você os seguintes papéis do IAM no seu projeto:
- Editor de AlertPolicy do Monitoring (
roles/monitoring.alertPolicyEditor) - Editor do canal de notificações do Monitoring (
roles/monitoring.notificationChannelEditor) - Editor de adiamento de monitoramento (
roles/monitoring.snoozeEditor)
Para mais informações sobre como conceder papéis, consulte Gerenciar o acesso.
Para informações detalhadas sobre os papéis do IAM para o Monitoring, consulte Controle de acesso.
Custos associados às políticas de alertas
Não há custos associados ao uso de políticas de alertas. Para informações sobre os preços das verificações de tempo de atividade, consulte o resumo do Cloud Monitoring.
Os limites a seguir se aplicam ao uso de políticas de alertas e verificações de tempo de atividade:
| Categoria | Valor | Tipo de política1 |
|---|---|---|
| Políticas de alertas (soma da métrica e do registro) por escopo de métricas 2 | 500 | Métrica, Registro |
| Condições por política de alertas | 6 | Métrica |
| Período máximo que uma condição de ausência de métrica avalia3 |
1 dia | Métrica |
| Período máximo em que uma condição de limite de métrica é avaliada3 |
23 horas e 30 minutos | Métrica |
| Número máximo de séries temporais monitoradas por uma condição de previsão |
64 | Métrica |
| Janela mínima de previsão | 1 hora (3.600 segundos) | Métrica |
| Janela máxima de previsão | 7 dias (604.800 segundos) | Métrica |
| Canais de notificação por política de alertas | 16 | Métrica, Registro |
| Taxa máxima de notificações | 1 notificação a cada 5 minutos para cada alerta baseado em registro | Registro |
| Número máximo de notificações | 20 notificações por dia para cada alerta baseado em registro | Registro |
| Número máximo de incidentes abertos simultaneamente por política de alertas |
1.000 | Métrica |
| Período após o qual um incidente sem dados novos é fechado automaticamente |
7 dias | Métrica |
| Duração máxima de um incidente, se ele não for fechado manualmente | 7 dias | Registro |
| Retenção de incidentes fechados | 13 meses | Não relevante |
| Retenção de incidentes abertos | Indefinida | Não relevante |
| Canais de notificação por escopo de métricas | 4.000 | Não relevante |
| Verificações de tempo de atividade por escopo de métricas 4 | 100 | Não relevante |
| Número máximo de pings no ICMP por verificação de tempo de atividade pública | 3 | Não relevante |
2Apigee e Apigee híbrida } estão profundamente integrados ao Cloud Monitoring. O limite de alerta para todos os níveis de assinatura da Apigee (Standard, Enterprise e Enterprise Plus) é o mesmo que para o Cloud Monitoring: 500 por escopo de métricas .
3O período máximo que uma condição avalia é a soma dos períodos de alinhamento e de duração. Por exemplo, se o período de alinhamento for definido como 15 horas e a janela de duração for definida como 15 horas, serão necessárias 30 horas de dados para avaliar a condição.
4Esse limite se aplica ao número de configurações de verificação de tempo de atividade. Cada configuração de verificação de tempo de atividade inclui o intervalo de tempo entre o teste do status do recurso especificado. Consulte Como gerenciar verificações de tempo de atividade para obter mais informações.
Para informações completas sobre preços, consulte Preços do conjunto de operações do Google Cloud.
A seguir
Para saber mais sobre a latência das notificações e como as opções dos parâmetros de uma política de alertas afetam o envio de notificações, consulte Comportamento de políticas de alertas baseadas em métricas.
Para ver informações sobre diferentes tipos de políticas, consulte Tipos de políticas de alertas.
Para exemplos de políticas de alertas, consulte: