Este documento descreve como receber notificações quando o app falhar ou quando o desempenho dele não atender aos critérios definidos.
Como os alertas funcionam
O processo de alertas do Cloud Monitoring tem três partes:
Uma política de alertas, que descreve as circunstâncias em que você ser alertado e como você quer receber notificações sobre um incidente. A política de alertas pode monitorar dados de séries temporais armazenados pelo Monitoring ou registros armazenados pelo Cloud Logging. Quando esses dados atendem à condição da política de alertas, o Monitoring cria um incidente e envia as notificações.
Cada incidente é um registro do tipo de dados que foi monitoradas e quando as condições foram atendidas. Essas informações podem ajudar a resolver os problemas que causaram o incidente.
Um canal de notificação define como você recebe notificações quando o Monitoring cria um incidente. Por exemplo, é possível configurar um canal de notificação para enviar
my-support-team@example.compor e-mail e postar uma mensagem do Slack no canal#my-support-team. Uma política de alertas pode conter um ou mais canais de notificação.
As políticas de alertas podem avaliar três tipos de dados:
Dados de série temporal, também chamados de dados métricos, que são armazenados por e monitoramento. Esses tipos de políticas são chamados baseadas em métricas.
Para aprender a configurar uma política de alertas com base em métricas, tente o Guia de início rápido do Compute Engine.
Dados de registro armazenados pelo Cloud Logging. As políticas de alertas que avaliam entradas de registro individuais são chamadas de políticas de alertas com base em registros. As políticas de alertas baseadas em registros notificam você quando uma mensagem específica aparece nos registros. Para mais informações, consulte Monitorar seus registros.
Os resultados de uma consulta SQL são executados na Análise de dados de registros em relação à entrada de registro. e dados armazenados no Logging. Políticas de alertas que monitoram os resultados de uma consulta SQL são chamados Políticas de alertas baseadas em SQL. Para mais informações, consulte Monitorar os resultados da consulta SQL com uma política de alertas.
As políticas de alertas baseadas em SQL estão em fase de pré-lançamento público.
O processo de alerta ajuda a responder a problemas quando o desempenho um aplicativo não atenda a valores aceitáveis. Por exemplo, você implanta um aplicativo da Web em uma instância de máquina virtual (VM) do Compute Engine. Embora você espere que a latência da resposta HTTP flutue, é importante que a equipe de suporte responda quando o aplicativo tiver alta latência por um período significativo. Você pode criar um política de alertas com base em métricas que monitora a resposta HTTP do aplicativo métrica de latência. Se a latência de resposta for superior a dois segundos por pelo menos cinco minutos, o Monitoring cria um incidente e envia notificações por e-mail para sua equipe de suporte.
Como criar uma política de alertas
Há várias maneiras de criar uma política de alertas. Por exemplo, é possível usar políticas de alertas pré-configuradas, ativando alertas recomendados de integrações ou de determinadas páginas no console do Google Cloud. Também é possível configurar uma nova política de alertas usando o Console do Google Cloud, API Cloud Monitoring, Google Cloud CLI e o Terraform.
Usar integrações e políticas de alerta recomendadas
O Monitoring fornece pacotes predefinidos para você criar políticas de alerta para seus serviços do Google Cloud e integrações de terceiros. Os pacotes incluem políticas de alerta recomendadas, painéis de exemplo e métricas importantes para o serviço. Esses pacotes estão disponíveis Serviços do Google Cloud, como Google Kubernetes Engine, Compute Engine e Cloud SQL, e integrações comuns de terceiros, como MongoDB, Kafka e Elasticsearch.
Ao instalar um pacote, é possível ativar o sistema de alertas recomendado políticas. Ao ativar uma política de alertas recomendada, você configura o canal de notificação e, opcionalmente, modifica outros valores. Após a configuração, a política de alerta começa a monitorar o alvo imediatamente, sem a necessidade de mais entradas do usuário.
As políticas de alertas recomendadas são úteis na implantação de um novo serviço e querem alertar sobre métricas importantes. Por exemplo, o O pacote de integração do Cloud SQL vem com políticas de alertas recomendadas para instâncias com falha e transações lentas:
Para mais informações sobre integrações de alertas, consulte Como monitorar aplicativos de terceiros.
Criar novas políticas de alertas
É possível criar políticas de alertas para monitorar diferentes tipos de dados, dependendo das suas necessidades. As seções a seguir listam os diferentes tipos de dados que podem ser monitorados com políticas de alerta.
Monitorar dados de série temporal
| Tipo de condição | Descrição | Exemplo |
|---|---|---|
| Condição de limite de métrica | As condições de limite de métrica são atendidas quando os valores de uma métrica são maior ou menor que o limite para uma janela específica de novo teste. Para mais informações, consulte Criar políticas de alertas de limite de métrica e Criar políticas de alertas usando a API. |
Você quer uma política de alertas que envie uma notificação quando a latência for de 500 ms ou mais por cinco verificações de tempo de atividade consecutivas mais de 10 minutos. |
| Condição de ausência de métrica | As condições de ausência de métrica são atendidas quando uma série temporal monitorada não tem dados para uma janela de novo teste específica. A janela máxima de nova tentativa é de 23,5 horas. Para mais informações, consulte Criar políticas de alertas de ausência de métricas e Criar políticas de alertas usando a API. | Você quer uma política de alerta que abra um incidente com sua equipe de suporte quando um recurso não responder a solicitações HTTP ao longo de cinco minutos. |
| Condição de valor de métrica previsto | As condições de valor de métrica previsto são atendidas quando a política de alertas prevê que o limite será violado na próxima janela de previsão. A janela de previsão pode variar de 1 hora a 7 dias. Para mais informações, consulte Criar políticas de alertas de valores de métricas previstas e Criar políticas de alertas usando a API. |
Você quer uma política de alertas que abra um incidente com seu suporte quando é provável que um recurso atinja 80% de uso do espaço em disco nas próximas 24 horas. |
Monitorar dados de entrada de registro
Para monitorar entradas de registro individuais, use uma política de alertas com base em registros.
Uma condição em uma política de alertas com base em registros é atendida quando
a política detecta que uma frase de uma entrada de registro
correspondem aos critérios da política de alertas. Por exemplo, você quer uma política de alertas
que abra um incidente com sua equipe de suporte
quando a message de uma entrada de registro
contiver product_ids=['tier_1_support', 'tier_2_support'].
Saiba mais em Configurar políticas de alertas com base em registros na na documentação do Logging.
Monitorar os resultados da consulta SQL
Para monitorar os resultados das consultas SQL, use uma política de alertas baseada em SQL.
A condição de uma política de alertas baseada em SQL analisa periodicamente
os dados de entrada de registro e cria incidentes quando a tabela de resultados de consulta
atendem a determinados critérios. Esse tipo de política de alerta é útil quando você precisa de uma
política de alerta que monitore agregações de dados ou padrões complexos
em várias entradas de registro. Por exemplo, convém ser notificado quando mais
50 entradas de registro nos últimos 60 minutos têm gravidade WARNING.
Para mais informações, consulte Monitore os resultados da sua consulta SQL com uma política de alertas no na documentação do Logging.
Componentes da política de alerta
Cada política de alertas tem os seguintes componentes:
Uma condição que descreve quando um recurso ou grupo de recursos, está em um estado que exige uma resposta. A condição inclui a fonte de dados, um limite estático ou dinâmico e a agregação de dados métodos, como filtros e groupby. Suas condições podem monitorar uma única métrica, várias métricas ou uma proporção delas. Você também pode usar a linguagem de consulta do Prometheus (PromQL) para incluir expressões complexas, como limites dinâmicos e lógica condicional.
Se você usar uma integração para ativar uma política de alertas recomendada, a condição da política de alertas será preenchida automaticamente.
uma lista de canais de notificação que descrevem quem notificar quando for iniciada uma ação obrigatórios. Para saber mais, consulte Criar e gerenciar canais de notificação.
Documentação que aparece em notificações e páginas de incidentes. É possível configurar o assunto de uma notificação e adicionar informações úteis ao corpo da notificação. Por exemplo, pode configurar a notificação para exibir links para playbooks internos ou às páginas do Google Cloud, como os painéis personalizados. Para mais informações sobre a documentação, incluindo exemplos, consulte Anexar anotações a incidentes com documentação definida pelo usuário.
Idiomas da consulta
Use linguagens de consulta e filtros nas suas políticas de alerta para ter mais controle sobre a avaliação de métricas. Monitoramento oferece suporte aos seguintes tipos de consulta:
A Linguagem de consulta do Prometheus (PromQL) é uma linguagem de consulta funcional usada para avaliar dados de série temporal em tempo real. É possível configurar políticas de alertas para incluir uma consulta PromQL nas condições. Suas consultas do PromQL podem usar qualquer expressão válida, como combinações de métricas, proporções e limites de escalonamento. Ao configurar políticas de alertas condição baseada em PromQL no Google Cloud, é possível reduzir as dependências infraestrutura de alertas externa. Para mais informações, consulte PromQL no Cloud Monitoring e Políticas de alertas com o PromQL.
Os filtros de monitoramento permitem configurar políticas de alertas para usar proporções de métricas com base em filtros. Com base em filtro e as políticas de alertas não podem ser visualizadas nem modificadas no console do Google Cloud. Para conferir um exemplo de política que usa filtros de monitoramento, consulte Proporção da métrica.
A linguagem de consulta do Monitoring (MQL) é uma interface expressiva baseada em texto que permite recuperar, filtrar e manipular dados de séries temporais. É possível criar políticas de alertas com condições que incluam uma operação de alerta da linguagem de consulta do Monitoring. Para mais informações, consulte Visão geral da linguagem de consulta de monitoramento e Políticas de alertas com MQL.
Gerenciar políticas de alertas e incidentes
Depois que uma política de alertas é ativada, o Monitoring monitora continuamente as condições dessa política. Não é possível configurar política de alertas para monitorar condições apenas em determinados períodos. Se você quiser para desativar a política de alertas por um determinado período, crie uma Soneca.
Se um incidente está aberto e o Monitoring determina que o condições da política com base em métricas não forem mais atendidas, O Monitoring encerra automaticamente o incidente e envia uma notificação sobre a interdição.
Preços
Em geral, as métricas do sistema do Cloud Monitoring são gratuitas, e as métricas de sistemas, agentes ou aplicativos externos. As métricas faturáveis são faturadas pelo número de bytes ou de amostras ingeridas.
Para mais informações sobre os preços do Cloud Monitoring, consulte os documentos a seguir:
Para saber como monitorar o número de períodos de trace ou registros que são ingeridos ou como receber notificações quando um conteúdo específico for incluído em uma entrada de registro, consulte os seguintes documentos:
- Alertas sobre a ingestão mensal de registros
- Alertas sobre a ingestão mensal de períodos de trace
- Configurar alertas com base em registros
A seguir
Para informações sobre latência de notificação e como as opções da de uma política de alertas afetam quando as notificações são enviadas, consulte Comportamento de políticas de alertas baseadas em métricas.
Para conferir uma lista de exemplos de políticas com base em métricas, consulte Resumo de exemplos de políticas de alertas.