Resolver problemas relacionados com os alertas do Azure Monitor

Este artigo discute problemas comuns em alertas e notificações do Azure Monitor. Os alertas do Azure Monitor notificam proativamente quando condições importantes são encontradas em seus dados de monitoramento.

Para obter informações específicas sobre como solucionar problemas de métricas do Azure ou alertas de pesquisa de log, consulte:

• Resolver problemas de alertas métricos do Azure Monitor
• Solucionar problemas de alertas de pesquisa de log do Azure Monitor

Antes da resolução de problemas

Se o alerta for acionado como pretendido, mas as notificações adequadas não tiverem o desempenho esperado, teste primeiro o grupo de ações para garantir que ele esteja configurado corretamente.

Caso contrário, use as informações no restante deste artigo para solucionar o problema.

Não recebi o e-mail esperado

Se conseguir ver um alerta disparado no portal do Azure, mas não receber o e-mail que configurou, siga estes passos:

1. O e-mail foi suprimido por uma regra de processamento de alerta?

   Verifique no portal ao clicar no alerta acionado e veja no separador Histórico os grupos de ações suprimidos:

   

2. É o tipo de ação “Enviar E-mail de Função do Azure Resource Manager”?

   Esta ação examina apenas as atribuições de função do Azure Resource Manager que estão no escopo da assinatura e do tipo Usuário. Certifique-se de que atribuiu a função ao nível da subscrição e não ao nível do recurso ou do grupo de recursos.

3. O servidor de e-mail e a caixa de correio estão a aceitar e-mails externos?

   Verifique se os e-mails destes 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 correio internas ou listas de distribuição bloqueiem os e-mails de endereços externos. Certifique-se de permitir e-mails dos endereços de e-mail acima. Para testar, adicione um endereço de e-mail de trabalho regular (não uma lista de correio) ao grupo de ações e veja se os alertas chegam a esse e-mail.

4. O e-mail foi processado por regras da caixa de entrada ou um filtro de spam?

   Verifique se não existem regras da caixa de entrada que eliminem esses e-mails ou os movam para uma pasta lateral. Por exemplo, as regras da caixa de entrada podem detetar palavras ou remetentes específicos no assunto. Além disso, verifique:

   • As configurações de spam do seu cliente de e-mail (como Outlook, Gmail)
   • Os limites de remetente / configurações de spam / configurações de quarentena do seu servidor de e-mail (como Exchange, Microsoft 365, G-suite)
   • As definições da aplicação de segurança de e-mail, se tiver alguma (como Barracuda, Cisco).

5. Anulou acidentalmente a subscrição do grupo de ações?

   Nota

   Lembre-se de que, se você cancelar a inscrição em um grupo de ações, todos os membros de uma lista de distribuição também serão cancelados. Pode continuar a utilizar o endereço de e-mail da sua lista de distribuição. No entanto, terá de informar os utilizadores da sua lista de distribuição de que, se cancelarem a subscrição, estão a cancelar a subscrição de toda a lista de distribuição e não apenas a si próprios. Uma solução alternativa para isso é adicionar o endereço de e-mail de todos os usuários no grupo de ação individualmente. Um grupo de ação pode conter até 1000 endereços de e-mail. Em seguida, se um usuário específico quiser cancelar a inscrição, ele poderá fazê-lo sem afetar os outros usuários. Você também poderá ver quais usuários cancelaram a inscrição.

   Os e-mails de alerta disponibilizam uma ligação para anular a subscrição do grupo de ações. Para verificar se cancelou acidentalmente a subscrição deste grupo de ações:

   1. Abra o grupo de ações no portal e verifique a coluna Estado:

   

   2. Procure a confirmação da anulação da subscrição no e-mail:

   

   Para se inscrever novamente – use o link no e-mail de confirmação de cancelamento de inscrição que você recebeu ou remova o endereço de e-mail do grupo de ações e adicione-o novamente.

