Solução de problemas de políticas de alertas

Esta página explica por que algumas políticas de alertas podem se comportar de maneira diferente do pretendido e oferece possíveis soluções para essas situações.

Para informações sobre as variáveis que podem afetar uma política de alertas, pela janela de escolha de duração, por exemplo, consulte Comportamento de alertas.

A política de utilização do disco cria incidentes inesperados

Você criou uma política de alertas para monitorar a capacidade "usada" dos discos em seu sistema. Essa política monitora a métrica agent.googleapis.com/disk/percent_used. Você espera receber notificações somente quando a utilização de qualquer disco físico exceder o limite definido na condição. No entanto, essa política está criando incidentes quando a utilização do disco de cada disco físico é menor que o limite.

Uma causa conhecida de incidentes inesperados para essas políticas é que as condições não estão restritas ao monitoramento de discos físicos. Em vez disso, essas políticas monitoram todos os discos, incluindo discos virtuais, como dispositivos de loopback. Se um disco virtual for criado de forma que sua utilização seja 100%, isso causaria um incidente para a política ser criada.

Por exemplo, considere a saída do comando df do Linux, que mostra o espaço em disco disponível em sistemas de arquivos ativados, para um sistema:

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

Para esse sistema, uma política de alertas de utilização de disco precisa ser configurada para filtrar as séries temporais dos dispositivos de loopback /dev/loop0 e /dev/loop1.

A política de tempo de atividade não cria alertas esperados

Você quer receber uma notificação se uma máquina virtual (VM) for reinicializada ou desligada. Para isso, crie uma política de alertas que monitore a métrica compute.googleapis.com/instance/uptime. Você cria e configura a condição para gerar um incidente quando não há dados de métrica. Para definir a condição, use a linguagem de consulta de monitoramento (MQL, na sigla em inglês)1. Você não recebe notificações quando a máquina virtual (VM) é reinicializada ou encerrada.

Esta política de alertas só monitora séries temporais para instâncias de VM do Compute Engine que estão no estado RUNNING. As séries temporais de VMs que estão em qualquer outro estado, como STOPPED ou DELETED, são filtradas antes que a condição seja avaliada. Devido a esse comportamento, não é possível usar uma política de alertas com uma condição de alerta de ausência de métrica para determinar se uma instância de VM está em execução. Para informações sobre os estados da instância de VM, consulte Ciclo de vida da instância da VM.

Para resolver esse problema, crie uma política de alertas para monitorar uma verificação de tempo de atividade. Para criar uma verificação de tempo de atividade, sua VM precisa ter um endereço IP externo.

Se a VM não tiver um endereço IP externo, crie uma política de alertas com MQL que notifique você que a VM foi encerrada. As condições definidas por MQL não filtram previamente os dados de série temporal com base no estado da instância de VM. Como o MQL não filtra os dados por estados da VM, é possível usá-lo para detectar a ausência de dados das VMs que foram encerradas.

Considere a seguinte condição MQL que monitora a métrica compute.googleapis.com/instance/cpu/utilization:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

Se uma VM monitorada por essa condição for encerrada, três minutos depois, um incidente será gerado e as notificações serão enviadas. O valor absent_for precisa ter pelo menos três minutos.

Para mais informações sobre o MQL, consulte Políticas de alertas com MQL.

1: MQL é uma linguagem expressiva baseada em texto que pode ser usada com chamadas da API Cloud Monitoring e no Console do Google Cloud. Para configurar uma condição com o MQL ao usar o Console do Cloud, selecione Editor de consultas.

Causas comuns para incidentes anômalos

Você criou uma política de alertas e a política parece criar incidentes prematuramente ou incorretamente.

Se houver uma lacuna nos dados, especialmente para as políticas de alertas com condições de ausência de métrica ou de limite menor, poderá ser criado um incidente que parece anômalo. Determinar se existe uma lacuna nos dados pode não ser fácil. Às vezes, a lacuna está oculta e, em outras, foi corrigida automaticamente.

  • Por exemplo, nos gráficos, as lacunas podem ser ocultadas porque os valores dos dados ausentes são interpolados. Mesmo quando vários minutos de dados estão ausentes, o gráfico conecta pontos ausentes pela continuidade visual. Uma lacuna desse tipo nos dados subjacentes é suficiente para que uma política de alertas crie um incidente.

  • É possível que os pontos nas métricas com base em registros cheguem atrasados e sejam preenchidos referente aos últimos 10 minutos. O comportamento de preenchimento corrige a lacuna efetivamente. Ela é preenchida quando os dados chegam. Assim, uma lacuna em uma métrica baseada em registros que não pode mais ser vista pode ter causado uma política de alertas para criar um incidente.

