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 duração escolhida, por exemplo, consulte Comportamento de políticas de alertas com base em métricas.

A variável de um identificador de métrica é nula

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 da variável. No entanto, o valor está 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 exibir.

    Por exemplo, suponha que você crie uma política de alertas que monitore os bytes do disco gravados por instâncias de VM. Você quer que a documentação liste o dispositivo que está causando a notificação. Portanto, adicione ao campo de documentação o seguinte: device: ${metric.label.device}.

    Também é preciso garantir que as configurações de agregação preservem o valor do rótulo device. É possível preservar esse rótulo definindo a função de agregação como none ou garantindo que as seleções de agrupamento incluam device.

  • Verifique a sintaxe e a aplicabilidade da variável. Para informações de sintaxe, consulte Anotar alertas com documentação definida pelo usuário.

    Por exemplo, a variável log.extracted_label.KEY só é compatível com alertas baseados em registros. Essa variável sempre é renderizada como null quando uma política de alertas monitora uma métrica, mesmo uma métrica com base em registros.

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, é possível adicionar o filtro device !=~ ^/dev/loop.*, que exclui todas as série temporal cujo rótulo device não corresponde à expressão regular ^/dev/loop.*.

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étricas 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 endpoints particulares, use verificações de tempo de atividade privados.

Uma alternativa aos alertas nas verificações de tempo de atividade é usar políticas que monitorem a ausência de dados. É altamente recomendável alertar nas verificações de tempo de atividade em vez da ausência de dados. Os alertas de ausência podem gerar falsos positivos se houver problemas temporários com a disponibilidade dos dados do Monitoring.

No entanto, se não for possível usar as verificações de tempo de atividade, crie uma política de alertas com o MQL para notificar que a VM foi encerrada. As condições definidas pelo MQL não pré-filtram dados de séries temporais 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 da 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, um incidente será gerado três minutos depois e as notificações serão enviadas. O valor de absent_for precisa ter pelo menos três minutos.

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

1: o 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 Google Cloud, use o editor de código.

A política de contagem de solicitações não cria os alertas esperados

Você quer monitorar o número de solicitações concluídas. Você criou uma política de alertas que monitora a métrica serviceruntime.googleapis.com/api/request_count, mas não recebe uma notificação quando o número de solicitações excede o limite configurado.

O período de alinhamento máximo para a métrica de contagem de solicitações é de 7 horas e 30 minutos.

Para resolver esse problema, verifique o valor do período de alinhamento na sua política de alertas. Se o valor for maior que o máximo para essa métrica, reduza o período de alinhamento para que não seja mais de 7 horas e 30 minutos.

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:

    • 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. 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 em até 10 minutos no passado. 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 pode ter feito uma política de alertas 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 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, garanta que várias medições sejam necessárias antes de um incidente ser criado. Para isso, defina o campo de duração 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 duração para pelo menos 3 minutos. Se você definir o campo de duração como o valor mais recente, ou equivalente a zero 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. Quando o período de alinhamento é definido como um minuto ou para a amostra mais recente, a latência de propagação pode fazer parecer que a política de alertas está sendo acionada incorretamente. Para reduzir a possibilidade dessa situação, use um período de alinhamento de pelo menos cinco minutos.

O incidente não é encerrado 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 incidentes quando os dados pararem de chegar. Em alguns casos, os dados param de chegar, mas um incidente aberto não é fechado automaticamente.

Se o recurso subjacente monitorado por uma política de alertas contiver o rótulo metadata.system_labels.state e se essa política não for gravada com a linguagem de consulta do Monitoring, o Monitoring poderá determinar o estado do recurso. Se o estado de um recurso estiver desativado, o Monitoring não fechará automaticamente os incidentes quando os dados pararem de chegar. No entanto, você pode fechar esses incidentes manualmente.

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 Monitoring 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 unidas sejam atendidas.

