Perguntas frequentes sobre o Application Insights – Perguntas frequentes

Para obter informações detalhadas sobre como instrumentar aplicativos para habilitar o Application Insights, confira as noções básicas de coleta de dados.

Depois de habilitar o Application Insights instrumentando um aplicativo, sugerimos primeiro verificar as métricas dinâmicas e o mapa do aplicativo.

A partir dos aplicativos Web do servidor:

• Solicitações HTTP.
• Dependências. Chamadas para bancos de dados SQL, chamadas HTTP para serviços externos, Azure Cosmos DB, Armazenamento de Tabelas do Azure, Armazenamento de Blobs do Azure e Armazenamento de Filas do Azure.
• Exceções e rastreamentos de pilha.
• Contadores de desempenho: os contadores de desempenho estão disponíveis ao usar:
  • Agente do Application Insights do Azure Monitor
  • Monitoramento do Azure para VMs ou conjuntos de dimensionamento de máquinas virtuais
  • Gravadorcollectd do Application Insights.
• Eventos e métricas personalizados que você codifica.
• Logs de rastreamento, se você configurar o coletor apropriado.

Nas páginas do cliente na Web:

• Exceções não capturadas no seu aplicativo, incluindo informações sobre

  • Rastreamento de pilha
  • Detalhes da exceção e mensagem que acompanha o erro
  • Número de coluna e linha do erro
  • URL no qual o erro foi gerado
  • Solicitações de dependência de rede realizadas pelo seu aplicativo, como XML HTTP Request (XHR) e Fetch (a coleta de solicitações Fetch está desativada por padrão), incluem informações sobre:
    • URL da fonte de dependência
    • O Comando e o Método utilizados para solicitar a dependência
    • A duração da solicitação
    • Código de resultado e o status de êxito da solicitação
    • ID do usuário que faz a solicitação (se houver)
    • Contexto de correlação (se houver) em que a solicitação é feita

• Informações do usuário (por exemplo, local, rede, IP)

• Informações do dispositivo (por exemplo, Navegador, SO, versão, idioma, modelo)

• Informações da sessão

  Observação

  Para alguns aplicativos, como SPAs (aplicativos de página única), a duração nem sempre é registrada e, nesses casos, o padrão é 0.

  Para obter mais informações, consulte Coleta de dados, retenção e armazenamento no Application Insights.

Em outras fontes, se você configurá-las:

• Diagnóstico do Azure
• Importar para o Log Analytics
• Log Analytics
• Logstash

Para entender o número de recursos do Application Insights necessários para abranger seu aplicativo ou seus componentes entre ambientes, confira o Guia de planejamento de implantação do Application Insights.

Você pode gravar scripts do PowerShell usando o Azure Resource Monitor para:

• Criar e atualizar recursos do Application Insights.
• Definir o plano de preços.
• Obter a chave de instrumentação.
• Adicione um alerta de métrica.
• Adicionar um teste de disponibilidade.

Não é possível configurar um relatório do Metric Explorer ou configurar a exportação contínua.

Utilize a API REST para executar consultas Log Analytics.

Recomendamos o Azure Monitor OpenTelemetry Distro.

O esquema de ingestão e o protocolo de ponto de extremidade estão disponíveis publicamente.

A maioria dos dados do Application Insights tem uma latência inferior a cinco minutos. Alguns dados podem levar mais tempo, o que é típico em arquivos de log maiores. Consulte o contrato de nível de serviço do Application Insights.

Cobrança

O Application Insights coleta telemetria sobre seu aplicativo, incluindo telemetria de servidor Web, telemetria de página da Web e contadores de desempenho. Esses dados podem ser usados para monitorar o desempenho, a integridade e o uso do seu aplicativo. Você pode selecionar o local ao criar um novo recurso do Application Insights.

Retenção e armazenamento

Os dados são enviados para um espaço de trabalho do Application Insights Log Analytics. Você pode escolher o período de retenção para dados brutos, de 30 a 730 dias. Os dados agregados são retidos por 90 dias e os instantâneos de depuração são retidos por 15 dias.

Privacidade

O Application Insights não lida com dados confidenciais por padrão. Recomendamos que você não coloque dados confidenciais em URLs como texto simples e garanta que seu código personalizado não colete detalhes pessoais ou outros detalhes confidenciais. Durante o desenvolvimento e teste, verifique os dados enviados no IDE e nas janelas de saída de depuração do navegador.

Para obter informações arquivadas, consulte Coleta de dados, retenção e armazenamento no Application Insights.

O Application Insights é cobrado por meio do workspace do Log Analytics no qual os dados de log foram ingeridos. O tipo de preço padrão pago conforme o uso do Log Analytics inclui 5 GB por mês de subsídio de dados gratuito por conta de cobrança. Saiba mais sobre as opções de preços de logs do Azure Monitor.

• Se seu aplicativo Web do Azure estiver hospedado em um data center, onde há um ponto de extremidade de coleta do Application Insights, não haverá cobrança.
• Se não houver um ponto de extremidade de coleta no datacenter do host, a telemetria do seu aplicativo incorrerá em cobranças de saída do Azure.

Essa resposta depende da distribuição de nossos pontos de extremidade, não do local em que o recurso do Application Insights está hospedado.

Sim, você pode incorrer em mais custos de rede, que variam dependendo da região de onde a telemetria está vindo e para onde está indo. Consulte os preços de largura de banda do Azure para obter detalhes.

Se você estiver vendo encargos inesperados ou custos altos no Application Insights, este guia poderá ajudar. Ele aborda causas comuns, como alto volume de telemetria, picos de ingestão de dados e amostragem configurada incorretamente. É especialmente útil se você estiver solucionando problemas relacionados a picos de custo, volume de telemetria, amostragem não funcionando, limites de dados, ingestão alta ou cobrança inesperada. Para começar, veja Solucionar problemas de alta ingestão de dados no Application Insights.

O Application Insights usa o TLS (Transport Layer Security) 1.2 e 1.3.

Para obter perguntas gerais sobre o problema de TLS herdado, consulte Solução de problemas de TLS e Suporte de TLS do Azure Resource Manager.

Para obter mais informações, consulte Introdução ao Application Insights.

Os dois TelemetryChannels perderão a telemetria em buffer se ela não for liberada antes que um aplicativo seja desligado.

Para evitar a perda de dados, libere o TelemetryClient quando um aplicativo estiver sendo desligado.

Para saber mais, confira Como liberar dados.

Nenhum. Você não precisa encapsulá-las em cláusulas try-catch. Se o SDK encontrar problemas, ele vai registrar mensagens na saída do console de depuração e, se elas passarem despercebidas, na Pesquisa de Diagnóstico.

Sim, a API de acesso a dados. Outras maneiras de extrair dados incluem o Power BI no recurso baseado em workspace.

O SDK do Application Insights não é compatível com a instrumentação automática. Se a instrumentação automática estiver habilitada, as chamadas para Track() e outros eventos personalizados e APIs de métricas serão ignoradas.

Desative a instrumentação automática no portal do Azure na guia Application Insights da página do Serviço de Aplicativo ou defina ApplicationInsightsAgent_EXTENSION_VERSION como disabled.

A Amostragem reduz o número de itens de telemetria ( como solicitações e eventos personalizados) que são enviados de seu aplicativo para o portal. Em Pesquisa, você visualiza o número de itens recebidos. Nos gráficos de métrica que exibem uma contagem de eventos, você visualiza o número de eventos originais que ocorreu.

Cada item transmitido carrega uma propriedade itemCount que mostra quantos eventos originais esse item representa. Para observar a amostragem na operação, é possível executar essa consulta no Log Analytics:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Os alertas do Azure são somente em métricas. Crie uma métrica personalizada que cruze um limite de valor sempre que o evento ocorrer. Em seguida, configure um alerta na métrica. Você recebe uma notificação sempre que a métrica ultrapassa o limite em qualquer direção. Você não receberá uma notificação até o primeiro cruzamento, independentemente de o valor inicial ser alto ou baixo. Há sempre uma latência de alguns minutos.

Para obter maios informações, consulte API do Application Insights para métricas e eventos personalizados.

Sim. Há várias maneiras de baixar o Application Insights Agent:

• Se o seu computador tiver acesso à Internet, você poderá fazer a integração à Galeria do PowerShell usando parâmetros -Proxy.
• Você também pode baixar manualmente o módulo e instalá-lo no seu computador ou usá-lo diretamente.

Cada uma dessas opções é descrita nas instruções detalhadas.

Sim. No Application Insights Agent 2.0.0 e posterior, há suporte para aplicativos ASP.NET Core hospedados no IIS.

• O cmdlet Get-ApplicationInsightsMonitoringStatus pode ser usado para verificar se a habilitação foi bem-sucedida.

• Recomendamos que você use Métricas Dinâmicas para determinar rapidamente se o seu aplicativo está enviando telemetria.

• Você também pode usar o Log Analytics para listar todas as funções de nuvem que estão enviando telemetria no momento:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Para obter a passagem de proxy, configure um proxy no nível da máquina ou um proxy no nível do aplicativo. Confira DefaultProxy.

Exemplo de Web.config:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Para obter mais informações, consulte Implantar o Application Insights Agent para servidores locais.

O Application Insights e o Azure Monitor não controlam a versão do TLS usada para conexões HTTPS. A versão do TLS depende do sistema operacional e do ambiente de runtime em que o aplicativo é executado.

Para confirmar a versão do TLS em uso:

• Examine a documentação do sistema operacional e do runtime ou da estrutura.
• Entre em contato com a equipe de suporte apropriada se precisar de mais ajuda. Não abra uma solicitação de suporte com o Application Insights.

Exemplo de linguagem e suporte a runtime para TLS 1.2+

As versões a seguir incluem suporte integrado para TLS 1.2 ou superior:

• .NET/.NET Core: .NET Framework 4.6.2 ou posterior e todas as versões do .NET Core
• Java: Java 8 atualização 161 (8u161) ou posterior
• Python: distribuições do Python criadas com o OpenSSL 1.0.1 ou posterior
• Node.js: Node.js versão 10 ou posterior

Exemplo de suporte do sistema operacional para TLS 1.2+

Os seguintes sistemas operacionais incluem suporte integrado para TLS 1.2 ou superior:

• Windows: Windows 8, Windows Server 2012 e posterior
• Linux: a maioria das distribuições modernas do Linux que usam o OpenSSL 1.0.1 ou posterior

Para evitar interrupções de serviço, cada ponto de extremidade remoto (incluindo solicitações dependentes) com o qual o recurso interage precisa dar suporte a pelo menos uma combinação da mesma versão de protocolo, cipher suite e curva elíptica mencionada anteriormente. Se o ponto de extremidade remoto não der suporte à configuração de TLS necessária, ele precisará ser atualizado com suporte para alguma combinação da configuração do TLS pós-substituição.

Os recursos afetados do Application Insights param de ingerir dados e não podem acessar os componentes de aplicativo necessários. Como resultado, alguns recursos param de funcionar.

A descontinuação do TLS (Transport Layer Security) detalhada neste documento só deve afetar o comportamento após 1º de maio de 2025. Para obter mais informações sobre operações CRUD, consulte o suporte ao TLS do Azure Resource Manager. Esse recurso fornece mais detalhes sobre os prazos de suporte e descontinuação do TLS.

Em caso de dúvidas gerais sobre o problema herdado do TLS, consulte Solução de problemas de TLS.

Para obter mais informações, consulte o suporte ao TLS.

Para remover o Application Insights, você precisará remover os pacotes NuGet e as referências da API em seu aplicativo. Você pode desinstalar pacotes NuGet usando o Gerenciador de Pacotes NuGet no Visual Studio.

1. Se a coleta de rastreamento estiver habilitada, primeiro desinstale o pacote Microsoft.ApplicationInsights.TraceListener usando o Gerenciador de Pacotes NuGet, mas não remova nenhuma dependência.
2. Desinstale o pacote Microsoft.ApplicationInsights.Web e remova suas dependências usando o Gerenciador de Pacotes NuGet e suas Opções de desinstalação no Controle de opções do Gerenciador de Pacotes NuGet.
3. Para remover o Application Insights completamente, verifique e exclua manualmente o código ou os arquivos adicionados juntamente com todas as chamadas à API que você adicionou no seu projeto. Para saber mais, confira O que é criado automaticamente ao adicionar o SDK do Application Insights?.

Quando você adiciona o Application Insights a um projeto, ele cria arquivos automaticamente e adiciona código a alguns deles. A simples desinstalação dos Pacotes do NuGet nem sempre descarta os arquivos e o código. Para remover completamente Application Insights, você deve verificar e excluir manualmente o código ou os arquivos adicionados juntamente com as chamadas à API que você adicionou em seu projeto.

Quando você adiciona o Application Insights Telemetry a um projeto ASP.NET do Visual Studio, ele adiciona os seguintes arquivos:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

Os seguintes trechos de código são adicionados automaticamente:

• [Nome do seu projeto]. csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  Se o projeto tiver um arquivo Layout.cshtml, o código a seguir será adicionado.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

Para desabilitar a correlação de telemetria na configuração, veja <ExcludeComponentCorrelationHttpHeadersOnDomains> em Application Insights para aplicativos de console.

Para obter mais informações, consulte Configurar o Application Insights para seu site de ASP.NET.

O ASP.NET Core 3.1 não tem mais suporte da Microsoft.

O SDK do Application Insights para ASP.NET Core versão 2.8.0 e Visual Studio 2019 ou posterior pode ser usado com aplicativos ASP.NET Core 3.1.

Obtenha uma instância de TelemetryClient usando a injeção de construtor e chame o método TrackXXX() necessário nela. Não recomendamos criar novas instâncias TelemetryClient ou TelemetryConfiguration em um aplicativo ASP.NET Core. Uma instância singleton do TelemetryClient já está registrada no contêiner de DependencyInjection, que compartilha o TelemetryConfiguration com o restante da telemetria. Crie uma instância de TelemetryClient apenas se ela precisar de uma configuração separada do restante da telemetria.

O exemplo a seguir mostra como acompanhar mais a telemetria de um controlador.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Para obter mais informações sobre relatórios de dados personalizados no Application Insights, confira Referência de API das métricas personalizadas do Application Insights. Uma abordagem semelhante pode ser usada para enviar métricas personalizadas para o Application Insights usando a API GetMetric.

O ASP.NET Core tem suporte integrado para registrar informações de solicitação/resposta HTTP (incluindo corpo) via ILogger. Recomenda-se aproveitar isso. Isso pode potencialmente expor informações de identificação pessoal (PII) em telemetria e pode fazer com que os custos (custos de desempenho e faturação do Application Insights) aumentem significativamente, por isso avalie cuidadosamente os riscos antes de utilizar isto.

A configuração padrão do Application Insights é capturar apenas o Aviso e logs mais graves.

Capture informações e logs menos graves alterando a configuração de log do provedor do Application Insights da seguinte maneira.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

É importante observar que o exemplo seguinte não fará com que o provedor do Application Insights capture logs Information. Ele não os captura porque o SDK adiciona um filtro de log padrão que instrui o ApplicationInsights a capturar os logs Warning e mais graves. O Application Insights requer uma substituição explícita.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

Para obter mais informações, confira a Configuração do ILogger.

Embora o método de extensão UseApplicationInsights() ainda tenha suporte, ele está marcado como obsoleto no SDK do Application insights versão 2.8.0 e posterior. Ele é removido na próxima versão principal do SDK. Para habilitar a telemetria do Application Insights, use o AddApplicationInsightsTelemetry(), pois ele fornece sobrecargas para controlar algumas configurações. Além disso, em aplicativos ASP.NET Core 3.X, services.AddApplicationInsightsTelemetry() é a única maneira de habilitar o Application Insights.

Se o SDK estiver instalado no momento da compilação, conforme mostrado neste artigo, você não precisará habilitar a extensão Application Insights no portal do Serviço de Aplicativo. Se a extensão estiver instalada, ela recuará quando detectar que o SDK já foi adicionado. Se você habilitar o Application Insights da extensão, não precisará instalar e atualizar o SDK. Porém, se você habilitar o Application Insights seguindo as instruções deste artigo, terá mais flexibilidade porque:

• A telemetria do Application Insights continuará a funcionar em:
  • Todos os sistemas operacionais, incluindo Windows, Linux e Mac.
  • Todos os modos de publicação, incluindo modos autocontidos ou dependentes da estrutura.
  • Todas as estruturas de destino, incluindo o .NET Framework completo.
  • Todas as opções de hospedagem, incluindo aplicativos Web, VMs, Linux, contêineres, AKS e hospedagem não Azure.
  • Todas as versões do .NET Core, incluindo as versões preliminares.
• Você pode ver a telemetria localmente quando estiver depurando do Visual Studio.
• Você pode acompanhar mais telemetria personalizada usando a API TrackXXX().
• Você tem controle total sobre a configuração.

Sim. No Agente do Application Insights 2.0.0-beta1 e posterior, há suporte para os aplicativos ASP.NET Core hospedados no IIS.

Sim. O suporte a recursos no SDK é o mesmo em todas as plataformas, com as seguintes exceções:

• O SDK coleta contadores de eventos no Linux porque há suporte para os contadores de desempenho apenas no Windows. A maioria das métricas são as mesmas.

Não. Em vez disso, use Application Insights para aplicativos Worker Service (aplicativos não HTTP) para serviços de trabalho.

Para remover o Application Insights, você precisará remover os pacotes NuGet e as referências da API em seu aplicativo. Você pode desinstalar pacotes NuGet usando o Gerenciador de Pacotes NuGet no Visual Studio.

1. Desinstale o pacote Microsoft.ApplicationInsights.AspNetCore usando o Gerenciador de Pacotes NuGet.
2. Para remover o Application Insights completamente, verifique e exclua manualmente o código ou os arquivos adicionados juntamente com todas as chamadas à API que você adicionou no seu projeto. Para obter mais informações, confira O que é criado ao adicionar o SDK do Application Insights?.

Quando você adiciona o Application Insights ao seu projeto, ele cria arquivos e adiciona código a alguns dos seus arquivos. A simples desinstalação dos Pacotes NuGet nem sempre descarta os arquivos e o código. Para remover completamente Application Insights, você deve verificar e excluir manualmente o código ou os arquivos adicionados juntamente com as chamadas à API que você adicionou em seu projeto.

Quando você adiciona o Application Insights Telemetry a um projeto de modelo do ASP.NET Core do Visual Studio, ele adiciona os seguintes códigos:

• [Nome do seu projeto]. csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

Para desabilitar a correlação de telemetria no código, veja <ExcludeComponentCorrelationHttpHeadersOnDomains> em Application Insights para aplicativos de console.

Para obter mais informações, consulte Application Insights para ASP.NET Core.

• Exception rate: a taxa de exceções é um contador de desempenho do sistema. O CLR conta todas as exceções tratadas e sem tratamento que são geradas, e divide o total em um intervalo de amostragem pela duração do intervalo. O SDK do Application Insights coleta esse resultado e o envia para o portal.
• Exceptions: A métrica de Exceções conta os relatórios TrackException recebidos pelo portal no intervalo de amostragem do gráfico. Ela inclui apenas as exceções tratadas nas quais você escreve chamadas TrackException em seu código. Não inclui todas as exceções sem tratamento.

Para obter mais informações, consulte Contadores para .NET no Application Insights.

As métricas ao vivo não mostram EventCounters. Use o Metric Explorer ou o Analytics para ver a telemetria.

A extensão do Application Insights para ASP.NET Core ainda não é compatível com esse recurso.

