Solucionar problemas de alertas da pesquisa de logs no Azure Monitor

Artigo
10/14/2024

Este artigo descreve como resolver problemas comuns com alertas da pesquisa de logs no Azure Monitor. Ele também fornece soluções para problemas comuns com a funcionalidade e a configuração de alertas de log.

Use os alertas de log para avaliar os logs de recursos a cada frequência definida usando uma consulta do Log Analytics e dispare um alerta com base nos resultados. As regras podem disparar uma ou mais ações usando os Grupo de Ações. Para saber mais sobre a funcionalidade e a terminologia dos alertas de pesquisa de log, consulte Alertas de log no Azure Monitor.

Observação

Este artigo não aborda os casos em que a regra de alerta foi acionada, você pode vê-la no portal do Azure, mas a notificação não foi enviada. Consulte alertas de solução de problemas de casos como esses.

Um alerta de pesquisa de logs não foi acionado quando deveria

Se seu alerta de pesquisa de logs não foi acionado quando deveria, verifique os seguintes itens:

A regra de alerta está em um estado de integridade degradado ou indisponível?

Exiba o status de integridade da regra de alerta de pesquisa de logs:
1. No portal, selecione Monitorar e Alertas.
2. Na barra de comandos superior, selecione Regras de alerta. A página mostra todas as suas regras de alerta em todas as assinaturas.
3. Selecione a regra de alerta de pesquisa de logs que você deseja monitorar.
4. No painel esquerdo, em Ajuda, selecione Integridade do recurso.
Consulte Monitorar a integridade das regras de alerta de pesquisa de log para saber mais.
Verificar a latência de ingestão de log.

O Azure Monitor processa terabytes de logs de clientes de todo o mundo, o que pode causar latência de ingestão de logs.

Os logs são dados semiestruturados e inerentemente mais latentes do que métricas. Em caso de atraso de mais de quatro minutos nos alertas disparados, considere o uso de alertas de métrica. Você pode enviar dados para o repositório de métricas de logs usando alertas de métricas para logs.

Para reduzir a latência, o sistema repete a avaliação do alerta diversas vezes. Depois que os dados chegam, o alerta é disparado, o que não é igual ao tempo de registro do log na maioria dos casos.
As ações foram silenciadas ou a regra de alerta foi configurada para resolver automaticamente?

Um problema comum é que você acha que o alerta não foi acionado, mas a regra foi configurada para que o alerta não fosse acionado. Consulte as opções avançadas da regra de alerta de pesquisa de log para verificar se as duas opções a seguir não foram selecionadas:
- A caixa de seleção Ações de ativar mudo: permite que você ative as ações de alerta ativadas por um tempo definido.
- Resolver alertas automaticamente: configura o alerta para ser acionado apenas uma vez por condição atendida.
O recurso de regra de alerta foi movido ou excluído?

Se um recurso de destino de regra de alerta for movido, renomeado ou excluído, todas as regras de alerta de log referentes a esse recurso serão interrompidas. Para corrigir esse problema, as regras de alerta precisam ser recriadas usando um recurso de destino válido para o escopo.
A regra de alerta usa uma identidade gerenciada atribuída pelo sistema?

Quando você cria uma regra de alerta de log com identidade gerenciada atribuída pelo sistema, a identidade é criada sem nenhuma permissão. Depois de criar a regra, você precisa atribuir as funções apropriadas à identidade da regra para que ela possa acessar os dados que você deseja consultar. Por exemplo, talvez seja necessário dar a ela uma função de Leitura para os workspaces relevantes do Log Analytics ou uma função de Leitura e uma função de Visualizador de banco de dados para o cluster ADX relevante. Confira identidades gerenciadas para obter mais informações sobre como usar identidades gerenciadas em alertas de log.
A consulta usada na regra de alerta de pesquisa de log é válida?

Quando uma regra de alerta de log é criada, a consulta é validada para uma sintaxe correta. Mas, às vezes, a consulta fornecida na regra de alerta de log pode começar a falhar. Alguns motivos comuns são:
- As regras foram criadas pela API e o usuário ignorou a validação.
- A consulta é executada em diversos recursos e um ou mais dos recursos foram excluídos ou movidos.
- A consulta falha porque:
  - Os dados pararam de fluir para uma tabela na consulta por mais de 30 dias.
  - As Tabelas de logs personalizados não foram criadas porque o fluxo de dados não foi iniciado.