Por exemplo, você tem uma política de alertas com duas condições, em que cada condição monitora três série temporal. A política envia uma notificação apenas quando as duas condições são atendidas. Quando as condições da política forem atendidas, você poderá receber entre duas notificações e incidentes (uma série temporal é atendida em cada condição) e seis (todas as séries temporais são atendidas em cada condição).

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.

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 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 os papéis do Identity and Access Management (IAM) de Leitor de incidentes do console do Cloud Monitoring (roles/monitoring.cloudConsoleIncidentViewer) e de Leitor de contas do Stackdriver (roles/stackdriver.accounts.viewer).

Para visualizar todos os detalhes do incidente, incluindo os dados da métrica, e poder confirmar ou encerrar incidentes, verifique se você tem os papéis do IAM de Leitor do Monitoring (roles/monitoring.viewer) e Editor de incidentes do Monitoring 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 que tem uma condição. O gráfico 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 depois que a condição da política de alertas for atendida, o Monitoring não abrirá o incidente.

  • a política de alertas foi adiada;
  • A política de alertas está desativada.
  • A política de alertas atingiu o número máximo de incidentes que pode abrir simultaneamente.

  • O estado do recurso que a política de alertas monitora é sabidamente desativado. O Monitoring pode determinar o estado de um recurso quando ele contém o rótulo metadata.system_labels.state e quando a política de alertas não é gravada com a linguagem de consulta do Monitoring.

Lista de detalhes do incidente o projeto errado

Você recebe uma notificação e o resumo da condição lista o projeto do Google Cloud em que o incidente foi criado, ou seja, lista o projeto do escopo. No entanto, espera-se que o incidente liste o nome do projeto do Google Cloud que armazena a série temporal que fez com que o Monitoring crie o incidente.

As opções de agregação especificadas na condição de uma política de alertas determinam o projeto do Google Cloud que é 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 do escopo. Por exemplo, se você agrupar os dados apenas por zona, o rótulo que armazena o ID do projeto será removido após o agrupamento.

  • 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 a ocorrência do incidente. Para preservar o rótulo do ID do projeto, inclua o rótulo project_id no 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.

As notificações não são recebidas

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

Para informações sobre como resolver problemas com notificações do Pub/Sub e webhook, consulte as seguintes seções deste documento:

Para coletar informações sobre a causa da falha, faça o seguinte:

  1. No painel de navegação do console do Google Cloud, selecione Logging e clique em Análise de registros:

    Acessar a Análise de registros

  2. Selecione o projeto do Google Cloud apropriado.

  3. Consulte os registros dos eventos do canal de notificação:

    1. Expanda o menu Nome do registro e selecione notification_channel_events.
    2. Expanda o menu Gravidade e selecione Erro.
    3. Opcional: para selecionar um período personalizado, use o seletor de período.
    4. Clique em Executar consulta.

    Nas etapas anteriores, criamos a seguinte consulta:

    logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR

    As informações de falha geralmente são incluídas na linha de resumo e no campo jsonPayload.

    A linha de resumo e o campo jsonPayload normalmente contêm informações de falha. Por exemplo, quando ocorre um erro de gateway, a linha de resumo inclui "failed with 502 Bad Gateway".

Nenhum dado novo após as mudanças 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 nome de exibição dela.

As notificações de webhook enviadas ao Google Chat não são recebidas

Configure um canal de notificação de webhook no Monitoring e configure o webhook para enviá-lo ao Google Chat. No entanto, você não está recebendo notificações ou está recebendo erros 400 Bad Request.

Para resolver esse problema, configure um canal de notificação do Pub/Sub no Monitoring e um serviço do Cloud Run para converter as mensagens do Pub/Sub no formato esperado pelo Chat e, em seguida, enviar a notificação ao Google Chat. Para um exemplo dessa configuração, consulte Como criar notificações personalizadas com o Cloud Monitoring e o Cloud Run.

