Solucionar problemas de alertas de pesquisa de log no Azure Monitor
Este artigo descreve como resolver problemas comuns com alertas de pesquisa de log no Azure Monitor. Ele também fornece soluções para problemas comuns com a funcionalidade e configuração de alertas de log.
Você pode usar alertas de log para avaliar recursos, registra cada frequência definida usando uma consulta do Log Analytics e disparar um alerta baseado nos resultados. As regras podem acionar uma ou mais ações usando Grupos de Ação. Para saber mais sobre a funcionalidade e a terminologia dos alertas de pesquisa de log, consulte Alertas de log no Azure Monitor.
Nota
Este artigo não discute 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 para casos como estes.
Um alerta de pesquisa de log não foi acionado quando deveria
Se o alerta de pesquisa de log 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 log:
Na barra de comandos superior, selecione Regras de alerta. A página mostra todas as suas regras de alerta em todas as subscrições.
Selecione a regra de alerta de pesquisa de log que você deseja monitorar.
No painel esquerdo, em Ajuda, selecione Estado de funcionamento do recurso.
Consulte Monitorar a integridade das regras de alerta de pesquisa de log para saber mais.
Verifique a latência de ingestão do 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 são inerentemente mais latentes do que as métricas. Se você estiver com um atraso de mais de 4 minutos nos alertas disparados, considere o uso de alertas métricos. Você pode enviar dados para o armazenamento de métricas a partir de logs usando alertas de métrica para logs.
Para reduzir a latência, o sistema tenta novamente a avaliação do alerta várias vezes. Depois que os dados chegam, o alerta é acionado, o que na maioria dos casos não equivale ao tempo de registro de log.
As ações estão silenciadas ou a regra de alerta foi configurada para ser resolvida automaticamente?
Um problema comum é que você acha que o alerta não disparou, mas a regra foi configurada para que o alerta não disparasse. Consulte as opções avançadas da regra de alerta de pesquisa de log para verificar se ambas as opções a seguir não estão selecionadas:
- A caixa de seleção Silenciar ações : permite silenciar ações de alerta disparadas por um determinado período de tempo.
- Resolver alertas automaticamente: configura o alerta para disparar 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 ao sistema?
Quando você cria uma regra de alerta de log com identidade gerenciada atribuída ao sistema, a identidade é criada sem permissões. 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 atribuir a ele uma função de Leitor para os espaços de trabalho relevantes do Log Analytics ou uma função de Leitor e uma função de Visualizador de Banco de Dados para o cluster ADX relevante. Consulte 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 a sintaxe correta. Mas, às vezes, a consulta fornecida na regra de alerta de log pode começar a falhar. Algumas razões comuns são:
- As regras foram criadas por meio da API e o usuário ignorou a validação.
- A consulta é executada em vários 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 personalizadas não foram criadas porque o fluxo de dados não foi iniciado.
- As alterações na linguagem de consulta incluem um formato revisado para comandos e funções, portanto, a consulta fornecida anteriormente não é mais válida.
O Azure Resource Health monitoriza o estado de funcionamento dos seus recursos na nuvem, incluindo regras de alerta de pesquisa de registo. Quando uma regra de alerta de pesquisa de log está íntegra, a regra é executada e a consulta é executada com êxito. Você pode usar a integridade dos recursos para regras de alerta de pesquisa de log para saber mais sobre os problemas que afetam suas regras de alerta de pesquisa de log.
A regra de alerta de pesquisa de log foi desativada?
Se uma consulta de regra de alerta de pesquisa de log não for avaliada continuamente por uma semana, o Azure Monitor a desativará automaticamente.
Além disso, há um exemplo do evento Registro 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 log disparado quando não deveria ter
Uma regra de alerta de log configurada no Azure Monitor pode ser acionada inesperadamente. As seções a seguir descrevem alguns motivos comuns.
O alerta foi acionado devido a 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. Existem recursos internos para evitar alertas falsos, mas eles ainda podem ocorrer em dados muito latentes (mais de ~30 minutos) e dados com picos de latência.
Os logs são dados semiestruturados e são inerentemente mais latentes do que as métricas. Se você estiver enfrentando muitas falhas de ignição em alertas disparados, considere o uso de alertas métricos. Você pode enviar dados para o armazenamento de métricas a partir de logs usando alertas de métrica para logs.
Os alertas de pesquisa de log funcionam melhor quando você está tentando detetar dados específicos nos logs. Eles são menos eficazes quando você está tentando detetar a falta de dados nos logs, como alertar sobre a pulsação da máquina virtual.
Mensagens de erro ao configurar regras de alerta de pesquisa de log
Consulte as seções a seguir para 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 receber esta mensagem de erro ao criar ou editar a consulta da regra de alerta, certifique-se de que tem permissões para ler os registos de recursos de destino.
- Permissões necessárias para ler logs no modo de acesso de contexto do espaço de trabalho:
Microsoft.OperationalInsights/workspaces/query/read. - Permissões necessárias para ler logs no modo de acesso de contexto de recurso (incluindo recurso do Application Insights baseado em espaço de trabalho):
Microsoft.Insights/logs/tableName/read.
Consulte Gerenciar acesso a espaços de trabalho do Log Analytics para saber mais sobre permissões.
A frequência de um minuto não é suportada para esta consulta
Existem algumas limitações para utilizar uma frequência de regra de alerta de um minuto. Quando define a frequência da regra de alerta para um minuto, é realizada uma manipulação interna para otimizar a consulta. Esta manipulação pode fazer com que a consulta falhe se contiver operações não suportadas.
Para obter uma lista de cenários sem suporte, consulte esta nota.
Falha ao resolver a expressão escalar nomeada <>
Essa mensagem de erro pode ser retornada ao criar ou editar sua consulta de regra de alerta se:
- Está referenciar uma coluna que não existe no esquema da tabela.
- Você está 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 do projeto anterior ou usar o operador columnifexists .
A API ScheduledQueryRules não é suportada para alertas OMS somente leitura
Essa mensagem de erro é retornada ao tentar atualizar ou excluir regras criadas com a versão herdada da API usando o portal do Azure.
- Edite ou exclua a regra programaticamente usando a API REST do Log Analytics.
- Recomendado: atualize suas regras de alerta para usar a API de Regras de Consulta Agendada (a API herdada está em um caminho de descontinuação).
O limite de 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 limites máximos de recursos, consulte Limites de serviço do Azure Monitor. Consulte Verificar o número total de regras de alerta de log em uso para ver quantas regras de alerta de métrica estão em uso no momento. Se você atingiu o limite de cota, as etapas a seguir podem ajudar a resolver o problema.
Elimine ou desative as regras de alerta de pesquisa de registos que já não são utilizadas.
Use a 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 que o limite de cota seja aumentado, continue a abrir uma solicitação de suporte e forneça as seguintes informações:
- As IDs de Assinatura e as IDs de Recursos para as quais o limite de cota precisa ser aumentado
- A razão para o aumento das quotas
- O limite de quota solicitado
Filtragem de tempo incompleta em consultas ARG e ADX
Ao usar consultas do Azure Data Explorer (ADX) ou do Azure Resource Graph (ARG) 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 ARG e ADX. Aqui estão os passos para garantir:
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.
Modificar a consulta: adicione um filtro de tempo à sua consulta ARG ou 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)
- Testar a consulta: execute a consulta modificada para garantir que ela retorne os resultados esperados dentro do intervalo de tempo especificado.
- Alertas de atualização: atualize seus alertas de pesquisa de log 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. Ao aplicar filtros de tempo explícitos em suas consultas ARG e ADX, você pode evitar o problema de recuperar dados excessivos e garantir que seus alertas de pesquisa de log sejam precisos e eficientes.
Próximos passos
- Saiba mais sobre alertas de log no Azure.
- Saiba mais sobre como configurar alertas de log.
- Saiba mais sobre consultas de log.