Application Insights FAQ – Frequently Asked Questions

For detailed information about instrumenting applications to enable Application Insights, see data collection basics.

After enabling Application Insights by instrumenting an application, we suggest first checking out Live metrics and the Application map.

From server web apps:

• HTTP requests.
• Dependencies. Calls to SQL databases, HTTP calls to external services, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage, and Azure Queue Storage.
• Exceptions and stack traces.
• Performance counters: Performance counters are available when using:
  • Azure Monitor Application Insights agent
  • Azure monitoring for VMs or virtual machine scale sets
  • Application Insights collectd writer.
• Custom events and metrics that you code.
• Trace logs if you configure the appropriate collector.

From client webpages:

• Uncaught exceptions in your app, including information on

  • Stack trace
  • Exception details and message accompanying the error
  • Line & column number of error
  • URL where error was raised
  • Network Dependency Requests made by your app XML Http Request (XHR) and Fetch (fetch collection is disabled by default) requests, include information on:
    • Url of dependency source
    • Command & Method used to request the dependency
    • Duration of the request
    • Result code and success status of the request
    • ID (if any) of user making the request
    • Correlation context (if any) where request is made

• User information (for example, Location, network, IP)

• Device information (for example, Browser, OS, version, language, model)

• Session information

  Note

  For some applications, such as single-page applications (SPAs), the duration isn't always recorded and, in those cases, defaults to 0.

  For more information, see Data collection, retention, and storage in Application Insights.

From other sources, if you configure them:

• Azure diagnostics
• Import to Log Analytics
• Log Analytics
• Logstash

To understand the number of Application Insights resources required to cover your application or components across environments, see the Application Insights deployment planning guide.

You can write PowerShell scripts by using Azure Resource Monitor to:

• Create and update Application Insights resources.
• Set the pricing plan.
• Get the instrumentation key.
• Add a metric alert.
• Add an availability test.

You can't set up a metrics explorer report or set up continuous export.

Use the REST API to run Log Analytics queries.

We recommend the Azure Monitor OpenTelemetry Distro.

The ingestion schema and endpoint protocol are available publicly.

Most Application Insights data has a latency of under 5 minutes. Some data can take longer, which is typical for larger log files. See the Application Insights service-level agreement.

Collection

Application Insights collects telemetry about your app, including web server telemetry, web page telemetry, and performance counters. This data can be used to monitor your app's performance, health, and usage. You can select the ___location when you create a new Application Insights resource.

Retention and Storage

Data is sent to an Application Insights Log Analytics workspace. You can choose the retention period for raw data, from 30 to 730 days. Aggregated data is retained for 90 days, and debug snapshots are retained for 15 days.

Privacy

Application Insights doesn't handle sensitive data by default. We recommend you don't put sensitive data in URLs as plain text and ensure your custom code doesn't collect personal or other sensitive details. During development and testing, check the sent data in your IDE and browser's debugging output windows.

For archived information, see Data collection, retention, and storage in Application Insights.

Application Insights is billed through the Log Analytics workspace into which its log data ingested. The default Pay-as-you-go Log Analytics pricing tier includes 5 GB per month of free data allowance per billing account. Learn more about Azure Monitor logs pricing options.

• If your Azure web app is hosted in a datacenter where there's an Application Insights collection endpoint, there's no charge.
• If there's no collection endpoint in your host datacenter, your app's telemetry incurs Azure outgoing charges.

This answer depends on the distribution of our endpoints, not on where your Application Insights resource is hosted.

Yes, you can incur more network costs, which vary depending on the region the telemetry is coming from and where it's going. Refer to Azure bandwidth pricing for details.

If you're seeing unexpected charges or high costs in Application Insights, this guide can help. It covers common causes like high telemetry volume, data ingestion spikes, and misconfigured sampling. It's especially useful if you're troubleshooting issues related to cost spikes, telemetry volume, sampling not working, data caps, high ingestion, or unexpected billing. To get started, see Troubleshoot high data ingestion in Application Insights.

Application Insights uses Transport Layer Security (TLS) 1.2 and 1.3.

For any general questions around the legacy TLS problem, see Solving TLS problems and Azure Resource Manager TLS Support.

For more information, see Introduction to Application Insights.

Both TelemetryChannels will lose buffered telemetry if it isn't flushed before an application shuts down.

To avoid data loss, flush the TelemetryClient when an application is shutting down.

For more information, see Flushing data.

None. You don't need to wrap them in try-catch clauses. If the SDK encounters problems, it will log messages in the debug console output and, if the messages get through, in Diagnostic Search.

Yes, the data access API. Other ways to extract data include Power BI on workspace-based resource.

The Application Insights SDK isn't compatible with autoinstrumentation. If autoinstrumentation is enabled, calls to Track() and other custom events and metrics APIs will be ignored.

Turn off autoinstrumentation in the Azure portal on the Application Insights tab of the App Service page or set ApplicationInsightsAgent_EXTENSION_VERSION to disabled.

Sampling reduces the number of telemetry items (like requests and custom events) that are sent from your app to the portal. In Search, you see the number of items received. In metric charts that display a count of events, you see the number of original events that occurred.

Each item that's transmitted carries an itemCount property that shows how many original events that item represents. To observe sampling in operation, you can run this query in Log Analytics:

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

Azure alerts are only on metrics. Create a custom metric that crosses a value threshold whenever your event occurs. Then set an alert on the metric. You get a notification whenever the metric crosses the threshold in either direction. You won't get a notification until the first crossing, no matter whether the initial value is high or low. There's always a latency of a few minutes.

For more information, see Application Insights API for custom events and metrics.

Yes. There are multiple ways to download Application Insights Agent:

• If your computer has internet access, you can onboard to the PowerShell Gallery by using -Proxy parameters.
• You can also manually download the module and either install it on your computer or use it directly.

Each of these options is described in the detailed instructions.

Yes. In Application Insights Agent 2.0.0 and later, ASP.NET Core applications hosted in IIS are supported.

• You can use the Get-ApplicationInsightsMonitoringStatus cmdlet to verify that enablement succeeded.

• Use Live Metrics to quickly determine if your app is sending telemetry.

• You can also use Log Analytics to list all the cloud roles currently sending telemetry:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

To achieve proxy passthrough, configure a machine-level proxy or an application-level proxy. See DefaultProxy.

Example Web.config:

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

For more information, see Deploy Application Insights Agent for on-premises servers.

Application Insights and Azure Monitor don't control the TLS version used for HTTPS connections. The TLS version depends on the operating system and runtime environment where your application runs.

To confirm the TLS version in use:

• Review the documentation for your operating system and runtime or framework.
• Contact the appropriate support team if you need further help. Don't open a support request with Application Insights.

Example language and runtime support for TLS 1.2+

The following versions include integrated support for TLS 1.2 or higher:

• .NET / .NET Core: .NET Framework 4.6.2 or later, and all versions of .NET Core
• Java: Java 8 update 161 (8u161) or later
• Python: Python distributions built with OpenSSL 1.0.1 or later
• Node.js: Node.js version 10 or later

Example operating system support for TLS 1.2+

The following operating systems include integrated support for TLS 1.2 or higher:

• Windows: Windows 8, Windows Server 2012, and later
• Linux: Most modern Linux distributions that use OpenSSL 1.0.1 or later

To avoid service disruptions, each remote endpoint (including dependent requests) your resource interacts with needs to support at least one combination of the same Protocol Version, Cipher Suite, and Elliptical Curve mentioned earlier. If the remote endpoint doesn't support the needed TLS configuration, it needs to be updated with support for some combination of the post-deprecation TLS configuration.

Affected Application Insights resources stop ingesting data and can't access required application components. As a result, some features stop working.

The Transport Layer Security (TLS) deprecation detailed in this document should only affect the behavior after May 1, 2025. For more information about CRUD operations, see Azure Resource Manager TLS Support. This resource provides more details on TLS support and deprecation timelines.

For any general questions around the legacy TLS problem, see Solving TLS problems.

For more information, see TLS support.

To remove Application Insights, you need to remove the NuGet packages and references from the API in your application. You can uninstall NuGet packages by using the NuGet Package Manager in Visual Studio.

1. If trace collection is enabled, first uninstall the Microsoft.ApplicationInsights.TraceListener package by using the NuGet Package Manager but don't remove any dependencies.
2. Uninstall the Microsoft.ApplicationInsights.Web package and remove its dependencies by using the NuGet Package Manager and its Uninstall options within the NuGet Package Manager Options control.
3. To fully remove Application Insights, check and manually delete the added code or files along with any API calls you added in your project. For more information, see What is automatically created when you add the Application Insights SDK?.

When you add Application Insights to your project, it automatically creates files and adds code to some of your files. Solely uninstalling the NuGet Packages doesn't always discard the files and code. To fully remove Application Insights, you should check and manually delete the added code or files along with any API calls you added in your project.

When you add Application Insights Telemetry to a Visual Studio ASP.NET project, it adds the following files:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

The following pieces of code are automatically added:

• [Your project's name].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

  If your project has a Layout.cshtml file, the following code is added.

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

To disable telemetry correlation in configuration, see <ExcludeComponentCorrelationHttpHeadersOnDomains> in Application Insights for console applications.

For more information, see Configure Application Insights for your ASP.NET website.

ASP.NET Core 3.1 is no longer supported by Microsoft.

Application Insights SDK for ASP.NET Core version 2.8.0 and Visual Studio 2019 or later can be used with ASP.NET Core 3.1 applications.

Get an instance of TelemetryClient by using constructor injection and call the required TrackXXX() method on it. We don't recommend creating new TelemetryClient or TelemetryConfiguration instances in an ASP.NET Core application. A singleton instance of TelemetryClient is already registered in the DependencyInjection container, which shares TelemetryConfiguration with the rest of the telemetry. Create a new TelemetryClient instance only if it needs a configuration that's separate from the rest of the telemetry.

The following example shows how to track more telemetry from a controller.

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

For more information about custom data reporting in Application Insights, see Application Insights custom metrics API reference. A similar approach can be used for sending custom metrics to Application Insights by using the GetMetric API.

ASP.NET Core has built-in support for logging HTTP Request/Response information (including body) via ILogger. It's recommended to leverage this. This may potentially expose personally identifiable information (PII) in telemetry, and can cause costs (performance costs and Application Insights billing) to significantly increase, so evaluate the risks carefully before using this.

The default setting for Application Insights is to only capture Warning and more severe logs.

Capture Information and less severe logs by changing the logging configuration for the Application Insights provider as follows.

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

It's important to note that the following example doesn't cause the Application Insights provider to capture Information logs. It doesn't capture it because the SDK adds a default logging filter that instructs ApplicationInsights to capture only Warning logs and more severe logs. Application Insights requires an explicit override.

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

For more information, see ILogger configuration.

The extension method UseApplicationInsights() is still supported, but it's marked as obsolete in Application Insights SDK version 2.8.0 and later. It's removed in the next major version of the SDK. To enable Application Insights telemetry, use AddApplicationInsightsTelemetry() because it provides overloads to control some configuration. Also, in ASP.NET Core 3.X apps, services.AddApplicationInsightsTelemetry() is the only way to enable Application Insights.

If the SDK is installed at build time as shown in this article, you don't need to enable the Application Insights extension from the App Service portal. If the extension is installed, it backs off when it detects the SDK is already added. If you enable Application Insights from the extension, you don't have to install and update the SDK. But if you enable Application Insights by following instructions in this article, you have more flexibility because:

• Application Insights telemetry continues to work in:
  • All operating systems, including Windows, Linux, and Mac.
  • All publish modes, including self-contained or framework dependent.
  • All target frameworks, including the full .NET Framework.
  • All hosting options, including Web Apps, VMs, Linux, containers, AKS, and non-Azure hosting.
  • All .NET Core versions, including preview versions.
• You can see telemetry locally when you're debugging from Visual Studio.
• You can track more custom telemetry by using the TrackXXX() API.
• You have full control over the configuration.

Yes. In Application Insights Agent 2.0.0-beta1 and later, ASP.NET Core applications hosted in IIS are supported.

Yes. Feature support for the SDK is the same in all platforms, with the following exceptions:

• The SDK collects event counters on Linux because performance counters are only supported in Windows. Most metrics are the same.

No. Instead, use Application Insights for Worker Service applications (non-HTTP applications) for worker services.

To remove Application Insights, you need to remove the NuGet packages and references from the API in your application. You can uninstall NuGet packages by using the NuGet Package Manager in Visual Studio.

1. Uninstall the Microsoft.ApplicationInsights.AspNetCore package by using the NuGet Package Manager.
2. To fully remove Application Insights, check and manually delete the added code or files along with any API calls you added in your project. For more information, see What is created when you add the Application Insights SDK?.

When you add Application Insights to your project, it creates files and adds code to some of your files. Solely uninstalling the NuGet Packages won't always discard the files and code. To fully remove Application Insights, you should check and manually delete the added code or files along with any API calls you added in your project.

When you add Application Insights Telemetry to a Visual Studio ASP.NET Core template project, it adds the following code:

• [Your project's name].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
       }
  

To disable telemetry correlation in code, see <ExcludeComponentCorrelationHttpHeadersOnDomains> in Application Insights for console applications.

For more information, see Application Insights for ASP.NET Core.

• Exception rate: The Exception rate is a system performance counter. The CLR counts all the handled and unhandled exceptions that are thrown and divides the total in a sampling interval by the length of the interval. The Application Insights SDK collects this result and sends it to the portal.
• Exceptions: The Exceptions metric counts the TrackException reports received by the portal in the sampling interval of the chart. It includes only the handled exceptions where you write TrackException calls in your code. It doesn't include all unhandled exceptions.

For more information, see Counters for .NET in Application Insights.

Live Metrics don't show EventCounters. Use Metric Explorer or Analytics to see the telemetry.

Application Insights extension for ASP.NET Core doesn't yet support this feature.

For more information, see Counters for .NET in Application Insights.

Client-side monitoring is enabled by default for ASP.NET Core apps. If you want to disable it, define an environment variable in the server with the following information:

• Name: APPINSIGHTS_JAVASCRIPT_ENABLED
• Value: false

For more information, see Application Insights for Azure VMs and virtual machine scale sets.

Failed dependency calls have the success field set to False. The module DependencyTrackingTelemetryModule doesn't report ExceptionTelemetry. The full data model for dependency is described in Application Insights telemetry data model.

Use this code:

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

In the Log Analytics query view, timestamp represents the moment the TrackDependency() call was initiated, which occurs immediately after the dependency call response is received. To calculate the time when the dependency call began, you would take timestamp and subtract the recorded duration of the dependency call.

Dependency tracking in Application Insights doesn't include logging response bodies as it would generate too much telemetry for most applications.

For more information, see Dependency tracking.

Availability tests run on points of presence that are distributed around the globe. There are two solutions:

• Firewall door: Allow requests to your server from the long and changeable list of web test agents.
• Custom code: Write your own code to send periodic requests to your server from inside your intranet. You could run Visual Studio web tests for this purpose. The tester could send the results to Application Insights by using the TrackAvailability() API.

The user agent string is Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

For more information, see Availability tests.

Availability tests act as a distributed client in each of the supported web test locations. Every time a web test is executed the availability test service attempts to reach out to the remote endpoint defined in the web test configuration. A TLS Client Hello message is sent which contains all the currently supported TLS configuration. If the remote endpoint shares a common TLS configuration with the availability test client, then the TLS handshake succeeds. Otherwise, the web test fails with a TLS handshake failure.

There are several tools available to test what TLS configuration an endpoint supports. One way would be to follow the example detailed on this page. If your remote endpoint isn't available via the Public internet, you need to ensure you validate the TLS configuration supported on the remote endpoint from a machine that has access to call your endpoint.

There's no one exception type that all TLS handshake failures impacted by this deprecation would present themselves with. However, the most common exception your web test would start failing with would be The request was aborted: Couldn't create SSL/TLS secure channel. You should also be able to see any TLS related failures in the TLS Transport Troubleshooting Step for the web test result that is potentially impacted.

The TLS configuration negotiated during a web test execution can't be viewed. As long as the remote endpoint supports common TLS configuration with availability tests, no impact should be seen post-deprecation.

The TLS deprecation detailed in this document should only affect the availability test web test execution behavior after May 1, 2025. For more information about interacting with the availability test service for CRUD operations, see Azure Resource Manager TLS Support. This resource provides more details on TLS support and deprecation timelines.

For any general questions around the legacy TLS problem, see Solving TLS problems.

For more information, see Supported TLS configurations.

The details depend on the type of project. The following list is an example for a web application.

• Adds files to your project:

  • ApplicationInsights.config
  • ai.js

• Installs NuGet packages:

  • Application Insights API: The core API
  • Application Insights API for Web Applications: Used to send telemetry from the server
  • Application Insights API for JavaScript Applications: Used to send telemetry from the client

• Includes assemblies in packages:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Inserts items into:

  • Web.config
  • packages.config

• Inserts snippets into the client and server code to initialize them with the Application Insights resource ID. For example, in an MVC app, code is inserted into the main page Views/Shared/_Layout.cshtml. For new projects only, you add Application Insights to an existing project manually.

Application Insights collects telemetry for the requests that made it to the application. If the failure occurs in WebApps/WebServer, and the request didn't reach the user application, Application Insights doesn't have any telemetry about it.

The duration for serverresponsetime calculated by Application Insights doesn't necessarily match the server response time observed by Web Apps. This behavior is because Application Insights only counts the duration when the request actually reaches the user application. If the request is stuck or queued in WebServer, the waiting time is included in the Web Apps metrics but not in Application Insights metrics.

For more information, see Enable application monitoring in Azure App Service.

We follow the Microsoft Style Guide for product documentation published to the Microsoft Learn platform.

In general, we don't include a hyphen after the "auto" prefix.

For more information, see What is autoinstrumentation for Azure Monitor Application Insights?.

If you want custom metrics in Node.js, manually instrument applications with the Azure Monitor OpenTelemetry Distro.

Java allows custom metrics with autoinstrumentation. You can collect custom metrics by updating your code and enabling this feature. If your code already has custom metrics, then they flow through when autoinstrumentation is enabled.

AKS autoinstrumentation can disrupt the telemetry sent to third parties by an OSS OpenTelemetry SDK.

AKS autoinstrumentation is designed to coexist with both manual instrumentation options: the Application Insights classic API SDK and OpenTelemetry Distro.

It always prevents duplicate data and ensures custom metrics work.

Refer to this chart to determine when autoinstrumentation or manual instrumentation takes precedence.

Vulnerabilities detected in the Azure Monitor OpenTelemetry Distro are prioritized, fixed, and released in the next version.

AKS autoinstrumentation injects the latest version of the Azure Monitor OpenTelemetry Distro into your application pods every time your deployment is changed or restarted.

The OpenTelemetry Distro can become vulnerable on deployments that aren't changed or restarted for extended periods of time. For this reason, we suggest updating or restarting deployments weekly to ensure a recent version of the Distro is being used.

This feature achieves autoinstrumentation by injecting Azure Monitor OpenTelemetry Distro into application pods.

For Java, this feature integrates the standalone Azure Monitor OpenTelemetry Distro for Java. See our Java distro documentation to learn more about the Java instrumentation binary.

For Node.js, we inject an autoinstrumentation binary based on our Azure Monitor OpenTelemetry Distro for Node.js. For more information, see Node.js distro documentation. Keep in mind that we don't have a standalone autoinstrumentation for Node.js so our distro documentation is geared towards manual instrumentation. You can ignore code based configurations steps related to manual instrumentation. However, everything else in our distro documentation such as default settings, environment variable configurations, etc. is applicable to this feature.

For more information, see Autoinstrumentation for AKS.

New Azure regions require the use of connection strings instead of instrumentation keys. Connection string identifies the resource that you want to associate with your telemetry data. It also allows you to modify the endpoints your resource uses as a destination for your telemetry. Copy the connection string and add it to your application's code or to an environment variable.

We recommend that you use connection strings instead of instrumentation keys.

Set the APPLICATIONINSIGHTS_CONNECTION_STRING manually in all scenarios where the system doesn't provide it automatically. These scenarios include, but aren't limited to: local development and .NET Isolated Functions using ASP.NET Core integration. In these cases, the environment variable ensures the OpenTelemetry pipeline can send telemetry to Application Insights. For more information on configuring connection strings with an environment variable, see Configuring OpenTelemetry in Application Insights.

To meet regional data compliance requirements, use regional Application Insights endpoints instead of the global endpoint. The global endpoint doesn't guarantee that data stays within a specific region. Regional endpoints help ensure that telemetry from users in regulated areas is sent only to data centers in those regions.

To configure your global web application for regional compliance:

• Create one Application Insights resource per region with strict compliance requirements, such as the European Union or the United States.
• Create another Application Insights resource for users in all other regions.
• Configure your application to send telemetry to the appropriate Application Insights resource based on each user’s region. Determine the region using signals like IP address, account metadata, or ___location settings.
• Connect all Application Insights resources to a Log Analytics workspace if you need a unified query experience across regions.

For example:

• Send data from Region A users to the Region A Application Insights resource using the Region A connection string.
• Send data from Region B users to the Region B Application Insights resource using the Region B connection string.
• Send all other user data to a general-purpose Application Insights resource using a different connection string.

The following diagram shows an example setup for a global web application:

For more information, see Connection strings.

Transferring existing Application Insights resources between regions isn't supported, and you can't migrate historical data to a new region. The workaround involves:

• Creating a new Application Insights resource in the desired region.
• Re-creating any unique customizations from the original resource in the new one.
• Updating your application with the new region resource's connection string.
• Testing to ensure everything works as expected with the new Application Insights resource.
• Decide to either keep or delete the original Application Insights resource. Deleting a classic resource means to lose all historical data. If the resource is workspace-based, the data remains in Log Analytics, enabling access to historical data until the retention period expires.

Unique customizations that commonly need to be manually re-created or updated for the resource in the new region include but aren't limited to:

• Re-create custom dashboards and workbooks.
• Re-create or update the scope of any custom log/metric alerts.
• Re-create availability alerts.
• Re-create any custom Azure role-based access control settings that are required for your users to access the new resource.
• Replicate settings involving ingestion sampling, data retention, daily cap, and custom metrics enablement. These settings are controlled via the Usage and estimated costs pane.
• Any integration that relies on API keys, such as release annotations and live metrics secure control channel. You need to generate new API keys and update the associated integration.
• Continuous export in classic resources must be configured again.
• Diagnostic settings in workspace-based resources must be configured again.

We don't recommend using this method of populating the API version. The newest version can represent preview releases, which might contain breaking changes. Even with newer non-preview releases, the API versions aren't always backward compatible with existing templates. In some cases, the API version might not be available to all subscriptions.

For more information, see Create and configure Application Insights resources.

To report data model or schema problems and suggestions, use our GitHub repository.

PageView Telemetry includes URL and you could parse the UTM parameter using a regex function in Kusto.

Occasionally, this data might be missing or inaccurate if the user or enterprise disables sending User Agent in browser settings. The UA Parser regexes might not include all device information. Or Application Insights might not have adopted the latest updates.

This can occur if you're using string values. Only numeric values work with custom measurements.

For more information, see Application Insights telemetry data model.

ApplicationInsightsLoggerProvider captures ILogger logs and creates TraceTelemetry from them. If an Exception object is passed to the Log method on ILogger, ExceptionTelemetry is created instead of TraceTelemetry.

Viewing ILogger Telemetry

In the Azure portal:

1. Go to the Azure portal and access your Application Insights resource.
2. Select the Logs section inside Application Insights.
3. Use Kusto Query Language (KQL) to query ILogger messages stored in the traces table. Example Query: traces | where message contains "YourSearchTerm".
4. Refine your queries to filter ILogger data by severity, time range, or specific message content.

In Visual Studio (Local Debugger):

1. Start your application in debug mode within Visual Studio.
2. Open the Diagnostic Tools window while the application runs.
3. In the Events tab, ILogger logs appear along with other telemetry data.
4. To locate specific ILogger messages, use the search and filter features in the Diagnostic Tools window.

If you prefer to always send TraceTelemetry, use this snippet:

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

Application Insights captures and sends ILogger logs by using the same TelemetryConfiguration information that's used for every other telemetry. But there's an exception. By default, TelemetryConfiguration isn't fully set up when you log from Program.cs or Startup.cs. Logs from these places don't have the default configuration, so they aren't running all TelemetryInitializer instances and TelemetryProcessor instances.

When you use the standalone package, TelemetryClient isn't injected to the dependency injection (DI) container. You need to create a new instance of TelemetryClient and use the same configuration that the logger provider uses, as the following code shows. This requirement ensures that the same configuration is used for all custom telemetry and telemetry from 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;
   }  
}

