Application Insights

Este guia ensina a usar o Application Insights, recurso do Azure Monitor, para acompanhar saúde, desempenho, falhas, logs e comportamento de aplicações. A ideia é servir tanto para quem está abrindo a ferramenta pela primeira vez quanto para quem precisa de uma cola rápida durante uma investigação.

[!NOTE] As imagens desta página são diagramas próprios criados para a Wiki. Elas não são screenshots reais do Azure Portal, porque isso exigiria acesso ao tenant e ao recurso específico da empresa. Os nomes das telas podem mudar um pouco conforme a Microsoft atualiza o Portal.

O que é o Application Insights

O Application Insights é uma ferramenta de observabilidade de aplicações. Ele recebe telemetria gerada pelo sistema e ajuda a responder perguntas como:

• O sistema está funcionando agora?
• Quantas requisições deram erro?
• Qual endpoint está lento?
• Qual dependência externa falhou?
• Qual exception foi lançada?
• O problema aconteceu depois de um deploy?
• O erro afetou todos os usuários ou apenas um fluxo?
• A API, o banco, a fila ou outro serviço externo está causando a lentidão?

Na prática, ele junta vários tipos de dados:

Como pensar nele

Pense em três camadas:

1. Coleta: a aplicação usa SDK, OpenTelemetry ou agente para enviar telemetria.
2. Armazenamento: a telemetria vai para um recurso Application Insights associado a um Log Analytics workspace.
3. Investigação: você usa telas prontas, gráficos, logs KQL, alertas e workbooks para entender o que aconteceu.

Os recursos novos recomendados pela Microsoft são workspace-based, ou seja, armazenam os dados em um Log Analytics workspace. Isso facilita consulta, retenção, controle de acesso, alertas e integração com outros dados do Azure Monitor.

Acesso no Portal Azure

O caminho mais comum é:

1. Acesse o Azure Portal.
2. Pesquise por Application Insights.
3. Abra o recurso da aplicação desejada.
4. Use o menu lateral para alternar entre Overview, Logs, Failures, Performance, Live Metrics, Application Map, Availability, Metrics, Alerts e Workbooks.

Também é possível acessar pelo recurso da aplicação, como App Service, Function App ou Container App, quando ele está conectado ao Application Insights.

Visão geral das telas principais

Pesquisar x Logs

As duas telas investigam dados, mas resolvem problemas diferentes.

Regra prática:

• Comece por Failures ou Performance se o problema for claro: erro ou lentidão.
• Use Pesquisar para abrir uma ocorrência específica e navegar pela transação.
• Use Logs quando precisar cruzar, contar, agrupar, comparar períodos ou montar evidência.

Conceitos essenciais

Connection string

A connection string identifica para onde a telemetria será enviada. Ela substituiu o uso isolado da instrumentation key em configurações modernas.

Boa prática:

• Em produção, configure por variável de ambiente, por exemplo APPLICATIONINSIGHTS_CONNECTION_STRING.
• Não grave connection string diretamente no código-fonte.
• Use uma connection string por ambiente quando precisar separar Desenvolvimento, Homologação e Produção.

Instrumentation key

A instrumentation key ainda aparece em muitos materiais e recursos legados. Ela identifica o recurso do Application Insights, mas a recomendação atual é usar a connection string, porque ela também carrega endpoints e fica mais adequada para cenários com regiões e configurações modernas.

Operação, correlação e transaction

Uma requisição normalmente gera vários itens:

• request de entrada;
• logs/traces;
• chamadas HTTP externas;
• consultas SQL;
• mensagens em fila;
• exceptions;
• eventos customizados.

O Application Insights tenta correlacionar esses itens por campos como OperationId, ParentId e contexto distribuído. Quando a correlação está correta, você consegue abrir uma requisição e ver a transação completa.

Cloud role name

O cloud role name é o nome lógico do componente que enviou a telemetria, como webfopag-api, pontofopag-worker ou integracao-epays. Ele é muito importante para Application Map, filtros e alertas.

Se todos os serviços aparecem com o mesmo nome, o mapa fica confuso. Configure nomes diferentes por aplicação/worker.