- As alterações na linguagem de consulta incluem um formato revisado de comandos e funções, portanto, a consulta fornecida anteriormente não é mais válida.
O Azure Resource Health monitora a integridade de seus recursos de nuvem, incluindo regras de alerta de pesquisa de log. Quando uma regra de alerta de pesquisa de logs está íntegra, a regra é executada e a consulta é executada com sucesso. Você pode usar a integridade do recurso para regras de alerta de pesquisa de log para saber mais sobre os problemas que afetam as regras de alerta de pesquisa de log.
A regra de alerta de pesquisa de log foi desabilitada?

Se uma consulta de regra de alerta de pesquisa de logs não for avaliada continuamente por uma semana, o Azure Monitor a desabilitará automaticamente.

Além disso, há um exemplo do evento Log de atividades que é enviado quando uma regra é desabilitada.

Exemplo de log de atividades quando a regra está desabilitada

{
    "caller": "Microsoft.Insights/ScheduledQueryRules",
    "channels": "Operation",
    "claims": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
    },
    "correlationId": "abcdefg-4d12-1234-4256-21233554aff",
    "description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
    "eventDataId": "f123e07-bf45-1234-4565-123a123455b",
    "eventName": {
        "value": "",
        "localizedValue": ""
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-03-22T04:18:22.8569543Z",
    "id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "level": "Informational",
    "operationId": "",
    "operationName": {
        "value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
    },
    "resourceGroupName": "<Resource Group>",
    "resourceProviderName": {
        "value": "MICROSOFT.INSIGHTS",
        "localizedValue": "Microsoft Insights"
    },
    "resourceType": {
        "value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
        "localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
    },
    "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "status": {
        "value": "Succeeded",
        "localizedValue": "Succeeded"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
    "subscriptionId": "<SubscriptionId>",
    "properties": {
        "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
        "subscriptionId": "<SubscriptionId>",
        "resourceGroup": "<ResourceGroup>",
        "eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
        "eventTimeStamp": "03/22/2019 04:18:22",
        "issueStartTime": "03/22/2019 04:18:22",
        "operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "status": "Succeeded",
        "reason": "Alert has been failing consistently with the same exception for the past week"
    },
    "relatedEvents": []
}

Um alerta de pesquisa de registro foi disparado quando não deveria ter sido

Uma regra de alerta de log do Azure Monitor configurada pode ser disparada inesperadamente. As seções a seguir descrevem alguns motivos comuns.

O alerta foi disparado por causa de problemas de latência?

O Azure Monitor processa terabytes de logs de clientes globalmente, o que pode causar latência de ingestão de logs. Há recursos integrados para evitar alertas falsos, mas eles ainda podem ocorrer em dados muito latentes (acima de cerca de 30 minutos) e com picos de latência.

Os logs são dados semiestruturados e inerentemente mais latentes do que métricas. Se você estiver enfrentando muitos erros nos alertas disparados, considere usar alertas de métrica. Você pode enviar dados para o repositório de métricas a partir de logs usando alertas de métricas para logs.

Os alertas de pesquisa de log funcionam melhor quando você está tentando detectar dados específicos nos logs. Eles são menos eficazes quando você está tentando detectar a falta de dados nos logs, como alertas sobre pulsação de máquina virtual.

Mensagens de erro ao configurar regras de alerta de pesquisa de log

Consulte as seções a seguir para obter mensagens de erro específicas e suas resoluções.

A consulta não pôde ser validada, pois você precisa de permissão para os logs

Se você receber essa mensagem de erro ao criar ou editar sua consulta de regra de alerta, certifique-se de ter permissões para ler os logs dos recursos de destino.

Permissões necessárias para ler os logs no modo de acesso de contexto do espaço de trabalho: Microsoft.OperationalInsights/workspaces/query/read.
Permissões necessárias para ler os logs no modo de acesso de contexto de recurso (incluindo o recurso do Application Insights baseado no espaço de trabalho): Microsoft.Insights/logs/tableName/read.

Consulte Gerenciar o acesso dos espaços de trabalho do Log Analytics para saber mais sobre permissões.

