Perguntas frequentes sobre o Application Insights – Perguntas frequentes

Perguntas frequentes oficiais sobre o Azure Monitor Application Insights. Encontre respostas para perguntas sobre como usar o Application Insights com o Azure Monitor.

Visão geral

Como faço para instrumentar uma aplicação?

Para obter informações detalhadas sobre a instrumentação de aplicativos para habilitar o Application Insights, consulte Noções básicas sobre coleta de dados.

Como posso utilizar o Application Insights?

Depois de habilitar o Application Insights instrumentando um aplicativo, sugerimos primeiro verificar as métricas em tempo real e o mapa do aplicativo.

Que telemetria o Application Insights recolhe?

A partir de aplicações Web de servidor:

• Solicitações HTTP.
• Dependências. Chamadas para bancos de dados SQL, chamadas HTTP para serviços externos, Azure Cosmos DB, Armazenamento de Tabela do Azure, Armazenamento de Blob 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 Azure Monitor Application Insights
  • Monitoramento do Azure para VMs ou conjuntos de dimensionamento de máquinas virtuais
  • Autor do Application Insightscollectd.
• Eventos e métricas personalizados que você codifica.
• Registos de rastreamento se tu configurares o coletor apropriado.

A partir das páginas Web do cliente:

• Exceções não detetadas na sua aplicação, incluindo informação sobre

  • Rasto de pilha
  • Detalhes da exceção e mensagem que acompanha o erro
  • Número de linha e coluna do erro
  • URL onde o erro foi gerado
  • As solicitações de dependência de rede feitas pela sua aplicação através de XML Http Request (XHR) e Fetch (a recolha de dados de Fetch está desativada por padrão) incluem informações sobre:
    • URL da fonte de dependência
    • Comando e Método usados para solicitar a dependência
    • Duração do pedido
    • Código de resultado e status de sucesso da solicitação
    • ID (se houver) do usuário que faz a solicitação
    • Contexto de correlação (se for caso disso) em que o pedido é feito

• Informações do utilizador (por exemplo, localização, rede, IP)

• Informações do dispositivo (por exemplo, navegador, sistema operacional, versão, idioma, modelo)

• Informações da Sessão

  Observação

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

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

De outras fontes, se as configurares:

• Diagnóstico do Azure
• Importar para Log Analytics
• Análise de logs
• Logstash

Quantos recursos do Application Insights devo implantar?

Para entender o número de recursos do Application Insights necessários para cobrir seu aplicativo ou componentes em todos os ambientes, consulte o guia de planejamento de implantação do Application Insights.

Como posso gerenciar recursos do Application Insights com o PowerShell?

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

• Crie e atualize recursos do Application Insights.
• Defina o plano de preços.
• Obtenha a chave de instrumentação.
• Adicione um alerta de métrica.
• Adicione um teste de disponibilidade.

Não é possível configurar um relatório do explorador de métricas ou configurar a exportação contínua.

Como posso consultar a telemetria do Application Insights?

Utilize a API REST para executar consultas de Log Analytics.

Posso enviar telemetria para o portal do Application Insights?

Recomendamos a Distro OpenTelemetry do Azure Monitor.

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

Quanto tempo demora para a telemetria ser coletada?

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

Como o Application Insights lida com a coleta, retenção, armazenamento e privacidade de dados?

Coleção

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 conservados por 90 dias, enquanto os instantâneos de depuração são conservados 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 sem formatação e garanta que seu código personalizado não colete detalhes pessoais ou outros detalhes confidenciais. Durante o desenvolvimento e o teste, verifique os dados enviados nas janelas de saída de depuração do IDE e do navegador.

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

O que é o modelo de preços do Application Insights?

O Application Insights é cobrado por meio do espaço de trabalho do Log Analytics no qual seus dados de log foram ingeridos. O nível de preço padrão do Pay-as-you-go Log Analytics inclui 5 GB por mês de franquia de dados gratuita por conta de cobrança. Saiba mais sobre as opções de preços dos logs do Azure Monitor.

Há cobranças de transferência de dados entre um aplicativo Web do Azure e o Application Insights?

• Se seu aplicativo Web do Azure estiver hospedado em um datacenter onde há um ponto de extremidade de coleta do Application Insights, não haverá cobrança.
• Se não houver nenhum ponto de extremidade de coleta no seu centro de dados anfitrião, a telemetria da sua aplicação incorrerá em encargos de saída do Azure.

Essa resposta depende da distribuição de nossos endpoints, não de onde seu recurso do Application Insights está hospedado.

Incorro em custos de rede se meu recurso do Application Insights estiver monitorando um recurso do Azure (ou seja, produtor de telemetria) em uma região diferente?

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

Se você estiver vendo cobranças inesperadas ou custos altos no Application Insights, este guia pode ajudar. Ele cobre causas comuns como alto volume de telemetria, picos de ingestão de dados e amostragem mal configurada. É especialmente útil se você estiver solucionando problemas relacionados a picos de custo, volume de telemetria, amostragem não funcionando, limites de dados, alta ingestão ou faturamento inesperado. Para começar, consulte Solucionar problemas de alta ingestão de dados no Application Insights.

Quais versões TLS são suportadas?

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

Importante

Em 1º de março de 2025, o Azure desativará as versões herdadas do TLS em todos os serviços. Naquele momento, o Application Insights não suporta mais TLS 1.0, TLS 1.1 e os conjuntos de codificação e curvas elípticas TLS 1.2/1.3 herdados listados.

Para perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS e Suporte de TLS do Azure Resource Manager.

Onde posso obter mais informações sobre o Application Insights?

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

API do Application Insights para eventos e métricas personalizados

Por que estou faltando dados de telemetria?

Ambos os TelemetryChannels perderão a telemetria em buffer se esta não for esvaziada antes que a aplicação seja desligada.

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

Para obter mais informações, consulte Descarregar dados.

Que exceções Track_() chamadas podem lançar?

Nenhum. Não é necessário envolver eles em cláusulas try-catch. Se o SDK encontrar problemas, ele irá gravar mensagens na saída do console de depuração e, se as mensagens passarem, na Pesquisa Diagnóstica.

Existe uma API REST para obter dados do portal?

Sim, a API de acesso a dados. Outras maneiras de extrair dados incluem Power BI em recurso baseado em espaço de trabalho.

Por que minhas chamadas para APIs de métricas e eventos personalizados são ignoradas?

O SDK do Application Insights não é compatível com a autoinstrumentação. Se a autoinstrumentação estiver ativada, as chamadas para Track() e outras APIs de eventos e métricas personalizados serão ignoradas.

Desative a autoinstrumentação no portal do Azure no separador Application Insights da página App Service ou defina ApplicationInsightsAgent_EXTENSION_VERSION como disabled.

Por que as contagens nos gráficos de Pesquisa e Métricas são desiguais?

A amostragem reduz o número de itens de telemetria (como solicitações e eventos personalizados) que são enviados do seu aplicativo para o portal. Em Pesquisar, você vê o número de itens recebidos. Em gráficos de métricas que exibem uma contagem de eventos, você vê o número de eventos originais que ocorreram.

Cada item transmitido carrega uma itemCount propriedade que mostra quantos eventos originais esse item representa. Para observar a amostragem em operação, você pode executar esta consulta no Log Analytics:

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

Como posso definir um alerta sobre um evento?

Os alertas no Azure são apenas sobre métricas. Crie uma métrica personalizada que ultrapasse um limite de valor sempre que o evento ocorrer. Em seguida, defina um alerta na métrica. Você recebe uma notificação sempre que a métrica cruza o limite em qualquer direção. Você não receberá uma notificação até a primeira travessia, não importa se o valor inicial é alto ou baixo. Há sempre uma latência de alguns minutos.

Onde posso obter mais informações sobre a API do Application Insights para eventos e métricas personalizados?

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

Implantando o Application Insights Agent para servidores locais

O Application Insights Agent suporta instalações de proxy?

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

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

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

O Application Insights Agent suporta aplicativos ASP.NET Core?

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

Como verifico se a habilitação foi bem-sucedida?

• Você pode usar o cmdlet Get-ApplicationInsightsMonitoringStatus para verificar se a habilitação foi bem-sucedida.

• Use o Live Metrics para determinar rapidamente se seu aplicativo está enviando telemetria.

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

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Como faço para obter passagem de proxy?

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

Exemplo Web.config:

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

Onde posso obter mais informações sobre a implantação do Application Insights Agent para servidores locais?

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

Suporte de TLS

Determine se a desativação do TLS afeta você

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

Para confirmar a versão do TLS em uso:

• Revise a documentação do seu sistema operacional e tempo de execução ou 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 suporte a linguagem e tempo de execução para TLS 1.2+

As seguintes versões 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 update 161 (8u161) ou posterior
• Python: distribuições Python construídas com 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 Linux modernas que usam OpenSSL 1.0.1 ou posterior

Como posso garantir que os meus recursos não são afetados?

Para evitar interrupções de serviço, cada ponto de extremidade remoto (incluindo solicitações dependentes) com o qual seu recurso interage precisa suportar 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 suportar a configuração TLS necessária, ele precisará ser atualizado com suporte para alguma combinação da configuração TLS pós-depreciação.

Após 1º de maio de 2025, qual é o comportamento dos recursos afetados?

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

Quais componentes a depreciação afeta?

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

Onde posso obter suporte para Transport Layer Security (TLS)?

Para quaisquer perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS.

Onde posso obter mais informações sobre o suporte a TLS no Application Insights?

Para obter mais informações, consulte Suporte a TLS.

ASP.NET

Como posso desinstalar o SDK?

Para remover o Application Insights, você precisa remover os pacotes e referências do NuGet 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 Opções do Gerenciador de Pacotes NuGet.
3. Para remover totalmente o Application Insights, verifique e exclua manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto. Para obter mais informações, consulte O que é criado automaticamente quando você adiciona o SDK do Application Insights?.

O que é criado automaticamente quando você adiciona o SDK do Application Insights?

Quando você adiciona o Application Insights ao seu projeto, ele cria automaticamente arquivos e adiciona código a alguns de seus arquivos. A desinstalação exclusiva dos Pacotes NuGet nem sempre descarta os arquivos e o código. Para remover totalmente o Application Insights, você deve verificar e excluir manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto.

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

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

As seguintes partes de código são adicionadas 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 seu 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
           }
  

Como posso desativar a correlação de telemetria?

Para desabilitar a correlação de telemetria na configuração, consulte <ExcludeComponentCorrelationHttpHeadersOnDomains> em Application Insights for console applications.

Onde posso obter mais informações sobre como usar o Application Insights com o ASP.NET?

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

ASP.NET Aplicações principais

O Application Insights suporta ASP.NET Core 3.1?

ASP.NET Core 3.1 não é mais suportado pela 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.

Como posso rastrear a telemetria que não é coletada automaticamente?

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

O exemplo a seguir mostra como controlar mais 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, consulte Referência da API de 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.

Como faço para capturar o corpo de Solicitação e Resposta na minha telemetria?

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) na telemetria e pode fazer com que os custos (custos de desempenho e faturamento do Application Insights) aumentem significativamente, portanto, avalie os riscos cuidadosamente antes de usá-los.

Como posso personalizar a coleção de logs do ILogger?

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

Capture informações e logs menos severos alterando a configuração de log para o 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 a seguir não faz com que o provedor do Application Insights capture Information logs. Não o captura porque o SDK adiciona um filtro de log padrão que instrui ApplicationInsights a capturar apenas logs Warning e logs mais severos. O Application Insights requer uma substituição explícita.

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

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

Alguns modelos do Visual Studio usaram o método de extensão UseApplicationInsights() no IWebHostBuilder para habilitar o Application Insights. Esse uso ainda é válido?

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

Estou implantando meu aplicativo ASP.NET Core em aplicativos Web. Ainda devo habilitar a extensão do Application Insights a partir de aplicativos Web?

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

• A telemetria do Application Insights continua a funcionar em:
  • Todos os sistemas operativos, incluindo Windows, Linux e Mac.
  • Todos os modos de publicação, incluindo autônomos 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 que não seja do Azure.
  • Todas as versões do .NET Core, incluindo versões de visualização.
• Você pode ver a telemetria localmente quando estiver depurando do Visual Studio.
• Você pode acompanhar mais telemetria personalizada usando a TrackXXX() API.
• Você tem controle total sobre a configuração.

Posso habilitar o monitoramento do Application Insights usando ferramentas como o Azure Monitor Application Insights Agent (anteriormente Status Monitor v2)?

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

Todos os recursos são suportados se eu executar meu aplicativo no Linux?

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

• O SDK coleta contadores de eventos no Linux porque os contadores de desempenho só são suportados no Windows. A maioria das métricas é a mesma.

Este SDK é suportado para os Serviços do Trabalhador?

Não. Em alternativa, use Application Insights para aplicações de serviços de trabalho (aplicações não-HTTP) para serviços de trabalho.

Como posso desinstalar o SDK?

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

Observação

Estas instruções são para desinstalar o ASP.NET Core SDK. Se você precisar desinstalar o ASP.NET SDK, consulte Como desinstalar o ASP.NET SDK?.

1. Desinstale o pacote Microsoft.ApplicationInsights.AspNetCore usando o Gerenciador de Pacotes NuGet.
2. Para remover totalmente o Application Insights, verifique e exclua manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto. Para obter mais informações, consulte O que é criado quando você adiciona o SDK do Application Insights?.

O que é criado quando você adiciona o SDK do Application Insights?

Quando você adiciona o Application Insights ao seu projeto, ele cria arquivos e adiciona código a alguns de seus arquivos. A desinstalação exclusiva dos Pacotes NuGet nem sempre descartará os arquivos e o código. Para remover totalmente o Application Insights, você deve verificar e excluir manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto.

Quando você adiciona Telemetria do Application Insights a um projeto de modelo do Visual Studio ASP.NET Core, ele adiciona o seguinte código:

• [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
       }
  

Como posso desativar a correlação de telemetria?

Para desabilitar a correlação de telemetria no código, consulte <ExcludeComponentCorrelationHttpHeadersOnDomains> em Application Insights for console applications.

Onde posso obter mais informações sobre como usar o Application Insights para aplicativos ASP.NET Core?

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

Contadores de desempenho ASP.NET

Qual é a diferença entre as métricas Taxa de exceção e Exceções?