Sampling

Sampling reduz o volume de telemetria enviada. Ele é útil para custo e performance, mas muda a forma de interpretar contagens.

Exemplo: se a aplicação recebe muito tráfego, o SDK pode enviar uma amostra representativa em vez de todos os eventos. Isso ajuda a controlar custo, mas uma consulta que conta linhas pode não representar exatamente o número bruto de eventos se você ignorar os campos de amostragem.

Boa prática:

• Mantenha exceptions e falhas importantes visíveis.
• Ajuste sampling com cuidado em sistemas de baixo volume, onde perder eventos pode atrapalhar investigação.
• Documente a política de sampling usada por ambiente.

Retenção e custo

Logs geram custo de ingestão e armazenamento. Antes de aumentar volume, pense:

• Quais logs são realmente úteis em produção?
• Existem logs repetitivos demais?
• O nível Information está exagerado?
• Dados sensíveis estão sendo enviados sem necessidade?
• A retenção do workspace está adequada?

Observabilidade boa não é “logar tudo”. É registrar o suficiente para diagnosticar com segurança.

Tabelas de logs mais usadas

[!TIP] Se uma query não encontrar AppRequests, tente procurar a tabela equivalente sem prefixo, como requests. Isso depende do tipo de recurso, contexto de consulta e modelo usado.

KQL para iniciantes

KQL significa Kusto Query Language. Ele é a linguagem usada no Logs.

Estrutura básica:

Tabela
| where TimeGenerated > ago(1h)
| where Campo == "valor"
| summarize Quantidade = count() by AlgumaDimensao
| order by Quantidade desc

Operadores que você mais vai usar:

Queries prontas

Requisições com erro nos últimos 30 minutos

AppRequests
| where TimeGenerated > ago(30m)
| where Success == false
| project TimeGenerated, Name, Url, ResultCode, DurationMs, OperationId
| order by TimeGenerated desc

Erros por endpoint

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize Erros = count() by Name, ResultCode
| order by Erros desc

Taxa de erro por intervalo

AppRequests
| where TimeGenerated > ago(6h)
| summarize Total = count(), Erros = countif(Success == false) by bin(TimeGenerated, 15m)
| extend TaxaErroPercentual = round(100.0 * Erros / Total, 2)
| order by TimeGenerated asc

Requests mais lentas

AppRequests
| where TimeGenerated > ago(24h)
| project TimeGenerated, Name, DurationMs, ResultCode, Success, OperationId
| order by DurationMs desc
| take 50

Percentil p95 por endpoint

AppRequests
| where TimeGenerated > ago(24h)
| summarize P50 = percentile(DurationMs, 50), P95 = percentile(DurationMs, 95), P99 = percentile(DurationMs, 99), Total = count() by Name
| order by P95 desc

Exceptions mais frequentes

AppExceptions
| where TimeGenerated > ago(24h)
| summarize Ocorrencias = count(), Ultima = max(TimeGenerated) by ExceptionType, Message
| order by Ocorrencias desc

Logs de uma transação pelo OperationId

let operationId = "COLE_AQUI_O_OPERATION_ID";
union withsource=Tabela AppRequests, AppDependencies, AppExceptions, AppTraces, AppEvents
| where OperationId == operationId
| project TimeGenerated, Tabela, Name, Message, Success, ResultCode, DurationMs, OperationId, ParentId
| order by TimeGenerated asc

Dependências externas com falha

AppDependencies
| where TimeGenerated > ago(24h)
| where Success == false
| summarize Falhas = count(), P95 = percentile(DurationMs, 95) by DependencyType, Target, Name
| order by Falhas desc

SQL ou HTTP externo mais lento

AppDependencies
| where TimeGenerated > ago(24h)
| summarize Chamadas = count(), P95 = percentile(DurationMs, 95), Maximo = max(DurationMs) by DependencyType, Target, Name
| order by P95 desc
| take 30

Traces com erro ou warning

AppTraces
| where TimeGenerated > ago(24h)
| where SeverityLevel >= 2
| project TimeGenerated, SeverityLevel, Message, OperationId, Properties
| order by TimeGenerated desc

