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, por exemplo, pela escolha da janela de reteste, consulte Comportamento das políticas de alertas com base em métricas.
A política de uso do disco cria alertas 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 uma notificação somente quando a utilização de qualquer disco físico
exceder o limite definido na condição. No entanto, essa política está criando alertas quando a utilização de cada disco físico está abaixo do limite.
Uma causa conhecida de alertas inesperados para essas políticas é que as condições não sã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 construído de forma que a utilização seja de 100%, isso vai gerar um alerta para a criação da política.
Por exemplo, veja a saída a seguir do comando df do Linux,
que mostra o espaço em disco disponível em sistemas de arquivos montados 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. Por exemplo, você pode
adicionar o filtro device !=~ ^/dev/loop.*, que exclui todas as série temporal
em que o rótulo device não corresponde à expressão regular ^/dev/loop.*.
Causas comuns para alertas anômalos
Você criou uma política de alertas e ela parece criar alertas prematuramente ou incorretamente.
Há diferentes motivos pelos quais você pode receber notificações de alertas que parecem estar incorretos:
Se houver uma lacuna nos dados, principalmente para políticas de alerta com condições de ausência de métrica ou de limite "menor que", um alerta poderá ser criado e parecer anômalo. Às vezes, o alerta não mostra a lacuna de dados, e às vezes ela é corrigida automaticamente:
Por exemplo, nos gráficos, as lacunas podem não aparecer 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. Essa lacuna nos dados subjacentes pode ser suficiente para uma política de alertas criar um alerta.
É possível que os pontos nas métricas com base em registros cheguem atrasados e sejam preenchidos referentes 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 com base em registros que não pode mais ser vista talvez tenha feito com que uma política de alertas criasse um alerta.
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 alerta correspondente fica visível no Monitoring.
Condições configuradas para criar um alerta em uma única medida podem resultar em alertas que parecem prematuros ou incorretos. Para evitar essa situação, verifique se várias medições são necessárias antes da criação de um alerta definindo a janela de novo teste de uma condição como mais que o dobro da taxa de amostragem da métrica.
Por exemplo, se uma métrica for amostrada a cada 60 segundos, defina a janela de reteste como pelo menos 3 minutos. Se você definir a janela de reteste como valor mais recente ou, de maneira equivalente, como 0 segundo, uma única medição poderá causar a criação de um alerta.
Quando a condição de uma política de alertas é editada, pode levar vários minutos para que a alteração seja propagada por toda a infraestrutura de alertas. Durante esse período, talvez você receba notificações de alertas que atenderam às condições originais da política de alertas.
Quando os dados de série temporal chegam, pode levar até um minuto para que eles se propaguem por toda a infraestrutura de alertas. Durante esse processo, uma política de alertas pode avaliar uma condição como atendida, mesmo que os dados da série temporal não tenham sido propagados para o gráfico. Como resultado, você pode receber uma notificação mesmo que o gráfico não indique que a condição foi atendida. Para reduzir a possibilidade dessa situação, use um período de alinhamento de pelo menos cinco minutos.
A mudança do rótulo do App Hub
metadata.system_labels.apphub_host_project_idparametadata.system_labels.apphub_application_containerpode resultar na geração de novos alertas e na não conclusão de alertas abertos.Não é preciso fazer nada. Os alertas são fechados automaticamente quando os dados param de chegar, após o fim da duração do fechamento automático. Para mais informações, consulte Dados de métricas parciais.
O alerta não é fechado quando os dados param de chegar
Siga as orientações em Dados de métricas parciais e configure uma política de alertas para fechar alertas quando os dados pararem de chegar. Em alguns casos, os dados param de chegar, mas um alerta aberto não é fechado automaticamente.
Se o recurso subjacente monitorado por uma política de alertas tiver o rótulo metadata.system_labels.state e se essa política não for escrita com a linguagem de consulta do Monitoring, o Monitoring poderá determinar o estado do recurso. Se o estado de um recurso for conhecido como desativado, o Monitoring não vai fechar automaticamente os alertas quando os dados pararem de chegar. No entanto, você pode fechar esses alertas manualmente.
Não foi possível ver os detalhes do alerta devido a um erro de permissão
Acesse a página de alertas no console do Google Cloud e selecione um alerta para visualizar. Você espera a página de detalhes ser aberta. No entanto, a página de detalhes não é aberta e uma mensagem "Permissão negada" é exibida.
Para conferir todos os detalhes do alerta, exceto os dados de métricas, verifique se você tem os papéis do Identity and Access Management (IAM) de Leitor de incidentes do console do Cloud Monitoring (roles/monitoring.cloudConsoleIncidentViewer) e Leitor de contas do Stackdriver (roles/stackdriver.accounts.viewer).
Para conferir todos os detalhes dos alertas, incluindo os dados de métricas, e para poder confirmar ou fechar alertas, verifique se você tem os papéis do IAM de Leitor do Monitoring (roles/monitoring.viewer) e Editor de incidentes do console do Cloud Monitoring (roles/monitoring.cloudConsoleIncidentEditor).
Papéis personalizados não podem conceder a permissão necessária para ver detalhes do alerta.
O alerta não é criado quando a condição é atendida
Você criou uma política de alertas com uma condição. O gráfico da política de alertas mostra que os dados monitorados violam a condição, mas você não recebeu uma notificação e um alerta não foi criado.
Se algum dos critérios a seguir for verdadeiro depois que a condição da política de alertas for atendida, o Monitoring não vai abrir o alerta.
- A política de alertas está suspensa.
- A política de alertas está desativada.
- A política de alertas atingiu o número máximo de alertas que pode abrir simultaneamente.
O estado do recurso monitorado pela política de alertas é conhecido como desativado. O Monitoring pode determinar o estado de um recurso quando ele contém o rótulo
metadata.system_labels.statee quando a política de alertas não é escrita com a linguagem de consulta do Monitoring.
A lista de detalhes do alerta mostra o projeto errado
Você recebe uma notificação, e o resumo da condição lista o projetoGoogle Cloud em que o alerta foi criado, ou seja, o projeto de escopo. No entanto, você espera que o alerta liste o nome do projeto Google Cloud que armazena a série temporal que fez com que o Monitoring criasse o alerta.
As opções de agregação especificadas na condição de uma política de alertas determinam o projeto Google Cloud referenciado em uma notificação:
Quando as opções de agregação eliminam o rótulo que armazena o ID do projeto, as informações do alerta listam o projeto de escopo. Por exemplo, se você agrupar os dados apenas por zona, depois do agrupamento, o rótulo que armazena o ID do projeto será removido.
Quando as opções de agregação preservam o rótulo que armazena o ID do projeto, as notificações de alerta incluem o nome do projeto Google Cloud que armazena a série temporal que causa o alerta. Para preservar o rótulo do ID do projeto, inclua o rótulo
project_idno campo de agrupamento ou não agrupe as série temporal.
Não é possível fechar um alerta manualmente
Você recebeu uma notificação de alerta no seu sistema. Acesse a página de detalhes do alerta e clique em Fechar alerta. Você espera que o alerta seja fechado, mas recebe a mensagem de erro:
Unable to close alert with active conditions.
Só é possível fechar um alerta 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 dentro do período de alerta.
O seguinte erro ocorre quando um alerta não pode ser fechado devido a um erro interno:
Unable to close alert. Please try again in a few minutes.
Quando a mensagem de erro anterior aparecer, tente novamente a operação de fechamento ou deixe o Monitoring fechar o alerta automaticamente.
Para mais informações, consulte Como gerenciar alertas.
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 alerta criado quando todas as condições forem atendidas. No entanto, você recebe várias notificações e vê que vários alertas foram criados.
O Monitoring envia uma notificação e cria um alerta para cada série temporal que faz com que uma condição seja atendida. Como resultado, quando você tem políticas de alertas com várias condições, é possível receber uma notificação e um alerta para cada série temporal que faz com que as condições combinadas sejam atendidas.
Por exemplo, você tem uma política de alertas com duas condições, em que cada uma monitora três série temporal. A política envia uma notificação somente quando as duas condições são atendidas. Quando as condições da sua política forem atendidas, você poderá receber entre 2 (uma série temporal atendida em cada condição) e 6 (todas as séries temporais atendidas em cada condição) notificações e alertas.
Não é possível configurar o Monitoring para criar um único alerta e enviar uma única notificação.
Para mais informações, consulte Quando o Monitoring envia notificações e cria alertas.
A variável de um identificador de métrica tem um valor nulo
Você cria uma política de alertas e adiciona uma variável para um rótulo de métrica à seção de documentação.
Você espera que as notificações mostrem o valor do rótulo a que a variável se refere. No entanto, o valor da variável é definido como null.
Para resolver esse problema, tente o seguinte:
Verifique se as configurações de agregação da política de alertas preservam o rótulo que você quer mostrar.
Por exemplo, suponha que você crie uma política de alertas que monitore os bytes de disco gravados por instâncias de VM. Você quer que a documentação liste o dispositivo que está causando a notificação. Por isso, adicione ao campo de documentação o seguinte:
device: ${metric.label.device}.Verifique também se as configurações de agregação preservam o valor do rótulo
device. Para preservar esse rótulo, defina a função de agregação comononeou verifique se as seleções de agrupamento incluemdevice.Verifique a sintaxe e a aplicabilidade da variável. Para informações sobre a sintaxe, consulte Anotar notificações com documentação definida pelo usuário.
Por exemplo, a variável
log.extracted_label.KEYsó é compatível com políticas de alertas com base em registros. Essa variável sempre é renderizada comonullquando uma política de alertas monitora uma métrica, mesmo que seja uma métrica com base em registros.
Nenhum dado novo após mudanças nas definições de métricas
Você muda a definição de uma métrica definida pelo usuário, por exemplo, modificando o filtro usado em uma métrica com base em registros, e a política de alertas não reflete a mudança feita na definição da métrica.
Para resolver esse problema, force a atualização da política de alertas editando o nome de exibição dela.
A criação de políticas de alertas falha na API devido à falta de métricas
Você criou uma métrica recentemente e a referenciou ao tentar criar uma política de alertas na API Cloud Monitoring. No entanto, o comando da API falha e mostra o seguinte erro:
Error 404: Cannot find metric(s) that match type = "METRIC_NAME". If a metric was created recently, it could take up to 10 minutes to become available. Please try again soon.
Para resolver esse problema, aguarde pelo menos dez minutos e reenvie a solicitação de API.
O gráfico da política de alertas não mostra a violação do limite
Você recebeu uma notificação informando que um alerta foi aberto para sua política de alertas. No entanto, quando você acessa a página de detalhes da política, o gráfico não indica que o limite foi violado.
Para resolver essa situação, tente reduzir o período do gráfico. É possível encurtar o período usando o seletor de período na barra de ferramentas ou destacando intervalos de tempo no gráfico com o ponteiro.
Os gráficos têm resolução limitada e podem não mostrar todas as medições de alguns períodos.