• Exception rate: A taxa de exceção é um contador de desempenho do sistema. O CLR conta todas as exceções manipuladas e não tratadas que são lançadas e divide o total em um intervalo de amostragem pelo comprimento do intervalo. O SDK do Application Insights coleta esse resultado e o envia para o portal.
• Exceptions: A métrica Exceções conta os TrackException relatórios recebidos pelo portal no intervalo de amostragem do gráfico. Inclui apenas as exceções tratadas em que você escreve TrackException chamadas em seu código. Ele não inclui todas as exceções não tratadas.

Onde posso obter mais informações sobre ASP.NET contadores de desempenho?

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

ASP.NET contadores de eventos

Posso ver EventCounters em métricas ao vivo?

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

Depois de habilitar o Application Insights no Portal do Aplicativo Web do Azure, por que não consigo ver os contadores de eventos?

A extensão do Application Insights para ASP.NET Core ainda não oferece suporte a esse recurso.

Onde posso obter mais informações sobre ASP.NET contadores de eventos?

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

VMs do Azure e conjuntos de dimensionamento de máquinas virtuais

Como posso desativar o monitoramento do lado do cliente para aplicativos ASP.NET Core?

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

• Designação:APPINSIGHTS_JAVASCRIPT_ENABLED
• Valor:false

Onde posso obter mais informações sobre como usar o Application Insights para VMs do Azure e conjuntos de dimensionamento de máquinas virtuais?

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

Rastreio de dependências

Como o coletor automático de dependência relata chamadas com falha para dependências?

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

Como calculo a latência de ingestão para a minha telemetria de dependência?

Use este código:

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

Como determino a hora em que a chamada de dependência foi iniciada?

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

O rastreamento de dependência no Application Insights inclui o registro de corpos de resposta?

O controle de dependência no Application Insights não inclui o registro de corpos de resposta, pois geraria muita telemetria para a maioria dos aplicativos.

Onde posso obter mais informações sobre o rastreamento de dependência no Application Insights?

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

Testes de disponibilidade

Posso executar testes de disponibilidade em um servidor de intranet?

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

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

O que é a cadeia de caracteres do agente do usuário para testes de disponibilidade?

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

Onde posso obter mais informações sobre os testes de disponibilidade do Application Insights?

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

Suporte TLS para testes de disponibilidade

Como a substituição afeta meu comportamento de teste da Web?

Os testes de disponibilidade atuam como um cliente distribuído em cada um dos locais de teste da Web suportados. Sempre que um teste da Web é executado, o serviço de teste de disponibilidade tenta entrar em contato com o ponto de extremidade remoto definido na configuração do teste da Web. É enviada uma mensagem Hello do Cliente TLS que contém toda a configuração TLS suportada no momento. Se o ponto de extremidade remoto compartilhar uma configuração TLS comum com o cliente de teste de disponibilidade, o handshake TLS será bem-sucedido. Caso contrário, o teste web falhará devido a um erro na ligação TLS.

Como faço para validar qual configuração TLS um ponto de extremidade remoto suporta?

Existem várias ferramentas disponíveis para testar qual configuração TLS um terminal suporta. Uma maneira seria seguir o exemplo detalhado nesta página. Se o seu ponto de extremidade remoto não estiver disponível através da Internet pública, você precisará garantir que valida a configuração TLS suportada no ponto de extremidade remoto a partir de uma máquina que tenha acesso para chamar seu ponto de extremidade.

Observação

Para conhecer as etapas para habilitar a configuração TLS necessária em seu servidor web, é melhor entrar em contato com a equipe proprietária da plataforma de hospedagem em que seu servidor web é executado, se o processo não for conhecido.

Após 1º de maio de 2025, qual será o comportamento do teste na web para testes impactados?

Não há um tipo único de exceção com o qual todas as falhas no handshake TLS afetadas por esta descontinuação se apresentariam. No entanto, a exceção mais comum com a qual o seu 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 TLS para o resultado do teste da Web que é potencialmente afetado.

Posso visualizar qual configuração TLS está atualmente em uso no meu teste da Web?

A configuração TLS negociada durante uma execução de teste da Web não pode ser visualizada. Desde que a extremidade remota ofereça suporte à configuração TLS comum e sejam realizados testes de disponibilidade, nenhum impacto deve ser percebido após a obsolescência.

Quais componentes a descontinuação afeta no serviço de teste de disponibilidade?

A depreciação do TLS detalhada neste documento só deve afetar o comportamento de execução dos testes de disponibilidade na web 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 TLS do Azure Resource Manager. Este recurso fornece mais detalhes sobre o suporte TLS e cronogramas de descontinuação.

Onde posso obter suporte TLS?

Para quaisquer perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS.

Onde posso obter mais informações sobre o suporte TLS para testes de disponibilidade?

Para obter mais informações, consulte Configurações TLS suportadas.

Monitoramento no Serviço de Aplicativo do Azure para aplicativos .NET, Node.js, Python e Java

O que o Application Insights modifica no meu projeto?

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

• Adiciona arquivos ao seu projeto:

  • ApplicationInsights.config
  • ai.js

• Instala 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 telemetria do cliente

• Inclui assemblagens em pacotes:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Insere itens em:

  • Web.config
  • packages.config

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

Qual é a diferença entre as métricas padrão do Application Insights e as métricas do Serviço de Aplicativo do Azure?

O Application Insights coleta telemetria para as solicitações que chegaram ao aplicativo. Se a falha ocorrer em WebApps/WebServer e a solicitação não chegar ao aplicativo do usuário, o Application Insights não terá nenhuma telemetria sobre isso.

A duração calculada serverresponsetime pelo Application Insights não corresponde 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 de aplicativos Web, mas não nas métricas do Application Insights.

Onde posso obter mais informações sobre monitoramento no Serviço de Aplicativo do Azure para aplicativos .NET, Node.js, Python e Java?

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

Autoinstrumentação

O termo "autoinstrumentação" deve ser hifenizado?

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

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

Onde posso obter mais informações sobre autoinstrumentação?

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

Autoinstrumentação para o Serviço Kubernetes do Azure

A autoinstrumentação do Serviço Kubernetes do Azure (AKS) suporta métricas personalizadas?

Se pretender métricas personalizadas no Node.js, deve instrumentar manualmente as aplicações com a distribuição OpenTelemetry do Azure Monitor.

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

A autoinstrumentação do AKS funciona com aplicações instrumentadas com um SDK OpenTelemetry de software de código aberto?

A autoinstrumentação AKS pode interromper a telemetria enviada a terceiros por um SDK OSS OpenTelemetry .

A autoinstrumentação AKS pode coexistir com a instrumentação manual?

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

Ele sempre evita dados duplicados e garante o trabalho de métricas personalizadas.

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

Língua	Precedência
Node.js	Instrumentação manual
Java	Autoinstrumentação

Como posso garantir que estou a utilizar as versões mais recentes e seguras da Distro OpenTelemetry do Azure Monitor?

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

A autoinstrumentação AKS injeta nos pods de aplicação a versão mais recente da Distro OpenTelemetry do Azure Monitor sempre que a sua implementação é alterada ou reiniciada.

A Distro OpenTelemetry pode ficar 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 as implantações semanalmente para garantir que uma versão recente da Distro esteja sendo usada.

Como posso saber mais sobre a Distro OpenTelemetry do Azure Monitor?

Esse recurso alcança a autoinstrumentação injetando a Distro OpenTelemetry do Azure Monitor em pods de aplicativo.

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

Para Node.js, injetamos um binário de autoinstrumentação baseado na nossa distribuição OpenTelemetry do Azure Monitor para Node.js. Para mais informações, consulte a documentação da distribuição Node.js. Tenha em mente que não temos uma autoinstrumentação independente para Node.js por isso nossa documentação de distribuição é voltada para instrumentação manual. Você pode ignorar as etapas de configuração 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áveis de ambiente, etc. é aplicável a esse recurso.

Onde posso obter mais informações sobre autoinstrumentação para AKS?

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

Cadeias de ligação

As novas regiões do Azure exigem o uso de cadeias de conexão?

As novas regiões do Azure exigem o uso de cadeias de conexão em vez de chaves de instrumentação. A cadeia de conexão identifica o recurso que você deseja associar aos seus dados de telemetria. Ele também permite que você modifique os pontos de extremidade que seu recurso usa como destino para sua telemetria. Copie a cadeia de conexão e adicione-a ao código do seu aplicativo ou a uma variável de ambiente.

Devo usar cadeias de conexão ou chaves de instrumentação?

Recomendamos que você use cadeias de conexão em vez de teclas de instrumentação.

Quando preciso definir a variável de ambiente?

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 estão limitados a: desenvolvimento local e funções isoladas do .NET usando a integração 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.

Como faço para instrumentar um aplicativo Web global para atender aos requisitos regionais de conformidade de dados?

Para atender aos requisitos regionais de conformidade de dados, 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. Os pontos de extremidade regionais ajudam a garantir que a telemetria dos utilizadores em áreas regulamentadas seja enviada exclusivamente para os centros de dados 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 da conta ou configurações de localização.
• Conecte todos os recursos do Application Insights a um espaço de trabalho 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 do Application Insights da Região A usando a cadeia de conexão da Região A.
• Envie dados de usuários da Região B para o recurso do 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 de uso geral do Application Insights usando uma cadeia de conexão diferente.

Importante

O uso do ponto de extremidade global não garante a conformidade regional. Para atender aos requisitos de residência de dados, utilize sempre pontos de extremidade específicos para cada região e encaminhe a telemetria com base na região do utilizador.

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

Onde posso obter mais informações sobre cadeias de conexão no Application Insights?

Para obter mais informações, consulte Cadeias de conexão.

Criando e configurando recursos do Application Insights

Como mover um recurso do Application Insights para uma nova região?

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

• Criação de um novo recurso do Application Insights na região desejada.
• Recriando quaisquer personalizações exclusivas do recurso original no novo.
• Atualizando seu aplicativo com a cadeia de conexão do novo recurso de região.
• Testes para garantir que tudo funcione conforme o esperado com o novo recurso do Application Insights.
• Decida manter ou excluir o recurso original do Application Insights. Excluir um recurso clássico significa perder todos os dados históricos. Se o recurso for baseado em espaço de trabalho, 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, mas não estão limitadas a:

• Recrie painéis e pastas de trabalho personalizados.
• Recrie ou atualize o escopo de quaisquer alertas de log/métrica personalizados.
• Recrie alertas de disponibilidade.
• Recrie quaisquer configurações personalizadas de controle de acesso baseado em função do Azure que sejam necessárias para que seus usuários acessem o novo recurso.
• Replicar configurações envolvendo amostragem de ingestão, retenção de dados, limite diário e ativaçã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 métricas ao vivo, canal de controle seguro. 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 configuradas novamente.

Posso usar providers('Microsoft.Insights', 'components').apiVersions[0] em minhas implantações do Azure Resource Manager?

Não recomendamos o uso desse método para preencher a versão da API. A versão mais recente pode representar versões prévias, que podem conter alterações de quebra. Mesmo com versões mais recentes que não são prévias, as versões da API nem sempre são retrocompatíveis com os modelos existentes. Em alguns casos, a versão da API pode não estar disponível para todas as assinaturas.

Onde posso obter mais informações sobre como criar e configurar recursos do Application Insights?

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

Modelo de dados de telemetria

Como posso relatar problemas e sugestões de modelo de dados ou esquema?

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

Como mediria o impacto de uma campanha de monitorização?

A Telemetria PageView inclui URL e você pode analisar o parâmetro UTM usando uma função regex no Kusto.

Ocasionalmente, esses dados podem estar ausentes ou imprecisos se o usuário ou a empresa desativar o envio do User Agent nas configurações do navegador. Os regexes do UA Parser podem não incluir todas as informações do dispositivo. Ou o Application Insights pode não ter adotado as atualizações mais recentes.

Por que uma medição personalizada seria bem-sucedida sem erros, mas o log não aparece?

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

Onde posso obter mais informações sobre o modelo de dados de telemetria?

Para obter mais informações, consulte Modelo de dados de telemetria do Application Insights.

Registro em log com .NET

Que tipo de telemetria do Application Insights é gerado a partir de logs de ILogger? Onde posso ver os logs do ILogger no Application Insights?

ApplicationInsightsLoggerProvider captura ILogger logs e cria TraceTelemetry a partir deles. Se um Exception objeto for passado para o Log método em ILogger, ExceptionTelemetry será criado em vez de TraceTelemetry.

Visualização da Telemetria ILogger

No portal do Azure, siga estes passos:

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

No Visual Studio (Depurador Local):

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

Se preferir enviar TraceTelemetrysempre, use este trecho:

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

Por que alguns logs ILogger não têm as mesmas propriedades que outros?

O Application Insights captura e envia ILogger logs usando as mesmas TelemetryConfiguration informações usadas para todas as outras telemetrias. Mas há uma exceção. Por padrão, TelemetryConfiguration não está totalmente configurado quando você faz login a partir do Program.cs ou Startup.cs. Os logs destes locais não têm a configuração padrão, por isso, não estão a executar todas as instâncias de TelemetryInitializer e de TelemetryProcessor.

Estou usando o pacote autônomo Microsoft.Extensions.Logging.ApplicationInsights e quero registrar mais telemetria personalizada manualmente. Como devo fazê-lo?

Quando usas o pacote independente, TelemetryClient não é injetado no contentor de injeção de dependência (DI). Você precisa criar uma nova instância de TelemetryClient e usar a mesma configuração que o provedor de logger usa, como mostra o código a seguir. Este requisito garante que a mesma configuração seja usada para a telemetria personalizada e a telemetria do 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;
   }  
}

Observação

Se utilizar o pacote Microsoft.ApplicationInsights.AspNetCore para habilitar o Application Insights, modifique esse código para obter TelemetryClient diretamente no construtor.

Não tenho o SDK instalado e uso a extensão de Aplicativos Web do Azure para habilitar o Application Insights para meus aplicativos ASP.NET Core. Como posso utilizar o novo fornecedor?

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 seu aplicativo.

Onde posso obter mais informações sobre como fazer login com o .NET?

Para obter mais informações, consulte Log do Application Insights com .NET.

Profilador Java

O que é o Azure Monitor Application Insights Java Profiling?

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

O que é Java Flight Recorder?

Java Flight Recorder (JFR) é uma ferramenta para a recolha de dados de perfilização de uma aplicação Java em execução. O JFR é integrado à Java Virtual Machine (JVM) e é usado para solucionar problemas de desempenho. Saiba mais sobre o Java SE JFR Runtime.