The Application Insights extension in Azure Web Apps uses the new provider. You can modify the filtering rules in the appsettings.json file for your application.

For more information, see Application Insights logging with .NET.

The Java Profiler uses Java Flight Recorder (JFR) to profile your application using a customized configuration.

Java Flight Recorder (JFR) is a tool for collecting profiling data of a running Java application. JFR is integrated into the Java Virtual Machine (JVM) and is used for troubleshooting performance issues. Learn more about Java SE JFR Runtime.

Java Profiling is a free feature with Application Insights. Azure Monitor Application Insights pricing is based on ingestion cost.

Profiling data collected by the JFR includes: method and execution profiling data, garbage collection data, and lock profiles.

JFR recording can be viewed and analyzed with your preferred tool, for example Java Mission Control (JMC).

'Performance diagnostics and recommendations' is a new feature that is available soon as Application Insights Java Diagnostics. You can sign up to preview this feature. JFR recording can be viewed with Java Mission Control (JMC).

On-demand is user triggered profiling in real-time whereas automatic profiling is with preconfigured triggers.

Use Profile Now for the on-demand profiling option. Profile Now immediately profiles all agents that are attached to the Application Insights instance.

Automated profiling is triggered by reaching a resource threshold.

Application Insights Java Agent currently supports monitoring of CPU and memory consumption. CPU threshold is configured as a percentage of all available cores on the machine. Memory is the current Tenured memory region (OldGen) occupancy against the maximum possible size of the region.

Review the Prerequisites.

Yes, you can profile a JVM running microservices using the JFR.

For more information, see Azure Monitor Application Insights Profiler for Java.

No, sampling overrides is now generally available (GA) and can be used with both autoinstrumentation and manual instrumentation.

If you use autoinstrumentation, update the applicationinsights.json file in the Azure portal.

For autoinstrumentation, no manual agent upload is required. However, for manual instrumentation, you still need to include the Application Insights agent JAR file and configuration files in your deployment package.

Local development refers to the environment where the app is being built or tested, such as a developer's machine or an Azure Cloud Shell instance. Application server refers to the web server running the application, such as Tomcat 11 in an Azure App Service environment. When using manual instrumentation, you must ensure that the agent JAR file is correctly placed on the application server.

For autoinstrumentation, you can configure sampling overrides via the Azure portal. If using manual instrumentation, you should place the Application Insights agent JAR in the appropriate directory and include the applicationinsights.json file with your desired sampling settings.

For more information, see Sampling overrides - Azure Monitor Application Insights for Java.

TelemetryClient.trackTrace() is part of the Application Insights Classic SDK bridge, and the log processors only work with the new OpenTelemetry-based instrumentation.

For more information, see Telemetry processors (preview) - Azure Monitor Application Insights for Java.

• The JavaScript SDK sets a user cookie on the web client, to identify returning users, and a session cookie to group activities.
• If there's no client-side script, you can set cookies at the server.
• If one real user uses your site in different browsers, or by using in-private/incognito browsing, or different machines, they're counted more than once.
• To identify a signed-in user across machines and browsers, add a call to setAuthenticatedUserContext().

The Application Insights JavaScript SDK has a minimal overhead on your website. At just 36 KB gzipped, and taking only ~15 ms to initialize, the SDK adds a negligible amount of load time to your website. The minimal components of the library are quickly loaded when you use the SDK, and the full script is downloaded in the background.

