KQL e Azure Monitor para IA: logs, painéis, Pastas de Trabalho e alertas
Transforme a telemetria do Application Insights em investigações, painéis operacionais, Pastas de Trabalho interativas e alertas proativos para pipelines distribuídos de IA.
Tempo de estudo sugerido: 120 minutos • Nível intermediário • Reescrita autoral completa com versão resumida de cada tópico, avaliação comentada e laboratório guiado
Por João Ricardo Dutra••Conteúdo autoral completo
1. Cenário e objetivos de aprendizagem
Um corporativo de moderação recebe documentos por uma de , classifica o conteúdo com um modelo, extrai entidades e verifica violações de política. Alguns documentos ultrapassam 30 segundos, certos formatos fazem a moderação falhar e os usuários descobrem incidentes antes da equipe de operações. O estado desejado reúne a saúde do , alerta a equipe em até cinco minutos após um pico de falhas e permite investigar por período, serviço e tipo de documento.
Recuperar e analisar telemetria do com KQL.
Encontrar padrões de erro, gargalos em dependências e tendências de desempenho.
Criar um painel do compartilhado para acompanhamento operacional.
Montar Pastas de Trabalho do orientadas por parâmetros.
Configurar regras de alerta, grupos de ação e detecção de anomalias.
Resumo rápido
O desenho de monitoramento deve conduzir dados brutos até perguntas, contexto visual, diagnóstico interativo e resposta oportuna.
2. KQL e a experiência de consulta do
A KQL (Linguagem de Consulta Kusto) é usada nos do , no Analytics e no . A consulta parte de uma fonte tabular e envia o resultado por operadores separados pelo caractere pipe. Cada etapa recebe a tabela anterior, transforma-a e produz outra tabela, o que torna a lógica legível de cima para baixo.
O Analytics no oferece preenchimento automático, destaque de sintaxe, seleção de tempo, resultados tabulares e gráficos. Ele pode ser aberto pelo , por um recurso do ou por um do Analytics. O escopo escolhido determina os recursos, os esquemas e os aliases de tabela disponíveis.
Cada operador do pipe executa uma transformação explícita e deixa a investigação fácil de ler e adaptar.
Resumo rápido
KQL é um de transformações tabulares: defina o escopo e componha uma operação analítica clara por etapa.
3. Tabelas do e campos de correlação
Telemetria principal e onde investigá-la
Tabela no
Tabela no
Finalidade
AppRequests
Operações recebidas, duração, código de resposta e sucesso.
dependencies
AppDependencies
Chamadas externas a bancos, , serviços do , modelos, bases vetoriais e microsserviços.
exceptions
AppExceptions
Erros tratados e não tratados, mensagens, tipos e pilhas.
AppTraces
Mensagens de da aplicação produzidas por compatíveis.
customEvents
AppEvents
Eventos de negócio explícitos, como documento classificado ou moderação sinalizada.
customMetrics
AppMetrics
Medições da aplicação, como profundidade de fila ou confiança.
performanceCounters
AppPerformanceCounters
CPU, memória, E/S e outros contadores do host.
Consultas no escopo do recurso do costumam expor nomes curtos; consultas no usam nomes iniciados por App. O contexto compartilhado é mais importante que o alias: timestamp posiciona o evento, operation_Id conecta uma operação distribuída, cloud_RoleName identifica o serviço emissor, customDimensions guarda contexto próprio e itemCount informa quantos eventos uma linha amostrada representa.
Resumo rápido
Escolha a tabela pelo tipo de telemetria e preserve operation_Id, cloud_RoleName, customDimensions e itemCount para correlacionar e contar corretamente.
4. Filtrar, selecionar, inspecionar e ordenar linhas
Use where para condições, project para limitar e nomear o esquema de saída, take para uma amostra arbitrária e top quando a ordem importa. Comparações exatas usam ==, !=, > e <. Em texto, has aproveita o índice de termos e costuma ser melhor para palavras inteiras; contains busca substring e pode custar mais em grande escala; startswith compara o prefixo. Combine condições com and e or.
requests
| where timestamp > ago(1h)
| where success == false
| project timestamp, name, resultCode, duration, cloud_RoleName
| top 20 by duration desc
A consulta limita o período, mantém falhas, expõe os campos necessários ao responsável e devolve as vinte ocorrências mais lentas. Uma projeção deliberada também impede que dimensões irrelevantes ou sensíveis se espalhem por exportações e blocos de painel.
Resumo rápido
Filtre cedo, projete apenas campos diagnósticos e prefira top a take quando a pergunta contiver “maior”, “mais lento” ou “mais recente”.
5. Agregar tendências com summarize, bin e percentis
summarize transforma linhas individuais em evidência por grupos. count(), sum(), avg(), min() e max() respondem totais e estatísticas comuns. dcount() estima valores distintos com eficiência; count_distinct() é exato, porém mais pesado. percentile() revela a cauda de latência ocultada pela média.
Datas normalmente devem ser agrupadas com bin(). Sem um intervalo fixo, timestamps em milissegundos fragmentam a série em quase um grupo por evento. As colunas depois de by definem a granularidade do resultado.
summarize define a pergunta, bin define a granularidade temporal e os percentis revelam a cauda lenta suavizada pelas médias.
6. Visualizar uma consulta com render
render acrescenta uma orientação visual ao resultado. timechart é adequado a métricas agrupadas no tempo; barchart e columnchart comparam categorias; piechart mostra uma distribuição proporcional com poucas categorias; areachart enfatiza movimento acumulado ou empilhado. O painel de resultados permite trocar o gráfico, mas manter render na consulta salva preserva a apresentação ao compartilhar ou fixar.
Associe o formato dos dados à visualização
Pergunta
Visual recomendado
Como o p95 muda no tempo?
timechart
Qual serviço concentra falhas?
barchart
Qual a participação das requisições por serviço?
piechart com poucas categorias
Quais são as falhas exatas mais recentes?
tabela/grade
Resumo rápido
O gráfico só ajuda quando eixos e categorias correspondem ao formato do resultado; render registra essa intenção.
7. Investigar exceções sem perder o volume amostrado
Comece medindo o alcance: quando a taxa mudou, quais exceções dominam e quais operações foram afetadas? Com amostragem de , count() conta linhas armazenadas, não necessariamente eventos reais. sum(itemCount) recompõe o volume representado e é a agregação correta para totais amostrados.
exceptions
| where timestamp > ago(24h)
| summarize exceptionCount = sum(itemCount)
by bin(timestamp, 1h), type
| render timechart
exceptions
| where timestamp > ago(24h)
| summarize exceptionCount = sum(itemCount)
by type, operation_Name
| top 10 by exceptionCount desc
O gráfico temporal mostra o início e o formato do pico; o ranking o reduz a um tipo de exceção e operação. Em um documental, pode ficar evidente que se concentram em um de classificação, e não em todos os serviços.
Resumo rápido
Use sum(itemCount) para o volume amostrado e avance do instante do pico para o tipo de exceção e a operação afetada.
8. Correlacionar requisições e exceções com operation_Id
Uma falha distribuída raramente é explicada por uma tabela. operation_Id é a chave que liga , dependencies, exceptions e da mesma transação. Projete só o necessário e renomeie colunas repetidas dentro de cada ramo antes do join; caso contrário, a KQL adiciona sufixos aos nomes ambíguos.
A linha combinada mostra se a exceção pertenceu a uma requisição visível ao usuário, quanto ela durou e qual função de nuvem a atendeu. Exceções de processos em segundo plano sem correspondente exigem outra estratégia, como leftouter, e não devem ser interpretadas como inexistentes.
Resumo rápido
operation_Id reconstrói o incidente entre tabelas; projete e renomeie antes do join para manter a correlação inequívoca.
9. Analisar latência e falhas de dependências
A tabela dependencies costuma ser o caminho mais curto até um gargalo de IA, pois inferência, embeddings, busca vetorial, armazenamento, bancos e posteriores aparecem como chamadas externas. Compare mediana, p95 e p99 por destino e tipo; depois examine separadamente chamadas malsucedidas por código e serviço de origem.
dependencies
| where timestamp > ago(24h)
| summarize averageDuration = avg(duration),
p50 = percentile(duration, 50),
p95 = percentile(duration, 95),
p99 = percentile(duration, 99)
by target, type
| order by p95 desc
dependencies
| where timestamp > ago(24h) and success == false
| summarize failureCount = sum(itemCount)
by target, resultCode, cloud_RoleName
| order by failureCount desc
Interprete o código no contexto: 429 normalmente indica limitação ou throughput esgotado; 5xx aponta falha do servidor dependente; código ausente com duração longa pode sugerir , conectividade ou saturação. Percentis distinguem degradação geral de uma cauda lenta.
Resumo rápido
Ordene dependências pela latência de cauda e segmente falhas por destino, código e serviço para decidir entre capacidade, repetição e confiabilidade.
10. Falhas, Desempenho e diagnóstico de transação
As visões internas do complementam consultas próprias. Falhas agrupa operações malsucedidas e expõe códigos, exceções, dependências com erro e amostras. Ao selecionar uma amostra, o diagnóstico de transação mostra, em ordem cronológica, a requisição, as dependências, as exceções e os .
Desempenho ordena operações por duração ou volume e mostra a distribuição dos tempos. Uma distribuição dividida ou bimodal pode revelar que um tipo de documento segue um caminho muito mais lento, mesmo com média aceitável. Use as visões prontas para orientação e KQL para joins, dimensões próprias, agregações especiais ou visual reutilizável.
Resumo rápido
As visões prontas localizam a área e uma transação concreta; KQL testa a hipótese em todo o conjunto de dados.
11. Painéis do para consciência operacional
Um painel do é uma superfície compartilhada e relativamente estática de blocos no . Ele combina métricas, resultados de consultas, Markdown e recursos de diferentes assinaturas ou grupos. Sua função é responder “o sistema está saudável agora?” no acompanhamento diário, em reuniões ou telas operacionais.
Tempo de resposta do servidor e percentis de latência.
Requisições e dependências com falha.
Taxa de requisições e throughput.
Sucesso dos testes de disponibilidade.
Poucos sinais de negócio, como documentos processados ou decisões de moderação.
Escolha a agregação conscientemente: média descreve a latência típica, soma totaliza eventos no período e máximo expõe extremos. Use filtros ou divisão por função, operação ou código quando for necessário separar serviços.
Resumo rápido
O painel é uma superfície operacional enxuta, baseada em sinais estáveis de saúde, e não uma tela ilimitada de investigação.
12. Fixar resultados KQL e projetar um painel utilizável
Execute a consulta em , selecione o gráfico e fixe-o em um painel novo ou existente. Uma distância crescente entre p50 e p95 significa que a maioria permanece rápida enquanto uma cauda relevante piora. Os blocos atualizam periodicamente, não em fluxo contínuo; para um incidente ativo, use Métricas ao Vivo ou uma visão interativa com período menor.
Mantenha cerca de cinco a dez blocos orientados a decisões.
Separe saúde técnica de resultados de negócio se ambos sobrecarregarem a mesma tela.
Agrupe latência, confiabilidade, throughput e disponibilidade em uma ordem previsível.
Use títulos explícitos, como “Latência p95 da Classificação”.
Inclua Markdown com proprietário, runbooks e contatos de escalonamento.
Publicar compartilha o painel, mas o do continua valendo para o painel e para cada fonte. Quem não pode ler o recebe erro de autorização nos blocos correspondentes.
Resumo rápido
Fixe consultas prontas para decisão, explique o propósito e teste permissões tanto no painel quanto nas fontes.
13. Pastas de Trabalho do como relatórios interativos
As Pastas de Trabalho do combinam texto, consultas de , métricas, parâmetros e visualizações em um relatório reutilizável. Diferentemente do painel, uma pasta responde “por que o sistema está assim?”: o usuário muda escopo, tempo e filtros, e as etapas dependentes são executadas novamente.
O painel detecta a condição; a Pasta de Trabalho permite mudar o contexto e seguir as evidências até a causa.
A pasta é construída verticalmente com etapas de texto, consulta, métricas e parâmetros. Resultados podem aparecer como grades, linhas, barras, blocos ou mapas. Modelos Microsoft de desempenho, falhas e uso podem ser adaptados, ou o relatório pode começar vazio.
Resumo rápido
Painéis monitoram; Pastas de Trabalho investigam por uma narrativa parametrizada de dados e explicações.
14. Parâmetros, visibilidade condicional e detalhamento
O parâmetro de intervalo de tempo coordena o período. Listas suspensas podem ser estáticas ou preenchidas por KQL, por exemplo com valores distintos de cloud_RoleName. O seletor de recursos alterna entre recursos do ou workspaces. A seleção múltipla alimenta o operador in para comparar serviços escolhidos.
Prefira o nativo de tempo para receber um predicado seguro. A sintaxe depende do controle e do formato escolhido na Pasta de Trabalho; confira o valor gerado antes de injetá-lo em KQL. Visibilidade condicional esconde detalhes até a seleção de um serviço. Um link na grade pode abrir o diagnóstico da transação, outra pasta ou exportar a linha selecionada como parâmetro.
Comece pela saúde geral do .
Disponibilize filtros de tempo e serviço no topo.
Faça uma grade de resumo alimentar um parâmetro.
Revele pilhas e linhas de dependência sob demanda.
Limite consultas, pois cada mudança pode reexecutá-las.
Resumo rápido
Parâmetros coordenam o escopo; grades vinculadas e etapas condicionais transformam o resumo em investigação focalizada.
15. Anatomia, tipos e severidade das regras de alerta
Uma regra de alerta do reúne escopo, condição, ações e severidade. O escopo seleciona recursos; a condição define sinal e disparo; grupos de ação notificam pessoas ou chamam automações; severidade comunica urgência de 0 Crítico a 4 Detalhado.
Escolha o mecanismo
Tipo
Uso indicado
Alerta de métrica
Métrica pré-calculada e limiar simples ou dinâmico.
Alerta de pesquisa de
Lógica KQL, agregações, joins, dimensões próprias ou avaliação agendada.
Alerta simples de pesquisa de
Cada evento de correspondente precisa de resposta rápida.
Alerta de detecção inteligente
Anomalia aprendida difícil de expressar em um limite estático.
Padronize severidades: interrupção em produção no nível 0, impacto funcional significativo no 1, risco emergente no 2, informação relevante no 3 e diagnóstico detalhado no 4. A severidade deve controlar roteamento e resposta, não apenas a cor no portal.
Resumo rápido
Um bom alerta identifica o que é observado, qual evidência constitui problema, quem ou o que responde e com qual urgência.
16. Criar alertas acionáveis de pesquisa de
Um alerta agendado possui três controles temporais: frequência de avaliação define quando a KQL executa; tamanho da janela define quantos dados entram; quantidade de violações define quantas avaliações precisam falhar. Eles equilibram velocidade, custo e resistência a ruído transitório.
// Failure-volume alert: return a row for every affected service.
requests
| where success == false
| summarize failedCount = sum(itemCount) by cloud_RoleName
| where failedCount > 10
// Latency-SLO alert: detect a p95 above three seconds.
requests
| summarize p95Duration = percentile(duration, 95)
by cloud_RoleName
| where p95Duration > 3s
Para falhas, use janela e frequência de cinco minutos e dispare quando houver mais de zero linhas; cada linha indica um serviço com mais de dez falhas. Para latência, p95 acima de três segundos protege a experiência dos 5% mais lentos melhor que a média. Devolva contexto suficiente, mas mantenha a consulta determinística e compatível com as restrições de alertas.
Resumo rápido
A consulta deve devolver apenas violações acionáveis; frequência, janela e número de violações controlam sensibilidade e ruído.
17. Grupos de ação e detecção automática de anomalias
Grupos de ação são conjuntos reutilizáveis de destinatários e automações. Notificações incluem email, SMS, push e voz. Ações podem chamar ,,, Runbooks de , ou integrações de incidentes. Um alerta pode acionar vários grupos, e o mesmo grupo pode servir a muitas regras.
Separe o roteamento crítico dos avisos: um grupo crítico pode chamar o plantonista e criar incidente; um grupo de aviso pode enviar email à equipe. Teste os grupos antes da produção e adote o esquema comum de alertas quando a automação precisar de estável.
A detecção inteligente aprende a linha de base e encontra comportamentos anormais. Anomalias de falha agrupam operações, usuários, exceções e dependências afetadas; anomalias de desempenho capturam mudanças graduais em latência ou volume. Regras manuais garantem conhecidos; a detecção procura desvios inesperados.
Limites conhecidos e anomalias aprendidas convergem para caminhos reutilizáveis de notificação e correção.
Resumo rápido
Padronize a resposta com grupos de ação, imponha limites conhecidos com regras e cubra desvios novos com detecção inteligente.
18. Laboratório guiado: consultar telemetria e criar alerta
O exercício provisiona , gera telemetria de , dependencies e exceptions em Python com OpenTelemetry, investiga em e cria um grupo de ação e uma regra agendada. Requer assinatura do ,, Python 3.12 ou superior e atualizada.
Crie grupo de recursos e ; mantenha a cadeia de conexão fora do repositório.
Execute um gerador para caminhos bem-sucedidos, lentos, com falha de dependência e com exceção.
Aguarde a e confirme dados nas três tabelas.
Consulte falhas e use sum(itemCount) para totais amostrados.
Una exceções a requisições por operation_Id.
Calcule p50, p95 e p99 das dependências e segmente falhas por destino e código.
Crie e teste um grupo de ação.
Crie alerta agendado com escopo, janela, frequência, limiar, severidade e grupo explícitos.
Provoque a condição e confirme o alerta disparado e a notificação.
az monitor app-insights component create \
--app ai200-telemetry --location <region> \
--resource-group <resource-group>
# After generating request, dependency, and exception telemetry,
# create an action group and a scheduled-query alert rule.
az monitor action-group create \
--name ai200-oncall --resource-group <resource-group> \
--short-name ai200
# Use the portal wizard or az monitor scheduled-query create with
# the Application Insights resource ID, KQL condition, window,
# frequency, severity, and action-group resource ID.
Resumo rápido
O laboratório termina quando a telemetria sustenta um diagnóstico correlacionado e um alerta provocado chega ao destinatário testado.
19. Avaliação comentada, checklist e referências
Respostas da avaliação
sum(itemCount) produz o total de exceções consciente da amostragem.
operation_Id liga a telemetria de uma transação distribuída.
Pastas de Trabalho do permitem filtrar interativamente por tempo, serviço e erro.
O limiar de linhas maior que zero dispara quando qualquer serviço devolve uma linha com mais de dez falhas.
percentile(duration, 95) representa o limite experimentado pelos 5% mais lentos.
Checklist de produção
Documente nomes de tabela por recurso e por .
Use operadores de texto indexados quando a semântica permitir.
Preserve a precisão da amostragem com itemCount.
Correlacione tabelas antes de atribuir causa.
Monitore cauda de latência e códigos das dependências.
Mantenha painéis pequenos, nomeados e com permissões testadas.
Projete Pastas de Trabalho em torno de perguntas e parâmetros.
Ajuste alertas a , persistência, roteamento e contexto.
Maturidade operacional combina KQL consciente de amostragem, correlação, painéis focados, Pastas de Trabalho interativas e alertas com resposta testada.