Quais são as implicações de preço e/ou taxa de licenciamento para habilitar o Perfil Java do App Insights?

O Java Profiling é um recurso gratuito com o Application Insights. O preço do Azure Monitor Application Insights é baseado no custo de ingestão.

Quais informações de monitorização de desempenho Java são coletadas?

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

Como posso usar o App Insights Java Profiling e visualizar os dados?

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

O diagnóstico de desempenho e as recomendações de correção são fornecidos com o App Insights Java Profiling?

'Diagnóstico e recomendações de desempenho' é um novo recurso que estará disponível em breve como Application Insights Java Diagnostics. Pode inscrever-se para pré-visualizar esta funcionalidade. A gravação JFR pode ser visualizada com o Java Mission Control (JMC).

Qual é a diferença entre criação de perfil Java sob demanda e automática no App Insights?

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

Use Perfil Agora para a opção de criação de perfil sob demanda. Perfil Agora cria perfis imediatos de todos os agentes que estão anexados à instância do Application Insights.

A criação automatizada de perfis é acionada ao atingir um limite de recursos.

Quais gatilhos de criação de perfil Java posso configurar?

O Application Insights Java Agent atualmente suporta o monitoramento do consumo de CPU e memória. O limite de CPU é configurado como uma porcentagem de todos os núcleos disponíveis na máquina. Memória é a ocupação atual da região de memória permanente (OldGen) em relação ao tamanho máximo possível da região.

Quais são os pré-requisitos necessários para habilitar a criação de perfil Java?

Analise os pré-requisitos.

Posso usar o Java Profiling para uma aplicação de microsserviços?

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

Onde posso obter mais informações sobre o Java Profiler?

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

Substituições de amostragem - Application Insights for Java

Preciso usar instrumentação manual para permitir substituições de amostragem?

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

Como configuro substituições de amostragem ao usar o Serviço de Aplicativo do Azure com autoinstrumentação?

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

É necessário carregar manualmente o arquivo do agente do Application Insights para substituições de amostragem?

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

Qual é a diferença entre "desenvolvimento local" e "servidor de aplicações" no contexto da instrumentação manual?

Desenvolvimento local refere-se ao ambiente onde o aplicativo está sendo criado ou testado, como a máquina de um desenvolvedor ou uma instância do Azure Cloud Shell. 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.

Se eu estiver usando um Serviço de Aplicativo do Azure com um tempo de execução Java (por exemplo, Tomcat 11), como configuro substituições de amostragem?

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

Onde posso obter mais informações sobre substituições de amostragem?

Para obter mais informações, consulte Substituições de amostragem - Azure Monitor Application Insights for Java.

Processadores de telemetria

Por que o processador de log não processa arquivos de log usando TelemetryClient.trackTrace()?

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

Onde posso obter mais informações sobre processadores de telemetria?

Para obter mais informações, consulte Processadores de telemetria (visualização) - Azure Monitor Application Insights for Java.

JavaScript SDK

Quais são as contagens de usuários e sessões?

• O JavaScript SDK define um cookie de usuário no web client, para identificar usuários que retornam, e um cookie de sessão para atividades de grupo.
• Se não houver um script do lado do cliente, você pode definir cookies no servidor.
• Se um usuário real usar seu site em navegadores diferentes, ou usando navegação privada/anônima, ou máquinas diferentes, eles serão contados mais de uma vez.
• Para identificar um usuário conectado em máquinas e navegadores, adicione uma chamada para setAuthenticatedUserContext().

O que é o desempenho/sobrecarga do SDK do JavaScript?

O SDK JavaScript do Application Insights tem uma sobrecarga mínima em seu site. Com apenas 36 KB compactados e levando apenas ~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 carregados rapidamente 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 da sua página é enfileirado, para que você não perca nenhuma telemetria durante todo o ciclo de vida da página. Esse processo de configuração fornece à sua página um sistema de análise perfeito que é invisível para seus usuários.

Quais navegadores são suportados pelo JavaScript SDK?

Chrome mais recente ✔	Firefox mais recente ✔	v3.x: IE 9+ & Microsoft Edge ✔ v2.x: Compatível com IE 8+ & Microsoft Edge ✔	Opera mais recente ✔	Safari mais recente ✔

Onde posso encontrar exemplos de código para o JavaScript SDK?

Para obter exemplos executáveis, consulte Exemplos do SDK JavaScript do Application Insights.

Qual é a compatibilidade do ES3/Internet Explorer 8 com o JavaScript SDK?

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

Esta declaração não significa que suportamos apenas o menor conjunto comum de recursos. Precisamos manter a compatibilidade do código ES3. Novos recursos precisam ser adicionados de uma maneira que não interrompa a análise de JavaScript do ES3 e adicionados como um recurso opcional.

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

O SDK do JavaScript é de código aberto?

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

Onde posso obter mais informações sobre o JavaScript SDK?

Para obter mais informações, consulte Habilitar o monitoramento de usuários reais do Azure Monitor Application Insights.

Configuração do SDK JavaScript

Como posso atualizar minha configuração de servidor de terceiros para o JavaScript SDK?

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

Access-Control-Allow-Headers: Request-Id, traceparent, Request-Context, <your header>

Como posso desativar o rastreamento distribuído para o JavaScript SDK?

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

As respostas HTTP 502 e 503 são sempre capturadas pelo Application Insights?

Não. Os erros "502 bad gateway" e "503 service unavailable" nem sempre são capturados pelo Application Insights. Se apenas JavaScript do lado do cliente estiver sendo usado para monitoramento, esse comportamento será esperado porque a resposta de erro é retornada antes da página que contém o cabeçalho HTML com o snippet JavaScript de monitoramento sendo renderizado.

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 empregam soluções como proxies reversos para passar 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, para que não seja capturada imediatamente pelo Application Insights. Para ajudar a detetar 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 causas comuns de erros 502 e 503, consulte Solucionar erros HTTP de "502 bad gateway" e "503 service unavailable" no Serviço de Aplicativo do Azure.

Onde posso obter mais informações sobre a configuração do JavaScript SDK?

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

Extensões da estrutura JavaScript

Como o Application Insights gera informações do dispositivo, como navegador, sistema operacional, idioma e modelo?

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 experiências. Como resultado, os usuários do Application Insights não podem alterar esses campos.

Ocasionalmente, esses dados podem estar ausentes ou imprecisos se o usuário ou a empresa desativar o envio do User Agent nas configurações do navegador. Os regexes do UA Parser podem não incluir todas as informações do dispositivo. Ou o Application Insights pode não ter adotado as atualizações mais recentes.

Onde posso obter mais informações sobre as extensões de estrutura JavaScript?

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

Espaços de trabalho gerenciados

Preciso atualizar scripts ou automação que fazem referência a recursos clássicos?

Não. Os modelos ARM existentes e as chamadas de API continuam a funcionar. Quando tenta criar um recurso clássico, em vez disso é criado um recurso baseado em espaço de trabalho com um espaço de trabalho gerido.

Sou notificado antes de meu recurso ser migrado?

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, use a migração manual.

Quanto tempo demora o processo de migração?

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

Como posso saber se um recurso foi migrado?

Após a migração, o recurso é vinculado a um espaço de trabalho do Log Analytics na página Visão geral. O aviso de aposentadoria tradicional é removido e o livro de registros de aposentadorias já não lista o recurso.

A minha faturação será alterada após a migração?

Os custos normalmente permanecem semelhantes. O Application Insights baseado em Workspace permite funcionalidades de poupança de custos, e recomendamos a revisão dos planos de preços.

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

Perco alertas ou testes de disponibilidade durante a migração?

Não. Todos os alertas, painéis e testes de disponibilidade permanecem intactos e continuam a funcionar após a migração.

Onde posso obter mais informações sobre espaços de trabalho gerenciados?

Para obter mais informações, consulte Espaços de trabalho gerenciados no Application Insights.

Node.js

Como posso desativar a correlação de telemetria?

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

Como posso configurar o nível de log desejado?

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

Onde posso obter mais informações sobre o monitoramento de Node.js serviços e aplicativos com o Application Insights?

Para obter mais informações, consulte Monitorar seus serviços e aplicativos Node.js com o Application Insights.

Azure Monitor OpenTelemetry (monitorização de telemetria aberta da Azure)

Onde posso encontrar uma lista de versões do SDK do Application Insights e seus nomes?

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

Onde posso obter mais informações sobre OpenTelemetry?

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

Migrar de SDKs do .NET Application Insights para o Azure Monitor OpenTelemetry

Como as APIs do SDK são mapeadas para os conceitos do OpenTelemetry ?

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 da 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 tempo de execução do .NET sem bibliotecas externas. Para obter mais informações, consulte os guias do .NET sobre rastreamento distribuído, métricas e log.

• Application Insights usa TelemetryModules para coletar telemetria automaticamente da sua aplicação. 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).

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

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

Como os tipos de telemetria do Application Insights são mapeados para o OpenTelemetry?

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

Tabela do Azure Monitor	Tipo de dados do Application Insights	OpenTelemetry Tipo de Dados	Implementação .NET
eventos personalizados	Telemetria de Eventos	N/A	N/A
customMetrics	Telemetria Métrica	Métricas	System.Diagnostics.Metrics.Meter
dependências	Dependência Telemetria	Spans (Cliente, Interno, Consumidor)	System.Diagnostics.Activity
exceções	Telemetria de Exceção	Exceções	System.Exception (Exceção do Sistema)
pedidos	Solicitar Telemetria	Spans (Servidor, Produtor)	System.Diagnostics.Activity
vestígios	Telemetria de Rastreamento	Registos	Microsoft.Extensões.Logging.ILogger
vestígios	Telemetria de Rastreamento	Eventos Span	System.Diagnostics.ActivityEvent

Os documentos seguintes fornecem mais informações.

• Noções básicas de coleta de dados do Azure Monitor Application Insights
• Modelo de dados telemétricos do Application Insights
• Conceitos de OpenTelemetry

Como os conceitos de amostragem do Application Insights são mapeados para o OpenTelemetry?

Enquanto o Application Insights oferecia várias opções para configurar a amostragem, o Azure Monitor Exporter ou o Azure Monitor Distro oferece apenas amostragem de taxa fixa. Somente solicitações e dependências (rastreamentos OpenTelemetry Traces) podem ser amostradas.

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

Como os processadores e inicializadores de telemetria são mapeados para o OpenTelemetry?

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

Filtrar rastros

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();
}

Filtrando registos

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

O exemplo a seguir define "Error" como o padrão LogLevel e também define "Warning" como o mínimo LogLevel para uma categoria definida pelo usuário. Estas regras, tal como 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 dados de telemetria com mais propriedades. É semelhante ao uso de inicializadores de telemetria no Application Insights, onde você pode modificar as propriedades de telemetria.

Por padrão, o Exportador do Monitor do Azure sinaliza qualquer solicitação HTTP com um código de resposta igual ou superior a 400 como falha. No entanto, se quiseres tratar 400 como um sucesso, podes adicionar um processador de atividades que enriquece a atividade atribuindo-lhe sucesso e acrescentando uma etiqueta 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.

Veja 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();
}

Como faço para rastrear manualmente a telemetria usando OpenTelemetry?

Envio de Rastros - Manual

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

O OpenTelemetry .NET utiliza as ActivitySource classes e Activity para rastreamento, que fazem parte do tempo de execução do .NET. Esta abordagem é singular porque a implementação do .NET integra a API de rastreamento diretamente no runtime. O System.Diagnostics.DiagnosticSource pacote permite que os desenvolvedores usem ActivitySource para criar e gerenciar Activity instâncias. 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:

Observação

No Application Insights, o nome da função e a instância da função podem ser definidos em um nível por telemetria. No entanto, com o exportador do Azure Monitor, não podemos personalizar a nível de telemetria. O nome da função e a instância da função são extraídos do recurso OpenTelemetry e aplicados em toda a telemetria. Leia este documento para obter mais informações: Defina o nome da função de nuvem e a instância de função de nuvem.

Dependência Telemetria

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));
}

Solicitar Telemetria

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 operações personalizadas usando StartOperation e StopOperation métodos. Conquiste-o usando ActivitySource e Activity no OpenTelemetry .NET. Para operações com ActivityKind.Server e ActivityKind.Consumer, o Azure Monitor Exporter gera RequestTelemetry. Para ActivityKind.Client, ActivityKind.Producer, e ActivityKind.Internal, 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 .NET.

Veja um exemplo de como iniciar e parar 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.
}

Envio de logs

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

Telemetria de Rastreamento

No OpenTelemetry, o registro em log é integrado através da ILogger interface. 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);
}

Telemetria de Exceção

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");
}