Notificações de webhook não são recebidas

Você configura um canal de notificação do webhook e espera receber uma notificação 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 de pull para esse tópico de notificação.

Ao configurar um canal de notificação do Pub/Sub, as notificações de incidentes são enviadas para uma fila do Pub/Sub que tem controles do Identity and Access Management. 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, Cloud Run ou Compute Engine podem consumir essas notificações.

Se você usar uma assinatura pull, uma solicitação será enviada ao Google, que aguarda a chegada de uma mensagem Essas assinaturas exigem acesso ao Google, mas não exigem regras para firewalls ou acesso de entrada.

Endpoint público

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

Por exemplo, é possível pesquisar nas entradas de registro pelo recurso de canal de notificação. Para isso, use o Explorador de registros, com um filtro como este:

resource.type="stackdriver_notification_channel"

Notificações do Pub/Sub não são recebidas

Você configura um canal de notificação do Pub/Sub, mas não recebe nenhuma notificação.

Para resolver essa condição, tente o seguinte:

  • Verifique se a conta do serviço de notificações existe. As notificações não são enviadas quando a conta de serviço é excluída.

    Para verificar se a conta de serviço existe, faça o seguinte:

    1. No painel de navegação do console do Google Cloud, selecione IAM:

      Acessar o IAM

    2. Pesquise uma conta de serviço que tenha a seguinte convenção de nomenclatura:

      service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

      Se ela não estiver listada, selecione Incluir concessões de papéis fornecidos pelo Google.

    Se a conta de serviço de notificações não existir, inicie o processo de criação do canal de notificação do Pub/Sub para que o Monitoring crie a conta de serviço:

    1. No painel de navegação do console do Google Cloud, selecione Monitoramento e  Alertas:

      Acessar Alertas

    2. Clique em Editar canais de notificação.

    3. Na seção Pub/Sub, clique em Adicionar novo.

      O Monitoring cria a conta de serviço de notificações quando uma não existe. A caixa de diálogo Criar canal do Pub/Sub mostra o nome da conta de serviço de notificações.

    4. Se você não quiser adicionar um canal de notificação, clique em Cancelar. Caso contrário, conclua a criação do canal de notificação e clique em Adicionar canal.

    5. Conceda permissões à conta de serviço para publicar seus tópicos do Pub/Sub:

      1. Em uma nova guia do navegador, abra o documento Criar um canal de notificação.
      2. Selecione a guia Pub/Sub e siga as etapas da seção Autorizar conta de serviço da página.

  • Verifique se a conta de serviço de notificações foi autorizada a enviar notificações para os tópicos de interesse do Pub/Sub.

    Para visualizar as permissões de uma conta de serviço, use o Console do Google Cloud ou o comando da Google Cloud CLI:

    • A página IAM no console do Google Cloud lista os papéis de cada conta de serviço.
    • A página Tópicos do Pub/Sub no console do Google Cloud lista cada tópico. Quando você seleciona um tópico, a guia Permissões lista os papéis concedidos às contas de serviço.

    • Para listar todas as contas de serviço e os respectivos papéis, execute o seguinte comando da Google Cloud CLI:

      gcloud projects get-iam-policy PROJECT_ID

      Veja a seguir uma resposta parcial para este comando:

          serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/monitoring.notificationServiceAgent
     - members:
       [...]
       role: roles/owner
     - members:
       - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/pubsub.publisher

      A resposta ao comando inclui apenas papéis, e não permissões por tópico.

    • Para listar as vinculações do IAM para um tópico específico, execute o seguinte comando:

      gcloud pubsub topics get-iam-policy TOPIC

      Veja a seguir um exemplo de resposta para este comando:

          bindings:
    - members:
      - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
      role: roles/pubsub.publisher
    etag: BwXPRb5WDPI=
    version: 1

    Para informações sobre como autorizar a conta de serviço de notificações, consulte Autorizar conta de serviço.