A frequência de um minuto não tem suporte para essa consulta

Há algumas limitações para usar uma frequência de regra de alerta de um minuto. Quando você define a frequência da regra de alerta como um minuto, uma manipulação interna é executada para otimizar a consulta. Essa manipulação poderá fazer com que a consulta falhe se ela contiver operações sem suporte.

Para obter uma lista dos cenários sem suporte, consulte esta nota.

Falha ao resolver a expressão escalar chamada <>

Essa mensagem de erro poderá ser retornada ao criar ou editar sua consulta de regra de alerta se:

Você está referenciando uma coluna que não existe no esquema da tabela.
Você estiver fazendo referência a uma coluna que não foi usada em uma cláusula de projeto anterior da consulta.

Para atenuar isso, você pode adicionar a coluna à cláusula de projeto anterior ou usar o operador columnifexists.

A API ScheduledQueryRules não tem suporte no caso dos Alertas OMS somente de leitura

Essa mensagem de erro é retornada ao tentar atualizar ou excluir as regras criadas com a versão da API herdada usando o portal do Azure.

Edite ou exclua a regra programaticamente usando o Log Analytics API REST.
Recomendado: Atualizar suas regras de alerta para usar a API de Regras de Consulta Agendadas (a API herdada está em um caminho de substituição).

O limite do serviço da regra de alerta foi atingido

Para obter detalhes sobre o número de regras de alerta de pesquisa de log por assinatura e os limites máximos de recursos, veja Limites de serviço do Azure Monitor. Consulte Verifique o número total de regras de alerta de log em uso para ver quantas regras de alerta de métrica estão sendo usadas no momento. Se você atingiu o limite de cota, as etapas a seguir podem ajudar a resolver o problema.

Exclua ou desabilite as regras de alerta de pesquisa de logs que não são mais usadas.
Use divisão por dimensões para reduzir o número de regras. Quando você usa a divisão por dimensões, uma regra pode monitorar muitos recursos.
Se você precisar aumentar o limite de cota, continue para abrir uma solicitação de suporte e forneça as seguintes informações:
- As IDs de assinatura e de recursos para as quais o limite de cota precisa ser aumentado
- O motivo do aumento de cota
- O limite de cota solicitado

Filtragem de tempo incompleta em consultas do ARG e do ADX

Ao usar consultas do ADX (Azure Data Explorer) ou do ARG (Azure Resource Graph) em alertas de pesquisa de log, você pode encontrar um problema em que a configuração "Granularidade de agregação" não aplica um filtro de tempo às suas consultas. Isso pode levar a resultados inesperados e possíveis problemas de desempenho, pois a consulta retorna todos os 30 dias, em vez do intervalo de tempo pretendido.

Para resolver esse problema, você precisa aplicar explicitamente filtros de tempo em suas consultas do ARG e do ADX. Aqui estão as etapas a serem asseguradas:

Filtragem de tempo adequada: identifique o intervalo de tempo: determine o intervalo de tempo específico que você deseja consultar. Por exemplo, se você quiser consultar dados das últimas 24 horas, precisará especificar esse intervalo de tempo em sua consulta.
Modifique a consulta: adicione um filtro de tempo à consulta do ARG ou do ADX para limitar os dados retornados ao intervalo de tempo desejado. Aqui está um exemplo de como modificar sua consulta:

    // Original query without time filter
    resources
    | where type == "microsoft.compute/virtualmachines"

    // Modified query with time filter
    resources
    | where type == "microsoft.compute/virtualmachines"
    | where timestamp >= ago(24h)

Teste a consulta: execute a consulta modificada para garantir que ela retorne os resultados esperados dentro do intervalo de tempo especificado.
Atualize os alertas: atualize os alertas de pesquisa de logs para usar a consulta modificada com o filtro de tempo explícito. Isso garantirá que seus alertas sejam baseados nos dados corretos e não incluam dados históricos desnecessários. Aplicando filtros de tempo explícitos em suas consultas do ARG e do ADX, você pode evitar o problema de recuperar dados excessivos e garantir que os alertas de pesquisa de log sejam precisos e eficientes.

Próximas etapas

Saiba mais sobre os alertas de log no Azure.
Saiba mais sobre como configurar os alertas de log.
Saiba mais sobre consultas de log.

Compartilhar via