Métricas de envio

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étricas não pré-agregantes (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 métricos.

O OpenTelemetry, por outro lado, exige que os usuários primeiro escolham o instrumento métrico certo com base na semântica real da métrica. Por exemplo, se a intenção é contar algo (como o número total de solicitações de servidor recebidas, etc.), OpenTelemetry Counter deve ser usado. Se a intenção for calcular vários percentis (como o valor P99 da latência do servidor), então o instrumento OpenTelemetry Histogram 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, processadores e inicializadores de telemetria podem ser usados para modificar ou descartar métricas, mas esse recurso não está disponível no OpenTelemetry.

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

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

Sugestão

O histograma é o equivalente mais versátil e mais próximo da API do Application Insights GetMetric().TrackValue() . Você pode substituir as APIs do Application Insights Metric pelo Histograma para atingir a mesma finalidade.

Outros tipos de telemetria

Eventos Personalizados

Não suportado em OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackEvent()

DisponibilidadeTelemetria

Não suportado em OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackAvailability()

PageView-Telemetria

Não suportado em OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackPageView()

Posso obter métricas em tempo real para aplicativos de serviço de console e de trabalho?

Recomendamos o Azure Monitor OpenTelemetry Exporter para aplicativos de serviço de console e de trabalho, que não inclui métricas em tempo real.

Onde posso obter mais informações sobre como migrar de SDKs do .NET Application Insights para o OpenTelemetry?

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

Amostragem do OpenTelemetry

O amostrador personalizado do Application Insights é baseado em amostragem por cauda?

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

Embora este comportamento se assemelhe à amostragem baseada em cauda em alguns aspetos, o amostrador não espera recolher múltiplos segmentos do mesmo rastreio antes de decidir. Em vez disso, ele usa um hash da ID de rastreamento para ajudar a garantir a completude do rastreamento.

Essa abordagem equilibra a completude e a eficiência do rastreio e evita o custo mais alto associado à amostragem completa baseada na cauda.

Para tomar decisões de amostragem com base no resultado de um rastreamento inteiro (por exemplo, determinar se algum segmento dentro do rastreamento falhou), a amostragem completa com base na cauda é necessária em um agente ou coletor posterior. Esse recurso não é suportado no momento, mas você pode solicitá-lo como um novo recurso por meio do Hub de Feedback.

Como o amostrador personalizado do Application Insights se compara à amostragem baseada em cabeçalho ou rodapé do OpenTelemetry?

Método de amostragem	Ponto de decisão	Pontos fortes	Fraquezas
Baseado na cabeça	Antes do início de um intervalo	Baixa latência, sobrecarga mínima	Pode obter amostras de vestígios desejados, incluindo falhas
Baseado na cauda	Depois que os intervalos são armazenados temporariamente com base nos limites de tempo ou volume	Permite critérios de amostragem de vestígios altamente seletivos	Custo mais elevado e atraso de processamento acrescido
Amostrador personalizado do App Insights	Fim da geração de intervalos	Equilibra a completude do rastreio com a eficiência	Necessário para compatibilidade com métricas em tempo real e API clássica

Posso amostrar dependências, solicitações ou outros tipos de telemetria a taxas diferentes?

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

Como é que o amostrador personalizado do Application Insights propaga as decisões de amostragem?

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

O amostrador personalizado do Application Insights respeita as decisões de amostragem de serviços upstream?

Não, o amostrador 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 W3C Trace Context, não influenciam a decisão do serviço downstream. No entanto, ele realiza uma amostragem com base num hash do ID de rastreio para garantir a completude do rastreamento. Para melhorar a consistência e reduzir a chance de traços interrompidos, configure todos os componentes do sistema para usar o mesmo amostrador e taxa de amostragem.

Por que alguns rastreamentos aparecem incompletos mesmo ao usar o amostrador personalizado do Application Insights?

Existem várias razões pelas quais os vestígios podem aparecer incompletos:

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

Se um componente aplicar amostragem baseada em cabeçalhos sem propagar a decisão de amostragem (por meio de cabeçalhos W3C Trace Context), os serviços a jusante amostram o rastreamento independentemente, o que pode resultar em intervalos descartados. Como resultado, algumas partes do rastreamento nem sempre estão disponíveis quando visualizadas no Application Insights.

Onde posso obter mais informações sobre a amostragem OpenTelemetria?

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

Suporte e feedback do OpenTelemetry

O que é OpenTelemetry?

É um padrão de código aberto para observabilidade. Saiba mais em OpenTelemetry.

Por que o Microsoft Azure Monitor está investindo em OpenTelemetry?

A Microsoft está investindo no OpenTelemetry pelos seguintes motivos:

• É independente do fornecedor e fornece APIs/SDKs consistentes em todos os idiomas.
• Com o tempo, acreditamos que o OpenTelemetry permitirá que os clientes do Azure Monitor observem aplicativos escritos em idiomas além dos nossos idiomas suportados.
• Ele expande os tipos de dados que você pode coletar por meio de um rico conjunto de bibliotecas de instrumentação.
• Os SDKs (Software Development Kits) OpenTelemetry tendem a ter um desempenho mais eficiente em escala do que seus antecessores, os SDKs do Application Insights.
• O OpenTelemetry está alinhado com a estratégia da Microsoft de adotar o código aberto.

Qual é o status do OpenTelemetry?

Consulte Status do OpenTelemetry .

O que é a Distro OpenTelemetry do Azure Monitor?

Você pode pensar nele como um wrapper fino que agrupa todos os componentes do OpenTelemetry para uma experiência de primeira classe no Azure. Este wrapper também é chamado de distribuição em OpenTelemetry.

Por que devo usar a Distro OpenTelemetry do Azure Monitor?

Há várias vantagens em usar a Distro OpenTelemetry do Azure Monitor em relação à OpenTelemetry nativa da comunidade:

• Reduz o esforço de habilitação
• Suportado pela Microsoft
• Traz recursos específicos do Azure, como:
  • Amostragem compatível com SDKs clássicos do Application Insights
  • Autenticação do Microsoft Entra
  • Armazenamento off-line e novas tentativas automáticas
  • Statsbeat
  • Métricas padrão do Application Insights
  • Detetar metadados de recursos para preencher automaticamente o Nome da Função de Nuvem e a Instância de Função de Nuvem em vários ambientes do Azure
  • Métricas ao vivo

No espírito da OpenTelemetry, projetamos a distro para ser aberta e extensível. Por exemplo, você pode adicionar:

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

Como a Distro fornece uma distribuição OpenTelemetria, a Distro suporta qualquer coisa suportada pela OpenTelemetry. Por exemplo, você pode adicionar mais processadores de telemetria, exportadores ou bibliotecas de instrumentação, se o OpenTelemetry oferecer suporte a eles.

Observação

A Distro define o amostrador como um amostrador personalizado de taxa fixa para o Application Insights. Você pode alterar isso para um amostrador diferente, mas isso pode desativar alguns dos recursos incluídos da distro. Para obter mais informações sobre o amostrador suportado, consulte a seção Habilitar amostragem de Configurar o Azure Monitor OpenTelemetry.

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

Como posso testar a Distro OpenTelemetry do Azure Monitor?

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

Devo usar o OpenTelemetry ou o SDK do Application Insights?

Recomendamos usar a Distro OpenTelemetry do Azure Monitor para novos projetos quando seus recursos estiverem alinhados com suas necessidades de monitoramento. OpenTelemetry é uma estrutura padrão do setor que melhora a observabilidade entre plataformas e fornece uma abordagem padronizada para a coleta de telemetria.

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

• Rastreamento automático de dependências – o OpenTelemetry oferece suporte ao rastreamento de dependências, mas algumas dependências exigem configuração adicional em comparação com o rastreamento automático disponível nos SDKs do Application Insights.
• Tipos de telemetria personalizados, como AvailabilityTelemetry e PageViewTelemetry – OpenTelemetry não tem equivalentes diretos. Funcionalidade semelhante pode ser implementada através de instrumentação manual.
• Processadores e inicializadores de telemetria – O OpenTelemetry tem processadores e processadores de extensão, mas eles não substituem totalmente os processadores de telemetria e inicializadores do Application Insights em todos os cenários.
• Coleta de métricas estendida – 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 em relação aos SDKs do Application Insights, incluindo:

• Melhor padronização entre plataformas
• Um ecossistema mais amplo de bibliotecas de instrumentação
• Maior flexibilidade na recolha e tratamento de dados
• Neutralidade de fornecedor melhorada, embora a Distro OpenTelemetry do Azure Monitor ainda esteja otimizada para o Azure.

A integração OpenTelemetry do Azure Monitor está em constante evolução e a Microsoft continua a melhorar as suas capacidades. 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 mais adequado às suas necessidades.

Quando devo usar o exportador OpenTelemetry do Azure Monitor?

Para ASP.NET Core, Java, Node.js e Python, recomendamos o uso da Distro OpenTelemetry do Azure Monitor. É uma linha de código para começar.

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

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

Qual é o estado atual da versão dos recursos na Distro OpenTelemetry do Azure Monitor?

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

Característica	.NET	Node.js	Píton	Java
Rastreio distribuído	✅	✅	✅	✅
Métricas personalizadas	✅	✅	✅	✅
Métricas padrão	✅	✅	✅	✅
Amostragem de taxa fixa	✅	✅	✅	✅
Armazenamento offline e repetições automáticas	✅	✅	✅	✅
Relatório de exceções	✅	✅	✅	✅
Recolha de registos	✅	⚠️	✅	✅
Eventos personalizados	⚠️	⚠️	⚠️	✅
Autenticação do Microsoft Entra	✅	✅	✅	✅
Métricas em tempo real	✅	✅	✅	✅
Filtragem de métricas em tempo real	✅	❌	❌	❌
Detetar contexto de recursos para VM/VMSS e Serviço de Aplicativo	✅	❌	✅	✅
Detetar contexto de recursos para o Serviço Kubernetes do Azure (AKS) e funções	❌	❌	❌	✅
Eventos de teste de disponibilidade gerados usando a API de controle de disponibilidade	❌	❌	❌	✅
Filtrar solicitações, dependências, logs e exceções por ID de usuário anônimo e fonte sintética	❌	❌	❌	✅
Filtrar dependências, logs e exceções por nome da operação	❌	❌	❌	✅
Amostragem adaptável	❌	❌	❌	✅
Criador de perfil .NET	⚠️	❌	❌	⚠️
Depurador de Instantâneos	❌	❌	❌	❌

Chave

• ✅ Este recurso está disponível para todos os clientes com suporte formal.
• ⚠️ Esta funcionalidade está disponível como pré-visualização pública. Consulte Termos de utilização suplementares para pré-visualizações do Microsoft Azure.
• ❌ Este recurso não está disponível ou não é aplicável.

O OpenTelemetry pode ser usado para navegadores da web?

Sim, mas não o recomendamos e o Azure não o suporta. OpenTelemetry JavaScript é altamente otimizado para Node.js. Em vez disso, recomendamos o uso do SDK JavaScript do Application Insights.

Quando podemos esperar que o SDK OpenTelemetry esteja disponível para uso em navegadores da Web?

O SDK da Web OpenTelemetry não tem um cronograma de disponibilidade determinado. É provável que estejamos a vários anos de distância de um SDK de navegador que seja uma alternativa viável ao SDK JavaScript do Application Insights.

Posso testar o OpenTelemetry em um navegador da Web hoje?

A área restrita da Web 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.

A execução do Application Insights ao lado de agentes concorrentes como AppDynamics, DataDog e NewRelic é suportada?

Essa prática não é algo que planejamos testar ou suportar, embora nossas Distros permitam que você exporte para um ponto de extremidade OTLP ao lado do Azure Monitor simultaneamente.

Posso usar recursos de visualização em ambientes de produção?

Nós não recomendamos. Consulte Termos de utilização suplementares para pré-visualizações do Microsoft Azure.

Qual é a diferença entre instrumentação manual e automática?

Consulte a Visão geral do OpenTelemetry .

Posso usar o OpenTelemetry Collector?

Alguns clientes usam o OpenTelemetry Collector como uma alternativa de agente, embora a Microsoft ainda não ofereça suporte oficial a uma abordagem baseada em agente para monitoramento de aplicativos. Enquanto isso, a comunidade de código aberto contribuiu com um OpenTelemetry Collector Azure Monitor Exporter que alguns clientes estão usando para enviar dados para o Azure Monitor Application Insights. Isso não é suportado pela Microsoft.

Qual é a diferença entre OpenCensus e OpenTelemetry?

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

Em Grafana, por que vejo "Status 500. Não é possível visualizar eventos de rastreamento usando o visualizador de rastreamento"?

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

No Application Insights, a tabela 'Rastreamentos' 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 'Rastreamentos' não contribui diretamente para a visualização de 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 de telemetria e na terminologia. OpenTelemetry tornou-se um padrão para coletar e instrumentar dados de telemetria. Neste contexto, o termo «vestígios» adquiriu um novo significado. Em vez de logs brutos, 'Traces' no OpenTelemetry referem-se a uma forma mais rica e estruturada de telemetria que inclui vãos, que representam unidades individuais de trabalho. Essas extensões são cruciais para construir visualizações detalhadas de transações, permitindo um melhor monitoramento e diagnóstico de aplicativos nativos da nuvem.

Como devo instrumentar Blazor Apps?

Para instrumentar um aplicativo Blazor, primeiro identifique o modelo de hospedagem. Blazor Server suporta instrumentação completa baseada em OpenTelemetry. Blazor WebAssembly é executado no navegador e suporta instrumentação limitada através de JavaScript.

Onde posso obter mais informações sobre o suporte e feedback do OpenTelemetria?

Para obter mais informações, consulte OpenTelemetry Support and Feedback for Application Insights.

Painel de visão geral

Posso apresentar mais de 30 dias de dados?

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

Estou vendo um erro "recurso não encontrado" no painel.

Um erro "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 Painel do aplicativo novamente para recriar um novo.

Onde posso obter mais informações sobre o painel Visão geral?

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

Canais de telemetria

O canal do Application Insights garante a entrega da telemetria? Se não, quais são os cenários em que a telemetria pode ser perdida?

A resposta curta é que nenhum dos canais integrados oferece uma garantia do tipo transação de entrega de telemetria para o back-end. ServerTelemetryChannel é mais avançado em comparação com InMemoryChannel uma 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:

• Itens na memória são perdidos quando o aplicativo falha.
• A telemetria é perdida durante longos períodos de problemas de rede. A telemetria é armazenada no disco local durante interrupções de 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.
• Nos Aplicativos Web do Azure no Windows, o local de armazenamento em disco padrão é D:\local\LocalAppData. Esta localização não é persistente. Ele é eliminado em reinicializações de aplicativos, scale-outs e outras operações semelhantes, o que leva à perda de qualquer telemetria armazenada lá. Você pode substituir o padrão e especificar o armazenamento para 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 possa causar itens de telemetria duplicados. Esse comportamento ocorre quando ServerTelemetryChannel 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 houve um tempo limite.

O ServerTelemetryChannel funciona em sistemas diferentes do Windows?

Embora o nome de seu pacote e namespace inclua "WindowsServer", esse canal é suportado em 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 forma em todos os sistemas.

Observação

Com a versão 2.15.0-beta3 e superior, o armazenamento local agora é criado automaticamente para Linux, Mac e Windows. Para sistemas que não sejam Windows, o SDK criará automaticamente uma pasta de armazenamento local com base na seguinte lógica:

• ${TMPDIR}: Se a ${TMPDIR} variável de ambiente estiver definida, este local será usado.
• /var/tmp: Se o local anterior não existir, tentamos /var/tmp.
• /tmp: Se ambos os locais anteriores não existirem, tentamos tmp.
• Se nenhum desses locais existir, o armazenamento local não será criado e a configuração manual ainda será necessária. Para obter detalhes completos da implementação, consulte este repositório GitHub.

O SDK cria armazenamento local temporário? Os dados são criptografados no armazenamento?

O SDK armazena itens de telemetria no armazenamento local durante problemas de rede ou durante a limitação. Esses dados não são criptografados localmente.

Para 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.

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

Observação

Com a versão 2.15.0-beta3 e superior, o armazenamento local agora é criado automaticamente para Linux, Mac e Windows.

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.

Onde posso obter mais informações sobre canais de telemetria?

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

Pesquisa de transações

Quantos dados são retidos?

Consulte o resumo dos limites.

Como posso ver os dados POST nos meus pedidos de servidor?

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

Por que minha pesquisa do Azure Function não retorna resultados?

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

Onde posso obter mais informações sobre a Pesquisa de Transações?

Para obter mais informações, consulte Pesquisa e diagnóstico de transações.

Diagnóstico de transações

Por que vejo um único componente no gráfico e os outros componentes só aparecem como dependências externas sem detalhes?

Razões potenciais:

• Os outros componentes são instrumentados com o 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 forem instrumentados com os SDKs mais recentes do Application Insights, informe-nos através do canal de feedback no canto superior direito.

Vejo linhas duplicadas para as dependências. Esse comportamento é esperado?

Atualmente, estamos mostrando a chamada de dependência de saída separada da solicitação de entrada. Normalmente, as duas chamadas parecem idênticas, com apenas o valor de duração sendo diferente por causa da viagem de ida e volta da rede. O ícone principal e o estilo distinto das barras de duração ajudam a diferenciá-las. Esta apresentação dos dados é confusa? Dê-nos a sua opinião!

E quanto às distorções de relógio em diferentes instâncias de componentes?

As linhas do tempo são ajustadas para distorções de relógio no gráfico de transações. Você pode ver os carimbos de data/hora exatos no painel de detalhes ou usando o Log Analytics.

Por que a nova experiência está faltando a maioria das consultas de itens relacionados?

Este comportamento é intencional. 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 cobre: toda a telemetria de cinco minutos antes e depois deste evento e a linha do tempo do usuário.

Existe uma maneira de ver menos eventos por transação quando uso o SDK JavaScript do Application Insights?

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

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

Por que as durações de detalhes da transação não se somam à duração da solicitação superior?

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

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

E se eu vir a mensagem "Erro ao recuperar dados" enquanto navego pelo Application Insights no portal do Azure?

Este erro indica que o browser não conseguiu chamar uma API necessária ou a API devolveu uma resposta de falha. Para solucionar o comportamento, abra uma janela InPrivate do navegador e desative todas as extensões do navegador em execução e, em seguida, identifique se ainda é possível reproduzir o comportamento do portal. Se o erro do portal ainda ocorrer, tente testar com outros navegadores ou outras máquinas, investigue o DNS ou outros problemas relacionados à rede da máquina cliente em que as chamadas de API estão falhando. Se o erro do portal continuar e precisar de mais investigação, colete um rastreamento de rede do navegador enquanto reproduz o comportamento inesperado do portal e, em seguida, abra um caso de suporte do portal do Azure.

Onde posso obter mais informações sobre o Diagnóstico de Transações?

Para obter mais informações, consulte Pesquisa e diagnóstico de transações.

Análise de utilização

O evento inicial representa a primeira vez que o evento aparece em uma sessão ou sempre que aparece em uma sessão?

O evento inicial na 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 puderem enviar o evento inicial várias vezes em uma sessão, a coluna Etapa 1 mostrará apenas como os usuários se comportam após a primeira instância de um evento inicial, não todas as instâncias.

Alguns dos nós na minha visualização têm um nível muito alto. Como posso conseguir nós mais detalhados?

Utilize as Opções de Divisão no menu Editar:

1. Selecione o evento que deseja analisar no menu Evento.

2. Selecione uma dimensão no menu Dimensão . Por exemplo, se você tiver um evento chamado Button Clicked, tente uma propriedade personalizada chamada Button Name.

Defini uma coorte de utilizadores de um determinado país/região. Quando comparo esta coorte na ferramenta Utilizadores com a definição de um filtro nesse país/região, porque vejo resultados diferentes?

Coortes e filtros são diferentes. Suponha que você tenha um grupo de usuários do Reino Unido (definido como o exemplo anterior) e compare seus resultados com a 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 intervalo de tempo 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.

Como faço para visualizar os dados em diferentes níveis (diariamente, mensalmente ou semanalmente)?

Você pode selecionar o filtro Data Grain para alterar o grão. O filtro está disponível em todas as abas de dimensão.

Como faço para acessar informações do meu aplicativo que não estão disponíveis nas pastas de trabalho HEART?

Você pode analisar os dados que alimentam a pasta de trabalho HEART se os elementos visuais não responderem a todas as suas perguntas. Para realizar essa tarefa, na seção Monitoramento do Application Insights, selecione Logs e consulte a customEvents tabela. Alguns dos atributos do Click Analytics estão contidos no customDimensions campo.

Um exemplo de consulta é mostrado 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 dos Logs do Azure Monitor.

Posso editar elementos visuais na pasta de trabalho?

Sim. Para saber como editar modelos de pasta de trabalho, consulte Modelos de pastas de trabalho do Azure.

Onde posso obter mais informações sobre análise de uso?

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

Aplicativos do Serviço do Trabalhador

Que embalagem devo usar?

Cenário do aplicativo .NET Core	Embalagem
Sem HostedServices	Serviço de Trabalhadores
Com os serviços hospedados	AspNetCore (não WorkerService)
Com HostedServices, monitorizando apenas HostedServices	WorkerService (cenário raro)

Os HostedServices dentro de um aplicativo .NET Core usando o pacote AspNetCore podem ter o TelemetryClient injetado nele?

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

Como posso rastrear a telemetria que não é coletada automaticamente?

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

Posso usar o IDE do Visual Studio para integrar o Application Insights a um projeto do Worker Service?

Atualmente, a integração do IDE do Visual Studio é suportada apenas para aplicativos ASP.NET/ASP.NET Core. Este documento é atualizado quando o Visual Studio fornece suporte para integração de aplicativos do Serviço de Trabalho.

Posso habilitar o monitoramento do Application Insights usando ferramentas como o Azure Monitor Application Insights Agent (anteriormente Status Monitor v2)?

Não. Atualmente, o Azure Monitor Application Insights Agent oferece suporte apenas ao .NET .

Todos os recursos são suportados se eu executar meu aplicativo no Linux?

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

• Contadores de desempenho são suportados apenas no Windows, exceto para o processo CPU/Memória exibido em métricas ao vivo.

• ServerTelemetryChannel Embora esteja habilitado por padrão, se o aplicativo estiver sendo executado no Linux ou macOS, o canal não criará automaticamente uma pasta de armazenamento local para manter a telemetria temporariamente se houver problemas de rede. Devido a essa limitação, a telemetria é perdida quando há problemas temporários de rede ou 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();
       }
  

