Benefícios do Azure Application Insights

Quando uma aplicação falha em produção, o primeiro problema muitas vezes não é corrigir o bug. É entender o que aconteceu.

O Azure Application Insights ajuda nessa investigação. Ele coleta a telemetria de uma aplicação e reúne requisições, dependências, exceções, logs e informações de desempenho no Azure Monitor. Em vez de consultar arquivos separados e tentar reconstruir uma falha manualmente, é possível acompanhar a operação em um só lugar, desde a requisição recebida até as chamadas feitas pela aplicação.

Isso é útil até mesmo em uma aplicação .NET pequena. A configuração inicial é simples, e os dados coletados podem responder a perguntas práticas como:

Quais endpoints estão falhando?
Quais requisições estão lentas?
O banco de dados ou uma API externa está causando o atraso?
Qual exceção ocorreu durante uma requisição?
O problema afetou uma única operação ou vários usuários?

O Application Insights não resolve esses problemas automaticamente. Seu principal benefício é substituir parte das suposições por evidências.

O que a integração com .NET coleta

A Microsoft recomenda a distribuição do Azure Monitor para OpenTelemetry em novas aplicações ASP.NET Core. O OpenTelemetry trabalha com três sinais principais: traces, métricas e logs.

Com a configuração padrão do ASP.NET Core, o Application Insights pode receber:

requisições HTTP de entrada, incluindo duração e status;
chamadas de saída feitas com HttpClient;
chamadas de dependência compatíveis com SQL e os SDKs do Azure;
exceções não tratadas e seus stack traces;
logs escritos por meio de ILogger;
métricas e dados de correlação que conectam uma operação à telemetria relacionada.

A correlação é uma das partes mais úteis. Uma requisição que falhou pode ser conectada à sua exceção e à chamada de dependência que apresentou erro durante a mesma operação.

Para logs da aplicação, os níveis mais relevantes em produção geralmente são:

Information para eventos selecionados da aplicação;
Warning quando algo inesperado acontece, mas a operação pode continuar;
Error quando uma operação falha;
Critical quando a aplicação ou uma funcionalidade essencial não pode continuar com segurança.

Debug e Trace são úteis durante o desenvolvimento, mas enviar grandes volumes desses logs em produção pode gerar ruído e aumentar o volume de telemetria.

Logs estruturados também tornam os dados mais fáceis de pesquisar:

logger.LogWarning(
    "Order {OrderId} could not be sent to provider {Provider}",
    orderId,
    providerName);

Nesse exemplo, OrderId e Provider se tornam propriedades pesquisáveis, em vez de ficarem escondidas dentro de uma única mensagem longa.

O ASP.NET Core continua controlando quais níveis de log serão exportados. Uma configuração simples de produção pode manter informações da aplicação e reduzir o ruído rotineiro do framework:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  }
}

Esse é apenas um ponto de partida. Um serviço pode precisar de logs mais detalhados para um namespace e menos detalhados para outro. O importante é manter os eventos que ajudam uma investigação e remover mensagens repetidas que não mudam o diagnóstico.

O que não é coletado automaticamente

A instrumentação automática tem limites. O Application Insights não consegue registrar informações que a aplicação nunca produziu.

Alguns exemplos:

uma exceção capturada e ignorada sem ser registrada em log;
um evento de negócio sem log, trace ou telemetria personalizada;
uma operação realizada por uma biblioteca sem instrumentação compatível;
o corpo de requisições e respostas;
falhas que acontecem antes de o tráfego chegar à aplicação;
visualizações de página e erros de JavaScript quando o SDK do navegador não está instalado.

Informações sensíveis não devem ser adicionadas para preencher essas lacunas. Senhas, tokens de acesso, strings de conexão, dados de pagamento e dados pessoais não pertencem à telemetria.

Monitoramento do backend e do navegador

O monitoramento do backend é executado dentro da aplicação .NET. Ele observa requisições no servidor, exceções, logs da aplicação, chamadas ao banco de dados e operações HTTP de saída.

O monitoramento do navegador é executado no dispositivo do visitante por meio do SDK JavaScript do Application Insights. Ele pode registrar visualizações de página, desempenho no cliente, sessões e erros de JavaScript.

Essas duas perspectivas respondem a perguntas diferentes. A telemetria do backend pode mostrar que uma API retornou um erro. A telemetria do navegador pode mostrar o que o visitante experimentou antes de a requisição ser feita. Uma API pode precisar apenas do monitoramento do backend, enquanto uma aplicação Razor Pages, Angular ou React pode usar os dois quando o comportamento no cliente for importante.

Configuração básica no ASP.NET Core

Instale o pacote do Azure Monitor OpenTelemetry no projeto web:

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

Depois, registre o Azure Monitor no Program.cs:

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();
app.Run();

O Application Insights usa uma string de conexão para identificar para onde a telemetria deve ser enviada. Em produção, a Microsoft recomenda fornecê-la por meio do ambiente:

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

O valor vem do recurso do Application Insights no portal do Azure e deve permanecer fora do controle de versão. Depois que a aplicação começar a receber tráfego, a telemetria pode levar alguns minutos para aparecer.

Uma primeira consulta KQL

O portal do Azure já oferece visualizações para falhas, desempenho, métricas em tempo real e dependências da aplicação. Para perguntas mais específicas, o Log Analytics usa a Kusto Query Language.

Esta consulta lista as requisições que falharam nas últimas 24 horas:

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

O OperationId ajuda a conectar uma requisição aos traces, dependências e exceções relacionados.

Os logs da aplicação ficam armazenados em AppTraces. Esta consulta se concentra nas entradas de Warning, Error e Critical:

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

Um próximo passo útil é obter o OperationId de um resultado interessante e procurar outros dados de telemetria da mesma operação. É nesse ponto que a correlação se torna mais valiosa do que a leitura de mensagens de log isoladas.

Custo e volume de telemetria

O Application Insights não é simplesmente uma funcionalidade de custo fixo. A cobrança do Azure Monitor depende principalmente da quantidade de telemetria ingerida e do período de retenção.

Logs detalhados demais, exceções repetidas, tráfego elevado e propriedades personalizadas desnecessárias podem aumentar esse volume. Sampling e filtragem podem reduzi-lo, enquanto alertas de custo e limites diários ajudam a detectar uma ingestão inesperada. Esses controles exigem equilíbrio: remover telemetria demais também pode eliminar as informações necessárias para investigar uma falha.

Um ponto de partida sensato é usar a telemetria automática do backend, logs estruturados em níveis úteis e um pequeno conjunto de consultas para problemas comuns. Mais telemetria pode ser adicionada quando houver uma pergunta clara que ela precise responder.