Introdução a alertas

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 baseadas em métrica. A maioria das documentações 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étricas, veja 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 registros. e não são baseadas em métricas. Este conteúdo não se aplica a políticas de alertas baseadas em registros. Para mais informações sobre as políticas de alertas com base em registros, consulte Como monitorar seus 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 requer resposta. 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.

    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.

    Nesse exemplo, a condição monitora a latência de resposta HTTP e especifica quando os valores da métrica exigem resposta. A condição é atendida quando o recurso ou o grupo de recursos está em um estado que requer resposta.

  • 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.com por 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étricas é configurada, o Monitoring monitora continuamente as condições dessa política. Não é possível configurar as condições a serem monitoradas somente para determinados períodos.

Quando as condições dessa política são atendidas, o Monitoring cria um incidente e envia uma notificação sobre a criação dele. 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étrica não são mais atendidas, ele será encerrado automaticamente e uma notificação sobre o fechamento será enviada.

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 flutua, você quer 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 seu 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 está monitorando a latência da resposta HTTP. Se essa latência for maior que dois segundos continuamente por cinco minutos, a condição será atendida e um incidente será criado. Um pico temporário na latência não faz com que a condição seja atendida ou um incidente seja criado.

O aplicativo da Web fica famoso, e a latência de resposta aumenta além de dois segundos. Veja como sua política de alertas responde:

  1. O Monitoring inicia um timer de cinco minutos quando ele recebe uma medição de latência HTTP superior a dois segundos.

  2. 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, o Monitoring marca a condição como atendida, abre um incidente e envia um e-mail à equipe de suporte.

  3. A equipe de suporte recebe o e-mail, faz login no console e confirma o recebimento da notificação.

  4. 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.

  5. 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 subir 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étrica ao projeto do Google Cloud usando o Console do Google Cloud, a API Cloud Monitoring ou a CLI do Google Cloud:

  • Ao usar o console, é possível ativar um alerta recomendado ou criar um alerta começando pela página Alertas do Cloud Monitoring.

    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 que são configurados para notificá-lo quando você estiver atingindo um limite de cota. Da mesma forma, a página Instâncias de VM de links do Monitoring para as políticas de alertas são configuradas para monitorar a utilização de memória e a latência de rede dessas instâncias.

    Qualquer política que você cria usando o console também pode ser modificada e visualizada usando o console 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á-las ou modificá-las usando o console.

    Para saber como criar uma política de alertas ao iniciar a página Alertas do Cloud Monitoring, consulte Como criar políticas de alertas usando o console

  • Ao usar a API Cloud Monitoring diretamente ou ao usar a CLI do Google Cloud, é possível criar, ver e modificar políticas de alertas. É possível criar condições que monitoram uma proporção de métricas usando a API Cloud Monitoring ou a CLI do Google Cloud. Com a API Cloud Monitoring, é possível especificar a proporção com a linguagem de consulta do Monitoring (MQL) ou os filtros do Monitoring. Para um exemplo de política que usa filtros do Monitoring, consulte Proporção da métrica.

    Para mais informações sobre como usar a API Cloud Monitoring e a CLI do Google Cloud, consulte Como criar políticas de alertas usando a API Cloud Monitoring ou a CLI do Google Cloud.

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 com base 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 informações sobre como visualizar uma lista das políticas de alertas com base em métricas do projeto e como modificar essas políticas, consulte:

Para informações sobre como gerenciar políticas de alertas com base em registros, consulte Como usar alertas baseados em registros.

Autorização necessária para criar políticas de alertas

Esta seção descreve as funções ou permissões necessárias para criar uma política de alertas. Para informações detalhadas sobre o gerenciamento de identidade e acesso (IAM, na sigla em inglês) do Cloud Monitoring, consulte Controle de acesso.

Cada papel do IAM tem um ID e um nome. Os IDs de papel têm o formato roles/monitoring.editor e são transmitidos como argumentos para a CLI do Google Cloud ao configurar o controle de acesso. Para mais informações, consulte Como conceder, alterar e revogar acesso. O console exibe nomes de papéis, como o Editor do Monitoring.

Funções obrigatórias do console

Para criar uma política de alertas, o nome do papel do IAM para o projeto do Google Cloud precisa ser um dos seguintes:

  • Editor do Monitoring
  • Administrador do Monitoring
  • Proprietário do projeto

Para ver uma lista de papéis e as permissões associadas, consulte Papéis.

Permissões de API necessárias

Para usar a API do Cloud Monitoring para criar uma política de alertas, o ID do papel do IAM para o projeto do Google Cloud precisa ser um dos seguintes:

  • roles/monitoring.alertPolicyEditor: este código de papel concede as permissões mínimas necessárias para criar uma política de alertas. Para mais detalhes sobre esse papel, consulte Papéis de alerta predefinidos.
  • roles/monitoring.editor
  • roles/monitoring.admin
  • roles/owner

Para identificar a permissão necessária para um método específico da API Cloud Monitoring, consulte Permissões da API Cloud Monitoring. Para ver uma lista de papéis e as permissões associadas, consulte Papéis.

Como determinar o papel

Para determinar o papel de um projeto usando o console, faça o seguinte:

  1. Abra o console e selecione o projeto do Google Cloud:

    Acesse o console

  2. Para visualizar o papel, clique em IAM e administrador. O papel está na mesma linha que o nome de usuário.

Para determinar as permissões no nível da organização, entre em contato com o administrador da organização.

Custos associados às políticas de alertas

Não há custos associados ao uso de políticas de alertas ou verificações de tempo de atividade, mas há os seguintes limites:

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
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		 5.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 aplicável
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
1Métrica: uma política de alertas com base em dados de métrica Registro: uma política de alertas baseada em mensagens de registro (alertas baseados em registros)
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