Onde posso obter mais informações sobre os aplicativos do Worker Service?

Para obter mais informações, consulte Application Insights for Worker Service applications (non-HTTP applications).

Perguntas frequentes oficiais sobre o Azure Monitor Application Insights. Encontre respostas para perguntas sobre como usar o Application Insights com o Azure Monitor.

Para obter informações detalhadas sobre a instrumentação de aplicativos para habilitar o Application Insights, consulte Noções básicas sobre coleta de dados.

Depois de habilitar o Application Insights instrumentando um aplicativo, sugerimos primeiro verificar as métricas em tempo real e o mapa do aplicativo.

A partir de aplicações Web de servidor:

• Solicitações HTTP.
• Dependências. Chamadas para bancos de dados SQL, chamadas HTTP para serviços externos, Azure Cosmos DB, Armazenamento de Tabela do Azure, Armazenamento de Blob 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 Azure Monitor Application Insights
  • Monitoramento do Azure para VMs ou conjuntos de dimensionamento de máquinas virtuais
  • Autor do Application Insightscollectd.
• Eventos e métricas personalizados que você codifica.
• Registos de rastreamento se tu configurares o coletor apropriado.

A partir das páginas Web do cliente:

• Exceções não detetadas na sua aplicação, incluindo informação sobre

  • Rasto de pilha
  • Detalhes da exceção e mensagem que acompanha o erro
  • Número de linha e coluna do erro
  • URL onde o erro foi gerado
  • As solicitações de dependência de rede feitas pela sua aplicação através de XML Http Request (XHR) e Fetch (a recolha de dados de Fetch está desativada por padrão) incluem informações sobre:
    • URL da fonte de dependência
    • Comando e Método usados para solicitar a dependência
    • Duração do pedido
    • Código de resultado e status de sucesso da solicitação
    • ID (se houver) do usuário que faz a solicitação
    • Contexto de correlação (se for caso disso) em que o pedido é feito

• Informações do utilizador (por exemplo, localização, rede, IP)

• Informações do dispositivo (por exemplo, navegador, sistema operacional, versão, idioma, modelo)

• Informações da Sessão

  Observação

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

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

De outras fontes, se as configurares:

• Diagnóstico do Azure
• Importar para Log Analytics
• Análise de logs
• Logstash

Para entender o número de recursos do Application Insights necessários para cobrir seu aplicativo ou componentes em todos os ambientes, consulte o guia de planejamento de implantação do Application Insights.

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

• Crie e atualize recursos do Application Insights.
• Defina o plano de preços.
• Obtenha a chave de instrumentação.
• Adicione um alerta de métrica.
• Adicione um teste de disponibilidade.

Não é possível configurar um relatório do explorador de métricas ou configurar a exportação contínua.

Utilize a API REST para executar consultas de Log Analytics.

Recomendamos a Distro OpenTelemetry do Azure Monitor.

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

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

Coleção

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 conservados por 90 dias, enquanto os instantâneos de depuração são conservados 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 sem formatação e garanta que seu código personalizado não colete detalhes pessoais ou outros detalhes confidenciais. Durante o desenvolvimento e o teste, verifique os dados enviados nas janelas de saída de depuração do IDE e do navegador.

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

O Application Insights é cobrado por meio do espaço de trabalho do Log Analytics no qual seus dados de log foram ingeridos. O nível de preço padrão do Pay-as-you-go Log Analytics inclui 5 GB por mês de franquia de dados gratuita por conta de cobrança. Saiba mais sobre as opções de preços dos logs do Azure Monitor.

• Se seu aplicativo Web do Azure estiver hospedado em um datacenter onde há um ponto de extremidade de coleta do Application Insights, não haverá cobrança.
• Se não houver nenhum ponto de extremidade de coleta no seu centro de dados anfitrião, a telemetria da sua aplicação incorrerá em encargos de saída do Azure.

Essa resposta depende da distribuição de nossos endpoints, não de onde seu 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 ela está indo. Consulte os preços da largura de banda do Azure para obter detalhes.

Se você estiver vendo cobranças inesperadas ou custos altos no Application Insights, este guia pode ajudar. Ele cobre causas comuns como alto volume de telemetria, picos de ingestão de dados e amostragem mal configurada. É especialmente útil se você estiver solucionando problemas relacionados a picos de custo, volume de telemetria, amostragem não funcionando, limites de dados, alta ingestão ou faturamento inesperado. Para começar, consulte Solucionar problemas de alta ingestão de dados no Application Insights.

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

Importante

Em 1º de março de 2025, o Azure desativará as versões herdadas do TLS em todos os serviços. Naquele momento, o Application Insights não suporta mais TLS 1.0, TLS 1.1 e os conjuntos de codificação e curvas elípticas TLS 1.2/1.3 herdados listados.

Para perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS e Suporte de TLS do Azure Resource Manager.

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

Ambos os TelemetryChannels perderão a telemetria em buffer se esta não for esvaziada antes que a aplicação seja desligada.

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

Para obter mais informações, consulte Descarregar dados.

Nenhum. Não é necessário envolver eles em cláusulas try-catch. Se o SDK encontrar problemas, ele irá gravar mensagens na saída do console de depuração e, se as mensagens passarem, na Pesquisa Diagnóstica.

Sim, a API de acesso a dados. Outras maneiras de extrair dados incluem Power BI em recurso baseado em espaço de trabalho.

O SDK do Application Insights não é compatível com a autoinstrumentação. Se a autoinstrumentação estiver ativada, as chamadas para Track() e outras APIs de eventos e métricas personalizados serão ignoradas.

Desative a autoinstrumentação no portal do Azure no separador Application Insights da página App Service 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 do seu aplicativo para o portal. Em Pesquisar, você vê o número de itens recebidos. Em gráficos de métricas que exibem uma contagem de eventos, você vê o número de eventos originais que ocorreram.

Cada item transmitido carrega uma itemCount propriedade que mostra quantos eventos originais esse item representa. Para observar a amostragem em operação, você pode executar esta consulta no Log Analytics:

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

Os alertas no Azure são apenas sobre métricas. Crie uma métrica personalizada que ultrapasse um limite de valor sempre que o evento ocorrer. Em seguida, defina um alerta na métrica. Você recebe uma notificação sempre que a métrica cruza o limite em qualquer direção. Você não receberá uma notificação até a primeira travessia, não importa se o valor inicial é alto ou baixo. Há sempre uma latência de alguns minutos.

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

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

• Se o seu computador tiver acesso à Internet, você poderá integrar a Galeria do PowerShell usando -Proxy parâmetros.
• Você também pode baixar manualmente o módulo e instalá-lo em 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.

• Você pode usar o cmdlet Get-ApplicationInsightsMonitoringStatus para verificar se a habilitação foi bem-sucedida.

• Use o Live Metrics para determinar rapidamente se seu aplicativo está enviando telemetria.

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

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

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

Exemplo 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 TLS usada para conexões HTTPS. A versão TLS depende do sistema operacional e do ambiente de tempo de execução em que o aplicativo é executado.

Para confirmar a versão do TLS em uso:

• Revise a documentação do seu sistema operacional e tempo de execução ou 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 suporte a linguagem e tempo de execução para TLS 1.2+

As seguintes versões 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 update 161 (8u161) ou posterior
• Python: distribuições Python construídas com 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 Linux modernas que usam 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 seu recurso interage precisa suportar 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 suportar a configuração TLS necessária, ele precisará ser atualizado com suporte para alguma combinação da configuração TLS pós-depreciação.

Os recursos afetados do Application Insights param de ingerir dados e não conseguem 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 afetará o comportamento apenas após 1º de maio de 2025. Para obter mais informações sobre operações CRUD, consulte Suporte TLS do Azure Resource Manager. Este recurso fornece mais detalhes sobre o suporte TLS e cronogramas de descontinuação.

Para quaisquer perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS.