Additionally, while the script is downloading from the CDN, all tracking of your page is queued, so you don't lose any telemetry during the entire life cycle of your page. This setup process provides your page with a seamless analytics system that's invisible to your users.

For runnable examples, see Application Insights JavaScript SDK samples.

We need to take necessary measures to ensure that this SDK continues to "work" and doesn't break the JavaScript execution when loaded by an older browser. It would be ideal to not support older browsers, but numerous large customers can't control which browser their users choose to use.

This statement doesn't mean that we only support the lowest common set of features. We need to maintain ES3 code compatibility. New features need to be added in a manner that wouldn't break ES3 JavaScript parsing and added as an optional feature.

See GitHub for full details on Internet Explorer 8 support.

Yes, the Application Insights JavaScript SDK is open source. To view the source code or to contribute to the project, see the official GitHub repository.

For more information, see Enable Azure Monitor Application Insights Real User Monitoring.

The server side needs to be able to accept connections with those headers present. Depending on the Access-Control-Allow-Headers configuration on the server side, it's often necessary to extend the server-side list by manually adding Request-Id, Request-Context, and traceparent (W3C distributed header).

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

Distributed tracing can be disabled in configuration.

No. The "502 bad gateway" and "503 service unavailable" errors aren't always captured by Application Insights. If only client-side JavaScript is being used for monitoring, this behavior would be expected because the error response is returned prior to the page containing the HTML header with the monitoring JavaScript snippet being rendered.

If the 502 or 503 response was sent from a server with server-side monitoring enabled, the errors are collected by the Application Insights SDK.

Even when server-side monitoring is enabled on an application's web server, sometimes a 502 or 503 error isn't captured by Application Insights. Many modern web servers don't allow a client to communicate directly. Instead, they employ solutions like reverse proxies to pass information back and forth between the client and the front-end web servers.

In this scenario, a 502 or 503 response might be returned to a client because of an issue at the reverse proxy layer, so it isn't captured out-of-box by Application Insights. To help detect issues at this layer, you might need to forward logs from your reverse proxy to Log Analytics and create a custom rule to check for 502 or 503 responses. To learn more about common causes of 502 and 503 errors, see Troubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable" in Azure App Service.

For more information, see Application Insights JavaScript SDK configuration.

The browser passes the User Agent string in the HTTP header of the request. The Application Insights ingestion service uses UA Parser to generate the fields you see in the data tables and experiences. As a result, Application Insights users are unable to change these fields.

Occasionally, this data might be missing or inaccurate if the user or enterprise disables sending User Agent in browser settings. The UA Parser regexes might not include all device information. Or Application Insights might not have adopted the latest updates.

For more information, see Enable a framework extension for Application Insights JavaScript SDK.

No. Existing ARM templates and API calls continue to work. When you attempt to create a classic resource, a workspace-based resource with a managed workspace is created instead.

No. Notification for individual resource migrations isn't available. To control when and how your resources are migrated, use manual migration.

Individual migrations usually complete in less than two minutes. The full rollout takes place over several weeks across all regions.

After migration, the resource links to a Log Analytics workspace on the Overview page. The classic retirement notice is removed, and the retirements workbook no longer lists the resource.

Costs typically remain similar. Workspace-based Application Insights enables cost-saving features and we recommend reviewing pricing plans.

If you're on a legacy billing model, review the pricing documentation for details.

No. All alerts, dashboards, and availability tests remain intact and continue to function after migration.

For more information, see Managed workspaces in Application Insights.

To disable telemetry correlation, use the correlationHeaderExcludedDomains property in configuration. For more information, see ApplicationInsights-node.js.

To configure the desired log level that Application Insights will use, use the APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL environment variable. The supported values are NONE, ERROR, WARN, INFO, DEBUG, VERBOSE and ALL. For more information, see ApplicationInsights-node.js.

For more information, see Monitor your Node.js services and apps with Application Insights.

A list of SDK versions and names is hosted on GitHub. For more information, see SDK Version.

For more information, see Collect telemetry with OpenTelemetry in Application Insights.

OpenTelemetry is a vendor neutral observability framework. There are no Application Insights APIs in the OpenTelemetry SDK or libraries. Before migrating, it's important to understand some of OpenTelemetry's concepts.

• In Application Insights, all telemetry was managed through a single TelemetryClient and TelemetryConfiguration. In OpenTelemetry, each of the three telemetry signals (Traces, Metrics, and Logs) has its own configuration. You can manually create telemetry via the .NET runtime without external libraries. For more information, see the .NET guides on distributed tracing, metrics, and logging.

• Application Insights used TelemetryModules to automatically collect telemetry for your application. Instead, OpenTelemetry uses Instrumentation libraries to collect telemetry from specific components (such as AspNetCore for Requests and HttpClient for Dependencies).

• Application Insights used TelemetryInitializers to enrich telemetry with additional information or to override properties. With OpenTelemetry, you can write a Processor to customize a specific signal. Additionally, many OpenTelemetry Instrumentation libraries offer an Enrich method to customize the telemetry generated by that specific component.

• Application Insights used TelemetryProcessors to filter telemetry. An OpenTelemetry Processor can also be used to apply filtering rules on a specific signal.

This table maps Application Insights data types to OpenTelemetry concepts and their .NET implementations.

The following documents provide more information.

• Data Collection Basics of Azure Monitor Application Insights
• Application Insights telemetry data model
• OpenTelemetry Concepts

While Application Insights offered multiple options to configure sampling, Azure Monitor Exporter or Azure Monitor Distro only offers fixed rate sampling. Only Requests and Dependencies (OpenTelemetry Traces) can be sampled.

For code samples detailing how to configure sampling, see our guide Enable Sampling

In the Application Insights .NET SDK, use telemetry processors to filter and modify or discard telemetry. Use telemetry initializers to add or modify custom properties. For more information, see the Azure Monitor documentation. OpenTelemetry replaces these concepts with activity or log processors, which enrich and filter telemetry.

Filtering Traces

To filter telemetry data in OpenTelemetry, you can implement an activity processor. This example is equivalent to the Application Insights example for filtering telemetry data as described in Azure Monitor documentation. The example illustrates where unsuccessful dependency calls are filtered.

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

To use this processor, you need to create a TracerProvider and add the processor before AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

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

Filtering Logs

ILogger implementations have a built-in mechanism to apply log filtering. This filtering lets you control the logs that are sent to each registered provider, including the OpenTelemetryLoggerProvider. "OpenTelemetry" is the alias for OpenTelemetryLoggerProvider, used in configuring filtering rules.

The following example defines "Error" as the default LogLevel and also defines "Warning" as the minimum LogLevel for a user defined category. These rules as defined only apply to the OpenTelemetryLoggerProvider.

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

For more information, please read the OpenTelemetry .NET documentation on logs.

Adding Custom Properties to Traces

In OpenTelemetry, you can use activity processors to enrich telemetry data with more properties. It's similar to using telemetry initializers in Application Insights, where you can modify telemetry properties.

By default, Azure Monitor Exporter flags any HTTP request with a response code of 400 or greater as failed. However, if you want to treat 400 as a success, you can add an enriching activity processor that sets the success on the activity and adds a tag to include more telemetry properties. It's similar to adding or modifying properties using an initializer in Application Insights as described in Azure Monitor documentation.