6. Você excedeu os limites de serviço enviando muitos e-mails indo para um único endereço de e-mail?

   Cada endereço de e-mail não pode receber mais de 100 e-mails por hora. Se você ultrapassar esse limite, não serão enviadas mais notificações por e-mail. Verifique se recebeu uma mensagem a indicar que o seu endereço de e-mail está temporariamente limitado:

   

   Se você quiser receber um grande volume de notificações sem limitação de taxa, considere usar uma ação diferente, como:

   • Webhook
   • Aplicação lógica
   • Função do Azure
   • Runbooks de automação

   Nenhuma dessas ações é limitada.

Não recebi o SMS, a chamada de voz ou a notificação push esperados

Se conseguir ver um alerta disparado no portal, mas não tiver recebido o SMS, a chamada de voz ou a notificação push que configurou, siga estes passos:

1. A ação foi suprimida por uma regra de processamento de alertas?

   Verifique no portal ao clicar no alerta acionado e veja no separador Histórico os grupos de ações suprimidos:

   

   Se não tiver sido intencional, poderá modificar, desativar ou eliminar a regra de processamento de alertas.

2. SMS/voz: O seu número de telefone está correto?

   Verifique a ação de SMS para eventuais erros de digitação no código do país ou no número de telefone.

3. SMS/voz: excedeu os limites de serviço?

   Os SMS e as chamadas de voz têm uma limitação de taxa de não mais de uma notificação de cinco em cinco minutos para cada número de telemóvel. Se você ultrapassar esse limite, as notificações serão descartadas.

   • Chamada de voz - verifique seu histórico de chamadas e veja se você teve uma chamada diferente do Azure nos cinco minutos anteriores.
   • SMS - verifique o seu histórico de SMS para uma mensagem indicando que o seu número de telefone é limitado por taxa.

   Se você quiser receber um grande volume de notificações sem limitação de taxa, considere usar uma ação diferente, como:

   • Webhook
   • Aplicação lógica
   • Função do Azure
   • Runbooks de automação

   Nenhuma dessas ações é limitada.

4. SMS: Anulou acidentalmente a subscrição do grupo de ações?

   Abra seu histórico de SMS e verifique se você optou por não receber SMS desse grupo de ações específico (usando a resposta DISABLE action_group_short_name) ou de todos os grupos de ação (usando a resposta STOP).

   Para subscrever novamente, envie o comando SMS relevante (ATIVAR action_group_short_name ou INICIAR) ou remova a ação SMS do grupo de ações e, em seguida, adicione-a de volta. Para obter mais informações, veja Comportamento dos alertas de SMS em grupos de ações.

5. Bloqueou acidentalmente as notificações no telemóvel?

   A maioria dos telemóveis permite bloquear chamadas ou SMS de números de telefone ou códigos curtos específicos ou permite bloquear notificações push de aplicações específicas (como a aplicação móvel do Azure). Para verificar se bloqueou acidentalmente as notificações no telemóvel, procure na documentação específica o sistema operativo e modelo do seu telemóvel, ou teste com um telemóvel e número de telefone diferentes.

A ação esperada não desencadeou

Se você conseguir ver um alerta disparado no portal, mas sua ação configurada não foi acionada, siga estas etapas:

1. A ação foi suprimida por uma regra de processamento de alerta?

   Verifique no portal ao clicar no alerta acionado e veja no separador Histórico os grupos de ações suprimidos:

   

   Se não tiver sido intencional, poderá modificar, desativar ou eliminar a regra de processamento de alertas.