As condições de ausência de métrica e de limite máximo são avaliadas em tempo real, com um pequeno atraso na consulta. O status da condição pode mudar entre o momento em que ela é avaliada e a hora em que o incidente correspondente fica visível no Monitoring.

Para garantir que várias medições sejam necessárias antes da criação de um incidente, verifique se o campo de duração de uma condição é maior que o dobro da taxa de amostragem da métrica. Por exemplo, se uma amostra for amostrada a cada 60 segundos, defina a duração como pelo menos três minutos. Se você definir o campo de duração como valor mais recente, ou equivalente a 0 segundos, uma única medição poderá fazer com que um incidente seja criado.

A política de várias condições cria várias notificações

Você criou uma política de alertas que contém várias condições e as associou a um AND lógico. Você espera receber uma notificação e ter um incidente criado quando todas as condições forem atendidas. No entanto, você recebe várias notificações e vê que vários incidentes foram criados.

Quando uma política de alertas contém várias condições unidas por uma lógicaAND, se essa política for acionada, para cada série temporal que resultar em uma condição atendida, a política enviará uma notificação e criará um incidente. Por exemplo, se você tiver uma política com duas condições e cada uma delas monitorar uma série temporal, dois incidentes serão abertos e você receberá duas notificações.

Não é possível configurar o Cloud Monitoring para criar um único incidente e enviar uma única notificação.

Para mais informações, consulte Notificações por incidente.

Não foi possível ver os detalhes do incidente devido a um erro de permissão

Acesse a página de incidentes no Console do Google Cloud e selecione um incidente para ser visualizado. Você espera que a página de detalhes seja aberta. No entanto, a página de detalhes não abre e uma mensagem "Permissão negada" é exibida.

Para resolver essa situação, verifique se seu papel de gerenciamento de identidade e acesso (IAM, na sigla em inglês) é roles/monitoring.viewer ou se inclui todas as permissões dele. Por exemplo, os papéis roles/monitoring.editor e roles/monitoring.admin incluem todas as permissões do papel de leitor.

Os papéis personalizados não podem conceder a permissão necessária para visualizar detalhes do incidente.

Não é possível fechar um incidente manualmente

Você recebeu uma notificação sobre um incidente no seu sistema. Acesse a página de detalhes do incidente e clique em Fechar incidente. Você espera que o incidente seja fechado. No entanto, você recebe a mensagem de erro:

Unable to close incident with active conditions.

Só é possível fechar um incidente quando nenhuma observação chega no período de alerta mais recente. O período de alerta, que normalmente tem um valor padrão de 5 minutos, é definido como parte da condição da política de alertas e é configurável. A mensagem de erro anterior indica que os dados foram recebidos no período de alerta.

O seguinte erro ocorre quando um incidente não pode ser fechado devido a um erro interno:

Unable to close incident. Please try again in a few minutes.

Ao ver a mensagem de erro anterior, é possível repetir a operação de fechamento ou permitir que o Monitoring feche automaticamente o incidente.

Para mais informações, consulte Como gerenciar incidentes.

Falha nas notificações do webhook

Você configura um canal de notificação do webhook e espera ser notificado quando ocorrerem incidentes. Você não recebe notificações.

Endpoint particular

Não é possível usar webhooks para notificações a menos que o endpoint seja público.

Para resolver essa situação, use notificações do Pub/Sub combinadas com uma assinatura pull para esse tópico de notificação.

Quando você configura um canal de notificação do Pub/Sub, as notificações de incidentes são enviadas para uma fila do Pub/Sub que tenha controles de gerenciamento de identidade e acesso. Qualquer serviço que possa consultar ou detectar um tópico do Pub/Sub pode consumir essas notificações. Por exemplo, aplicativos executados em máquinas virtuais do App Engine, do Cloud Run ou do Compute Engine podem consumir essas notificações.

Se você usar uma assinatura pull, uma solicitação será enviada ao Google até que uma mensagem chegue. Essas assinaturas exigem acesso ao Google, mas não exigem regras de firewall ou acesso de entrada.

Endpoint público

Para identificar por que a entrega falhou, examine as entradas de registro do Cloud Logging para informações de falha.

Por exemplo, é possível pesquisar entradas de registro para o recurso do canal de notificação usando o Explorador de registros, com um filtro como o seguinte:

resource.type="stackdriver_notification_channel"