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 nova avaliação, consulte Comportamento das políticas de alertas com base em métricas.
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 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 cria incidentes quando o uso 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, 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, talvez você
adicione o filtro device !=~ ^/dev/loop.*, que exclui todas as série temporal
cujo rótulo device não corresponda à expressão regular ^/dev/loop.*.
Causas comuns para incidentes anômalos
Você criou uma política de alertas e a política parece criar incidentes prematuramente ou incorretamente.
Há diferentes motivos pelos quais você pode receber notificações de incidentes que parecem estar incorretos:
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. Às vezes, o incidente não mostra a lacuna de dados e, às vezes, ela é corrigida automaticamente:
Nos gráficos, por exemplo, as lacunas podem não aparecer porque os valores de os 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 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 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 o momento em que o incidente correspondente fica visível no Monitoring.
As condições configuradas para criar um incidente em uma única medida podem resultar em incidentes que parecem ser prematuros ou incorretos. Para evitar essa situação, certifique-se de que várias medições sejam necessárias antes que um incidente é criado definindo a janela de novo teste de uma condição seja mais do que o dobro da taxa de amostragem da métrica.
Por exemplo, se uma métrica for amostrada a cada 60 segundos e defina a janela de novo teste para pelo menos 3 minutos. Se você definir a janela de nova tentativa como o valor mais recente, ou equivalente a 0 segundo, uma única medição poderá fazer com que um incidente seja criado.
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 incidentes 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 os dados sejam propagados em 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 de séries temporais. 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.
O incidente não é fechado quando os dados param de chegar
Você segue as orientações Dados de métricas parciais e configurar uma política de alertas para encerrar incidentes quando os dados pararem de chegar. Em alguns casos, os dados param de chegar, mas um incidente aberto não é será fechado automaticamente.
Se o recurso que está sendo monitorado por uma política de alertas tiver
o rótulo metadata.system_labels.state e, se essa política não estiver gravada
com a linguagem de consulta do Monitoring, o Monitoring pode determinar o estado
do recurso. Se o estado de um recurso estiver desativado, o Monitoring não vai fechar automaticamente os incidentes quando os dados pararem de chegar. No entanto, é possível encerrar esses incidentes manualmente.
Não foi possível ver os detalhes do incidente devido a um erro de permissão
Você acessa a página de incidentes no console do Google Cloud e seleciona um incidente 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 visualizar todos os detalhes do incidente, exceto os dados de métricas, verifique se você tem
do Identity and Access Management (IAM) de
Como monitorar o visualizador de incidentes do console do Cloud
(roles/monitoring.cloudConsoleIncidentViewer) e
Leitor de contas do Stackdriver (roles/stackdriver.accounts.viewer).
Para acessar todos os detalhes do incidente, incluindo os dados de métricas, e conseguir
confirmar ou encerrar incidentes, confirmar que você tem o
de Leitor do Monitoring (roles/monitoring.viewer) e
Como monitorar o editor de incidentes do console do Cloud
(roles/monitoring.cloudConsoleIncidentEditor).
Papéis personalizados não podem conceder a permissão necessária para ver detalhes do incidente.
O incidente 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 incidente não foi criado.
Se algum dos critérios a seguir for verdadeiro após a condição da política de alertas é atendido, o Monitoring não abre o incidente.
- A política de alertas é adiada.
- A política de alertas está desativada.
- A política de alertas atingiu o número máximo de incidentes que ele pode abrir simultaneamente.
O estado do recurso monitorado pela política de alertas é conhecido como desativado. O monitoramento pode determinar o estado de um recurso quando ele contém as
metadata.system_labels.statequando a política de alertas não estiver escritos com a linguagem de consulta do Monitoring.
Os detalhes do incidente listam o projeto errado
Você recebe uma notificação, e o resumo da condição lista no projeto do Google Cloud em que o incidente foi criado, ou seja, lista os do projeto do escopo. No entanto, você espera que o incidente liste o nome do projeto do Google Cloud que armazena a série temporal que fez com que o monitoramento criasse o incidente.
As opções de agregação especificadas na condição de uma política de alertas. determinar o projeto do 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 incidente listam o projeto de escopo. Por exemplo, se você agrupar os dados somente por zona, após o agrupamento, os o rótulo que armazena o ID do projeto é removido.
Quando as opções de agregação preservam o rótulo que armazena o ID do projeto, as notificações de incidentes incluem o nome do projeto do Google Cloud que armazena a série temporal que causa o incidente. Para preservar o rótulo do ID do projeto, inclua o rótulo
project_idno campo de agrupamento ou não agrupe a série temporal.
Não foi possível fechar um incidente manualmente
Você recebeu uma notificação sobre um incidente no seu sistema. Você acessa a página de detalhes do incidente e clica em Fechar incidente. Você espera que o incidente seja encerrado. No entanto, você recebe esta mensagem de erro:
Unable to close incident with active conditions.
Só é possível fechar um incidente quando nenhuma observação chega ao 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 incidente não pode ser fechado devido a um erro interno:
Unable to close incident. Please try again in a few minutes.
Se você vir a mensagem de erro acima, é 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.
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.
O monitoramento envia uma notificação e cria um incidente 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 incidente 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éries temporais. A política envia uma notificação apenas quando ambas as condições são atendidas. Quando as condições da sua política forem atendidas, você poderá receber entre duas (uma série temporal é atendida em cada condição) e seis (todas as séries temporais são atendidas em cada condição) notificações e incidentes.
Não é possível configurar o Monitoring para criar um único incidente e enviar uma única notificação.
Para mais informações, consulte Notificações por incidente.
A variável de um rótulo de métrica é nula
Você cria uma política de alertas e
adicionar uma variável para um rótulo de métrica na seção de documentação.
Você espera que as notificações mostrem o valor da variável. No entanto,
o valor é 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 o rótulo que você quer exibir.
Por exemplo, suponha que você crie uma política de alertas que monitore o bytes de disco gravados por instâncias de VM. Você quer que a documentação liste o dispositivo que está causando a notificação. Para isso, adicione o seguinte ao campo de documentação:
device: ${metric.label.device}.Também é preciso garantir que as configurações de agregação preservem 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 sintaxe, consulte Anexar documentação definida pelo usuário às notificações.
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 alerta monitora uma métrica, mesmo que seja com base em registros.
Nenhum dado novo após alterações nas definições de métricas
Você altera 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 está refletindo a alteração feita na definição da métrica.
Para resolver esse problema, force a atualização da política de alertas editando o o nome de exibição da política.