2. O webhook foi acionado?

   1. O endereço IP de origem está bloqueado?

      Adicione os endereços IP dos quais o webhook é chamado à sua lista de permissões.

   2. O ponto final do webhook funciona corretamente?

      Verifique se o ponto de extremidade webhook que você configurou está correto e se o ponto de extremidade está funcionando corretamente. Verifique os registos do webhook ou instrumente o código para que possa ser analisado (por exemplo, registe o payload de entrada).

   3. Você está usando o formato correto para chamar o Slack ou o Microsoft Teams?
      Cada um destes pontos finais espera um formato JSON específico. Siga estas instruções para configurar uma ação da aplicação lógica como alternativa.

   4. Seu webhook deixou de responder ou retornou erros?

      Os grupos de ação Webhook geralmente seguem estas regras quando chamados:

      • Quando um webhook é invocado, se a primeira chamada falhar, ele é repetido pelo menos mais 1 vez e até cinco vezes (5 tentativas) 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 chama 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 , WebExceptionou HttpRequestExceptionTaskCancellationException permitem que a chamada seja repetida.

A ação ou notificação aconteceu mais de uma vez

Se você recebeu uma notificação para um alerta (como um email ou um SMS) mais de uma vez, ou a ação do alerta (como webhook ou função do Azure) foi acionada várias vezes, siga estas etapas:

1. É realmente o mesmo alerta?

   Em certos casos, vários alertas semelhantes são acionados por volta da mesma hora. Assim, pode parecer que o mesmo alerta acionou as ações várias vezes. Por exemplo, uma regra de alerta de registro de atividades pode ser configurada para ser acionada quando um evento é iniciado e terminado (bem-sucedido ou com falha), não filtrando no campo de status do evento.

   Para verificar se estas ações ou notificações provêm de alertas diferentes, examine os detalhes do alerta, como o carimbo de data/hora e o ID de alerta ou o ID de correlação. Em alternativa, verifique a lista de alertas acionados no portal. Se esse for o caso, você precisará adaptar a lógica da regra de alerta ou configurar a fonte de alerta.

2. A ação repete-se em vários grupos de ações?

   Quando um alerta é acionado, cada um dos grupos de ações é processado de forma independente. Por conseguinte, se uma ação (para um endereço de e-mail, por exemplo) aparecer em vários grupos de ações acionados, ela será chamada uma vez por cada grupo de ações.

   Para verificar quais grupos de ações foram acionados, verifique a guia Histórico de alertas. Você veria lá os grupos de ação definidos na regra de alerta e os grupos de ação adicionados ao alerta por regras de processamento de alerta:

   

A ação ou notificação tem conteúdo inesperado

1. Houve uma interrupção que desencadeou o uso do provedor de e-mail de fallback?

   Os Grupos de Ação usam dois provedores de e-mail diferentes para garantir a entrega de notificações por e-mail. O provedor de e-mail principal é resiliente e rápido, mas ocasionalmente sofre interrupções. Quando há interrupções, o provedor de e-mail secundário lida com solicitações de e-mail. O provedor secundário é apenas uma solução de fallback. Devido a diferenças de provedor, um e-mail enviado de nosso provedor secundário pode ter uma experiência de e-mail degradada. A degradação resulta em formatação e conteúdo de e-mail ligeiramente diferentes. Como os modelos de e-mail diferem nos dois sistemas, manter a paridade entre os dois sistemas não é viável.

   As notificações geradas pela solução de fallback contêm uma nota que diz:

   "Esta é uma experiência de e-mail degradada. Isso significa que a formatação pode estar desativada ou detalhes podem estar faltando. Para obter mais informações sobre a experiência de e-mail degradada, leia aqui."

   Se a sua notificação não contiver essa nota e você tiver recebido o alerta, mas acreditar que alguns de seus campos estão ausentes ou incorretos, verifique o formato da carga.

