Fundamentos do Log Analytics e KQL

Um espaço de trabalho do Log Analytics é o repositório central de dados do Azure Monitor para dados de registros e telemetria. Quando você configura as configurações de diagnóstico em um recurso do Azure, os registros estruturados e as métricas são enviados para o espaço de trabalho. Em seguida, você pode consultar os dados usando a Kusto Query Language (KQL). Um espaço de trabalho tem sua própria política de retenção (30 dias por padrão, até 730 dias) e seus próprios controles de acesso.

Todo recurso do Azure pode emitir registros de diagnóstico — registros detalhados de operações como chamadas de API, eventos de autenticação e execução de consultas. Você os habilita por meio das Configurações de diagnóstico no recurso, especificando o destino como seu espaço de trabalho do Log Analytics. As categorias comuns de registros incluem AuditEvent para Key Vault, AppServiceHTTPLogs para App Service e NetworkSecurityGroupFlowEvent para NSGs.

A Kusto Query Language (KQL) é uma linguagem de consulta somente leitura para analisar dados de registros. Uma consulta KQL é lida da esquerda para a direita como uma cadeia: começa com um nome de tabela e, em seguida, passa pelo pipe (|) por meio de operadores. Entre os operadores comuns estão where para filtragem, project para selecionar colunas, summarize para agregação e order by para ordenação. O KQL diferencia maiúsculas de minúsculas nos nomes de colunas, mas não nas palavras-chave.

O operador where filtra linhas usando expressões booleanas. Você pode combinar condições com and, or e not. O operador has realiza uma pesquisa que não diferencia maiúsculas de minúsculas e respeita os limites das palavras em cadeias de caracteres, enquanto contains faz uma pesquisa por substring. O operador in testa a associação a uma lista. Use ago() para expressar intervalos de tempo relativos, como ago(1h) ou ago(7d).

O operador summarize calcula agregações entre linhas. As funções de agregação comuns incluem count(), sum(), avg(), max(), min() e dcount() para contagem distinta. Você pode agrupar por uma ou mais colunas usando a cláusula by. A função bin() arredonda os carimbos de data e hora para intervalos, permitindo a agregação de séries temporais.

O KQL é compatível com join para correlacionar dados de várias tabelas. O tipo de junção padrão é innerunique, mas você pode especificar inner, leftouter, rightouter ou fullouter. Um padrão comum é unir AzureActivity a AzureMetrics para correlacionar alterações administrativas com quedas de desempenho. O operador lookup é uma alternativa mais leve para enriquecer linhas usando uma pequena tabela de referência.

Depois de escrever uma consulta no portal do Log Analytics, você pode renderizar os resultados como um gráfico temporal, gráfico de barras, gráfico de pizza ou tabela usando o operador render. Você também pode fixar qualquer resultado de consulta em um painel do Azure ou salvá-lo como uma pasta de trabalho. O comando render timechart transforma uma consulta de séries temporais com summarize em um gráfico de linhas instantâneo para análise de tendências.

Os alertas de pesquisa de registros executam uma consulta KQL segundo uma programação e são acionados quando o resultado atende a uma condição, como uma contagem de resultados maior que zero ou uma coluna numérica que excede um limite. Eles são mais flexíveis que os alertas de métricas, pois permitem consultar quaisquer dados de registros em várias tabelas. A frequência de avaliação e a janela de tempo são configuráveis de forma independente — por exemplo, executar a cada 5 minutos considerando os últimos 15 minutos.

O Azure Monitor armazena registros em tabelas conhecidas. AzureActivity registra operações no nível da assinatura. SecurityEvent contém registros de segurança do Windows provenientes de VMs com o agente do Log Analytics. Heartbeat mostra a conectividade do agente (uma linha por minuto para cada VM conectada). AppRequests, AppExceptions e AppDependencies vêm do Application Insights. Conhecer esses nomes de tabela é essencial para escrever consultas operacionais eficazes.

A precificação do Log Analytics tem dois componentes: ingestão de dados (por GB ingerido) e retenção de dados (os primeiros 30 dias são gratuitos; depois, é cobrado um valor por GB por mês além do padrão). Você pode reduzir os custos filtrando categorias de registros ruidosas antes da ingestão, usando Basic Logs para dados de alto volume e baixo valor a um preço reduzido e arquivando dados antigos no Azure Data Explorer ou em armazenamento frio para retenção de conformidade de longo prazo.

Os espaços de trabalho do Log Analytics são compatíveis com dois modelos de controle de acesso. No modo workspace-context, um usuário com acesso de Leitura ao espaço de trabalho pode consultar todas as tabelas. No modo resource-context, um usuário pode consultar apenas os registros emitidos pelos recursos que ele tem permissão RBAC para ler — mesmo sem acesso explícito ao espaço de trabalho. O modo resource-context é recomendado para organizações grandes nas quais equipes diferentes são responsáveis por recursos diferentes.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que os espaços de trabalho do Log Analytics centralizam dados de registros de diagnóstico dos recursos do Azure, que os operadores do KQL, como where, summarize e render, permitem filtrar, agregar e visualizar registros, e que os alertas de pesquisa de registros acionam respostas automatizadas quando o resultado de uma consulta KQL atende a uma condição definida. A seguir, exploraremos o Application Insights para obter telemetria no nível da aplicação.