Para obter mais informações, consulte Suporte a TLS.

Para remover o Application Insights, você precisa remover os pacotes e referências do NuGet 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 Opções do Gerenciador de Pacotes NuGet.
3. Para remover totalmente o Application Insights, verifique e exclua manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto. Para obter mais informações, consulte O que é criado automaticamente quando você adiciona o SDK do Application Insights?.

Quando você adiciona o Application Insights ao seu projeto, ele cria automaticamente arquivos e adiciona código a alguns de seus arquivos. A desinstalação exclusiva dos Pacotes NuGet nem sempre descarta os arquivos e o código. Para remover totalmente o Application Insights, você deve verificar e excluir manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto.

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

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

As seguintes partes de código são adicionadas 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 seu 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, consulte <ExcludeComponentCorrelationHttpHeadersOnDomains> em Application Insights for console applications.

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

ASP.NET Core 3.1 não é mais suportado pela 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 do construtor e chame o método TrackXXX() necessário nele. Não recomendamos a criação de instâncias novas TelemetryClient ou TelemetryConfiguration em um aplicativo ASP.NET Core. Uma instância singleton de TelemetryClient já está registrada no DependencyInjection contêiner, que compartilha TelemetryConfiguration com o resto da telemetria. Crie uma nova TelemetryClient instância somente se ela precisar de uma configuração separada do restante da telemetria.

O exemplo a seguir mostra como controlar mais 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, consulte Referência da API de 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.

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) na telemetria e pode fazer com que os custos (custos de desempenho e faturamento do Application Insights) aumentem significativamente, portanto, avalie os riscos cuidadosamente antes de usá-los.

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

Capture informações e logs menos severos alterando a configuração de log para o 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 a seguir não faz com que o provedor do Application Insights capture Information logs. Não o captura porque o SDK adiciona um filtro de log padrão que instrui ApplicationInsights a capturar apenas logs Warning e logs mais severos. O Application Insights requer uma substituição explícita.

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

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

O método UseApplicationInsights() de extensão ainda é suportado, mas está marcado como obsoleto no SDK do Application Insights versão 2.8.0 e posterior. Ele foi removido na próxima versão principal do SDK. Para habilitar a telemetria do Application Insights, use AddApplicationInsightsTelemetry() porque ela fornece sobrecargas para controlar algumas configurações. Além disso, em ASP.NET aplicativos 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, não será necessário habilitar a extensão do Application Insights no portal do Serviço de Aplicativo. Se a extensão estiver instalada, ela recuará quando detetar que o SDK já foi adicionado. Se você habilitar o Application Insights a partir da extensão, não será necessário instalar e atualizar o SDK. Mas se você habilitar o Application Insights seguindo as instruções neste artigo, terá mais flexibilidade porque:

• A telemetria do Application Insights continua a funcionar em:
  • Todos os sistemas operativos, incluindo Windows, Linux e Mac.
  • Todos os modos de publicação, incluindo autônomos 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 que não seja do Azure.
  • Todas as versões do .NET Core, incluindo versões de visualização.
• Você pode ver a telemetria localmente quando estiver depurando do Visual Studio.
• Você pode acompanhar mais telemetria personalizada usando a TrackXXX() API.
• Você tem controle total sobre a configuração.

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

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

• O SDK coleta contadores de eventos no Linux porque os contadores de desempenho só são suportados no Windows. A maioria das métricas é a mesma.

Não. Em alternativa, use Application Insights para aplicações de serviços de trabalho (aplicações não-HTTP) para serviços de trabalho.

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

Observação

Estas instruções são para desinstalar o ASP.NET Core SDK. Se você precisar desinstalar o ASP.NET SDK, consulte Como desinstalar o ASP.NET SDK?.

1. Desinstale o pacote Microsoft.ApplicationInsights.AspNetCore usando o Gerenciador de Pacotes NuGet.
2. Para remover totalmente o Application Insights, verifique e exclua manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto. Para obter mais informações, consulte O que é criado quando você adiciona o SDK do Application Insights?.

Quando você adiciona o Application Insights ao seu projeto, ele cria arquivos e adiciona código a alguns de seus arquivos. A desinstalação exclusiva dos Pacotes NuGet nem sempre descartará os arquivos e o código. Para remover totalmente o Application Insights, você deve verificar e excluir manualmente o código ou os arquivos adicionados junto com quaisquer chamadas de API adicionadas em seu projeto.

Quando você adiciona Telemetria do Application Insights a um projeto de modelo do Visual Studio ASP.NET Core, ele adiciona o seguinte código:

• [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, consulte <ExcludeComponentCorrelationHttpHeadersOnDomains> em Application Insights for console applications.

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

• Exception rate: A taxa de exceção é um contador de desempenho do sistema. O CLR conta todas as exceções manipuladas e não tratadas que são lançadas e divide o total em um intervalo de amostragem pelo comprimento do intervalo. O SDK do Application Insights coleta esse resultado e o envia para o portal.
• Exceptions: A métrica Exceções conta os TrackException relatórios recebidos pelo portal no intervalo de amostragem do gráfico. Inclui apenas as exceções tratadas em que você escreve TrackException chamadas em seu código. Ele não inclui todas as exceções não tratadas.

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 oferece suporte a 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 desativá-lo, defina uma variável de ambiente no servidor com as seguintes informações:

• Designação:APPINSIGHTS_JAVASCRIPT_ENABLED
• Valor:false

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

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

Use este código:

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

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

O controle de dependência no Application Insights não inclui o registro de corpos de resposta, pois geraria muita 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 de firewall: permita solicitações ao seu servidor a partir da lista longa e variável de agentes de testes web.
• Código personalizado: escreva seu próprio código para enviar solicitações periódicas ao seu servidor de dentro da intranet. Você pode executar testes da Web do Visual Studio para essa finalidade. O testador pode enviar os resultados para o Application Insights usando a TrackAvailability() API.

A cadeia de caracteres do agente do usuário é Mozilla/5.0 (compatível; MSIE 9,0; Windows NT 6.1; Tridente/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 suportados. Sempre que um teste da Web é executado, o serviço de teste de disponibilidade tenta entrar em contato com o ponto de extremidade remoto definido na configuração do teste da Web. É enviada uma mensagem Hello do Cliente TLS que contém toda a configuração TLS suportada no momento. Se o ponto de extremidade remoto compartilhar uma configuração TLS comum com o cliente de teste de disponibilidade, o handshake TLS será bem-sucedido. Caso contrário, o teste web falhará devido a um erro na ligação TLS.

Existem várias ferramentas disponíveis para testar qual configuração TLS um terminal suporta. Uma maneira seria seguir o exemplo detalhado nesta página. Se o seu ponto de extremidade remoto não estiver disponível através da Internet pública, você precisará garantir que valida a configuração TLS suportada no ponto de extremidade remoto a partir de uma máquina que tenha acesso para chamar seu ponto de extremidade.

Observação

Para conhecer as etapas para habilitar a configuração TLS necessária em seu servidor web, é melhor entrar em contato com a equipe proprietária da plataforma de hospedagem em que seu servidor web é executado, se o processo não for conhecido.

Não há um tipo único de exceção com o qual todas as falhas no handshake TLS afetadas por esta descontinuação se apresentariam. No entanto, a exceção mais comum com a qual o seu 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 TLS para o resultado do teste da Web que é potencialmente afetado.

A configuração TLS negociada durante uma execução de teste da Web não pode ser visualizada. Desde que a extremidade remota ofereça suporte à configuração TLS comum e sejam realizados testes de disponibilidade, nenhum impacto deve ser percebido após a obsolescência.

A depreciação do TLS detalhada neste documento só deve afetar o comportamento de execução dos testes de disponibilidade na web 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 TLS do Azure Resource Manager. Este recurso fornece mais detalhes sobre o suporte TLS e cronogramas de descontinuação.

Para quaisquer perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS.

Para obter mais informações, consulte Configurações TLS suportadas.

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

• Adiciona arquivos ao seu projeto:

  • ApplicationInsights.config
  • ai.js

• Instala 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 telemetria do cliente

• Inclui assemblagens em pacotes:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Insere itens em:

  • Web.config
  • packages.config

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

O Application Insights coleta telemetria para as solicitações que chegaram ao aplicativo. Se a falha ocorrer em WebApps/WebServer e a solicitação não chegar ao aplicativo do usuário, o Application Insights não terá nenhuma telemetria sobre isso.

A duração calculada serverresponsetime pelo Application Insights não corresponde 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 de 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 obter a documentação do produto 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 é a autoinstrumentação para o Azure Monitor Application Insights?.

Se pretender métricas personalizadas no Node.js, deve instrumentar manualmente as aplicações com a distribuição OpenTelemetry do Azure Monitor.

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

A autoinstrumentação AKS pode interromper a telemetria enviada a terceiros por um SDK OSS OpenTelemetry .

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

Ele sempre evita dados duplicados e garante o trabalho de métricas personalizadas.

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

Língua	Precedência
Node.js	Instrumentação manual
Java	Autoinstrumentação

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

A autoinstrumentação AKS injeta nos pods de aplicação a versão mais recente da Distro OpenTelemetry do Azure Monitor sempre que a sua implementação é alterada ou reiniciada.

A Distro OpenTelemetry pode ficar 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 as implantações semanalmente para garantir que uma versão recente da Distro esteja sendo usada.

Esse recurso alcança a autoinstrumentação injetando a Distro OpenTelemetry do Azure Monitor em pods de aplicativo.

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

Para Node.js, injetamos um binário de autoinstrumentação baseado na nossa distribuição OpenTelemetry do Azure Monitor para Node.js. Para mais informações, consulte a documentação da distribuição Node.js. Tenha em mente que não temos uma autoinstrumentação independente para Node.js por isso nossa documentação de distribuição é voltada para instrumentação manual. Você pode ignorar as etapas de configuração 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áveis de ambiente, etc. é aplicável a esse recurso.

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

As novas regiões do Azure exigem o uso de cadeias de conexão em vez de chaves de instrumentação. A cadeia de conexão identifica o recurso que você deseja associar aos seus dados de telemetria. Ele também permite que você modifique os pontos de extremidade que seu recurso usa como destino para sua telemetria. Copie a cadeia de conexão e adicione-a ao código do seu aplicativo ou a uma variável de ambiente.

Recomendamos que você use cadeias de conexão em vez de teclas 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 estão limitados a: desenvolvimento local e funções isoladas do .NET usando a integração 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 regionais de conformidade de dados, 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. Os pontos de extremidade regionais ajudam a garantir que a telemetria dos utilizadores em áreas regulamentadas seja enviada exclusivamente para os centros de dados 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 da conta ou configurações de localização.
• Conecte todos os recursos do Application Insights a um espaço de trabalho 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 do Application Insights da Região A usando a cadeia de conexão da Região A.
• Envie dados de usuários da Região B para o recurso do 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 de uso geral do Application Insights usando uma cadeia de conexão diferente.

Importante

O uso do ponto de extremidade global não garante a conformidade regional. Para atender aos requisitos de residência de dados, utilize sempre pontos de extremidade específicos para cada região e encaminhe a telemetria com base na região do utilizador.

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

Para obter mais informações, consulte Cadeias de conexão.

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

• Criação de um novo recurso do Application Insights na região desejada.
• Recriando quaisquer personalizações exclusivas do recurso original no novo.
• Atualizando seu aplicativo com a cadeia de conexão do novo recurso de região.
• Testes para garantir que tudo funcione conforme o esperado com o novo recurso do Application Insights.
• Decida manter ou excluir o recurso original do Application Insights. Excluir um recurso clássico significa perder todos os dados históricos. Se o recurso for baseado em espaço de trabalho, 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, mas não estão limitadas a:

• Recrie painéis e pastas de trabalho personalizados.
• Recrie ou atualize o escopo de quaisquer alertas de log/métrica personalizados.
• Recrie alertas de disponibilidade.
• Recrie quaisquer configurações personalizadas de controle de acesso baseado em função do Azure que sejam necessárias para que seus usuários acessem o novo recurso.
• Replicar configurações envolvendo amostragem de ingestão, retenção de dados, limite diário e ativaçã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 métricas ao vivo, canal de controle seguro. 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 configuradas novamente.

Não recomendamos o uso desse método para preencher a versão da API. A versão mais recente pode representar versões prévias, que podem conter alterações de quebra. Mesmo com versões mais recentes que não são prévias, as versões da API nem sempre são retrocompatíveis com os 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 e sugestões de modelo de dados ou esquema, use nosso repositório GitHub.

A Telemetria PageView inclui URL e você pode analisar o parâmetro UTM usando uma função regex no Kusto.

Ocasionalmente, esses dados podem estar ausentes ou imprecisos se o usuário ou a empresa desativar o envio do User Agent nas configurações do navegador. Os regexes do UA Parser podem não incluir 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. Apenas os valores numéricos funcionam com medidas personalizadas.

Para obter mais informações, consulte Modelo de dados de telemetria do Application Insights.

ApplicationInsightsLoggerProvider captura ILogger logs e cria TraceTelemetry a partir deles. Se um Exception objeto for passado para o Log método em ILogger, ExceptionTelemetry será criado em vez de TraceTelemetry.

Visualização da Telemetria ILogger

No portal do Azure, siga estes passos:

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

No Visual Studio (Depurador Local):

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

Se preferir enviar TraceTelemetrysempre, use este trecho:

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

O Application Insights captura e envia ILogger logs usando as mesmas TelemetryConfiguration informações usadas para todas as outras telemetrias. Mas há uma exceção. Por padrão, TelemetryConfiguration não está totalmente configurado quando você faz login a partir do Program.cs ou Startup.cs. Os logs destes locais não têm a configuração padrão, por isso, não estão a executar todas as instâncias de TelemetryInitializer e de TelemetryProcessor.

Quando usas o pacote independente, TelemetryClient não é injetado no contentor de injeção de dependência (DI). Você precisa criar uma nova instância de TelemetryClient e usar a mesma configuração que o provedor de logger usa, como mostra o código a seguir. Este requisito garante que a mesma configuração seja usada para a telemetria personalizada e a telemetria do 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;
   }  
}

Observação

Se utilizar o pacote Microsoft.ApplicationInsights.AspNetCore para habilitar o Application Insights, modifique esse código para obter TelemetryClient diretamente no construtor.

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 seu aplicativo.

Para obter mais informações, consulte Log do Application Insights com .NET.

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