Para obter mais informações, consulte Contadores para .NET no Application Insights.

O monitoramento do lado do cliente é habilitado por padrão para aplicativos ASP.NET Core. Se você quiser desabilitá-la, defina uma variável de ambiente no servidor com as seguintes informações:

• Nome: APPINSIGHTS_JAVASCRIPT_ENABLED
• Valor: false

Para obter mais informações, consulte Application Insights para VMs do Azure e conjuntos de dimensionamento de máquinas virtuais.

O campo success das chamadas de dependência com falha aparece definido como False. O módulo DependencyTrackingTelemetryModule não relata ExceptionTelemetry. O modelo de dados completo para dependência é descrito no modelo de dados de telemetria do Application Insights.

Use este código:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

No modo de exibição da consulta do Log Analytics, timestamp representa o momento em que a chamada TrackDependency() foi iniciada, o que ocorre imediatamente após o recebimento da resposta da chamada de dependência. Para calcular a hora em que a chamada de dependência começou, você pegaria timestamp e subtrairia o duration registrado da chamada de dependência.

O acompanhamento de dependências no Application Insights não inclui corpos de resposta de registro em log, porque isso geraria um excesso de telemetria para a maioria dos aplicativos.

Para obter mais informações, consulte Controle de dependência.

Os testes de disponibilidade são executados em pontos de presença distribuídos em todo o mundo. Existem duas soluções:

• Porta do firewall: permita solicitações ao seu servidor da lista mutável e longa dos agentes de teste na Web.
• Código personalizado: grave seu próprio código para enviar solicitações periódicas ao seu servidor a partir da sua intranet. Você pode executar testes na Web do Visual Studio para essa finalidade. O testador pode enviar os resultados ao Application Insights usando a API TrackAvailability().

