Solucionar problemas em alertas do Azure Monitor
Este artigo discute problemas comuns em alertas e notificações do Azure Monitor. Os alertas do Azure Monitor notificam você proativamente quando condições importantes são encontradas em seus dados de monitoramento.
Para obter informações específicas sobre como solucionar os problemas de métricas do Azure ou alertas de pesquisa de log, consulte:
- Solucionar problemas de alertas de métrica do Azure Monitor
- Solução de problemas de alertas de pesquisa de log do Azure Monitor
Antes da solução de problemas
Se o alerta for disparado como pretendido, mas as notificações adequadas não funcionarem como esperado, teste seu grupo de ações primeiro para garantir que ele esteja configurado corretamente.
Caso contrário, use as informações do restante deste artigo para solucionar o problema.
Não recebi o email esperado
Se você puder ver um alerta disparado no portal do Azure, mas não recebeu o email que configurou, siga estas etapas:
A ação foi suprimida por uma regra de processamento de alerta?
Verifique clicando no alerta acionado no portal e examine a guia de histórico para grupos de ações suprimidos:
É uma ação do tipo “Função de enviar email ao Azure Resource Manager”?
Essa ação examina somente atribuições de função do Azure Resource Manager (ARM) que estão no escopo da assinatura e que são do tipo Usuário ou Grupo. Veja se você atribuiu a função no nível de assinatura e não no nível de recurso ou de grupo de recursos.
O seu servidor de email e a sua caixa de correio aceitam emails externos?
Verifique se os emails desses três endereços não estão bloqueados:
- azure-noreply@microsoft.com
- azureemail-noreply@microsoft.com
- alerts-noreply@mail.windowsazure.com
É comum que listas de endereçamento internas ou listas de distribuição bloqueiem emails de endereços de email externos. Certifique-se de permitir o envio de emails dos endereços de email acima. Para testar, adicione um endereço de email de trabalho regular (não uma lista de endereçamento) ao grupo de ações e veja se os alertas chegam a esse email.
O email foi processado pelas regras da caixa de entrada ou por um filtro de spam?
Verifique se não há nenhuma regra de caixa de entrada que exclua esses emails ou mova-os para uma pasta lateral. As regras de caixa de entrada podem, por exemplo, capturar remetentes específicos ou palavras específicas no assunto. Além disso, verifique:
- As configurações de spam do seu cliente de email (como o Outlook, Gmail)
- As configurações de limites de remetente/spam/quarentena do seu servidor de email (como Exchange, Microsoft 365, G-Suite)
- As configurações de seu dispositivo de segurança de email, se houver (como Barracuda, Cisco).
Você cancelou acidentalmente a assinatura do grupo de ações?
Observação
Tenha em mente que se você cancelar a inscrição em um grupo de ação, todos os membros de uma lista de distribuição também serão cancelados. Você pode continuar usando o endereço de email da sua lista de distribuição. No entanto, você precisará informar aos usuários da sua lista de distribuição que, se cancelarem a assinatura, estarão cancelando a assinatura de toda a lista de distribuição, e não apenas de si mesmos. Uma solução alternativa para isso é adicionar o endereço de email de todos os usuários no grupo de ação individualmente. Um grupo de ação pode conter até 1.000 endereços de email. Então, se um usuário específico quiser cancelar a assinatura, ele poderá fazê-lo sem afetar os outros usuários. Você também poderá ver quais usuários cancelaram a assinatura.
Os emails de alerta fornecem um link para cancelar a assinatura do grupo de ações. Para verificar se você cancelou acidentalmente a assinatura desse grupo de ações, faça o seguinte:
- Abra o grupo de ações no portal e verifique a coluna status faça um dos seguintes procedimentos:
- Pesquise seu email para obter a confirmação de cancelamento da assinatura:
Para assinar novamente, use o link no email de confirmação de cancelamento de assinatura que você recebeu ou remova o endereço de email do grupo de ações e, em seguida, adicione-o novamente.
Você excedeu os limites do serviço ao enviar muitos emails para um único endereço de email?
A taxa de emails está limitada a 100 emails por hora para cada endereço de email. Se você ultrapassar esse limite, não serão enviadas mais notificações por email. Verifique se recebeu uma mensagem indicando que o endereço sofreu limitação de taxa temporária:
Se você quiser receber um grande volume de notificações sem limitar a taxa, considere o uso de uma ação diferente, como:
- webhook
- Aplicativo lógico
- Função do Azure
- Runbooks de automação
Nenhuma dessas ações é limitada por taxa.
Não recebi a notificação esperada por SMS, chamada de voz ou push
Se você puder ver um alerta disparado no portal, mas não tiver recebido o SMS, a chamada de voz ou a notificação por push que configurou, siga estas etapas:
A ação foi suprimida por uma regra de processamento de alerta?
Verifique clicando no alerta acionado no portal e examine a guia de histórico para grupos de ações suprimidos:
Se isso não foi intencional, é possível modificar, desabilitar ou excluir a regra de processamento de alerta.
SMS/Voz: seu número de telefone está correto?
Verifique a ação de SMS para erros de digitação no código do país ou no número de telefone.
SMS/voz: você excedeu os limites do serviço?
Chamadas de voz e SMS têm limitações por taxa de, no máximo, uma notificação a cada cinco minutos por número de telefone. Se você ultrapassar esse limite, as notificações serão descartadas.
- Chamada de voz: verifique seu histórico de chamadas e veja se recebeu outra chamada do Azure nos últimos cinco minutos.
- SMS: verifique o histórico de SMS em busca de uma mensagem que indique que o número de telefone sofreu uma limitação por taxa
Se você quiser receber um grande volume de notificações sem limitar a taxa, considere usar uma ação diferente, como:
- webhook
- Aplicativo lógico
- Função do Azure
- Runbooks de automação
Nenhuma dessas ações é limitada por taxa.
4. SMS: você cancelou acidentalmente a assinatura do grupo de ações?
Abra o seu histórico de SMS e verifique se você recusou a entrega de SMS desse grupo de ações específico (usando a resposta DISABLE action_group_short_name) ou de todos os grupos de ações (usando a resposta STOP).
Para assinar novamente, envie o comando relevante do SMS (ENABLE action_group_short_name ou START) ou remova a ação SMS do grupo de ações e adicione-a novamente. Para obter mais informações, confira comportamento de alerta do SMS em grupos de ações.
Você bloqueou acidentalmente as notificações em seu telefone?
A maioria dos telefones celulares permite que você bloqueie chamadas ou SMS de números de telefone ou códigos curtos específicos ou que bloqueie notificações por push de aplicativos específicos (como o aplicativo móvel do Azure). Para verificar se você bloqueou acidentalmente as notificações em seu telefone, pesquise a documentação específica do sistema operacional e do modelo do seu telefone ou teste com um telefone e um número de telefone diferentes.
A ação esperada não foi disparada
Se você puder ver um alerta disparado no portal, mas a ação configurada não foi disparada, siga estas etapas:
A ação foi suprimida por uma regra de processamento de alerta?
Verifique clicando no alerta acionado no portal e examine a guia de histórico para grupos de ações suprimidos:
Se isso não foi intencional, é possível modificar, desabilitar ou excluir a regra de processamento de alerta.
O webhook foi disparado?
O endereço IP de origem está bloqueado?
Adicione os endereços IP dos quais o webhook é chamado à sua lista de permissões.
O ponto de extremidade do webhook funciona corretamente?
Verifique se o ponto de extremidade de webhook configurado está correto e se o ponto de extremidade está funcionando corretamente. Verifique seus logs do webhook ou instrumente o código dele para que você possa investigar (por exemplo, registrar o conteúdo de entrada).
Você está usando o formato correto para chamar o Slack ou o Microsoft Teams?
Cada um desses pontos de extremidade espera um formato JSON específico. Siga estas instruções para configurar uma ação de aplicativo lógico em vez disso.Seu webhook parou de responder ou retornou erros?
Os grupos de ações do Webhook geralmente seguem estas regras quando chamados:
- Quando um webhook é invocado, se a primeira chamada falhar, ele será repetido pelo menos mais uma vez e até cinco vezes (5 repetições) em vários intervalos de atraso (5, 20, 40 segundos).
- O atraso entre a 1ª e a 2ª tentativa é de 5 segundos
- O atraso entre a 2ª e a 3ª tentativa é de 20 segundos
- O atraso entre a 3ª e a 4ª tentativa é de 5 segundos
- O atraso entre a 4ª e a 5ª tentativa é de 40 segundos
- O atraso entre a 5ª e a 6ª tentativa é de 5 segundos
- Depois que novas tentativas de chamar o webhook falharem, nenhum grupo de ação chamará o ponto de extremidade por 15 minutos.
- A lógica de repetição pressupõe que a chamada pode ser repetida. Os códigos de status: 408, 429, 503, 504 ou
HttpRequestException,WebExceptionouTaskCancellationExceptionpermitem que a chamada seja repetida.
- Quando um webhook é invocado, se a primeira chamada falhar, ele será repetido pelo menos mais uma vez e até cinco vezes (5 repetições) em vários intervalos de atraso (5, 20, 40 segundos).
A ação ou notificação ocorreu mais de uma vez
Se você tiver recebido uma notificação para um alerta (como um email ou um SMS) mais de uma vez ou se a ação do alerta (como webhook ou Função do Azure) tiver sido disparada várias vezes, siga essas etapas:
É realmente o mesmo alerta?
Em alguns casos, vários alertas semelhantes são acionados quase ao mesmo tempo. Portanto, pode parecer que o mesmo alerta disparou as ações dele várias vezes. Por exemplo, uma regra de alerta do log de atividades poderá ser configurada para ser acionada quando um evento for iniciado e quando tiver terminado (êxito ou falha), não filtrando pelo campo de status do evento.
Para verificar se essas ações ou notificações vieram de alertas diferentes, examine os detalhes do alerta, tais como o respectivo carimbo de data/hora e a ID do alerta ou, alternativamente a ela, a ID de correlação dele. Como alternativa, verifique a lista de alertas acionados no portal. Se for esse o caso, você precisará adaptar a lógica da regra de alertas ou configurar a fonte do alerta.
A ação é repetida em vários grupos de ações?
Quando um alerta é acionado, cada um dos grupos de ações dele é processado de maneira independente. Portanto, se uma ação (como um endereço de email) aparecer em vários grupos de ações disparados, ela será chamada uma vez por grupo de ações.
Para verificar quais grupos de ações foram disparados, verifique a guia histórico de alertas. Você verá que há grupos de ações definidos na regra de alerta e grupos de ações adicionados ao alerta por regras de processamento de alerta:
A ação ou notificação tem conteúdo inesperado
Houve uma interrupção que acionou o uso do provedor de email de fallback?
Os Grupos de Ações usam dois provedores de email diferentes para garantir a entrega das notificações por email. O provedor de email principal é resiliente e rápido, mas ocasionalmente sofre interrupções. Quando há interrupções, o provedor de email secundário lida com as solicitações de email. O provedor secundário é apenas uma solução alternativa. Devido às diferenças entre os provedores, um email enviado do nosso provedor secundário pode apresentar uma experiência de email degradada. A degradação resulta em um conteúdo e formatação de email ligeiramente diferentes. Como os modelos de email são diferentes nos dois sistemas, não é possível manter a paridade entre os dois sistemas.
As notificações geradas pela solução de fallback contêm uma nota que diz:
"Essa é uma experiência de email degradada. Isso significa que a formatação pode estar desativada ou os detalhes podem estar ausentes. Para obter mais informações sobre a experiência degradada de email, leia aqui."
Se a sua notificação não contiver essa anotação e você recebeu o alerta, mas acredita que alguns dos campos estão ausentes ou incorretos, verifique o formato do payload.
Que formato você usou ao configurar a regra de alerta?
Cada tipo de ação (email, webhook etc.) tem dois formatos: o padrão, o formato herdado e o formato de esquema comum. Ao criar um grupo de ações, especifique o formato da ação. Ações diferentes nos grupos de ações podem ter formatos diferentes.
Por exemplo, para ações de webhook:
Verifique se o formato especificado no nível de ação é o que você espera. Por exemplo, você pode ter desenvolvido código que responde a alertas (webhook, função, aplicativo lógico etc.), esperando um formato, mas posteriormente na ação, você ou outra pessoa especificou um formato diferente.
Além disso, verifique o formato de carga (JSON) para alertas do log de atividades, para alertas de pesquisa de logs (Application Insights e análise de logs), para de alertas de métrica, para o esquema de alerta comum e para os alertas de métrica clássico preteridos.
Os resultados da pesquisa não são incluídos nas notificações de alerta da pesquisa de logs.
A partir da versão 2021-08-01 da API de alertas de pesquisa de registros, os resultados da pesquisa foram removidos do payload da notificação de alerta. Os resultados da pesquisa só estão disponíveis para regras de alerta criadas com versões anteriores da API (2018-04-16). A criação de novas regras de alerta por meio do portal do Azure criará, por padrão, a regra com a versão mais recente. Siga Alterações na experiência de criação da regra de alerta de log para saber mais sobre as alterações e os ajustes recomendados para usar a versão atualizada.
O campo MetricValue contém "nulo" para notificações de alertas da pesquisa de logs resolvidas.
Isso ocorre por design. Os alertas de pesquisa de log com estado usam uma lógica de resolução baseada em tempo em vez de baseada em valor. O Azure Monitor está enviando um valor de métrica nulo, pois não há nenhum valor que tenha causado a resolução do alerta, mas sim o tempo decorrido.
A lista de dimensões está vazia ou o título do alerta não contém um nome de dimensão
Quando você tem uma regra de alerta de pesquisa de log que não retorna nenhum resultado, o alerta pode ser disparado como esperado, mas a lista de dimensões está vazia ou o título do alerta não contém um nome de dimensão. Quando uma consulta não retorna nenhuma linha, o campo ID do recurso (que é a base para preencher os campos de dimensão e título) fica vazio.
Faltam informações em um alerta de log de atividades
Alertas do log de atividades são alertas baseados em eventos gravados no log de atividades do Azure, como eventos sobre criação, atualização ou exclusão de recursos do Azure, eventos de integridade de serviços e recursos ou descobertas do Assistente do Azure e do Azure Policy. Se você tiver recebido um alerta com base no log de atividades, mas alguns campos necessários estiverem ausentes ou incorretos, primeiro verifique os eventos no próprio log de atividades. Se o recurso do Azure não gravar os campos que você está procurando em seu evento do log de atividades, esses campos não serão incluídos no alerta correspondente.
As propriedades personalizadas não estão presentes nas notificações por email, SMS ou push.
As propriedades personalizadas são passadas apenas para o payload de ações, como webhook, função do Azure ou aplicativos lógicos. As propriedades personalizadas não estão incluídas nas notificações (email/SMS/push).
A regra de processamento de alertas não está funcionando conforme o esperado
Se você puder ver um alerta disparado no portal, mas uma regra de processamento de alerta relacionada não funcionar como esperado, siga estas etapas:
A regra de processamento de alerta está habilitada?
Verifique o campo status da regra de processamento de alerta para verificar se a função de ação relacionada está habilitada. Por padrão, o portal mostra apenas as regras de alerta habilitadas, mas você pode alterar o filtro para mostrar todas as regras.
Se ela não estiver habilitada, você poderá habilitar a regra de processamento de alertas selecionando-a e clicando em Habilitar.
Trata-se de um alerta de integridade de serviço?
Os alertas de integridade do serviço não são afetados pelas regras de processamento de alertas. Portanto, se você tiver uma regra de processamento de alertas configurada para um escopo que inclua alertas de integridade de serviço, enquanto os alertas de integridade de serviço estiverem dentro do escopo, a regra de processamento de alertas não os afetará.
A regra de processamento de alertas processou seu alerta?
Selecione o alerta disparado no portal e examine a guia Histórico para ver se a regra de processamento de alerta foi processada.
Aqui está um exemplo de regra de processamento de alertas que suprime todos os grupos de ação:
Aqui está um exemplo de uma regra de processamento de alertas que adiciona outro grupo de ações:
O escopo e o filtro da regra de processamento de alerta correspondem ao alerta disparado?
Se você acha que a regra de processamento de alertas deveria ter sido disparada, mas não foi, ou que não deveria ter sido disparada, mas foi, examine cuidadosamente o escopo da regra de processamento de alertas e as condições do filtro e compare-os com as propriedades do alerta disparado.
Problemas para criar, atualizar ou excluir regras de processamento de alertas no portal do Azure
Se você recebeu um erro ao tentar criar, atualizar ou excluir uma regra de processamento alerta, siga estas etapas:
Verifique as permissões.
Você precisa ter a função interna de colaborador de monitoramento ou as permissões específicas relacionadas a regras de processamento de alerta e a alertas.
Verifique os parâmetros da regra de processamento de alertas.
Verifique a documentação da regra de processamento de alertas ou o comando PowerShell Set-AzAlertProcessingRule da regra de processamento de alertas.