Java Flight Recorder (JFR) é uma ferramenta para a recolha de dados de perfilização de uma aplicação Java em execução. O JFR é integrado à Java Virtual Machine (JVM) e é usado para solucionar problemas de desempenho. Saiba mais sobre o Java SE JFR Runtime.

O Java Profiling é um recurso gratuito com o Application Insights. O preço do Azure Monitor Application Insights é baseado no custo de ingestão.

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

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

'Diagnóstico e recomendações de desempenho' é um novo recurso que estará disponível em breve como Application Insights Java Diagnostics. Pode inscrever-se para pré-visualizar esta funcionalidade. A gravação JFR pode ser visualizada com o Java Mission Control (JMC).

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

Use Perfil Agora para a opção de criação de perfil sob demanda. Perfil Agora cria perfis imediatos de todos os agentes que estão anexados à instância do Application Insights.

A criação automatizada de perfis é acionada ao atingir um limite de recursos.

O Application Insights Java Agent atualmente suporta o monitoramento do consumo de CPU e memória. O limite de CPU é configurado como uma porcentagem de todos os núcleos disponíveis na máquina. Memória é a ocupação atual da região de memória permanente (OldGen) em relação ao tamanho máximo possível da região.

Analise os pré-requisitos.

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

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

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

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

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

Desenvolvimento local refere-se ao ambiente onde o aplicativo está sendo criado ou testado, como a máquina de um desenvolvedor ou uma instância do Azure Cloud Shell. 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 instrumentação manual, você deve colocar o JAR do agente do Application Insights no diretório apropriado e incluir o arquivo applicationinsights.json com as configurações de amostragem desejadas.

Para obter mais informações, consulte Substituições de amostragem - Azure Monitor Application Insights for Java.

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

Para obter mais informações, consulte Processadores de telemetria (visualização) - Azure Monitor Application Insights for Java.

• O JavaScript SDK define um cookie de usuário no web client, para identificar usuários que retornam, e um cookie de sessão para atividades de grupo.
• Se não houver um script do lado do cliente, você pode definir cookies no servidor.
• Se um usuário real usar seu site em navegadores diferentes, ou usando navegação privada/anônima, ou máquinas diferentes, eles serão contados mais de uma vez.
• Para identificar um usuário conectado em máquinas e navegadores, adicione uma chamada para setAuthenticatedUserContext().

O SDK JavaScript do Application Insights tem uma sobrecarga mínima em seu site. Com apenas 36 KB compactados e levando apenas ~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 carregados rapidamente 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 da sua página é enfileirado, para que você não perca nenhuma telemetria durante todo o ciclo de vida da página. Esse processo de configuração fornece à sua página um sistema de análise perfeito que é invisível para seus usuários.

Chrome mais recente ✔	Firefox mais recente ✔	v3.x: IE 9+ & Microsoft Edge ✔ v2.x: Compatível com IE 8+ & Microsoft Edge ✔	Opera mais recente ✔	Safari mais recente ✔

Para obter exemplos executáveis, consulte Exemplos do SDK JavaScript do Application Insights.

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

Esta declaração não significa que suportamos apenas o menor conjunto comum de recursos. Precisamos manter a compatibilidade do código ES3. Novos recursos precisam ser adicionados de uma maneira que não interrompa a análise de JavaScript do ES3 e adicionados como um recurso opcional.

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

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

Para obter mais informações, consulte Habilitar o monitoramento de usuários reais do Azure Monitor Application Insights.

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

Access-Control-Allow-Headers: Request-Id, traceparent, Request-Context, <your header>

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

Não. Os erros "502 bad gateway" e "503 service unavailable" nem sempre são capturados pelo Application Insights. Se apenas JavaScript do lado do cliente estiver sendo usado para monitoramento, esse comportamento será esperado porque a resposta de erro é retornada antes da página que contém o cabeçalho HTML com o snippet JavaScript de monitoramento sendo renderizado.

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 empregam soluções como proxies reversos para passar 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, para que não seja capturada imediatamente pelo Application Insights. Para ajudar a detetar 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 causas comuns de erros 502 e 503, consulte Solucionar erros HTTP de "502 bad gateway" e "503 service unavailable" no Serviço de Aplicativo do Azure.

Para obter mais informações, consulte Configuração do SDK 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 experiências. Como resultado, os usuários do Application Insights não podem alterar esses campos.

Ocasionalmente, esses dados podem estar ausentes ou imprecisos se o usuário ou a empresa desativar o envio do User Agent nas configurações do navegador. Os regexes do UA Parser podem não incluir 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 JavaScript do Application Insights.

Não. Os modelos ARM existentes e as chamadas de API continuam a funcionar. Quando tenta criar um recurso clássico, em vez disso é criado um recurso baseado em espaço de trabalho com um espaço de trabalho gerido.

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, use a migração manual.

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

Após a migração, o recurso é vinculado a um espaço de trabalho do Log Analytics na página Visão geral. O aviso de aposentadoria tradicional é removido e o livro de registros de aposentadorias já não lista o recurso.

Os custos normalmente permanecem semelhantes. O Application Insights baseado em Workspace permite funcionalidades de poupança de custos, e recomendamos a revisão dos planos de preços.

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

Não. Todos os alertas, painéis e testes de disponibilidade permanecem intactos e continuam a funcionar após a migração.

Para obter mais informações, consulte Espaços de trabalho gerenciados no Application Insights.

Para desabilitar a correlação de telemetria, use a correlationHeaderExcludedDomains propriedade em 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 APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL variável de ambiente. Os valores suportados 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 Monitorar seus serviços e aplicativos Node.js com o Application Insights.

Uma lista de versões e nomes do SDK está hospedada no GitHub. Para obter mais informações, consulte 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 da 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 tempo de execução do .NET sem bibliotecas externas. Para obter mais informações, consulte os guias do .NET sobre rastreamento distribuído, métricas e log.

• Application Insights usa TelemetryModules para coletar telemetria automaticamente da sua aplicação. 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).

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

• Application Insights utilizou TelemetryProcessors para filtrar 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 os conceitos do OpenTelemetry e suas implementações .NET.

Tabela do Azure Monitor	Tipo de dados do Application Insights	OpenTelemetry Tipo de Dados	Implementação .NET
eventos personalizados	Telemetria de Eventos	N/A	N/A
customMetrics	Telemetria Métrica	Métricas	System.Diagnostics.Metrics.Meter
dependências	Dependência Telemetria	Spans (Cliente, Interno, Consumidor)	System.Diagnostics.Activity
exceções	Telemetria de Exceção	Exceções	System.Exception (Exceção do Sistema)
pedidos	Solicitar Telemetria	Spans (Servidor, Produtor)	System.Diagnostics.Activity
vestígios	Telemetria de Rastreamento	Registos	Microsoft.Extensões.Logging.ILogger
vestígios	Telemetria de Rastreamento	Eventos Span	System.Diagnostics.ActivityEvent

Os documentos seguintes fornecem mais informações.

• Noções básicas de coleta de dados do Azure Monitor Application Insights
• Modelo de dados telemétricos do Application Insights
• Conceitos de OpenTelemetry

Enquanto o Application Insights oferecia várias opções para configurar a amostragem, o Azure Monitor Exporter ou o Azure Monitor Distro oferece apenas amostragem de taxa fixa. Somente solicitações e dependências (rastreamentos OpenTelemetry Traces) podem ser amostradas.

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 e modificar ou descartar essa informação. Use inicializadores de telemetria para adicionar ou modificar propriedades personalizadas. Para obter mais informações, consulte a documentação do Azure Monitor. O OpenTelemetry substitui esses conceitos por processadores de atividade ou log, que enriquecem e filtram a telemetria.

Filtrar rastros

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();
}

Filtrando registos

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

O exemplo a seguir define "Error" como o padrão LogLevel e também define "Warning" como o mínimo LogLevel para uma categoria definida pelo usuário. Estas regras, tal como 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 dados de telemetria com mais propriedades. É semelhante ao uso de inicializadores de telemetria no Application Insights, onde você pode modificar as propriedades de telemetria.

Por padrão, o Exportador do Monitor do Azure sinaliza qualquer solicitação HTTP com um código de resposta igual ou superior a 400 como falha. No entanto, se quiseres tratar 400 como um sucesso, podes adicionar um processador de atividades que enriquece a atividade atribuindo-lhe sucesso e acrescentando uma etiqueta 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.

Veja 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 Rastros - Manual

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

O OpenTelemetry .NET utiliza as ActivitySource classes e Activity para rastreamento, que fazem parte do tempo de execução do .NET. Esta abordagem é singular porque a implementação do .NET integra a API de rastreamento diretamente no runtime. O System.Diagnostics.DiagnosticSource pacote permite que os desenvolvedores usem ActivitySource para criar e gerenciar Activity instâncias. 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:

Observação

No Application Insights, o nome da função e a instância da função podem ser definidos em um nível por telemetria. No entanto, com o exportador do Azure Monitor, não podemos personalizar a nível de telemetria. O nome da função e a instância da função são extraídos do recurso OpenTelemetry e aplicados em toda a telemetria. Leia este documento para obter mais informações: Defina o nome da função de nuvem e a instância de função de nuvem.

Dependência Telemetria

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));
}

Solicitar Telemetria

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 operações personalizadas usando StartOperation e StopOperation métodos. Conquiste-o usando ActivitySource e Activity no OpenTelemetry .NET. Para operações com ActivityKind.Server e ActivityKind.Consumer, o Azure Monitor Exporter gera RequestTelemetry. Para ActivityKind.Client, ActivityKind.Producer, e ActivityKind.Internal, 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 .NET.

Veja um exemplo de como iniciar e parar 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.
}

Envio de logs

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

Telemetria de Rastreamento

No OpenTelemetry, o registro em log é integrado através da ILogger interface. 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);
}

Telemetria de Exceção

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");
}