Here's an example of how to add custom properties and override the default behavior for certain response codes:

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

To use this processor, you need to create a TracerProvider and add the processor before AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

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

Sending Traces - Manual

Traces in Application Insights are stored as RequestTelemetry and DependencyTelemetry. In OpenTelemetry, traces are modeled as Span using the Activity class.

OpenTelemetry .NET utilizes the ActivitySource and Activity classes for tracing, which are part of the .NET runtime. This approach is distinctive because the .NET implementation integrates the tracing API directly into the runtime itself. The System.Diagnostics.DiagnosticSource package allows developers to use ActivitySource to create and manage Activity instances. This method provides a seamless way to add tracing to .NET applications without relying on external libraries, applying the built-in capabilities of the .NET ecosystem. For more detailed information, refer to the distributed tracing instrumentation walkthroughs.

Here's how to migrate manual tracing:

DependencyTelemetry

Application Insights DependencyTelemetry is used to model outgoing requests. Here's how to convert it to OpenTelemetry:

Application Insights Example:

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

OpenTelemetry Example:

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

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

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

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

RequestTelemetry

Application Insights RequestTelemetry models incoming requests. Here's how to migrate it to OpenTelemetry:

Application Insights Example:

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

OpenTelemetry Example:

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

Custom Operations Tracking

In Application Insights, track custom operations using StartOperation and StopOperation methods. Achieve it using ActivitySource and Activity in OpenTelemetry .NET. For operations with ActivityKind.Server and ActivityKind.Consumer, Azure Monitor Exporter generates RequestTelemetry. For ActivityKind.Client, ActivityKind.Producer, and ActivityKind.Internal, it generates DependencyTelemetry. For more information on custom operations tracking, see the Azure Monitor documentation. For more on using ActivitySource and Activity in .NET, see the .NET distributed tracing instrumentation walkthroughs.

Here's an example of how to start and stop an activity for custom operations:

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

Sending Logs

Logs in Application Insights are stored as TraceTelemetry and ExceptionTelemetry.

TraceTelemetry

In OpenTelemetry, logging is integrated via the ILogger interface. Here's how to migrate TraceTelemetry:

Application Insights Example:

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

OpenTelemetry Example:

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

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

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

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

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

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

ExceptionTelemetry

Application Insights uses ExceptionTelemetry to log exceptions. Here's how to migrate to OpenTelemetry:

Application Insights Example:

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

OpenTelemetry Example:

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

Sending Metrics

Metrics in Application Insights are stored as MetricTelemetry. In OpenTelemetry, metrics are modeled as Meter from the System.Diagnostics.DiagnosticSource package.

Application Insights has both non-pre-aggregating (TrackMetric()) and preaggregating (GetMetric().TrackValue()) Metric APIs. Unlike OpenTelemetry, Application Insights has no notion of Instruments. Application Insights has the same API for all the metric scenarios.

OpenTelemetry, on the other hand, requires users to first pick the right metric instrument based on the actual semantics of the metric. For example, if the intention is to count something (like the number of total server requests received, etc.), OpenTelemetry Counter should be used. If the intention is to calculate various percentiles (like the P99 value of server latency), then OpenTelemetry Histogram instrument should be used. Due to this fundamental difference between Application Insights and OpenTelemetry, no direct comparison is made between them.

Unlike Application Insights, OpenTelemetry doesn't provide built-in mechanisms to enrich or filter metrics. In Application Insights, telemetry processors and initializers could be used to modify or discard metrics, but this capability isn't available in OpenTelemetry.

Additionally, OpenTelemetry doesn't support sending raw metrics directly, as there's no equivalent to the TrackMetric() functionality found in Application Insights.

Migrating from Application Insights to OpenTelemetry involves replacing all Application Insights Metric API usages with the OpenTelemetry API. It requires understanding the various OpenTelemetry Instruments and their semantics.

Other Telemetry Types

CustomEvents

Not supported in OpenTelemetry.

Application Insights Example:

TelemetryClient.TrackEvent()

AvailabilityTelemetry

Not supported in OpenTelemetry.

Application Insights Example:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Not supported in OpenTelemetry.

Application Insights Example:

TelemetryClient.TrackPageView()

We recommend the Azure Monitor OpenTelemetry Exporter for console and worker service applications, which does not include live metrics.

For more information, see Migrate from .NET Application Insights SDKs to Azure Monitor OpenTelemetry.

The Application Insights custom sampler makes sampling decisions after span creation, rather than before, so it doesn't follow a traditional head-based approach. Instead, it applies sampling decisions at the end of span generation—after the span is complete but before export.

Although this behavior resembles tail-based sampling in some ways, the sampler doesn't wait to collect multiple spans from the same trace before deciding. Instead, it uses a hash of the Trace ID to help ensure trace completeness.

This approach balances trace completeness and efficiency, and avoids the higher cost associated with full tail-based sampling.

To make sampling decisions based on the outcome of an entire trace (for example, determining if any span within the trace failed), full tail-based sampling is required in a downstream Agent or Collector. This capability isn't currently supported, but you can request it as a new feature through the Feedback Hub.