Disponibilidade por localidade

AppAvailabilityResults
| where TimeGenerated > ago(24h)
| summarize Total = count(), Falhas = countif(Success == false), Disponibilidade = round(100.0 * countif(Success == true) / count(), 2) by Name, Location
| order by Disponibilidade asc

Comparar antes e depois de um deploy

Troque os horários pelos horários reais do deploy.

let antesInicio = datetime(2026-06-30 08:00:00);
let antesFim = datetime(2026-06-30 09:00:00);
let depoisInicio = datetime(2026-06-30 09:00:00);
let depoisFim = datetime(2026-06-30 10:00:00);
AppRequests
| where TimeGenerated between (antesInicio .. depoisFim)
| extend Janela = case(
    TimeGenerated between (antesInicio .. antesFim), "Antes",
    TimeGenerated between (depoisInicio .. depoisFim), "Depois",
    "Fora"
  )
| where Janela != "Fora"
| summarize Total = count(), Erros = countif(Success == false), P95 = percentile(DurationMs, 95) by Janela, Name
| order by Name asc, Janela asc

Falhas

A tela Failures é uma das mais importantes para suporte e desenvolvimento.

Ela ajuda a responder:

• Quais operações estão falhando?
• Qual status code aparece mais?
• Qual exception está mais recorrente?
• A falha está em request, dependência ou exceção?
• Quando começou?
• O erro cresceu depois de um deploy?
• Existe uma transação exemplo para abrir?

Fluxo recomendado:

1. Abra Failures.
2. Ajuste o período no topo da tela.
3. Veja se o problema aparece em requests, dependencies ou exceptions.
4. Ordene por contagem ou impacto.
5. Abra um item representativo.
6. Clique na transação de exemplo para ver detalhes ponta a ponta.
7. Copie o OperationId se precisar ir para Logs.

O que observar:

Desempenho

A tela Performance ajuda a entender lentidão.

Termos importantes:

Como investigar lentidão:

1. Abra Performance.
2. Selecione o período do incidente.
3. Ordene operações por duração ou p95.
4. Abra a operação lenta.
5. Veja se o tempo está no código da aplicação ou em dependências.
6. Confira exemplos de transação lenta.
7. Use Logs para comparar p95 antes/depois.

Evite olhar apenas a média. Um endpoint pode ter média aceitável, mas p95 alto, o que significa que uma parte dos usuários sofre com lentidão.

Live Metrics

Live Metrics mostra dados quase em tempo real, geralmente com atraso pequeno. É excelente para acompanhar:

• deploy em andamento;
• teste manual de uma correção;
• teste de carga;
• aumento súbito de erro;
• CPU/memória sob pressão;
• request rate;
• exceptions por segundo;
• dependência lenta ou falhando.

Use Live Metrics quando a pergunta for: “o que está acontecendo agora?”

Não use Live Metrics como substituto de Logs quando a pergunta for histórica, detalhada ou exige agregação complexa.

Boas práticas:

• Abra antes de iniciar um deploy crítico.
• Tenha um endpoint de saúde para verificar resposta.
• Observe se exceptions crescem logo após a publicação.
• Compare request rate com falhas. Uma queda de erro pode significar correção, mas também pode significar queda de tráfego.

Application Map

O Application Map mostra a aplicação como componentes conectados. Ele é muito útil quando o sistema tem:

• API chamando outra API;
• worker chamando fila;
• aplicação chamando SQL;
• integrações HTTP externas;
• múltiplos serviços no mesmo fluxo;
• front-end e back-end instrumentados.

O mapa ajuda a visualizar:

• qual componente está com erro;
• qual dependência está lenta;
• qual serviço chama qual;
• gargalos entre camadas;
• aumento de falhas em conexões específicas.

Para o mapa ficar bom, configure corretamente:

• cloud role name por serviço;
• correlação distribuída;
• instrumentação de dependências;
• connection string correta por ambiente.

Métricas

Métricas são números agregados ao longo do tempo. Elas são mais baratas e rápidas para gráficos e alertas simples.

Métricas comuns:

Como acompanhar métricas:

1. Abra Metrics.
2. Escolha o escopo: recurso Application Insights.
3. Escolha a métrica.
4. Defina agregação: Avg, Count, Max, Min, percentil quando disponível.
5. Divida por dimensão se fizer sentido, por exemplo endpoint, status code ou role.
6. Salve em Dashboard ou Workbook se for acompanhamento recorrente.

Para incidente, prefira gráficos com período curto. Para tendência, use períodos maiores.

Availability

Availability cria testes externos para verificar se uma URL responde.

Exemplo de uso:

• monitorar /health;
• monitorar página de login;
• monitorar endpoint público de API;
• validar disponibilidade por regiões diferentes;
• alertar quando o sistema fica indisponível.

Boa prática para endpoint de saúde:

• Responder rápido.
• Não depender de operações pesadas.
• Validar dependências críticas quando isso fizer sentido.
• Retornar status HTTP coerente.
• Não expor dados sensíveis.

Ao criar um teste, configure:

Alertas

Alertas transformam sinais em notificações.

Tipos comuns:

Exemplos de alertas úteis:

Cuidados:

• Evite alerta que dispara todo dia e ninguém olha.
• Defina severidade coerente.
• Escreva descrição com link para dashboard/query.
• Inclua action group certo.
• Revise limites após aprender o comportamento normal do sistema.

Workbooks e dashboards

Workbooks são painéis interativos. Eles podem misturar:

• texto explicativo;
• parâmetros;
• métricas;
• queries KQL;
• gráficos;
• tabelas;
• links de investigação.

Use workbooks para rotinas como:

• painel de saúde por ambiente;
• acompanhamento pós-deploy;
• falhas por integração;
• desempenho por endpoint;
• disponibilidade por sistema;
• visão executiva de incidentes.

Sugestão de workbook inicial:

Configurando uma aplicação

Criar o recurso

1. No Azure Portal, crie ou abra um Log Analytics workspace.
2. Crie um recurso Application Insights.
3. Prefira o modo workspace-based.
4. Escolha assinatura, resource group, região e workspace corretos.
5. Copie a connection string.
6. Configure a aplicação para enviar telemetria.

Configurar por variável de ambiente

Nome comum:

APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=...;IngestionEndpoint=...

Em ambientes Azure, configure em:

• App Service: Configuration > Application settings.
• Function App: Configuration > Application settings.
• Container Apps: Environment variables.
• Kubernetes: secret/config map.
• Pipeline: variável segura por ambiente.

.NET moderno com OpenTelemetry

Exemplo conceitual para ASP.NET Core:

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddOpenTelemetry()
    .UseAzureMonitor();

var app = builder.Build();
app.MapGet("/health", () => Results.Ok("ok"));
app.Run();

Com a variável APPLICATIONINSIGHTS_CONNECTION_STRING, o SDK consegue encontrar o destino da telemetria sem gravar segredo no código.

.NET legado com SDK Application Insights

Em projetos existentes, você pode encontrar:

builder.Services.AddApplicationInsightsTelemetry();

Isso ainda existe em muitos sistemas. Para projeto novo, avalie OpenTelemetry e a Azure Monitor OpenTelemetry Distro, conforme recomendação atual da Microsoft.

JavaScript no front-end

Exemplo conceitual:

import { ApplicationInsights } from '@microsoft/applicationinsights-web';

const appInsights = new ApplicationInsights({
  config: {
    connectionString: window.__APP_INSIGHTS_CONNECTION_STRING__,
    enableAutoRouteTracking: true
  }
});

appInsights.loadAppInsights();
appInsights.trackPageView();

Cuidados no front-end:

• A connection string de browser não deve ser tratada como segredo absoluto, porque fica no cliente.
• Nunca envie CPF, token, senha, holerite, dados bancários ou conteúdo sensível em propriedades de telemetria.
• Use eventos customizados com nomes de negócio, mas sem dados pessoais.

Logs bons em código

Um log bom ajuda a investigar sem expor segredo.

Ruim:

Erro ao salvar.

Melhor:

Falha ao salvar fechamento de folha. EmpresaId={EmpresaId} Competencia={Competencia} OperationId={OperationId}