Métricas de envio

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étricas não pré-agregantes (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 métricos.

O OpenTelemetry, por outro lado, exige que os usuários primeiro escolham o instrumento métrico certo com base na semântica real da métrica. Por exemplo, se a intenção é contar algo (como o número total de solicitações de servidor recebidas, etc.), OpenTelemetry Counter deve ser usado. Se a intenção for calcular vários percentis (como o valor P99 da latência do servidor), então o instrumento OpenTelemetry Histogram 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, processadores e inicializadores de telemetria podem ser usados para modificar ou descartar métricas, mas esse recurso não está disponível no OpenTelemetry.

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

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

Sugestão

O histograma é o equivalente mais versátil e mais próximo da API do Application Insights GetMetric().TrackValue() . Você pode substituir as APIs do Application Insights Metric pelo Histograma para atingir a mesma finalidade.

Outros tipos de telemetria

Eventos Personalizados

Não suportado em OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackEvent()

DisponibilidadeTelemetria

Não suportado em OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackAvailability()

PageView-Telemetria

Não suportado em OpenTelemetry.

Exemplo do Application Insights:

TelemetryClient.TrackPageView()

Recomendamos o Azure Monitor OpenTelemetry Exporter para aplicativos de serviço de console e de trabalho, que não inclui métricas em tempo real.

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

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

Embora este comportamento se assemelhe à amostragem baseada em cauda em alguns aspetos, o amostrador não espera recolher múltiplos segmentos do mesmo rastreio antes de decidir. Em vez disso, ele usa um hash da ID de rastreamento para ajudar a garantir a completude do rastreamento.

Essa abordagem equilibra a completude e a eficiência do rastreio e evita o custo mais alto associado à amostragem completa baseada na cauda.

Para tomar decisões de amostragem com base no resultado de um rastreamento inteiro (por exemplo, determinar se algum segmento dentro do rastreamento falhou), a amostragem completa com base na cauda é necessária em um agente ou coletor posterior. Esse recurso não é suportado no momento, mas você pode solicitá-lo como um novo recurso por meio do Hub de Feedback.

Método de amostragem	Ponto de decisão	Pontos fortes	Fraquezas
Baseado na cabeça	Antes do início de um intervalo	Baixa latência, sobrecarga mínima	Pode obter amostras de vestígios desejados, incluindo falhas
Baseado na cauda	Depois que os intervalos são armazenados temporariamente com base nos limites de tempo ou volume	Permite critérios de amostragem de vestígios altamente seletivos	Custo mais elevado e atraso de processamento acrescido
Amostrador personalizado do App Insights	Fim da geração de intervalos	Equilibra a completude do rastreio com a eficiência	Necessário para compatibilidade com métricas em tempo real e API clássica

Não, o amostrador aplica uma taxa fixa a todos os tipos de telemetria durante um rastreio. Solicitações, dependências e outros intervalos seguem a mesma porcentagem de amostragem. Para aplicar taxas diferentes por tipo de telemetria, considere o uso de processadores de extensão 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. Esta norma permite que as decisões de amostragem fluam entre serviços. No entanto, como o amostrador toma decisões de amostragem após a geração do span — após a chamada para serviços a jusante — a propagação carrega informações de amostragem incompletas. Essa limitação está em conformidade com a especificação W3C Trace Context, mas os serviços downstream não podem usar de forma confiável essa decisão de amostragem propagada.

Não, o amostrador 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 W3C Trace Context, não influenciam a decisão do serviço downstream. No entanto, ele realiza uma amostragem com base num hash do ID de rastreio para garantir a completude do rastreamento. Para melhorar a consistência e reduzir a chance de traços interrompidos, configure todos os componentes do sistema para usar o mesmo amostrador e taxa de amostragem.

Existem várias razões pelas quais os vestígios podem aparecer incompletos:

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

Se um componente aplicar amostragem baseada em cabeçalhos sem propagar a decisão de amostragem (por meio de cabeçalhos W3C Trace Context), os serviços a jusante amostram o rastreamento independentemente, o que pode resultar em intervalos descartados. Como resultado, algumas partes do rastreamento nem sempre estão disponíveis quando visualizadas no Application Insights.

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

É um padrão de código aberto para observabilidade. Saiba mais em OpenTelemetry.

A Microsoft está investindo no OpenTelemetry pelos seguintes motivos:

• É independente do fornecedor e fornece APIs/SDKs consistentes em todos os idiomas.
• Com o tempo, acreditamos que o OpenTelemetry permitirá que os clientes do Azure Monitor observem aplicativos escritos em idiomas além dos nossos idiomas suportados.
• Ele expande os tipos de dados que você pode coletar por meio de um rico conjunto de bibliotecas de instrumentação.
• Os SDKs (Software Development Kits) OpenTelemetry tendem a ter um desempenho mais eficiente em escala do que seus antecessores, os SDKs do Application Insights.
• O OpenTelemetry está alinhado com a estratégia da Microsoft de adotar o código aberto.

Consulte Status do OpenTelemetry .

Você pode pensar nele como um wrapper fino que agrupa todos os componentes do OpenTelemetry para uma experiência de primeira classe no Azure. Este wrapper também é chamado de distribuição em OpenTelemetry.

Há várias vantagens em usar a Distro OpenTelemetry do Azure Monitor em relação à OpenTelemetry nativa da comunidade:

• Reduz o esforço de habilitação
• Suportado pela Microsoft
• Traz recursos específicos do Azure, como:
  • Amostragem compatível com SDKs clássicos do Application Insights
  • Autenticação do Microsoft Entra
  • Armazenamento off-line e novas tentativas automáticas
  • Statsbeat
  • Métricas padrão do Application Insights
  • Detetar metadados de recursos para preencher automaticamente o Nome da Função de Nuvem e a Instância de Função de Nuvem em vários ambientes do Azure
  • Métricas ao vivo

No espírito da OpenTelemetry, projetamos a distro para ser aberta e extensível. Por exemplo, você pode adicionar:

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

Como a Distro fornece uma distribuição OpenTelemetria, a Distro suporta qualquer coisa suportada pela OpenTelemetry. Por exemplo, você pode adicionar mais processadores de telemetria, exportadores ou bibliotecas de instrumentação, se o OpenTelemetry oferecer suporte a eles.

Observação

A Distro define o amostrador como um amostrador personalizado de taxa fixa para o Application Insights. Você pode alterar isso para um amostrador diferente, mas isso pode desativar alguns dos recursos incluídos da distro. Para obter mais informações sobre o amostrador suportado, consulte a seção Habilitar amostragem de Configurar o Azure Monitor OpenTelemetry.

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

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

Recomendamos usar a Distro OpenTelemetry do Azure Monitor para novos projetos quando seus recursos estiverem alinhados com suas necessidades de monitoramento. OpenTelemetry é uma estrutura padrão do setor que melhora a observabilidade entre plataformas e fornece uma abordagem padronizada para a coleta de telemetria.

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

• Rastreamento automático de dependências – o OpenTelemetry oferece suporte ao rastreamento de dependências, mas algumas dependências exigem configuração adicional em comparação com o rastreamento automático disponível nos SDKs do Application Insights.
• Tipos de telemetria personalizados, como AvailabilityTelemetry e PageViewTelemetry – OpenTelemetry não tem equivalentes diretos. Funcionalidade semelhante pode ser implementada através de instrumentação manual.
• Processadores e inicializadores de telemetria – O OpenTelemetry tem processadores e processadores de extensão, mas eles não substituem totalmente os processadores de telemetria e inicializadores do Application Insights em todos os cenários.
• Coleta de métricas estendida – 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 em relação aos SDKs do Application Insights, incluindo:

• Melhor padronização entre plataformas
• Um ecossistema mais amplo de bibliotecas de instrumentação
• Maior flexibilidade na recolha e tratamento de dados
• Neutralidade de fornecedor melhorada, embora a Distro OpenTelemetry do Azure Monitor ainda esteja otimizada para o Azure.

A integração OpenTelemetry do Azure Monitor está em constante evolução e a Microsoft continua a melhorar as suas capacidades. 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 mais adequado às suas necessidades.

Para ASP.NET Core, Java, Node.js e Python, recomendamos o uso da Distro OpenTelemetry do Azure Monitor. É uma linha de código para começar.

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

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

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

Característica	.NET	Node.js	Píton	Java
Rastreio distribuído	✅	✅	✅	✅
Métricas personalizadas	✅	✅	✅	✅
Métricas padrão	✅	✅	✅	✅
Amostragem de taxa fixa	✅	✅	✅	✅
Armazenamento offline e repetições automáticas	✅	✅	✅	✅
Relatório de exceções	✅	✅	✅	✅
Recolha de registos	✅	⚠️	✅	✅
Eventos personalizados	⚠️	⚠️	⚠️	✅
Autenticação do Microsoft Entra	✅	✅	✅	✅
Métricas em tempo real	✅	✅	✅	✅
Filtragem de métricas em tempo real	✅	❌	❌	❌
Detetar contexto de recursos para VM/VMSS e Serviço de Aplicativo	✅	❌	✅	✅
Detetar contexto de recursos para o Serviço Kubernetes do Azure (AKS) e funções	❌	❌	❌	✅
Eventos de teste de disponibilidade gerados usando a API de controle de disponibilidade	❌	❌	❌	✅
Filtrar solicitações, dependências, logs e exceções por ID de usuário anônimo e fonte sintética	❌	❌	❌	✅
Filtrar dependências, logs e exceções por nome da operação	❌	❌	❌	✅
Amostragem adaptável	❌	❌	❌	✅
Criador de perfil .NET	⚠️	❌	❌	⚠️
Depurador de Instantâneos	❌	❌	❌	❌

Chave

• ✅ Este recurso está disponível para todos os clientes com suporte formal.
• ⚠️ Esta funcionalidade está disponível como pré-visualização pública. Consulte Termos de utilização suplementares para pré-visualizações do Microsoft Azure.
• ❌ Este recurso não está disponível ou não é aplicável.

Sim, mas não o recomendamos e o Azure não o suporta. OpenTelemetry JavaScript é altamente otimizado para Node.js. Em vez disso, recomendamos o uso do SDK JavaScript do Application Insights.

O SDK da Web OpenTelemetry não tem um cronograma de disponibilidade determinado. É provável que estejamos a vários anos de distância de um SDK de navegador que seja uma alternativa viável ao SDK JavaScript do Application Insights.

A área restrita da Web 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 suportar, embora nossas Distros permitam que você exporte para um ponto de extremidade OTLP ao lado do Azure Monitor simultaneamente.

Nós não recomendamos. Consulte Termos de utilização suplementares para pré-visualizações do Microsoft Azure.

Consulte a Visão geral do OpenTelemetry .

Alguns clientes usam o OpenTelemetry Collector como uma alternativa de agente, embora a Microsoft ainda não ofereça suporte oficial a uma abordagem baseada em agente para monitoramento de aplicativos. Enquanto isso, a comunidade de código aberto contribuiu com um OpenTelemetry Collector Azure Monitor Exporter que alguns clientes estão usando para enviar dados para o Azure Monitor Application Insights. Isso não é suportado pela Microsoft.

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

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

No Application Insights, a tabela 'Rastreamentos' 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 'Rastreamentos' não contribui diretamente para a visualização de 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 de telemetria e na terminologia. OpenTelemetry tornou-se um padrão para coletar e instrumentar dados de telemetria. Neste contexto, o termo «vestígios» adquiriu um novo significado. Em vez de logs brutos, 'Traces' no OpenTelemetry referem-se a uma forma mais rica e estruturada de telemetria que inclui vãos, que representam unidades individuais de trabalho. Essas extensões são cruciais para construir visualizações detalhadas de transações, permitindo um melhor monitoramento e diagnóstico de aplicativos nativos da nuvem.

Para instrumentar um aplicativo Blazor, primeiro identifique o modelo de hospedagem. Blazor Server suporta instrumentação completa baseada em OpenTelemetry. Blazor WebAssembly é executado no navegador e suporta instrumentação limitada através de JavaScript.

Para obter mais informações, consulte OpenTelemetry Support and Feedback for Application Insights.

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

Um erro "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 Painel do aplicativo novamente para recriar um 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 transação de entrega de telemetria para o back-end. ServerTelemetryChannel é mais avançado em comparação com InMemoryChannel uma 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:

• Itens na memória são perdidos quando o aplicativo falha.
• A telemetria é perdida durante longos períodos de problemas de rede. A telemetria é armazenada no disco local durante interrupções de 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.
• Nos Aplicativos Web do Azure no Windows, o local de armazenamento em disco padrão é D:\local\LocalAppData. Esta localização não é persistente. Ele é eliminado em reinicializações de aplicativos, scale-outs e outras operações semelhantes, o que leva à perda de qualquer telemetria armazenada lá. Você pode substituir o padrão e especificar o armazenamento para 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 possa causar itens de telemetria duplicados. Esse comportamento ocorre quando ServerTelemetryChannel 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 houve um tempo limite.

Embora o nome de seu pacote e namespace inclua "WindowsServer", esse canal é suportado em 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 forma em todos os sistemas.

Observação

Com a versão 2.15.0-beta3 e superior, o armazenamento local agora é criado automaticamente para Linux, Mac e Windows. Para sistemas que não sejam Windows, o SDK criará automaticamente uma pasta de armazenamento local com base na seguinte lógica:

• ${TMPDIR}: Se a ${TMPDIR} variável de ambiente estiver definida, este local será usado.
• /var/tmp: Se o local anterior não existir, tentamos /var/tmp.
• /tmp: Se ambos os locais anteriores não existirem, tentamos tmp.
• Se nenhum desses locais existir, o armazenamento local não será criado e a configuração manual ainda será necessária. Para obter detalhes completos da implementação, consulte este repositório GitHub.

O SDK armazena itens de telemetria no armazenamento local durante problemas de rede ou durante a limitação. Esses dados não são criptografados localmente.

Para 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.

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

Observação

Com a versão 2.15.0-beta3 e superior, o armazenamento local agora é criado automaticamente para Linux, Mac e Windows.

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.

Consulte o resumo dos limites.

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

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

Para obter mais informações, consulte Pesquisa e diagnóstico de transações.

Razões potenciais:

• Os outros componentes são instrumentados com o 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 forem instrumentados com os SDKs mais recentes do Application Insights, informe-nos através do canal de feedback no canto superior direito.

Atualmente, estamos mostrando a chamada de dependência de saída separada da solicitação de entrada. Normalmente, as duas chamadas parecem idênticas, com apenas o valor de duração sendo diferente por causa da viagem de ida e volta da rede. O ícone principal e o estilo distinto das barras de duração ajudam a diferenciá-las. Esta apresentação dos dados é confusa? Dê-nos a sua opinião!

As linhas do tempo são ajustadas para distorções de relógio no gráfico de transações. Você pode ver os carimbos de data/hora exatos no painel de detalhes ou usando o Log Analytics.

Este comportamento é intencional. 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 cobre: toda a telemetria de cinco minutos antes e depois deste 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 de operação. Por padrão, o SDK do Application Insights para JavaScript cria uma nova operação para cada exibição de página exclusiva. Em um aplicativo de página única (SPA), apenas um evento de exibição de página é gerado e um único ID de operação é usado para toda a telemetria gerada. Como resultado, muitos eventos podem estar correlacionados à mesma operação.

Nesses cenários, você pode usar o Rastreamento Automático de Rotas para criar automaticamente novas operações para navegação em seu SPA. Você deve ativar enableAutoRouteTracking para que uma exibição de página seja gerada sempre que a rota de URL for atualizada (a exibição de página lógica ocorre). Se quiser atualizar manualmente o ID da operação, chame appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Acionar manualmente um evento PageView também redefine 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 controlada. Esse problema pode ocorrer porque as chamadas externas não foram instrumentadas, automaticamente ou manualmente. Também pode ocorrer porque o tempo gasto estava em processo e não por causa de uma chamada externa.

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

Este erro indica que o browser não conseguiu chamar uma API necessária ou a API devolveu uma resposta de falha. Para solucionar o comportamento, abra uma janela InPrivate do navegador e desative todas as extensões do navegador em execução e, em seguida, identifique se ainda é possível reproduzir o comportamento do portal. Se o erro do portal ainda ocorrer, tente testar com outros navegadores ou outras máquinas, investigue o DNS ou outros problemas relacionados à rede da máquina cliente em que as chamadas de API estão falhando. Se o erro do portal continuar e precisar de mais investigação, colete um rastreamento de rede do navegador enquanto reproduz o comportamento inesperado do portal e, em seguida, abra um caso de suporte do portal do Azure.

Para obter mais informações, consulte Pesquisa e diagnóstico de transações.

O evento inicial na 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 puderem enviar o evento inicial várias vezes em uma sessão, a coluna Etapa 1 mostrará apenas como os usuários se comportam após a primeira instância de um evento inicial, não todas as instâncias.

Utilize as Opções de Divisão no menu Editar:

1. Selecione o evento que deseja analisar no menu Evento.

2. Selecione uma dimensão no menu Dimensão . Por exemplo, se você tiver um evento chamado Button Clicked, tente uma propriedade personalizada chamada Button Name.

Coortes e filtros são diferentes. Suponha que você tenha um grupo de usuários do Reino Unido (definido como o exemplo anterior) e compare seus resultados com a 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 intervalo de tempo 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 Data Grain para alterar o grão. O filtro está disponível em todas as abas de dimensão.

Você pode analisar os dados que alimentam a pasta de trabalho HEART se os elementos visuais não responderem a todas as suas perguntas. Para realizar essa tarefa, na seção Monitoramento do Application Insights, selecione Logs e consulte a customEvents tabela. Alguns dos atributos do Click Analytics estão contidos no customDimensions campo.

Um exemplo de consulta é mostrado 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 dos Logs do Azure Monitor.

Sim. Para saber como editar modelos de pasta de trabalho, consulte Modelos de pastas de trabalho do Azure.

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

Cenário do aplicativo .NET Core	Embalagem
Sem HostedServices	Serviço de Trabalhadores
Com os serviços hospedados	AspNetCore (não WorkerService)
Com HostedServices, monitorizando apenas HostedServices	WorkerService (cenário raro)

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

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

Atualmente, a integração do IDE do Visual Studio é suportada apenas para aplicativos ASP.NET/ASP.NET Core. Este documento é atualizado quando o Visual Studio fornece suporte para integração de aplicativos do Serviço de Trabalho.

Não. Atualmente, o Azure Monitor Application Insights Agent oferece suporte apenas ao .NET .

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

• Contadores de desempenho são suportados apenas no Windows, exceto para o processo CPU/Memória exibido em métricas ao vivo.

• ServerTelemetryChannel Embora esteja habilitado por padrão, se o aplicativo estiver sendo executado no Linux ou macOS, o canal não criará automaticamente uma pasta de armazenamento local para manter a telemetria temporariamente se houver problemas de rede. Devido a essa limitação, a telemetria é perdida quando há problemas temporários de rede ou 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 for Worker Service applications (non-HTTP applications).