A cadeia de caracteres do agente de usuário é Mozilla/5.0 (compatível; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Para obter mais informações, consulte testes de disponibilidade.

Os testes de disponibilidade atuam como um cliente distribuído em cada um dos locais de teste da Web com suporte. Sempre que um teste na Web é executado, o serviço de teste de disponibilidade tenta entrar em contato com o ponto de extremidade remoto definido na configuração de teste da Web. Uma mensagem “Olá” do cliente TLS é enviada contendo toda a configuração TLS com suporte no momento. Se o ponto de extremidade remoto compartilhar uma configuração TLS comum com o cliente de teste de disponibilidade, o handshake do TLS terá êxito. Caso contrário, o teste da Web falhará com uma falha de handshake do TLS.

Há várias ferramentas disponíveis para testar qual configuração de TLS um ponto de extremidade dá suporte. Uma maneira seria seguir o exemplo detalhado nesta página. Se o ponto de extremidade remoto não estiver disponível por meio da Internet pública, você precisará garantir a validação da configuração do TLS com suporte no ponto de extremidade remoto de um computador que tenha acesso para chamar seu ponto de extremidade.

Não há um tipo de exceção com o qual todas as falhas de handshake do TLS afetadas por essa substituição se apresentariam. No entanto, a exceção mais comum com a qual o teste da Web começaria a falhar seria The request was aborted: Couldn't create SSL/TLS secure channel. Você também deve ser capaz de ver quaisquer falhas relacionadas ao TLS na Etapa de solução de problemas de Transporte do TLS para o resultado do teste da Web potencialmente afetado.

A configuração do TLS negociada durante uma execução de teste da Web não pode ser exibida. Desde que o ponto de extremidade remoto dê suporte à configuração TLS comum com testes de disponibilidade, nenhum impacto deve ser visto após a substituição.

A preterição do TLS detalhada nesse documento só deve afetar o comportamento de execução do teste web de disponibilidade após 1° de maio de 2025. Para obter mais informações sobre como interagir com o serviço de teste de disponibilidade para operações CRUD, consulte Suporte do TLS do Azure Resource Manager. Esse recurso fornece mais detalhes sobre os prazos de suporte e descontinuação do TLS.

Em caso de dúvidas gerais sobre o problema herdado do TLS, consulte Solução de problemas de TLS.

Para obter mais informações, consulte as configurações de TLS com suporte.

Os detalhes dependem do tipo de projeto. A lista a seguir é um exemplo para um aplicativo Web.

• Adiciona arquivos ao seu projeto:

  • ApplicationInsights.config
  • ai.js

• Instala os pacotes NuGet:

  • API do Application Insights: a API principal
  • API do Application Insights para Aplicativos Web: usada para enviar telemetria do servidor
  • API do Application Insights para Aplicativos JavaScript: usada para enviar dados de telemetria do lado do cliente

• Inclui assemblies em pacotes:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Insere itens em:

  • Web.config
  • packages.config

• Insere snippets no código do cliente e do servidor para inicializá-los com a ID de recurso do Application Insights. Por exemplo, em um aplicativo MVC, o código é inserido na página principal Views/Shared/_Layout.cshtml. Somente para novos projetos, você adicionará manualmente o Application Insights a um projeto existente.

O Application Insights coleta a telemetria das solicitações que chegaram no aplicativo. Se a falha ocorreu no WebApps/WebServer e a solicitação não chegou ao aplicativo do usuário, o Application Insights não terá telemetrias sobre ele.

A duração da serverresponsetime calculada pelo Application Insights não corresponderá necessariamente ao tempo de resposta do servidor observado pelos aplicativos Web. Esse comportamento ocorre porque o Application Insights só conta a duração quando a solicitação realmente chega ao aplicativo do usuário. Se a solicitação estiver presa ou enfileirada no WebServer, o tempo de espera será incluído nas métricas dos aplicativos Web, mas não nas métricas do Application Insights.

Para obter mais informações, consulte Habilitar o monitoramento de aplicativos no Serviço de Aplicativo do Azure.

Seguimos o Guia de Estilo da Microsoft para a documentação de produtos publicada na plataforma Microsoft Learn.

Em geral, não incluímos um hífen após o prefixo "auto".

Para obter mais informações, consulte o que é autoinstrumentação para o Application Insights do Azure Monitor?.

Se você quiser métricas personalizadas no Node.js, instrumente manualmente os aplicativos com o Azure Monitor OpenTelemetry Distro.

O Java permite métricas personalizadas com autoinstrumentação. Você pode coletar métricas personalizadas atualizando seu código e habilitando esse recurso. Se o código já tiver métricas personalizadas, elas fluirão quando a autoinstrumentação estiver habilitada.

A instrumentação automática do AKS pode interromper a telemetria enviada a terceiros por um SDK OpenTelemetry OSS.

A autoinstrumentação do AKS foi projetada para coexistir com as duas opções de instrumentação manual: o SDK da API clássica do Application Insights e o OpenTelemetry Distro.

Ele sempre impede dados duplicados e garante que as métricas personalizadas funcionem.

Consulte este gráfico para determinar quando a autoinstrumentação ou instrumentação manual tem precedência.

As vulnerabilidades detectadas no Azure Monitor OpenTelemetry Distro são priorizadas, corrigidas e lançadas na próxima versão.

A instrumentação automática do AKS injeta a última versão do Azure Monitor OpenTelemetry Distro nos pods do aplicativo sempre que a implantação é alterada ou reiniciada.

O OpenTelemetry Distro pode se tornar vulnerável em implantações que não são alteradas ou reiniciadas por longos períodos de tempo. Por esse motivo, sugerimos atualizar ou reiniciar implantações semanalmente para garantir que uma versão recente da Distribuição esteja sendo usada.

Este recurso realiza a instrumentação automática injetando o Azure Monitor OpenTelemetry Distro nos pods do aplicativo.

Para Java, esse recurso integra a Distribuição autônoma do Azure Monitor OpenTelemetry para Java. Consulte nossa documentação de distribuição do Java para saber mais sobre o binário de instrumentação Java.

Para Node.js, injetamos um binário de instrumentação automática com base no nosso Azure Monitor OpenTelemetry Distro para Node.js. Para obter mais informações, consulte Node.js documentação de distribuição. Tenha em mente que não temos uma autoinstrumentação autônoma para Node.js, portanto, nossa documentação de distribuição está voltada para a instrumentação manual. Você pode ignorar as etapas de configurações baseadas em código relacionadas à instrumentação manual. No entanto, todo o resto em nossa documentação de distribuição, como configurações padrão, configurações de variável de ambiente etc. é aplicável a esse recurso.

Para obter mais informações, consulte Autoinstrumentação para AKS.

Novas regiões do Azure exigem o uso de cadeias de conexão em vez de chaves de instrumentação. Uma cadeia de conexão identifica o recurso com o qual você deseja associar os dados telemétricos. Ela também permite modificar os pontos de extremidade que o recurso usa como um destino para a telemetria. Copie a cadeia de conexão e adicione-a ao código do seu aplicativo ou a uma variável de ambiente.

Recomendamos usar cadeias de conexão em vez de chaves de instrumentação.

Defina manualmente APPLICATIONINSIGHTS_CONNECTION_STRING em todos os cenários em que o sistema não o fornece automaticamente. Esses cenários incluem, mas não se limitam a: desenvolvimento local e funções isoladas do .NET usando a integração do ASP.NET Core. Nesses casos, a variável de ambiente garante que o pipeline OpenTelemetry possa enviar telemetria para o Application Insights. Para obter mais informações sobre como configurar cadeias de conexão com uma variável de ambiente, consulte Configurando OpenTelemetry no Application Insights.

Para atender aos requisitos de conformidade de dados regionais, use pontos de extremidade regionais do Application Insights em vez do ponto de extremidade global. O ponto de extremidade global não garante que os dados permaneçam em uma região específica. Pontos de extremidade regionais ajudam a garantir que a telemetria de usuários em áreas regulamentadas seja enviada apenas para datacenters nessas regiões.

Para configurar seu aplicativo Web global para conformidade regional:

• Crie um recurso do Application Insights por região com requisitos de conformidade rigorosos, como a União Europeia ou os Estados Unidos.
• Crie outro recurso do Application Insights para usuários em todas as outras regiões.
• Configure seu aplicativo para enviar telemetria para o recurso apropriado do Application Insights com base na região de cada usuário. Determine a região usando sinais como endereço IP, metadados de conta ou configurações de local.
• Conecte todos os recursos do Application Insights a um workspace do Log Analytics se precisar de uma experiência de consulta unificada entre regiões.

Por exemplo:

• Envie dados de usuários da Região A para o recurso Region A Application Insights usando a cadeia de conexão região A.
• Envie dados de usuários da Região B para o recurso Application Insights da Região B usando a cadeia de conexão da Região B.
• Envie todos os outros dados do usuário para um recurso do Application Insights de uso geral usando uma cadeia de conexão diferente.

O diagrama a seguir mostra um exemplo de configuração para um aplicativo Web global:

Para saber mais, confira Cadeias de conexão.

Não há suporte para a transferência de recursos existentes do Application Insights entre regiões, e você não pode migrar dados históricos para uma nova região. A solução alternativa envolve:

• Criando um novo recurso do Application Insights na região desejada.
• Recriar quaisquer personalizações exclusivas do recurso original no novo.
• Atualizar seu aplicativo com a cadeia de conexão do recurso da nova região.
• Testar para garantir que tudo funcione conforme o esperado com o novo recurso do Application Insights.
• Decidir manter ou excluir o recurso original do Application Insights. A exclusão de um recurso clássico significa perder todos os dados históricos. Se o recurso for baseado em workspace, os dados permanecerão no Log Analytics, permitindo o acesso aos dados históricos até que o período de retenção expire.

As personalizações exclusivas que normalmente precisam ser recriadas ou atualizadas manualmente para o recurso na nova região incluem, entre outros:

• Recriar painéis personalizados e pastas de trabalho.
• Recriar ou atualizar o escopo de quaisquer alertas de log/métrica personalizados.
• Recriar alertas de disponibilidade.
• Recriar qualquer configuração personalizada do controle de acesso baseado em função do Azure que é necessária para os usuários acessarem o novo recurso.
• Replicar as configurações que envolvem amostragem de ingestão, retenção de dados, limite diário e habilitação de métricas personalizadas. Essas configurações são controladas por meio do painel Uso e custos estimados.
• Qualquer integração que dependa de chaves de API, como anotações de versão e canal de controle seguro do Live Metrics. Você precisa gerar novas chaves de API e atualizar a integração associada.
• A exportação contínua em recursos clássicos deve ser configurada novamente.
• As configurações de diagnóstico em recursos baseados em espaço de trabalho devem ser definidas novamente.

Não é recomendável usar esse método de preenchimento da versão da API. A versão mais recente pode representar versões de visualização, que podem conter alterações interruptivas. Mesmo com versões mais recentes que não sejam de visualização, as versões da API nem sempre são compatíveis com versões anteriores de modelos existentes. Em alguns casos, a versão da API pode não estar disponível para todas as assinaturas.

Para obter mais informações, consulte Criar e configurar recursos do Application Insights.

Para relatar problemas de esquema ou modelo de dados e sugestões, use nosso repositório GitHub.

A Telemetria de Visualizações de Página inclui o URL e você pode analisar o parâmetro UTM usando uma função regex no Kusto.

Ocasionalmente, esses dados poderão estar ausentes ou ser imprecisos se o usuário ou a empresa desabilitar o envio do Agente do usuário nas configurações do navegador. As expressões regulares do Analisador do agente do usuário talvez não incluam todas as informações do dispositivo. Ou o Application Insights pode não ter adotado as atualizações mais recentes.

Isso pode ocorrer se você estiver usando valores de cadeia de caracteres. Somente valores numéricos funcionam com medidas personalizadas.

Para saber mais, confira o Modelo de dados de telemetria do Application Insights.

ApplicationInsightsLoggerProvider captura ILogger logs e cria TraceTelemetry com base neles. Se um Exception objeto for passado para oLog método em ILogger, ExceptionTelemetry é criado em vez deTraceTelemetry.

Exibindo a telemetria do ILogger

No Portal do Azure:

1. Abra o portal do Azure e acesse o seu recurso do Application Insights.
2. Selecione a seção Logs dentro do Application Insights.
3. Use a KQL (Linguagem de Consulta Kusto) para consultar mensagens do ILogger armazenadas na tabela traces. Consulta de exemplo: traces | where message contains "YourSearchTerm".
4. Refine suas consultas para filtrar dados ILogger por severidade, intervalo de tempo ou conteúdo de mensagem específico.

No Visual Studio (Depurador Local):

1. Inicie seu aplicativo em modo de depuração no Visual Studio.
2. Abra a janela Ferramentas de Diagnóstico enquanto o aplicativo é executado.
3. No guia Eventos, os logs do ILogger aparecem junto com outros dados de telemetria.
4. Para localizar mensagens específicas do ILogger, use os recursos de pesquisa e filtro na janela Ferramentas de Diagnóstico.

Se você preferir sempre enviar TraceTelemetry, use este trecho de código:

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

O Application Insights captura e envia ILoggerlogs usando a mesmaTelemetryConfiguration informação usada para todas as outras telemetrias. Mas há uma exceção. Por padrão, o TelemetryConfiguration não é totalmente configurado quando você faz o log de Program.cs ou de Startup.cs. Os logs desses locais não têm a configuração padrão, portanto, não estão executando todas as instâncias de TelemetryInitializer e TelemetryProcessor.

Quando você usa o pacote autônomo, o TelemetryClient não é injetado no contêiner de DI (injeção de dependência). Você precisa criar uma nova instância de TelemetryClient e usar a mesma configuração que o provedor do logger usa, como mostra o código a seguir. Esse requisito garante que a mesma configuração seja usada para toda a telemetria personalizada e a telemetria de ILogger.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

A extensão do Application Insights nos Aplicativos Web do Azure usa o novo provedor. Você pode modificar as regras de filtragem no arquivo appsettings.json para o seu aplicativo.

Para obter mais informações, consulte o registro em log do Application Insights com o .NET.

O Java Profiler usa o Java Flight Recorder (JFR) para criar o perfil do aplicativo usando uma configuração personalizada.

O Java Flight Recorder (JFR) é uma ferramenta usada para coletar dados de criação de perfil de um aplicativo Java em execução. O JFR é integrado à Máquina Virtual Java (JVM) e é usado para solucionar problemas de desempenho. Saiba mais sobre o JFR Runtime do Java SE.

A habilitação da Criação de Perfil Java é um recurso gratuito com o Application Insights. O preço do Application Insights do Azure Monitor se baseia no custo de ingestão.

Os dados da criação de perfil coletados pelo JFR incluem: dados de criação de perfil de método e execução, dados de coleta de lixo e perfis de bloqueio.

A gravação do JFR pode ser exibida e analisada com sua ferramenta preferida, por exemplo, JMC (Java Mission Control).

O "Diagnóstico e recomendações de desempenho" é um nova funcionalidade que estará disponível em breve como Diagnóstico Java do Application Insights. Você pode se inscrever para obter a versão prévia desse recurso. A gravação do JFR pode ser exibida com o JMC (Java Mission Control).

A criação de perfil sob demanda é disparada pelo usuário em tempo real, enquanto a automática é feita com gatilhos pré-configurados.

Use Criar perfil agora para a opção de criação de perfil sob demanda. A função Criar perfil agora cria imediatamente o perfil de todos os agentes que estão anexados à instância do Application Insights.

A criação de perfil automatizada é disparada atingindo um limite de recurso.

Atualmente, o Agente Java do Application Insights dá suporte ao monitoramento do consumo de CPU e de memória. O limite da CPU é configurado como uma porcentagem de todos os núcleos disponíveis no computador. A memória é a ocupação atual da região de memória titular (OldGen) em relação ao tamanho máximo possível da região.

Examine os pré-requisitos.

Sim, você pode criar um perfil de uma JVM executando microsserviços usando o JFR.

Para obter mais informações, consulte o Azure Monitor Application Insights Profiler para Java.

Não, as substituições de amostragem agora estão disponíveis em geral (GA) e podem ser usadas com a autoinstrumentação e a instrumentação manual.

Se você usar a autoinstrumentação, atualize o arquivo applicationinsights.json no portal do Azure.

Para autoinstrumentação, nenhum upload manual de agente é necessário. No entanto, para instrumentação manual, você ainda precisa incluir o arquivo JAR do agente do Application Insights e os arquivos de configuração no pacote de implantação.

O desenvolvimento local refere-se ao ambiente em que o aplicativo está sendo criado ou testado, como um computador do desenvolvedor ou uma instância do Azure Cloud Shell. O servidor de aplicativos refere-se ao servidor Web que executa o aplicativo, como o Tomcat 11 em um ambiente do Serviço de Aplicativo do Azure. Ao usar a instrumentação manual, você deve garantir que o arquivo JAR do agente seja colocado corretamente no servidor de aplicativos.

Para autoinstrumentação, você pode configurar substituições de amostragem por meio do portal do Azure. Se estiver usando a instrumentação manual, coloque o JAR do agente do Application Insights no diretório apropriado e inclua o arquivo applicationinsights.json com as configurações de amostragem desejadas.

Para obter mais informações, consulte As substituições de amostragem – Application Insights do Azure Monitor para Java.

TelemetryClient.trackTrace() faz parte da ponte do SDK Clássico do Application Insights e os processadores de log só funcionam com a nova instrumentação baseada em OpenTelemetry.

Para obter mais informações, consulte Os processadores de telemetria (versão prévia) – Application Insights do Azure Monitor para Java.

• O SDK do JavaScript define um cookie de usuário no cliente Web para identificar os usuários que retornam e, um cookie de sessão para atividades de grupo.
• Se não houver nenhum script do lado do cliente, você poderá definir cookies no server.
• Se um usuário real usar seu site em diferentes navegadores, usar navegação em modo privado/anônimo ou usar diferentes máquinas, eles serão contados mais de uma vez.
• Para identificar um usuário conectado entre navegadores e máquinas, adicione uma chamada a setAuthenticatedUserContext().

O SDK do JavaScript Application Insights tem uma sobrecarga mínima em seu site. Com apenas 36 KB compressado com gzip e levando apenas em torno de 15 ms para inicializar, o SDK adiciona uma quantidade insignificante de tempo de carregamento ao seu site. Os componentes mínimos da biblioteca são rapidamente carregados quando você usa o SDK e o script completo é baixado em segundo plano.

Além disso, enquanto o script é baixado da CDN, todo o acompanhamento de sua página é enfileirado, para que você não perca nenhuma telemetria durante todo o ciclo de vida de sua página. Esse processo de instalação fornece à sua página um sistema de análise contínuo que é invisível para os usuários.

Para obter amostras de executáveis, confira Amostras do SDK JavaScript do Application Insights.

Precisamos tomar as medidas necessárias para garantir que este SDK continue a "funcionar" e não interrompa a execução do JavaScript quando carregado por um navegador mais antigo. Seria ideal não dar suporte a navegadores mais antigos, mas vários clientes grandes não podem controlar qual navegador seus usuários optam por usar.

Esta instrução não significa que daremos suporte apenas ao menor conjunto comum de funcionalidades. Precisamos manter a compatibilidade de código ES3. Novas funcionalidades precisam ser adicionadas de uma maneira que não interrompa a análise do JavaScript ES3, e que sejam adicionados como uma funcionalidade opcional.

Consulte o GitHub para obter detalhes completos sobre o suporte ao Internet Explorer 8.

Sim, o SDK do JavaScript Application Insights é de código aberto. Para exibir o código-fonte ou para contribuir para o projeto, confira o repositório oficial do GitHub.

Para obter mais informações, consulte Habilitar o Monitoramento Real do Usuário do Application Insights do Azure Monitor.

O lado do servidor precisa ser capaz de aceitar conexões com esses cabeçalhos presentes. Dependendo da configuração Access-Control-Allow-Headers no lado do servidor, muitas vezes é necessário estender a lista do lado do servidor adicionando Request-Id, Request-Context e traceparent (cabeçalho distribuído W3C).

Controle de Acesso a Cabeçalhos Permitidos: Request-Id, traceparent, Request-Context e <your header>

O rastreamento distribuído pode ser desabilitado na configuração.

Não. Os erros "502 Gateway incorreto" e "503 Serviço indisponível" nem sempre são capturados pelo Application Insights. Se apenas o JavaScript do lado do cliente estiver sendo usado para monitoramento, esse comportamento será esperado, pois a resposta de erro é retornada antes da renderização da página que contém o cabeçalho HTML com o snippet de código JavaScript de monitoramento.

Se a resposta 502 ou 503 foi enviada de um servidor com o monitoramento do lado do servidor habilitado, os erros são coletados pelo SDK do Application Insights.

Mesmo quando o monitoramento do lado do servidor está habilitado no servidor Web de um aplicativo, às vezes um erro 502 ou 503 não é capturado pelo Application Insights. Muitos servidores Web modernos não permitem que um cliente se comunique diretamente. Em vez disso, eles utilizam soluções como proxies reversos para transmitir informações entre o cliente e os servidores Web front-end.

Nesse cenário, uma resposta 502 ou 503 pode ser retornada a um cliente devido a um problema na camada de proxy reverso, então ela não será capturada pelo Application Insights. Para ajudar a detectar problemas nessa camada, talvez seja necessário encaminhar logs do proxy reverso para o Log Analytics e criar uma regra personalizada para verificar se há respostas 502 ou 503. Para saber mais sobre as causas comuns dos erros 502 e 503, confiraSolucionar erros HTTP “502 Gateway incorreto” e “503 Serviço indisponível” no Serviço de Aplicativo do Azure.

Para obter mais informações, consulte a configuração do SDK do JavaScript do Application Insights.

O navegador passa a string do User-Agent no cabeçalho HTTP da solicitação. O serviço de ingestão do Application Insights usa o UA Parser para gerar os campos que você vê nas tabelas de dados e nas experiências. Como resultado, os usuários do Application Insights não podem alterar esses campos.

Ocasionalmente, esses dados poderão estar ausentes ou ser imprecisos se o usuário ou a empresa desabilitar o envio do Agente do usuário nas configurações do navegador. As expressões regulares do Analisador do agente do usuário talvez não incluam todas as informações do dispositivo. Ou o Application Insights pode não ter adotado as atualizações mais recentes.

Para obter mais informações, consulte Habilitar uma extensão de estrutura para o SDK do JavaScript do Application Insights.

Não. Os modelos e as chamadas à API do ARM existentes continuam funcionando. Quando você tenta criar um recurso clássico, um recurso baseado em espaço de trabalho com gerenciamento é criado em vez disso.

Não. A notificação para migrações de recursos individuais não está disponível. Para controlar quando e como seus recursos são migrados, utilize migração manual.

As migrações individuais geralmente são concluídas em menos de dois minutos. A distribuição completa ocorre ao longo de várias semanas em todas as regiões.

Após a migração, o recurso é vinculado a um workspace do Log Analytics na página Visão Geral. O aviso clássico de retirada é removido, e a planilha de aposentadorias não lista mais o recurso.

Normalmente, os custos permanecem semelhantes. O Application Insights baseado em workspace permite recursos de economia de custos e recomendamos revisar os planos de preços.

Se você estiver em um modelo de cobrança herdado, examine a documentação de preços para obter detalhes.

Não. Todos os alertas, dashboards e testes de disponibilidade permanecem intactos e continuam funcionando após a migração.

Para obter mais informações, consulte workspaces gerenciados no Application Insights.

Para desabilitar a correlação de telemetria, use a propriedade correlationHeaderExcludedDomains na configuração. Para obter mais informações, consulte ApplicationInsights-node.js.

Para configurar o nível de log desejado que o Application Insights usará, use a variável de APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL ambiente. Os valores com suporte são NONE, ERROR, WARN, INFO, DEBUG, VERBOSE e ALL. Para obter mais informações, consulte ApplicationInsights-node.js.

Para obter mais informações, consulte Monitor your Node.js services and apps with Application Insights.

Uma lista de versões e nomes do SDK está hospedada no GitHub. Para obter mais informações, confira a Versão do SDK.

Para obter mais informações, consulte Coletar telemetria com OpenTelemetry no Application Insights.

OpenTelemetry é uma estrutura de observabilidade neutra do fornecedor. Não há APIs do Application Insights no SDK ou nas bibliotecas do OpenTelemetry. Antes de migrar, é importante entender alguns dos conceitos do OpenTelemetry.

• No Application Insights, toda a telemetria era gerenciada por meio de um único TelemetryClient e TelemetryConfiguration. No OpenTelemetry, cada um dos três sinais de telemetria (Traces, Metrics e Logs) tem sua própria configuração. Você pode criar telemetria manualmente por meio do runtime do .NET sem bibliotecas externas. Para obter mais informações, consulte os guias do .NET sobre rastreamento distribuído, métricas e registro em log.

• O Application Insights usou TelemetryModules para coletar automaticamente a telemetria para seu aplicativo. Em vez disso, o OpenTelemetry usa bibliotecas de instrumentação para coletar telemetria de componentes específicos (como AspNetCore para solicitações e HttpClient para dependências).

• O Application Insights usou TelemetryInitializers para enriquecer a telemetria com informações adicionais ou para substituir propriedades. Com o OpenTelemetry, você pode escrever um Processador para personalizar um sinal específico. Além disso, muitas bibliotecas do OpenTelemetry Instrumentation oferecem um método Enrich para personalizar a telemetria gerada por esse componente específico.

• O Application Insights usou TelemetryProcessors para filtrar a telemetria. Um Processador OpenTelemetry também pode ser usado para aplicar regras de filtragem em um sinal específico.

Esta tabela mapeia os tipos de dados do Application Insights para conceitos do OpenTelemetry e suas implementações do .NET.

Os documentos a seguir fornecem mais informações.

• Noções básicas da Coleta de Dados do Application Insights do Azure Monitor
• Modelo de dados de telemetria do Application Insights
• Conceitos do OpenTelemetry

Embora o Application Insights ofereça várias opções para configurar a amostragem, tanto o Exportador do Azure Monitor quanto a Distribuição do Azure Monitor oferecem apenas amostragem com taxa fixa. Somente Solicitações e Dependências (Rastreamentos de OpenTelemetry) podem ser amostrados.

Para obter exemplos de código detalhando como configurar a amostragem, consulte nosso guia Habilitar amostragem

No SDK do Application Insights .NET, use processadores de telemetria para filtrar, modificar ou descartar a telemetria. Use inicializadores de telemetria para adicionar ou modificar propriedades personalizadas. Para obter mais informações, consulte a documentação Azure Monitor. O OpenTelemetry substitui esses conceitos por processadores de atividade ou log, que enriquecem e filtram a telemetria.

Filtrar rastreamentos

Para filtrar dados de telemetria no OpenTelemetry, você pode implementar um processador de atividade. Este exemplo é equivalente ao exemplo do Application Insights para filtrar dados de telemetria, conforme descrito na documentação do Azure Monitor. O exemplo ilustra onde as chamadas de dependência malsucedidas são filtradas.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

Para usar este processador, você precisa criar um TracerProvider e adicionar o processador antes de AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Filtrar logs

Implementações ILogger tem um mecanismo interno para aplicar a filtragem de log. Essa filtragem permite controlar os logs enviados para cada provedor registrado, incluindo o OpenTelemetryLoggerProvider. "OpenTelemetry" é o alias para OpenTelemetryLoggerProvider, usado na configuração de regras de filtragem.

O exemplo a seguir define "Erro" como o LogLevel padrão e também define "Aviso" como o LogLevel mínimo para uma categoria definida pelo usuário. Essas regras, conforme definidas, aplicam-se apenas ao OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

Para obter mais informações, leia a documentação do OpenTelemetry .NET sobre logs.

Adicionando propriedades personalizadas a rastreamentos

No OpenTelemetry, você pode usar processadores de atividade para enriquecer os dados de telemetria com mais propriedades. É semelhante ao uso de inicializadores de telemetria no Application Insights, em que você pode modificar as propriedades de telemetria.

Por padrão, o Exportador do Azure Monitor sinaliza qualquer solicitação HTTP com um código de resposta de 400 ou superior como falha. No entanto, se você quiser tratar 400 como um sucesso, poderá adicionar um processador de atividade enriquecedor que define o sucesso na atividade e adiciona uma marca para incluir mais propriedades de telemetria. É semelhante a adicionar ou modificar propriedades usando um inicializador no Application Insights, conforme descrito na documentação do Azure Monitor.

Aqui está um exemplo de como adicionar propriedades personalizadas e substituir o comportamento padrão para determinados códigos de resposta:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

Para usar este processador, você precisa criar um TracerProvider e adicionar o processador antes de AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Envio de rastreamentos – Manual

Os rastreamentos no Application Insights são armazenados como RequestTelemetry e DependencyTelemetry. No OpenTelemetry, os rastreamentos são modelados como Span usando a classe Activity.

O OpenTelemetry .NET utiliza as classes ActivitySource e Activity para rastreamento, que fazem parte do runtime do .NET. Essa abordagem é distinta porque a implementação do .NET integra a API de rastreamento diretamente ao próprio runtime. O pacote System.Diagnostics.DiagnosticSource permite que os desenvolvedores usem ActivitySource para criar e gerenciar instâncias Activity. Esse método fornece uma maneira perfeita de adicionar rastreamento a aplicativos .NET sem depender de bibliotecas externas, aplicando os recursos internos do ecossistema .NET. Para obter informações mais detalhadas, consulte as instruções passo a passo da instrumentação de rastreamento distribuído.

Veja como migrar o rastreamento manual:

DependencyTelemetry

O Application Insights DependencyTelemetry é usado para modelar solicitações de saída. Veja como convertê-lo para OpenTelemetry:

Exemplo do Application Insights:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

Exemplo de OpenTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

RequestTelemetry

O Application Insights RequestTelemetry modela as solicitações de entrada. Veja como migrá-lo para o OpenTelemetry:

Exemplo do Application Insights:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

Exemplo de OpenTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Acompanhamento de operações personalizadas

No Application Insights, acompanhe as operações personalizadas usando os métodos StartOperation e StopOperation. Consiga isso usando ActivitySource e Activity no OpenTelemetry .NET. Para operações com ActivityKind.Server e ActivityKind.Consumer, o Exportador do Azure Monitor gera RequestTelemetry. Para ActivityKind.Client, ActivityKind.Producer e ActivityKind.Internal, ele gera DependencyTelemetry. Para obter mais informações sobre o acompanhamento de operações personalizadas, consulte a documentação do Azure Monitor. Para obter mais informações sobre como usar ActivitySource e Activity no .NET, consulte as instruções passo a passo da instrumentação de rastreamento distribuído do ..

Veja um exemplo de como iniciar e interromper uma atividade para operações personalizadas:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Enviar logs

Os logs no Application Insights são armazenados como TraceTelemetry e ExceptionTelemetry.

TraceTelemetry

No OpenTelemetry, o registro é integrado por meio da interface ILogger. Veja como migrar TraceTelemetry:

Exemplo do Application Insights:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

Exemplo de OpenTelemetry:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

O Application Insights usa ExceptionTelemetry para registrar exceções. Veja como migrar para o OpenTelemetry:

Exemplo do Application Insights:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

Exemplo de OpenTelemetry:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Envio de métricas

As métricas no Application Insights são armazenadas como MetricTelemetry. No OpenTelemetry, as métricas são modeladas como Meter do pacote System.Diagnostics.DiagnosticSource.

O Application Insights tem APIs de métrica não pré-agregadas (TrackMetric()) e pré-agregadas (GetMetric().TrackValue()). Ao contrário do OpenTelemetry, o Application Insights não tem noção de Instrumentos. O Application Insights tem a mesma API para todos os cenários de métrica.

O OpenTelemetry, por outro lado, exige que os usuários primeiro escolham o instrumento de métrica certo com base na semântica real da métrica. Por exemplo, se a intenção for contar algo (como o número total de solicitações de servidor recebidas etc.), Contador OpenTelemetry deverá ser usado. Se a intenção for calcular vários percentis (como o valor P99 da latência do servidor), então instrumento de Histograma do OpenTelemetry deve ser usado. Devido a essa diferença fundamental entre o Application Insights e o OpenTelemetry, nenhuma comparação direta é feita entre eles.

Ao contrário do Application Insights, o OpenTelemetry não fornece mecanismos internos para enriquecer ou filtrar métricas. No Application Insights, os processadores e inicializadores de telemetria podem ser usados para modificar ou descartar métricas, mas essa funcionalidade não está disponível no OpenTelemetry.

Além disso, o OpenTelemetry não dá suporte ao envio direto de métricas brutas, pois não há equivalente à funcionalidade TrackMetric() encontrada no Application Insights.

A migração do Application Insights para o OpenTelemetry envolve a substituição de todos os usos da API de Métrica do Application Insights pela API do OpenTelemetry. Requer a compreensão dos vários instrumentos OpenTelemetry e sua semântica.

Outros tipos de telemetria

Eventos Personalizados

Não suportado no OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackEvent()

AvailabilityTelemetry

Não suportado no OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Não suportado no OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackPageView()

Recomendamos o Exportador de OpenTelemetry do Azure Monitor para os aplicativos de console e serviços de trabalho, o que não inclui métricas dinâmicas.

Para obter mais informações, consulte Migrar de SDKs do .NET Application Insights para o OpenTelemetry do Azure Monitor.

O amostrador personalizado do Application Insights toma decisões de amostragem após a criação do intervalo, e não antes, portanto, ele não segue uma abordagem tradicional baseada em cabeçalho. Em vez disso, ele aplica decisões de amostragem no final da geração do intervalo—após a conclusão do intervalo, mas antes da exportação.

Embora esse comportamento se assemelhe à amostragem baseada na parte final em alguns aspectos, o amostrador não espera coletar vários intervalos do mesmo rastreamento antes de tomar a decisão. Em vez disso, ele usa um hash do ID de rastreamento para ajudar a garantir a completude do rastreamento.

Essa abordagem equilibra a integridade e a eficiência do rastreamento e evita o custo mais alto associado à amostragem completa baseada na parte final.

Para tomar decisões de amostragem com base no resultado de um rastreamento inteiro (por exemplo, determinar se ocorreu uma falha em algum intervalo dentro do rastreamento), é necessária uma amostragem completa baseada na parte final em um agente ou um coletor downstream. No momento, não há suporte para essa funcionalidade, mas você pode solicitá-la como um novo recurso por meio do Hub de Comentários.

Não, o amostrador aplica uma taxa fixa em todos os tipos de telemetria em um rastreamento. Solicitações, dependências e outros intervalos seguem a mesma porcentagem de amostragem. Para aplicar taxas diferentes por tipo de telemetria, considere usar processadores de intervalo OpenTelemetry ou (transformações de tempo de ingestão)[opentelemetry-overview.md#telemetry-routing].

O amostrador personalizado do Application Insights propaga decisões de amostragem usando o padrão W3C Trace Context por padrão. Esse padrão permite que as decisões de amostragem fluam entre os serviços. Entretanto, como o amostrador toma decisões de amostragem no final da geração do intervalo—após a chamada para serviços downstream—a propagação carrega informações de amostragem incompletas. Essa limitação está em conformidade com a especificação de Contexto de Rastreamento do W3C, mas os serviços downstream não podem usar de forma confiável essa decisão de amostragem propagada.

Não, o sampler personalizado do Application Insights sempre toma uma decisão de amostragem independente, mesmo que o serviço upstream use o mesmo algoritmo de amostragem. As decisões de amostragem de serviços upstream, incluindo aqueles que usam cabeçalhos de contexto de rastreamento do W3C, não influenciam a decisão do serviço downstream. No entanto, ele faz a amostragem com base em um hash da ID do rastreamento para garantir a integridade do rastreamento. Para aprimorar a consistência e reduzir a chance de rastreamentos interrompidos, configure todos os componentes no sistema para usar o mesmo amostrador e taxa de amostragem.

Há vários motivos pelos quais os rastreamentos podem aparecer incompletos:

• Diferentes nós em um sistema distribuído usam abordagens distintas de amostragem que não coordenam decisões. Por exemplo, um nó aplica a amostragem baseada em cabeçalho do OpenTelemetry, e outro nó aplica a amostragem por meio do amostrador personalizado do Azure Monitor.
• Nós diferentes são definidos para taxas de amostragem diferentes, mesmo que ambos usem a mesma abordagem de amostragem.
• Você define limites de filtragem, amostragem ou taxa no pipeline do lado do serviço, e essa configuração faz a amostragem aleatória de intervalos sem considerar a integridade do rastreamento.

Se um componente aplicar amostragem baseada em cabeçalho sem propagar a decisão de amostragem (por meio de cabeçalhos de contexto de rastreamento do W3C), os serviços downstream amostrarão o rastreamento de forma independente, o que pode resultar em intervalos descartados. Como resultado, algumas partes do rastreamento nem sempre estão disponíveis quando exibidas no Application Insights.

Para obter mais informações, consulte Amostragem no Azure Monitor Application Insights com OpenTelemetry.

É um padrão de software livre para observabilidade. Saiba mais em OpenTelemetry.

A Microsoft está investindo no OpenTelemetry pelos seguintes motivos:

• É neutro em relação a fornecedores e fornece APIs/SDKs consistentes entre diferentes linguagens.
• Ao longo do tempo, acreditamos que o OpenTelemetry permitirá que os clientes do Azure Monitor observem os aplicativos escritos em linguagens além das nossas linguagens com suporte.
• Ele expande os tipos de dados que podem ser coletados por meio de um conjunto avançado de bibliotecas de instrumentação.
• Os Kits de Desenvolvimento de Software (SDKs) do OpenTelemetry tendem a ser mais eficientes em grande escala do que seus predecessores, os SDKs do Application Insights.
• OpenTelemetry está alinhado com a estratégia da Microsoft de adotar o código aberto.

Confira Status do OpenTelemetry.

Você pode pensar nela como um wrapper fino que reúne todos os componentes do OpenTelemetry para uma experiência de primeira classe no Azure. Esse wrapper também é chamado de distribuição no OpenTelemetry.

Há várias vantagens em usar a Distribuição OpenTelemetry do Azure Monitor em relação ao OpenTelemetry nativo da comunidade:

• Reduz o esforço da habilitação
• Compatível com a Microsoft
• Inclui recursos específicos do Azure, como:
  • Amostragem compatível com os SDKs clássicos do Application Insights
  • autenticação do Microsoft Entra
  • Armazenamento offline e novas tentativas automáticas
  • Statsbeat
  • Métricas Padrão do Application Insights
  • Detectar metadados de recurso para preencher automaticamente o Nome da Função na Nuvem e a Instância da Função na Nuvem em vários ambientes do Azure
  • Métricas Dinâmicas

No espírito do OpenTelemetry, projetamos a distribuição para ser aberta e extensível. Por exemplo, você pode adicionar:

• Um exportador do Protocolo OpenTelemetry (OTLP) e enviar para um segundo destino simultaneamente
• Outras bibliotecas de instrumentação não incluídas na distribuição

Como a Distribuição oferece uma distribuição do OpenTelemetry, ela suporta tudo o que é suportado pelo OpenTelemetry. Por exemplo, você pode adicionar mais processadores de telemetria, exportadores ou bibliotecas de instrumentação se o OpenTelemetry der suporte a eles.

Para idiomas sem um exportador autônomo do OpenTelemetry com suporte, a Distribuição do OpenTelemetry para Azure Monitor é atualmente a única maneira com suporte para usar o OpenTelemetry com o Azure Monitor. Para idiomas com um exportador autônomo do OpenTelemetry com suporte, você tem a opção de usar tanto a Distribuição do OpenTelemetry do Azure Monitor quanto o exportador autônomo apropriado do OpenTelemetry, dependendo do seu cenário de telemetria. Para obter mais informações, consulte Quando devo usar o exportador do OpenTelemetry do Azure Monitor?.

Confira nossos documentos de ativação para .NET, Java, JavaScript (Node.js) e Python.

É recomendável usar a Distribuição OpenTelemetry do Azure Monitor para novos projetos quando seus recursos se alinharem às suas necessidades de monitoramento. O OpenTelemetry é uma estrutura padrão do setor que aprimora a observabilidade entre plataformas e fornece uma abordagem padronizada para a coleção de telemetria.

No entanto, os SDKs do Application Insights ainda fornecem determinados recursos que ainda não são totalmente automatizados no OpenTelemetry, incluindo:

• Acompanhamento automático de dependência – o OpenTelemetry dá suporte ao acompanhamento de dependências, mas algumas dependências exigem configuração adicional em comparação com o acompanhamento automático disponível nos SDKs do Application Insights.
• Tipos de telemetria personalizados, como AvailabilityTelemetry e PageViewTelemetry – OpenTelemetry não tem equivalentes diretos. Funcionalidades semelhantes podem ser implementadas por meio de instrumentação manual.
• Processadores e inicializadores de telemetria — o OpenTelemetry tem processadores e processadores de intervalo, mas eles não substituem totalmente os Processadores e Inicializadores do Application Insights Telemetry em todos os cenários.
• Coleção de métricas estendidas – embora o OpenTelemetry tenha um sistema de métricas forte, algumas métricas internas dos SDKs do Application Insights exigem configuração manual no OpenTelemetry.

O OpenTelemetry também oferece vantagens sobre os SDKs do Application Insights, incluindo:

• Melhor padronização entre plataformas
• Um ecossistema mais amplo de bibliotecas de instrumentação
• Maior flexibilidade na coleta e processamento de dados
• Melhor neutralidade do fornecedor, embora o Azure Monitor OpenTelemetry Distro ainda esteja otimizado para o Azure.

A integração do OpenTelemetry do Azure Monitor está em constante evolução e a Microsoft continua aprimorando seus recursos. Se você estiver considerando uma transição, avalie cuidadosamente se o OpenTelemetry atualmente atende aos seus requisitos de observabilidade ou se o SDK do Application Insights continua sendo o melhor adequado para suas necessidades.

No caso do ASP.NET Core, do Java, do Node.js e do Python, recomendamos usar a Distribuição do OpenTelemetry para Azure Monitor. Basta uma linha de código para começar.

Para todos os outros cenários de .NET, incluindo ASP.NET clássico, aplicativos de console, Windows Forms (WinForms) etc., recomendamos o uso do exportador OpenTelemetry do Azure Monitor para .NET: Azure.Monitor.OpenTelemetry.Exporter.

Para cenários de telemetria do Python mais complexos que exigem configuração avançada, recomendamos usar o Exportador OpenTelemetry do Azure Monitor do Python.

O gráfico a seguir divide o suporte ao recurso OpenTelemetry para cada idioma.

Chave

• ✅ Esse recurso está disponível para todos os clientes com suporte formal.
• ⚠ Esse recurso está disponível em versão prévia pública. Consulte os Termos de uso complementares para versões prévias do Microsoft Azure.
• ❌ Esse recurso não está disponível ou não é aplicável.

Sim, mas não recomendamos e o Azure não dá suporte a ele. O Javascript do OpenTelemetry é altamente otimizado para Node.js. Nesse caso, recomendamos usar o SDK do JavaScript do Application Insights.

O SDK da Web do OpenTelemetry não tem uma linha do tempo de disponibilidade determinada. Deve demorar alguns anos para algum SDK de navegador ser uma alternativa viável ao SDK do JavaScript do Application Insights.

A área restrita Web do OpenTelemetry é uma bifurcação projetada para fazer o OpenTelemetry funcionar em um navegador. Ainda não é possível enviar telemetria para o Application Insights. O SDK não define eventos gerais do cliente.

Essa prática não é algo que planejamos testar ou oferecer suporte, embora nossas distribuições permitam que você exporte para um ponto de extremidade OTLP junto com o Azure Monitor simultaneamente.

Não recomendamos isso. Consulte os Termos de uso complementares para versões prévias do Microsoft Azure.

Consulte a Visão geral do OpenTelemetry.

Alguns clientes usam o Coletor do OpenTelemetry como uma alternativa de agente, embora a Microsoft ainda não dê suporte oficial a uma abordagem baseada em agente para o monitoramento de aplicativos. Enquanto isso, a comunidade de código aberto contribuiu com um Exportador do Azure Monitor para o Coletor do OpenTelemetry, que alguns clientes estão usando para enviar dados para o Application Insights do Azure Monitor. Isso não tem suporte da Microsoft.

O OpenCensus é o precursor do OpenTelemetry. A Microsoft ajudou a reunir o OpenTracing e o OpenCensus para criar o OpenTelemetry, um padrão de observabilidade exclusivo para o mundo. O SDK do Python recomendado para produção atual para o Azure Monitor é baseado no OpenCensus. A Microsoft está comprometida em dar suporte ao OpenTelemetry no Azure Monitor.

Você pode estar tentando visualizar logs de texto bruto em vez de rastreamentos do OpenTelemetry.

No Application Insights, a tabela "Traces" armazena logs de texto bruto para fins de diagnóstico. Eles ajudam a identificar e correlacionar rastreamentos associados a solicitações de usuários, outros eventos e relatórios de exceções. No entanto, a tabela "Traces" não contribui diretamente para a visualização da transação de ponta a ponta (gráfico em cascata) em ferramentas de visualização como o Grafana.

Com a crescente adoção de práticas nativas da nuvem, há uma evolução na coleta e na terminologia de telemetria. OpenTelemetry tornou-se um padrão para coleta e instrumentação de dados de telemetria. Nesse contexto, o termo "Traços" ganhou um novo significado. Em vez de logs brutos, 'Traces' no OpenTelemetry referem-se a uma forma de telemetria mais rica e estruturada que inclui spans, que representam unidades individuais de trabalho. Esses intervalos são cruciais para a construção de visualizações detalhadas de transações, permitindo melhor monitoramento e diagnóstico de aplicativos nativos da nuvem.

Para instrumentar um aplicativo Blazor, primeiro identifique o modelo de hospedagem. O Blazor Server dá suporte à instrumentação completa baseada em OpenTelemetry. O Blazor WebAssembly é executado no navegador e dá suporte à instrumentação limitada por meio do JavaScript.

Para obter mais informações, consulte Suporte e Comentários do OpenTelemetry para Application Insights.

Não, existe um limite de 30 dias de dados exibidos em um painel.

Um erro de "recurso não encontrado" pode ocorrer se você mover ou renomear sua instância do Application Insights.

Para contornar esse comportamento, exclua o painel padrão e selecione novamente o Painel de Aplicativos para criar um painel novo.

Para obter mais informações, consulte Painel de visão geral do Application Insights.

A resposta curta é que nenhum dos canais integrados oferece uma garantia do tipo de transação de entrega de telemetria para o backend. ServerTelemetryChannel é mais avançado em comparação com InMemoryChannel para entrega confiável, mas também faz apenas uma tentativa de melhor esforço para enviar telemetria. A telemetria ainda pode ser perdida em várias situações, incluindo estes cenários comuns:

• Os itens na memória são perdidos quando o aplicativo trava.
• A telemetria é perdida durante longos períodos de problemas de rede. A telemetria é armazenada no disco local durante interrupções da rede ou quando ocorrem problemas com o back-end do Application Insights. No entanto, itens com mais de 48 horas são descartados.
• Os locais de disco padrão para armazenar telemetria no Windows são% LOCALAPPDATA% ou% TEMP%. Esses locais são normalmente locais para a máquina. Se o aplicativo migrar fisicamente de um local para outro, qualquer telemetria armazenada no local original será perdida.
• Em Web Apps do Azure no Windows, o local de armazenamento em disco padrão é D:\local\LocalAppData. Este local não é persistente. Ela é apagada em reinicializações de aplicativos, expansões e outras operações semelhantes e isso gera a perda de qualquer telemetria armazenada nela. Você pode substituir o padrão e especificar o armazenamento em um local persistente como D:\home. No entanto, esses locais persistentes são servidos por armazenamento remoto e, portanto, podem ser lentos.

Embora menos provável, também é possível que o canal cause itens duplicados de telemetria. Esse comportamento ocorre quando ServerTelemetryChannel faz novas tentativas devido a falha de rede ou tempo limite, quando a telemetria foi entregue ao back-end, mas a resposta foi perdida devido a problemas de rede ou porque houve um tempo limite.

Embora o nome de seu pacote e namespace inclua "WindowsServer", este canal é compatível com sistemas diferentes do Windows, com a seguinte exceção. Em sistemas diferentes do Windows, o canal não cria uma pasta de armazenamento local por padrão. Você deve criar uma pasta de armazenamento local e configurar o canal para usá-la. Após a configuração do armazenamento local, o canal funciona da mesma maneira em todos os sistemas.

O SDK armazena itens de telemetria no armazenamento local em situações de problemas de rede ou controle de fluxo. Esses dados não são criptografados localmente.

Em sistemas Windows, o SDK cria automaticamente uma pasta local temporária no diretório %TEMP% ou %LOCALAPPDATA% e restringe o acesso apenas aos administradores e ao usuário atual.

Em sistemas diferentes do Windows, nenhum armazenamento local é criado automaticamente pelo SDK e, portanto, nenhum dado é armazenado localmente por padrão.

Você mesmo pode criar um diretório de armazenamento e configurar o canal para usá-lo. Nesse caso, você é responsável por garantir que o diretório esteja protegido. Leia mais sobre proteção de dados e privacidade.

Para obter mais informações, consulte canais de telemetria no Application Insights.

Confira o resumo de Limites.

Não registramos os dados POST automaticamente, mas você pode usar TrackTrace ou chamadas de log. Coloque os dados de POSTAGEM no parâmetro de mensagem. Não é possível filtrar a mensagem da mesma maneira que as propriedades, mas o limite de tamanho é maior.

O Azure Functions não registra em log cadeias de caracteres de consulta de URL.

Para obter mais informações, consulte Pesquisa e Diagnóstico de Transações.

Motivos possíveis:

• Os outros componentes são instrumentados com Application Insights?
• Eles estão usando o SDK estável mais recente do Application Insights?
• Se esses componentes forem recursos separados do Application Insights, valide se você tem acesso. Se você tiver acesso e os componentes estiverem instrumentados com os SDKs mais recentes do Application Insights, avise-nos através do canal de comentários no canto superior direito.

No momento, estamos mostrando a chamada de dependência de saída separada da solicitação de entrada. Normalmente, as duas chamadas parecem idênticas, apenas o valor da duração sendo diferente devido à viagem de ida e volta da rede. O ícone principal e o estilo distinto das barras de duração ajudam a diferenciá-las. Essa apresentação dos dados está confusa? Envie-nos seus comentários!

As linhas do tempo são ajustadas para as distorções do relógio no gráfico de transações. É possível visualizar os carimbos de data/hora exatos no painel de detalhes ou usando o Log Analytics.

Esse comportamento é por design. Todos os itens relacionados, em todos os componentes, já estão disponíveis no lado esquerdo, nas seções superior e inferior. A nova experiência tem dois itens relacionados que o lado esquerdo não abrange: toda a telemetria de cinco minutos antes e depois desse evento e a linha do tempo do usuário.

A experiência de diagnóstico de transação mostra toda a telemetria em uma única operação que compartilha uma ID da Operação. Por padrão, o SDK do Application Insights para JavaScript cria uma operação para cada exibição de página exclusiva. Em um SPA (aplicativo de página única), somente um evento de exibição de página é gerado e apenas uma ID de operação é usada para todas as telemetrias geradas. Como resultado, muitos eventos podem estar correlacionados com a mesma operação.

Nesses cenários, você pode usar o Acompanhamento de Rota Automático para criar automaticamente novas operações de navegação em seu SPA. Você deve ativar o enableAutoRouteTracking para que uma visualização de página seja gerada sempre que a rota de URL for atualizada (uma visualização lógica de página ocorre). Se você quiser atualizar manualmente a ID da operação, chame appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). O disparo manual de um evento PageView também redefinirá a ID da operação.

O tempo não explicado no gráfico de Gantt é o tempo que não é coberto por uma dependência rastreada. Esse problema pode ocorrer porque as chamadas externas não foram instrumentadas, seja automaticamente ou manualmente. Também pode ocorrer porque o tempo gasto estava em processo, em vez de por causa de uma chamada externa.

Se todas as chamadas foram instrumentadas, em andamento é a causa raiz provável para o tempo gasto. Uma ferramenta útil para diagnosticar o processo é o .NET Profiler.

Esse erro indica que o navegador não pôde chamar uma API exigida ou a API retornou uma resposta de falha. Para solucionar o comportamento, abra uma janela InPrivate do navegador e desabilite todas as extensões do navegador em execução e identifique se você ainda pode reproduzir o comportamento do portal. Se o erro do portal ainda ocorrer, tente testar com outros navegadores ou outros computadores, investigue o DNS ou outros problemas relacionados à rede do computador cliente em que as chamadas à API estão falhando. Se o erro do portal continuar e precisar de mais investigação, colete um rastreamento de rede do navegador ao reproduzir o comportamento inesperado do portal e abra um caso de suporte no portal do Azure.

Para obter mais informações, consulte Pesquisa e Diagnóstico de Transações.

O evento inicial em visualização representa apenas a primeira vez que um usuário enviou essa exibição de página ou evento personalizado durante uma sessão. Se os usuários podem enviar o evento inicial várias vezes em uma sessão, a coluna Etapa 1 mostra apenas como os usuários se comportam após a primeira instância de um evento inicial e não de todas as instâncias.

Use as opções Dividir por no menu Editar:

1. Selecione o evento que você deseja dividir no menu Evento.

2. Selecione uma dimensão no menu Dimensão. Por exemplo, se você tiver um evento chamado Botão clicado, tente uma propriedade personalizada chamada Nome do botão.

Coortes e filtros são diferentes. Suponha que você tenha uma coorte de usuários do Reino Unido (definidos como no exemplo anterior) e compare os resultados com uma configuração do filtro Country or region = United Kingdom:

• A versão de coorte mostra todos os eventos de usuários que enviaram um ou mais eventos do Reino Unido no período atual. Se você dividir por país ou região, provavelmente verá muitos países e regiões.

• A versão dos filtros mostra apenas eventos do Reino Unido. Se você dividir por país ou região, verá apenas o Reino Unido.

Você pode selecionar o filtro Granularidade de Datas para alterar a granularidade. O filtro está disponível em todas as guias de dimensão.

Você poderá se aprofundar nos dados que alimentam a pasta de trabalho HEART se os visuais não responderem a todas as suas dúvidas. Para fazer essa tarefa, na seção Monitoramento no Application Insights, selecione Logs e consulte a customEvents tabela. Alguns dos atributos do Click Analytics estão contidos no campo customDimensions.

Uma consulta de exemplo é mostrada aqui:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Para saber mais sobre Logs no Azure Monitor, consulte visão geral de Logs do Azure Monitor.

Sim. Para saber como editar modelos de pasta de trabalho, consulte os modelos de Pastas de Trabalho do Azure.

Para obter mais informações, consulte Análise de uso com o Application Insights.

Sim, a configuração é compartilhada com o restante do aplicativo Web.

Obtenha uma instância de TelemetryClient usando a injeção de construtor e chame o método TrackXXX() necessário nela. Não recomendamos criar novas instâncias de TelemetryClient. Uma instância singleton do TelemetryClient já está registrada no contêiner de DependencyInjection, que compartilha o TelemetryConfiguration com o restante da telemetria. A criação de uma instância de TelemetryClient é recomendada apenas se ela precisar de uma configuração separada do restante da telemetria.

Atualmente, há suporte para a integração do IDE do Visual Studio apenas para aplicativos ASP.NET/ASP.NET Core. Esse documento será atualizado quando o Visual Studio incluir o suporte para a integração de aplicativos do Serviço de Trabalho.

Não. O Agente do Application Insights do Azure Monitor atualmente oferece suporte apenas ao .NET.

Sim. O suporte a recursos neste SDK é o mesmo em todas as plataformas, com as seguintes exceções:

• Os contadores de desempenho têm suporte apenas no Windows, exceto para CPU/Memória de processo mostrada em métricas dinâmicas.

• Embora o ServerTelemetryChannel esteja habilitado por padrão, se o aplicativo estiver sendo executado no Linux ou no macOS, se houver problemas de rede, o canal não criará automaticamente uma pasta de armazenamento local na qual manter a telemetria temporariamente. Devido a essa limitação, a telemetria será perdida quando houver problemas temporários de rede ou de servidor. Para contornar esse problema, configure uma pasta local para o canal:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

Para obter mais informações, consulte Application Insights para aplicativos do Serviço de Trabalho (aplicativos não HTTP).