Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Application Insights collects telemetry from your application to help diagnosing failures and investigating slow transactions. It includes four essential tools:
Failures - Tracks errors, exceptions, and faults, offering clear insights for fast problem-solving and enhanced stability.
Performance - Quickly identifies and helps resolve application bottlenecks by displaying response times and operation counts.
Transaction search - Enables users to locate and examine individual telemetry items such as page views, exceptions, and custom events.
Transaction diagnostics - Helps to quickly identify issues in components through comprehensive insight into end-to-end transaction details.
Together, these tools ensure the ongoing health and efficiency of web applications. You can use them to pinpoint issues or enhancements that would have the most impact on users.
To get to the Failures view in Application Insights, select either the Failed requests graph on the Overview pane, or Failures under the Investigate category in the resource menu.
You can also get to the failures view from the Application Map by selecting a resource, then Investigate failures from the triage section.
Note
You can access Transaction diagnostics through any of the other three experiences. For more information, see Investigate telemetry.
Overview
The Failures view shows a list of all failed operations collected for your application with the option to drill into each one. It lets you view their frequency and the number of users affected, to help you focus your efforts on the issues with the highest impact.
Note
In addition to the out-of-the-box telemetry sent by the Azure Monitor OpenTelemetry Distro or JavaScript SDK, you can add and modify telemetry (for example, custom events).
For more information, see Add and modify Azure Monitor OpenTelemetry for .NET, Java, Node.js, and Python applications.
Filter telemetry
Default filters
All experiences allow you to filter telemetry by time range. In addition, each experience comes with its own default filter:
You can select which service (Cloud Role Name) or machine/container (Cloud Role Instance) to view from the Roles filter menu. This action allows you to isolate issues or performance trends within specific parts of your application.
To learn how to set the Cloud Role Name and the Cloud Role Instance, see Configure Azure Monitor OpenTelemetry.
Add filters
You can filter events on the values of their properties. The available properties depend on the event or telemetry types you selected. To add a filter:
Select
to add a filter.
From the left dropdown list, select a property.
From the center dropdown list, select one of the following operators:
=
,!=
,contains
, ornot contains
.From the right dropdown list, select all property values you want to filter on.
Note
Notice that the counts to the right of the filter values show how many occurrences there are in the current filtered set.
To add another filter, select
again.
Search telemetry
You can search for specific operations using the Search to filter items... field above the operations list.
Use analytics data
All data collected by Application Insights is stored in Log Analytics. It provides a rich query language to analyze the requests that generated the exception you're investigating.
Tip
Simple mode in Log Analytics offers an intuitive point-and-click interface for analyzing and visualizing log data.
On either the performance, failures, or transaction search view, select View in Logs in the top navigation bar and pick a query from the dropdown menu.
This action takes you to the Logs view, where you can further modify the query or select a different one from the sidebar.
Investigate telemetry
To investigate the root cause of an error or exception, you can drill into the problematic operation for a detailed end-to-end transaction details view that includes dependencies and exception details.
Select an operation to view the Top 3 response codes, Top 3 exception types, and Top 3 failed dependencies for that operation.
Under Drill into, select the button with the number of filtered results to view a list of sample operations.
Select a sample operation to open the End-to-end transaction details view.
Note
The Suggested samples contain related telemetry from all components, even if sampling is in effect in any of them.
Analyze client-side performance and failures
If you instrument your web pages with Application Insights, you can gain visibility into page views, browser operations, and dependencies. Collecting this browser data requires adding a script to your web pages.
After you add the script, you can access page views and their associated performance metrics by selecting the Browser toggle on the Performance or Failures view.
This view provides a visual summary of various telemetries of your application from the perspective of the browser.
For browser operations, the end-to-end transaction details view shows Page View Properties of the client requesting the page, including the type of browser and its location. This information can help determining whether there are performance issues related to particular types of clients.
Note
Like the data collected for server performance, Application Insights makes all client data available for deep analysis by using logs.
Transaction diagnostics experience
The Transaction diagnostics experience, also called End-to-end transaction details view, shows a Gantt chart of the transaction, which lists all events with their duration and response code.
This diagnostics experience automatically correlates server-side telemetry from across all your Application Insights monitored components into a single view and supports multiple resources. Application Insights detects the underlying relationship and allows you to easily diagnose the application component, dependency, or exception that caused a transaction slowdown or failure.
Selecting a specific event reveals its properties, including additional information like the underlying command or call stack.
This view has four key parts:
This collapsible pane shows the other results that meet the filter criteria. Select any result to update the respective details of the preceding three sections. We try to find samples that are most likely to have the details available from all components, even if sampling is in effect in any of them. These samples are shown as suggestions.
Release annotations
Release annotations mark deployments and other significant events on Application Insights charts, allowing correlation of changes with performance, failures, and usage.
Automatic annotations with Azure Pipelines
Azure Pipelines creates a release annotation during deployment when all the following conditions are true:
- The target resource links to Application Insights through the
APPINSIGHTS_INSTRUMENTATIONKEY
app setting. - The Application Insights resource is in the same subscription as the target resource.
- The deployment uses one of the following Azure Pipelines tasks:
Task code | Task name | Versions |
---|---|---|
AzureAppServiceSettings | Azure App Service Settings | Any |
AzureRmWebAppDeployment | Azure App Service | V3+ |
AzureFunctionApp | Azure Functions | Any |
AzureFunctionAppContainer | Azure Functions for container | Any |
AzureWebAppContainer | Azure Web App for Containers | Any |
AzureWebApp | Azure Web App | Any |
Note
If you still use the older Application Insights annotation deployment task, delete it.
Configure annotations in a pipeline by using an inline script
If you don't use the tasks in the previous section, add an inline script in the deployment stage.
Open an existing pipeline or create a new one, and select a task under Stages.
Add a new Azure CLI task.
Select the Azure subscription. Set Script Type to PowerShell, and set Script Location to Inline.
Add the PowerShell script from step 2 in Create release annotations with the Azure CLI to Inline Script.
Add script arguments. Replace placeholders in angle brackets.
-aiResourceId "<aiResourceId>" ` -releaseName "<releaseName>" ` -releaseProperties @{"ReleaseDescription"="<a description>"; "TriggerBy"="<Your name>" }
The following example shows metadata you can set in the optional
releaseProperties
argument by using build and release variables. Select Save.-releaseProperties @{ "BuildNumber"="$(Build.BuildNumber)"; "BuildRepositoryName"="$(Build.Repository.Name)"; "BuildRepositoryProvider"="$(Build.Repository.Provider)"; "ReleaseDefinitionName"="$(Build.DefinitionName)"; "ReleaseDescription"="Triggered by $(Build.DefinitionName) $(Build.BuildNumber)"; "ReleaseEnvironmentName"="$(Release.EnvironmentName)"; "ReleaseId"="$(Release.ReleaseId)"; "ReleaseName"="$(Release.ReleaseName)"; "ReleaseRequestedFor"="$(Release.RequestedFor)"; "ReleaseWebUrl"="$(Release.ReleaseWebUrl)"; "SourceBranch"="$(Build.SourceBranch)"; "TeamFoundationCollectionUri"="$(System.TeamFoundationCollectionUri)" }
Create release annotations with the Azure CLI
Use the following PowerShell script to create a release annotation from any process, without Azure DevOps.
Sign in to the Azure CLI.
Save the following script as
CreateReleaseAnnotation.ps1
.param( [parameter(Mandatory = $true)][string]$aiResourceId, [parameter(Mandatory = $true)][string]$releaseName, [parameter(Mandatory = $false)]$releaseProperties = @() ) # Function to ensure all Unicode characters in a JSON string are properly escaped function Convert-UnicodeToEscapeHex { param ( [parameter(Mandatory = $true)][string]$JsonString ) $JsonObject = ConvertFrom-Json -InputObject $JsonString foreach ($property in $JsonObject.PSObject.Properties) { $name = $property.Name $value = $property.Value if ($value -is [string]) { $value = [regex]::Unescape($value) $OutputString = "" foreach ($char in $value.ToCharArray()) { $dec = [int]$char if ($dec -gt 127) { $hex = [convert]::ToString($dec, 16) $hex = $hex.PadLeft(4, '0') $OutputString += "\u$hex" } else { $OutputString += $char } } $JsonObject.$name = $OutputString } } return ConvertTo-Json -InputObject $JsonObject -Compress } $annotation = @{ Id = [GUID]::NewGuid(); AnnotationName = $releaseName; EventTime = (Get-Date).ToUniversalTime().GetDateTimeFormats("s")[0]; Category = "Deployment"; #Application Insights only displays annotations from the "Deployment" Category Properties = ConvertTo-Json $releaseProperties -Compress } $annotation = ConvertTo-Json $annotation -Compress $annotation = Convert-UnicodeToEscapeHex -JsonString $annotation $accessToken = (az account get-access-token | ConvertFrom-Json).accessToken $headers = @{ "Authorization" = "Bearer $accessToken" "Accept" = "application/json" "Content-Type" = "application/json" } $params = @{ Headers = $headers Method = "Put" Uri = "https://management.azure.com$($aiResourceId)/Annotations?api-version=2015-05-01" Body = $annotation } Invoke-RestMethod @params
Note
Set Category to Deployment or annotations don't appear in the Azure portal.
Call the script and pass values for the parameters. The -releaseProperties
parameter is optional.
.\CreateReleaseAnnotation.ps1 `
-aiResourceId "<aiResourceId>" `
-releaseName "<releaseName>" `
-releaseProperties @{"ReleaseDescription"="<a description>";
"TriggerBy"="<Your name>" }
Argument | Definition | Note |
---|---|---|
aiResourceId |
Resource ID of the target Application Insights resource. | Example: /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyRGName/providers/microsoft.insights/components/MyResourceName |
releaseName |
Name of the new release annotation. | |
releaseProperties |
Custom metadata to attach to the annotation. | Optional |
View annotations
Note
Release annotations aren't available in the Metrics pane.
Application Insights displays release annotations in the following experiences:
- Performance and Failures
- Usage
- Workbooks (for any time-series visualization)
Annotations are visualized as markers at the top of charts.
To enable annotations in a workbook, open Advanced Settings and then select Show annotations. Select any annotation marker to open release details such as requestor, source control branch, release pipeline, and environment.
Frequently asked questions
This section provides answers to common questions.
Transaction search
What is a component?
Components are independently deployable parts of your distributed or microservice application. Developers and operations teams have code-level visibility or access to telemetry generated by these application components.
- Components are different from "observed" external dependencies, such as SQL and event hubs, which your team or organization might not have access to (code or telemetry).
- Components run on any number of server, role, or container instances.
- Components can be separate Application Insights instrumentation keys, even if subscriptions are different. Components also can be different roles that report to a single Application Insights instrumentation key. The new experience shows details across all components, regardless of how they were set up.
How much data is retained?
See the Limits summary.
How can I see POST data in my server requests?
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.
Why does my Azure Function search return no results?
Azure Functions doesn't log URL query strings.
Transaction diagnostics
Why do I see a single component on the chart and the other components only show as external dependencies without any details?
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 Software Development Kits (SDKs), let us know via the feedback channel in the upper-right corner.
I see duplicate rows for the dependencies. Is this behavior expected?
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!
What about clock skews across different component instances?
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.
Why is the new experience missing most of the related items queries?
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.
Is there a way to see fewer events per transaction when I use the Application Insights JavaScript SDK?
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 created 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 the system creates a page view each 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.
Why do transaction detail durations not add up to the top-request duration?
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.
What if I see the message "Error retrieving data" while navigating Application Insights in the Azure portal?
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 Domain Name System (DNS) or other network related issues from the client machine where the API calls are failing. If the portal error continues, collect a browser network trace while reproducing the unexpected behavior. Then open a support case from the Azure portal.
Next steps
- Learn more about using Application Map to spot performance bottlenecks and failure hotspots across all components of your application.
- Learn more about using the Availability view to set up recurring tests to monitor availability and responsiveness for your application.
- Learn how to use Log Analytics and write complex queries to gain deeper insights from your telemetry data.
- Learn how to send logs and custom telemetry to Application Insights for more comprehensive monitoring.
- For an introduction to monitoring uptime and responsiveness, see the Availability overview.