2. Qual formato você usou ao configurar a regra de alerta?

   Cada tipo de ação (e-mail, webhook, etc.) tem dois formatos - o padrão, o formato herdado e o formato de esquema comum. Ao criar um grupo de ações, você especifica o formato da ação. As diferentes ações nos grupos de ação podem ter formatos diferentes.

   Por exemplo, para ações de webhook:

   

   Verifique se o formato especificado ao nível da ação é o esperado. Por exemplo, você pode ter desenvolvido um código que responde a alertas (webhook, função, aplicativo lógico, etc.), esperando um formato, mas mais tarde na ação você ou outra pessoa especificou um formato diferente.

   Adicionalmente, verifique o formato do payload (JSON) dos alertas de registo de atividade, dos alertas de pesquisa de registo (tanto para o Application Insights como para o Log analytics), dos alertas de métricas, do esquema de alertas comuns e dos alertas de métricas clássicas preteridos.

Os resultados da pesquisa não são incluídos nas notificações de alerta de pesquisa de log.

A partir da API de alertas de pesquisa de log versão 2021-08-01, os resultados da pesquisa foram removidos da carga útil da notificação de alerta. Os resultados da pesquisa só estão disponíveis para regras de alerta criadas com versões mais antigas da API (2018-04-16). A criação de novas regras de alerta por meio do portal do Azure irá, por padrão, criar a regra com a versão mais recente. Siga Alterações à experiência de criação de regras de alertas de registo para saber mais sobre as alterações e os ajustes recomendados para utilizar a versão atualizada.

O MetricValue campo contém "null" para notificações de alerta de pesquisa de log resolvidas.

Esta ação é propositada. Os alertas de pesquisa de log com monitoração de 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 causou 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 resultados, o alerta pode ser acionado conforme o 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.

Informações estão faltando em um alerta de registro de atividades

Alertas de 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 e integridade de recursos do serviço ou descobertas do Azure Advisor e da Política do Azure. Se você recebeu um alerta com base no registro de atividades, mas alguns campos necessários estão ausentes ou incorretos, primeiro verifique os eventos no próprio registro de atividades. Se o recurso do Azure não tiver escrito os campos que você está procurando em seu evento de log de atividades, esses campos não serão incluídos no alerta correspondente.

As propriedades personalizadas estão ausentes de notificações por e-mail, SMS ou push.

As propriedades personalizadas só são passadas para a carga útil para ações, como webhook, função do Azure ou aplicativos lógicos. As propriedades personalizadas não estão incluídas nas notificações (e-mail/SMS/push).

A regra de processamento de alertas não está funcionando como esperado

Se conseguir ver um alerta disparado no portal, mas uma regra de processamento de alertas relacionada não tiver funcionado como esperado, siga estes passos:

1. A regra de processamento de alertas está ativada?

   Verifique o campo de status da regra de processamento de alertas 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 não estiver ativada, pode ativar a regra de processamento de alertas selecionando-a e clicando em Ativar.

2. Trata-se de um alerta de estado de funcionamento do 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 do serviço, enquanto os alertas de integridade do serviço estiverem dentro do escopo, a regra de processamento de alertas não os afetará.

3. A regra de processamento de alertas processou o seu alerta?

   Selecione o alerta disparado no portal e veja a guia Histórico para ver se a regra de processamento de alertas foi processada.

   Veja um exemplo de regra de processamento de alertas que suprime todos os grupos de ações:

   

   Veja um exemplo de uma regra de processamento de alertas que adiciona outro grupo de ações:

   

4. O escopo e o filtro da regra de processamento de alertas correspondem ao alerta disparado?

   Se você acha que a regra de processamento de alertas deveria ter disparado, mas não disparou, ou que não deveria ter disparado, mas disparou, examine cuidadosamente o escopo da regra de processamento de alertas e as condições de filtro e compare-as com as propriedades do alerta disparado.

Problemas ao 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 de alerta, siga estas etapas:

1. Verifique as permissões.

   Você deve ter a função interna Colaborador de Monitoramento ou as permissões específicas relacionadas a regras e alertas de processamento de alertas.

2. 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.

Próximos passos

• Resolver problemas de alertas métricos do Azure Monitor
• Solucionar problemas de alertas de pesquisa de log do Azure Monitor