Esta página explica por que motivo algumas políticas de alerta podem ter um comportamento diferente do esperado e oferece possíveis soluções para essas situações.
Para ver informações sobre as variáveis que podem afetar uma política de alertas, como a escolha do período de novo teste, consulte o artigo Comportamento das políticas de alertas baseadas em métricas.
A política de utilização do disco cria incidentes inesperados
Criou uma política de alertas para monitorizar a capacidade "usada" dos discos no seu sistema. Esta política monitoriza a métrica
agent.googleapis.com/disk/percent_used.
Espera receber uma notificação apenas quando a utilização de qualquer disco físico exceder o limite definido na condição. No entanto, esta política está a criar incidentes quando a utilização do disco de cada disco físico é inferior ao limite.
Uma causa conhecida de incidentes inesperados para estas políticas é que as condições não estão restritas à monitorização de discos físicos. Em alternativa, estas políticas monitorizam todos os discos, incluindo discos virtuais, como dispositivos de loopback. Se um disco virtual for construído de forma que a sua utilização seja de 100%, isso fará com que seja criado um incidente para a política.
Por exemplo, considere a seguinte saída do comando df do Linux, que mostra o espaço em disco disponível nos sistemas de ficheiros 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 este sistema, deve configurar uma política de alerta de utilização do disco para filtrar as séries cronológicas dos dispositivos de loopback /dev/loop0 e /dev/loop1. Por exemplo, pode
adicionar o filtro device !=~ ^/dev/loop.*, que exclui todas as séries cronológicas
cuja etiqueta device não corresponde à expressão regular ^/dev/loop.*.
Causas comuns para incidentes anómalos
Criou uma política de alertas e a política parece criar incidentes prematura ou incorretamente.
Existem diferentes motivos pelos quais pode receber uma notificação de incidentes que parecem estar incorretos:
Se existir uma lacuna nos dados, especialmente para as políticas de alerta com condições de ausência de métricas ou de limite "inferior a", pode ser criado um incidente que pareça anómalo. Por vezes, o incidente não mostra a lacuna de dados e, por vezes, a lacuna de dados é corrigida automaticamente:
Nos gráficos, por exemplo, as lacunas podem não aparecer porque os valores dos dados em falta são interpolados. Mesmo quando faltam vários minutos de dados, o gráfico liga os pontos em falta para garantir a continuidade visual. Essa lacuna nos dados subjacentes pode ser suficiente para que uma política de alerta crie um incidente.
Os pontos nas métricas baseadas em registos podem chegar com atraso e ser preenchidos, até 10 minutos no passado. O comportamento de preenchimento corrige eficazmente a lacuna. A lacuna é preenchida quando os dados chegam finalmente. Assim, uma lacuna numa métrica baseada em registos que já não pode ser vista pode ter feito com que uma política de alerta criasse um incidente.
As condições de ausência de métricas e de limite "inferior a" são avaliadas em tempo real, com um pequeno atraso na consulta. O estado da condição pode mudar entre o momento em que é avaliada e o momento em que o incidente correspondente fica visível na monitorização.
As condições configuradas para criar um incidente numa única medida podem resultar em incidentes que parecem prematuros ou incorretos. Para evitar esta situação, verifique se são necessárias várias medições antes de ser criado um incidente definindo a janela de novo teste de uma condição para ser mais do que o dobro da taxa de amostragem da métrica.
Por exemplo, se uma métrica for amostrada a cada 60 segundos, defina o período de novo teste para, pelo menos, 3 minutos. Se definir a janela de novo teste para o valor mais recente ou, equivalentemente, para 0 segundos, uma única medição pode fazer com que seja criado um incidente.
Quando a condição de uma política de alerta é editada, a alteração pode demorar vários minutos a propagar-se através da infraestrutura de alertas. Durante este período, pode receber notificações de incidentes que cumpriram as condições da política de alerta original.
Quando chegam dados de séries cronológicas, pode demorar até um minuto para que os dados se propaguem por toda a infraestrutura de alertas. Durante este processo, uma política de alerta pode avaliar uma condição como sendo cumprida, mesmo que os dados da série cronológica não tenham sido propagados para o gráfico da série cronológica. Como resultado, pode receber uma notificação, mesmo que o gráfico não indique que a condição foi cumprida. Para reduzir a possibilidade desta situação, use um período de alinhamento de, pelo menos, cinco minutos.
A mudança do nome da etiqueta do App Hub
metadata.system_labels.apphub_host_project_idparametadata.system_labels.apphub_application_containerpode resultar na geração de novos incidentes e no não encerramento de alguns incidentes abertos.Não é necessária nenhuma ação. Os alertas são fechados automaticamente quando os dados deixam de chegar, após a duração do fecho automático expirar. Para mais informações, consulte o artigo Dados de métricas parciais.
O incidente não é encerrado quando os dados deixam de chegar
Segue as orientações em Dados de métricas parciais e configura uma política de alertas para fechar incidentes quando os dados deixarem de chegar. Em alguns casos, os dados deixam de chegar, mas um incidente aberto não é fechado automaticamente.
Se o recurso subjacente monitorizado por uma política de alertas contiver a etiqueta metadata.system_labels.state e se essa política não for escrita com a linguagem de consulta do Monitoring, o Monitoring pode determinar o estado do recurso. Se o estado de um recurso for conhecido por estar desativado, o Monitoring não fecha automaticamente os incidentes quando os dados deixam de chegar. No entanto, pode fechar estes incidentes manualmente.
Não é possível ver os detalhes do incidente devido a um erro de autorização
Navega para a página de incidentes na Google Cloud consola e seleciona um incidente para ver. Espera ter a página de detalhes aberta. No entanto, a página de detalhes não é aberta e é apresentada a mensagem "Acesso recusado".
Para ver todos os detalhes dos incidentes, exceto os dados de métricas, verifique se tem as funções de
gestão de identidade e acesso (IAM) de
Visualizador de incidentes da Cloud Console do Monitoring
(roles/monitoring.cloudConsoleIncidentViewer) e
Visualizador de contas do Stackdriver (roles/stackdriver.accounts.viewer).
Para ver todos os detalhes dos incidentes, incluindo os dados de métricas, e poder
confirmar ou fechar incidentes, verifique se tem as funções do
IAM de leitor de monitorização (roles/monitoring.viewer) e
editor de incidentes da Cloud Console do Monitoring
(roles/monitoring.cloudConsoleIncidentEditor).
As funções personalizadas não podem conceder a autorização necessária para ver os detalhes dos incidentes.
O incidente não é criado quando a condição é cumprida
Criou uma política de alerta com uma condição. O gráfico da política de alertas mostra que os dados monitorizados violam a condição, mas não recebeu uma notificação e não foi criado nenhum incidente.
Se algum dos seguintes critérios for verdadeiro após o cumprimento da condição da política de alerta, o Monitoring não abre o incidente.
- 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 incidentes que pode abrir em simultâneo.
O estado do recurso que a política de alertas monitoriza é conhecido por estar desativado. A monitorização pode determinar o estado de um recurso quando o recurso contém a etiqueta
metadata.system_labels.statee quando a política de alertas não é escrita com a linguagem de consulta do Monitoring.
Os detalhes do incidente indicam o projeto errado
Recebe uma notificação e o resumo da condição apresenta o Google Cloud projeto no qual o incidente foi criado, ou seja, apresenta o projeto de âmbito. No entanto, espera que o incidente liste o nome do projeto que armazena as séries cronológicas que fizeram com que o Monitoring criasse o incidente. Google Cloud
As opções de agregação especificadas na condição de uma política de alerta determinam o Google Cloud projeto que é referenciado numa notificação:
Quando as opções de agregação eliminam a etiqueta que armazena o ID do projeto, as informações do incidente indicam o projeto de âmbito. Por exemplo, se agrupar os dados apenas por zona, após o agrupamento, a etiqueta que armazena o ID do projeto é removida.
Quando as opções de agregação preservam a etiqueta que armazena o ID do projeto, as notificações de incidentes incluem o nome do Google Cloud projeto que armazena a série cronológica que faz com que o incidente ocorra. Para preservar a etiqueta do ID do projeto, inclua a etiqueta
project_idno campo de agrupamento ou não agrupe as séries cronológicas.
Não é possível fechar um incidente manualmente
Recebeu uma notificação de um incidente no seu sistema. Aceda à página de detalhes do incidente e clique em Fechar incidente. Espera que o incidente seja encerrado. No entanto, recebe a seguinte mensagem de erro:
Unable to close incident with active conditions.
Só pode fechar um incidente quando não chegam observações no período de alerta mais recente. O período de alerta, que normalmente tem um valor predefinido de 5 minutos, é definido como parte da condição da política de alerta e é configurável. A mensagem de erro anterior indica que foram recebidos dados no período de alerta.
O seguinte erro ocorre quando não é possível fechar um incidente devido a um erro interno:
Unable to close incident. Please try again in a few minutes.
Quando vir a mensagem de erro anterior, pode tentar novamente a operação de fecho ou permitir que o Monitoring feche automaticamente o incidente.
Para mais informações, consulte o artigo Gerir incidentes.
A política com várias condições cria várias notificações
Criou uma política de alertas que contém várias condições e juntou essas condições com um operador lógico AND. Espera receber uma notificação e ter um incidente criado quando todas as condições forem cumpridas. No entanto, recebe várias notificações e vê que são criados vários incidentes.
A monitorização envia uma notificação e cria um incidente para cada série cronológica que faz com que uma condição seja cumprida. Como resultado, quando tem políticas de alerta com várias condições, pode receber uma notificação e um incidente para cada série cronológica que faz com que as condições associadas sejam cumpridas.
Por exemplo, tem uma política de alertas com duas condições, em que cada condição monitoriza 3 séries cronológicas. A política envia uma notificação apenas quando ambas as condições forem cumpridas. Quando as condições da política forem cumpridas, pode receber entre 2 (uma série cronológica é cumprida em cada condição) e 6 (todas as séries cronológicas são cumpridas em cada condição) notificações e incidentes.
Não pode configurar a monitorização para criar um único incidente e enviar uma única notificação.
Para mais informações, consulte o artigo Notificações por incidente.
A variável de uma etiqueta de métrica é nula
Cria uma política de alerta e adiciona uma variável para uma etiqueta de métrica à secção de documentação.
Espera que as notificações mostrem o valor da variável. No entanto, o valor está definido como null.
Para resolver esta situação, experimente o seguinte:
Confirme se as definições de agregação da política de alerta preservam a etiqueta que quer apresentar.
Por exemplo, suponha que cria uma política de alertas que monitoriza os bytes de disco escritos por instâncias de VM. Quer que a documentação liste o dispositivo que está a causar a notificação, por isso, adiciona ao campo de documentação o seguinte:
device: ${metric.label.device}.Também tem de verificar se as definições de agregação preservam o valor da etiqueta
device. Pode preservar esta etiqueta definindo a função de agregação comononeou verificando se as seleções de agrupamento incluemdevice.Verifique a sintaxe e a aplicabilidade da variável. Para informações sobre a sintaxe, consulte o artigo Anote as notificações com documentação definida pelo utilizador.
Por exemplo, a variável
log.extracted_label.KEYsó é suportada para políticas de alerta baseadas em registos. Esta variável é sempre renderizada comonullquando uma política de alerta monitoriza uma métrica, mesmo uma métrica baseada em registos.
Não existem novos dados após alterações às definições de métricas
Altera a definição de uma métrica definida pelo utilizador, por exemplo, modificando o filtro que usou numa métrica baseada em registos, e a política de alertas não reflete a alteração que fez à definição da métrica.
Para resolver este problema, force a atualização da política de alerta editando o nome a apresentar da política.
A criação de políticas de alerta falha na API devido à falta de uma métrica
Criou recentemente uma métrica e, em seguida, fez referência a essa métrica quando tentou criar uma política de alerta na API Cloud Monitoring. No entanto, o comando da API falha e apresenta 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 este problema, aguarde, pelo menos, dez minutos e, em seguida, reenvie o pedido de API.
O gráfico da política de alertas não mostra a violação do limite
Recebeu uma notificação de que foi aberto um incidente para a sua política de alerta. No entanto, quando acede à página de detalhes da política, o gráfico não indica que o limite foi violado.
Para resolver esta situação, experimente reduzir o intervalo de tempo do gráfico. Pode reduzir o intervalo de tempo através do seletor de intervalo de tempo na barra de ferramentas ou realçando intervalos de tempo no gráfico com o ponteiro.
Os gráficos têm uma resolução limitada e podem não mostrar todas as medições para alguns intervalos de tempo.