Evite:

• senha;
• token;
• cookie;
• CPF completo;
• dados bancários;
• payload inteiro sem necessidade;
• arquivo completo enviado pelo usuário;
• dados pessoais sensíveis.

Prefira:

• ids internos;
• nome da operação;
• etapa do fluxo;
• status de negócio;
• duração;
• quantidade processada;
• correlation id;
• mensagem clara.

Eventos customizados

Eventos customizados ajudam a medir ações de negócio.

Exemplos:

Boas práticas:

• Use nomes estáveis.
• Evite colocar valor variável no nome do evento.
• Coloque variáveis em propriedades.
• Padronize propriedades entre sistemas.
• Não envie dados sensíveis.

Roteiros de investigação

Cenário 1: usuário reportou erro

1. Pergunte horário aproximado, usuário, tela e ação.
2. Abra Failures no período informado.
3. Filtre por endpoint ou operação se souber.
4. Abra uma exception/request de exemplo.
5. Copie OperationId.
6. Rode a query de transação no Logs.
7. Veja request, traces, exceptions e dependencies na ordem do tempo.
8. Verifique se erro vem do código, banco, API externa ou autenticação.

Cenário 2: sistema está lento

1. Abra Performance.
2. Selecione período do relato.
3. Veja endpoints com maior p95.
4. Abra uma amostra lenta.
5. Analise dependências da transação.
6. No Logs, compare p95 antes e depois.
7. Confira se houve aumento de volume, dependência lenta ou erro intermitente.

Cenário 3: integração externa falhando

1. Abra Application Map para localizar dependência.
2. Abra Failures > Dependencies.
3. Filtre por target/nome da dependência.
4. Veja status code, duração e quantidade.
5. Use AppDependencies para agrupar por Target, Name e ResultCode.
6. Confira se a falha é timeout, DNS, HTTP 4xx, HTTP 5xx ou autenticação.

Cenário 4: acompanhar deploy

1. Antes do deploy, abra Live Metrics.
2. Deixe visível request rate, failed requests e exceptions.
3. Durante o deploy, observe queda de tráfego ou aumento de exceptions.
4. Depois do deploy, compare período antes/depois com KQL.
5. Se houver falha, salve uma transação exemplo e o horário exato.

Cenário 5: não apareceu log nenhum

Verifique:

• A aplicação está usando a connection string correta?
• A variável de ambiente existe no ambiente certo?
• O recurso está no tenant/assinatura esperados?
• A aplicação foi reiniciada após configurar variável?
• Há firewall/proxy bloqueando ingestão?
• O sampling está descartando demais?
• O período do Portal está correto?
• A query está na tabela certa (AppRequests x requests)?
• O ambiente está recebendo tráfego?

Checklist rápido para incidentes

• Período correto selecionado.
• Ambiente correto selecionado.
• Application Insights correto selecionado.
• Request com erro identificada.
• OperationId salvo.
• Exceptions revisadas.
• Dependências revisadas.
• P95 comparado com comportamento normal.
• Volume de requests comparado com o normal.
• Deploy recente verificado.
• Alertas/histórico consultados.
• Evidências registradas no chamado.

Checklist de boas práticas

• Usar connection string por ambiente.
• Não versionar connection string em código.
• Configurar cloud role name por componente.
• Habilitar correlação distribuída.
• Criar endpoint de health.
• Criar alertas com limites revisados.
• Ter queries prontas para incidentes.
• Ter workbook de saúde da aplicação.
• Evitar PII e segredos nos logs.
• Revisar sampling e retenção.
• Documentar dono do recurso e action group.
• Validar telemetria após deploy.

Glossário

Links de referência

• Application Insights overview
• Criar recurso workspace-based do Application Insights
• Connection strings no Application Insights
• Azure Monitor OpenTelemetry
• Modelo de dados do Application Insights
• Transaction search and diagnostics
• Failures and performance views
• Live Metrics
• Application Map
• Availability tests
• Azure Monitor Logs e consultas KQL
• Métricas no Azure Monitor
• Alertas no Azure Monitor
• Workbooks no Azure Monitor