No, the sampler applies a fixed rate across all telemetry types in a trace. Requests, dependencies, and other spans follow the same sampling percentage. To apply different rates per telemetry type, consider using OpenTelemetry span processors or (ingestion-time transformations)[opentelemetry-overview.md#telemetry-routing].

The Application Insights custom sampler propagates sampling decisions using the W3C Trace Context standard by default. This standard enables sampling decisions to flow between services. However, because the sampler makes sampling decisions at the end of span generation—after the call to downstream services—the propagation carries incomplete sampling information. This limitation complies with the W3C Trace Context specification, but downstream services can't reliably use this propagated sampling decision.

No, the Application Insights custom sampler always makes an independent sampling decision, even if the upstream service uses the same sampling algorithm. Sampling decisions from upstream services, including those using W3C Trace Context headers, don't influence the downstream service's decision. However, it does sample based on a hash of the Trace ID to ensure trace completeness. To improve consistency and reduce the chance of broken traces, configure all components in the system to use the same sampler and sampling rate.

There are several reasons traces can appear incomplete:

• Different nodes in a distributed system use different sampling approaches that don't coordinate decisions. For example, one node applies OpenTelemetry head-based sampling, and another node applies sampling via the Azure Monitor Custom Sampler.
• Different nodes are set to different sampling rates, even if they both use the same sampling approach.
• You set filtering, sampling, or rate caps in the service-side pipeline, and this configuration randomly samples out spans without considering trace completeness.

If one component applies head-based sampling without propagating the sampling decision (via W3C Trace Context headers), downstream services sample the trace independently, which can result in discarded spans. As a result, some parts of the trace aren't always available when viewed in Application Insights.

For more information, see Sampling in Azure Monitor Application Insights with OpenTelemetry.

It's an open-source standard for observability. Learn more at OpenTelemetry.

Microsoft is investing in OpenTelemetry for the following reasons:

• It's vendor-neutral and provides consistent APIs/SDKs across languages.
• Over time, we believe OpenTelemetry will enable Azure Monitor customers to observe applications written in languages beyond our supported languages.
• It expands the types of data you can collect through a rich set of instrumentation libraries.
• OpenTelemetry Software Development Kits (SDKs) tend to be more performant at scale than their predecessors, the Application Insights SDKs.
• OpenTelemetry aligns with Microsoft's strategy to embrace open source.

See OpenTelemetry Status.

You can think of it as a thin wrapper that bundles together all the OpenTelemetry components for a first-class experience on Azure. This wrapper is also called a distribution in OpenTelemetry.

There are several advantages to using the Azure Monitor OpenTelemetry Distro over native OpenTelemetry from the community:

• Reduces enablement effort
• Supported by Microsoft
• Brings in Azure-specific features such as:
  • Sampling compatible with classic Application Insights SDKs
  • Microsoft Entra authentication
  • Offline Storage and Automatic Retries
  • Statsbeat
  • Application Insights Standard Metrics
  • Detect resource metadata to autopopulate Cloud Role Name and Cloud Role Instance on various Azure environments
  • Live Metrics

In the spirit of OpenTelemetry, we designed the distro to be open and extensible. For example, you can add:

• An OpenTelemetry Protocol (OTLP) exporter and send to a second destination simultaneously
• Other instrumentation libraries not included in the distro

Because the Distro provides an OpenTelemetry distribution, the Distro supports anything supported by OpenTelemetry. For example, you can add more telemetry processors, exporters, or instrumentation libraries, if OpenTelemetry supports them.

For languages without a supported standalone OpenTelemetry exporter, the Azure Monitor OpenTelemetry Distro is the only currently supported way to use OpenTelemetry with Azure Monitor. For languages with a supported standalone OpenTelemetry exporter, you have the option of using either the Azure Monitor OpenTelemetry Distro or the appropriate standalone OpenTelemetry exporter depending on your telemetry scenario. For more information, see When should I use the Azure Monitor OpenTelemetry exporter?.

Check out our enablement docs for .NET, Java, JavaScript (Node.js), and Python.

We recommend using the Azure Monitor OpenTelemetry Distro for new projects when its capabilities align with your monitoring needs. OpenTelemetry is an industry-standard framework that enhances cross-platform observability and provides a standardized approach to telemetry collection.

However, the Application Insights SDKs still provide certain capabilities that aren't yet fully automated in OpenTelemetry, including:

• Automatic dependency tracking – OpenTelemetry supports dependency tracking, but some dependencies require additional configuration compared to the automatic tracking available in Application Insights SDKs.
• Custom telemetry types, such as AvailabilityTelemetry and PageViewTelemetry – OpenTelemetry doesn't have direct equivalents. Similar functionality can be implemented via manual instrumentation.
• Telemetry processors and initializers – OpenTelemetry has processors and span processors, but they don't fully replace Application Insights Telemetry Processors and Initializers in all scenarios.
• Extended metrics collection – While OpenTelemetry has a strong metrics system, some built-in metrics from Application Insights SDKs require manual setup in OpenTelemetry.

OpenTelemetry also provides advantages over the Application Insights SDKs, including:

• Better standardization across platforms
• A wider ecosystem of instrumentation libraries
• Greater flexibility in data collection and processing
• Improved vendor neutrality, though Azure Monitor OpenTelemetry Distro is still optimized for Azure.

Azure Monitor's OpenTelemetry integration is continuously evolving, and Microsoft continues to enhance its capabilities. If you're considering a transition, carefully evaluate whether OpenTelemetry currently meets your observability requirements or if the Application Insights SDK remains the better fit for your needs.

For ASP.NET Core, Java, Node.js, and Python, we recommend using the Azure Monitor OpenTelemetry Distro. It's one line of code to get started.

For all other .NET scenarios, including classic ASP.NET, console apps, Windows Forms (WinForms), etc., we recommend using the .NET Azure Monitor OpenTelemetry exporter: Azure.Monitor.OpenTelemetry.Exporter.

For more complex Python telemetry scenarios that require advanced configuration, we recommend using the Python Azure Monitor OpenTelemetry Exporter.

The following chart breaks out OpenTelemetry feature support for each language.

Key

• ✅ This feature is available to all customers with formal support.
• ⚠️ This feature is available as a public preview. See Supplemental terms of use for Microsoft Azure previews.
• ❌ This feature isn't available or isn't applicable.

Yes, but we don't recommend it and Azure doesn't support it. OpenTelemetry JavaScript is heavily optimized for Node.js. Instead, we recommend using the Application Insights JavaScript SDK.

The OpenTelemetry web SDK doesn't have a determined availability timeline. We're likely several years away from a browser SDK that is a viable alternative to the Application Insights JavaScript SDK.

The OpenTelemetry web sandbox is a fork designed to make OpenTelemetry work in a browser. It's not yet possible to send telemetry to Application Insights. The SDK doesn't define general client events.

This practice isn't something we plan to test or support, although our Distros allow you to export to an OTLP endpoint alongside Azure Monitor simultaneously.

We don't recommend it. See Supplemental terms of use for Microsoft Azure previews.

See the OpenTelemetry Overview.

Some customers use the OpenTelemetry Collector as an agent alternative, even though Microsoft doesn't officially support an agent-based approach for application monitoring yet. In the meantime, the open-source community contributed an OpenTelemetry Collector Azure Monitor Exporter that some customers are using to send data to Azure Monitor Application Insights. This is not supported by Microsoft.

OpenCensus is the precursor to OpenTelemetry. Microsoft helped bring together OpenTracing and OpenCensus to create OpenTelemetry, a single observability standard for the world. The current production-recommended Python SDK for Azure Monitor is based on OpenCensus. Microsoft is committed to making Azure Monitor based on OpenTelemetry.

You could be trying to visualize raw text logs rather than OpenTelemetry traces.

In Application Insights, the 'Traces' table stores raw text logs for diagnostic purposes. They aid in identifying and correlating traces associated with user requests, other events, and exception reports. However, the 'Traces' table doesn't directly contribute to the end-to-end transaction view (waterfall chart) in visualization tools like Grafana.

With the growing adoption of cloud-native practices, there's an evolution in telemetry collection and terminology. OpenTelemetry became a standard for collecting and instrumenting telemetry data. In this context, the term 'Traces' took on a new meaning. Rather than raw logs, 'Traces' in OpenTelemetry refer to a richer, structured form of telemetry that includes spans, which represent individual units of work. These spans are crucial for constructing detailed transaction views, enabling better monitoring and diagnostics of cloud-native applications.

To instrument a Blazor app, first identify the hosting model. Blazor Server supports full OpenTelemetry-based instrumentation. Blazor WebAssembly runs in the browser and supports limited instrumentation through JavaScript.

For more information, see OpenTelemetry Support and Feedback for Application Insights.

No, there's a limit of 30 days of data displayed in a dashboard.

A "resource not found" error can occur if you move or rename your Application Insights instance.

To work around this behavior, delete the default dashboard and select Application Dashboard again to re-create a new one.

For more information, see Application Insights Overview dashboard.

The short answer is that none of the built-in channels offer a transaction-type guarantee of telemetry delivery to the back end. ServerTelemetryChannel is more advanced compared with InMemoryChannel for reliable delivery, but it also makes only a best-effort attempt to send telemetry. Telemetry can still be lost in several situations, including these common scenarios:

• Items in memory are lost when the application crashes.
• Telemetry is lost during extended periods of network problems. Telemetry is stored to local disk during network outages or when problems occur with the Application Insights back end. However, items older than 48 hours are discarded.
• The default disk locations for storing telemetry in Windows are %LOCALAPPDATA% or %TEMP%. These locations are typically local to the machine. If the application migrates physically from one ___location to another, any telemetry stored in the original ___location is lost.
• In Azure Web Apps on Windows, the default disk-storage ___location is D:\local\LocalAppData. This ___location isn't persisted. It's wiped out in app restarts, scale-outs, and other such operations, which leads to loss of any telemetry stored there. You can override the default and specify storage to a persisted ___location like D:\home. However, such persisted locations are served by remote storage and so can be slow.

Although less likely, it's also possible that the channel can cause duplicate telemetry items. This behavior occurs when ServerTelemetryChannel retries because of network failure or timeout, when the telemetry was delivered to the back end, but the response was lost because of network issues or there was a timeout.

Although the name of its package and namespace includes "WindowsServer," this channel is supported on systems other than Windows, with the following exception. On systems other than Windows, the channel doesn't create a local storage folder by default. You must create a local storage folder and configure the channel to use it. After local storage has been configured, the channel works the same way on all systems.

The SDK stores telemetry items in local storage during network problems or during throttling. This data isn't encrypted locally.

For Windows systems, the SDK automatically creates a temporary local folder in the %TEMP% or %LOCALAPPDATA% directory and restricts access to administrators and the current user only.

For systems other than Windows, no local storage is created automatically by the SDK, so no data is stored locally by default.

You can create a storage directory yourself and configure the channel to use it. In this case, you're responsible for ensuring that the directory is secured. Read more about data protection and privacy.

For more information, see Telemetry channels in Application Insights.

See the Limits summary.

We don't log the POST data automatically, but you can use TrackTrace or log calls. Put the POST data in the message parameter. You can't filter on the message in the same way you can filter on properties, but the size limit is longer.

Azure Functions doesn't log URL query strings.

For more information, see Transaction Search and Diagnostics.

Potential reasons:

• Are the other components instrumented with Application Insights?
• Are they using the latest stable Application Insights SDK?
• If these components are separate Application Insights resources, validate you have access. If you do have access and the components are instrumented with the latest Application Insights SDKs, let us know via the feedback channel in the upper-right corner.

Currently, we're showing the outbound dependency call separate from the inbound request. Typically, the two calls look identical with only the duration value being different because of the network round trip. The leading icon and distinct styling of the duration bars help differentiate between them. Is this presentation of the data confusing? Give us your feedback!

Timelines are adjusted for clock skews in the transaction chart. You can see the exact timestamps in the details pane or by using Log Analytics.

This behavior is by design. All the related items, across all components, are already available on the left side in the top and bottom sections. The new experience has two related items that the left side doesn't cover: all telemetry from five minutes before and after this event and the user timeline.

The transaction diagnostics experience shows all telemetry in a single operation that shares an Operation ID. By default, the Application Insights SDK for JavaScript creates a new operation for each unique page view. In a single-page application (SPA), only one page view event is generated and a single Operation ID is used for all telemetry generated. As a result, many events might be correlated to the same operation.

In these scenarios, you can use Automatic Route Tracking to automatically create new operations for navigation in your SPA. You must turn on enableAutoRouteTracking so that a page view is generated every time the URL route is updated (logical page view occurs). If you want to manually refresh the Operation ID, call appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Manually triggering a PageView event also resets the Operation ID.

Time not explained in the Gantt chart is time that isn't covered by a tracked dependency. This issue can occur because external calls weren't instrumented, either automatically or manually. It can also occur because the time taken was in process rather than because of an external call.

If all calls were instrumented, in process is the likely root cause for the time spent. A useful tool for diagnosing the process is the .NET Profiler.

This error indicates that the browser was unable to call into a required API or the API returned a failure response. To troubleshoot the behavior, open a browser InPrivate window and disable any browser extensions that are running, then identify if you can still reproduce the portal behavior. If the portal error still occurs, try testing with other browsers, or other machines, investigate DNS or other network related issues from the client machine where the API calls are failing. If the portal error continues and needs more investigation, collect a browser network trace while reproducing the unexpected portal behavior, then open a support case from the Azure portal.

For more information, see Transaction Search and Diagnostics.

The initial event on the visualization only represents the first time a user sent that page view or custom event during a session. If users can send the initial event multiple times in a session, then the Step 1 column only shows how users behave after the first instance of an initial event, not all instances.

Use the Split by options on the Edit menu:

1. Select the event you want to break down on the Event menu.

2. Select a dimension on the Dimension menu. For example, if you have an event called Button Clicked, try a custom property called Button Name.

Cohorts and filters are different. Suppose you have a cohort of users from the United Kingdom (defined like the previous example), and you compare its results to setting the filter Country or region = United Kingdom:

• The cohort version shows all events from users who sent one or more events from the United Kingdom in the current time range. If you split by country or region, you likely see many countries and regions.

• The filters version only shows events from the United Kingdom. If you split by country or region, you see only the United Kingdom.

You can select the Date Grain filter to change the grain. The filter is available across all the dimension tabs.

You can dig into the data that feeds the HEART workbook if the visuals don't answer all your questions. To do this task, under the Monitoring section in Application Insights, select Logs, and query the customEvents table. Some of the Click Analytics attributes are contained within the customDimensions field.

An example query is shown here:

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

To learn more about Logs in Azure Monitor, see Azure Monitor Logs overview.

Yes. To learn how to edit workbook templates, see Azure Workbooks templates.

For more information, see Usage analysis with Application Insights.

Yes, the configuration is shared with the rest of the web application.

Get an instance of TelemetryClient by using constructor injection and call the required TrackXXX() method on it. We don't recommend creating new TelemetryClient instances. A singleton instance of TelemetryClient is already registered in the DependencyInjection container, which shares TelemetryConfiguration with the rest of the telemetry. Creating a new TelemetryClient instance is recommended only if it needs a configuration that's separate from the rest of the telemetry.

Visual Studio IDE onboarding is currently supported only for ASP.NET/ASP.NET Core applications. This document is updated when Visual Studio ships support for onboarding Worker Service applications.

No. Azure Monitor Application Insights Agent currently supports .NET only.

Yes. Feature support for this SDK is the same in all platforms, with the following exceptions:

• Performance counters are supported only in Windows except for Process CPU/Memory shown in live metrics.

• Even though ServerTelemetryChannel is enabled by default, if the application is running in Linux or macOS, the channel doesn't automatically create a local storage folder to keep telemetry temporarily if there are network issues. Because of this limitation, telemetry is lost when there are temporary network or server issues. To work around this issue, configure a local folder for the channel:

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

For more information, see Application Insights for Worker Service applications (non-HTTP applications).