Application Insights - introduction
Visual Studio Application Insights is an extensible analytics service that monitors your live web application. With it you can detect and diagnose performance issues, and understand what users actually do with your app. It's designed for developers, to help you continuously improve performance and usability. It works for apps on a wide variety of platforms including .NET, Node.js and J2EE, hosted on-premises or in the cloud.
You install a small instrumentation package in your application, and set up an Application Insights resource in the Microsoft Azure portal. The instrumentation monitors your app and sends telemetry data to the portal. The portal shows you statistical charts and provides powerful search tools to help you diagnose any problems.
Application Insights has several standard instrumentation modules that collect different types of telemetry such as request response times, exceptions, and dependency calls. You can also write code to send custom telemetry to the portal.
The impact on your app's performance is very small. Tracking calls are non-blocking, and are batched and sent in a separate thread.
Application Insights is aimed at the development team, to help you understand how your app is performing and how it's being used. It provides:
- HTTP request rates, response times, success rates.
- Dependency (HTTP & SQL) call rates, response times, success rates.
- Exception traces from both server and client.
- Diagnostic log traces.
- Page view counts, user and session counts, browser load times, exceptions.
- AJAX call rates, response times and success rates.
- Server performance counters.
- Custom client and server telemetry.
- Segmentation by client location, browser version, OS version, server instance, custom dimensions, and more.
- Availability tests
Diagnostic and analytic tools:
- Smart and manual alerts on failure rates and other metrics, and on availability.
- Charts over time of aggregated metrics.
- Diagnostic search on instances of requests, exceptions, custom events, log traces, page views, dependency and AJAX calls.
- Analytics - a powerful query language over your telemetry
- Dashboards - compose the charts you need to monitor all your app components.
Application Insights is one of the many services hosted within Microsoft Azure, and telemetry is sent there for analysis and presentation. So before you do anything else, you'll need a subscription to Microsoft Azure. It's free to sign up, and you can choose the free pricing tier of Application Insights. If your organization already has a subscription, they could add your Microsoft account to it.
There are several ways to get started. Begin with whichever works best for you. You can add the others later.
- At run time: instrument your web app on the server. Avoids any update to the code. You need admin access to your server.
- At development time: add Application Insights to your code. Allows you to write custom telemetry and to instrument back-end and desktop apps.
- Instrument your web pages for page view, AJAX and other client-side telemetry.
- Availability tests - ping your website regularly from our servers.
At this point, maybe you just want to get on and experiment. But if you'd like to see what Application Insights can do, read on....
Run your app - either in debug mode on your development machine, or by deploying it to a server - and use it for a while. Then sign in to the Azure portal.
Navigate to your app's Application Insights overview blade:
The overview allows you to see immediately how your app is performing. You can compare load (in terms of rate of requests) with the time your app too to respond to the requests. If there's a disproportionate rise in response time when the load goes up, you might want to allocate more resources to your app. If it shows more failed responses right after you deployed a new build, then you might want to roll back.
Click through any chart to get a more detailed set of charts. For example, the Server Response Time chart leads to charts that show request rates, response times, and response times of dependencies (that is, services that your app calls).
The dependencies chart is useful because it helps you see whether the databases and REST APIs that your app uses are responding well, or are causing delays.
Try editing one of these charts. For example, if your web app runs on a collection of server instances, you can compare response times on the different server instances:
- Hover over the chart and click Edit.
- Choose a metric. Multiple metrics can be displayed on one chart, but only in certain combinations: you might have to deselect one metric before you select the one you want.
Use Group-By to segment a metric by a property. In this example, we display separate lines for different response times.
Note that you have to select a valid property for the metric, or the chart will not show any data.
Select a chart type. Area and bar charts show a stacked display suitable when the aggregation type is 'Sum'.
To investigate a problem, it's useful to inspect specific event instances.
Click through a metric chart to search through instance data with relevant filters and time range. For example, click through server request counts to see individual request reports.
Or you can get directly to instance data from Search on the overview page:
Use Filters to focus on particular types of event and on chosen property values:
Click "..." to see a full list of properties, or open other events associated with the same request. In this example, the failed request has an associated exception report:
Open an event - in this example, the related exception - and you can create a work item (if you use Visual Studio Team Services to track tasks).
Analytics is an even more powerful search and analysis feature, in which you can write SQL-like queries over your telemetry data, either to look for specific issues or to compile statistical information.
Open the tutorial window to see and run examples of queries over your data, or read the longer tutorial walkthrough. Intellisense prompts you with the queries that you can use, and there's a full language reference.
Queries usually begin with the name of a telemetry stream such as requests, exceptions, or dependencies. Pop open the schema bar at the left to see a list of the available telemetry streams. The query is a pipeline of query operations such as
where - a boolean filter - or
project - which computes new properties.
summarize aggregates instances, grouping them by functions you define, and then applying aggregation functions over the grouped data.
Results can be rendered in tables or various types of chart.
The built-in telemetry that you get just by installing Application Insights lets you analyze counts, success rates, and response times both for web requests to your app, and dependencies - that is, calls from your app to SQL, REST APIs. You also get exception traces, and (with Status Monitor on your server) system performance counters. If you add the client snippet to your web pages, you get page view counts and load times, client exceptions, and AJAX call success and response rates.
Analyzing all this telemetry can tell you a lot about your app's performance and usage. But sometimes that isn't enough. You might want to monitor the length of a queue so that you can tune performance; or count sales and segment them by location; or, on the client side, find out how often users click a particular button so that you can tune the user experience.
The Application Insights API provides calls
TrackMetric(name, value) so that you can send your own custom events and metrics. There are equivalent calls for the client side.
For example, if your web page is a single-page game app, you might insert a lines in the appropriate places to log when the user wins or loses a game:
appInsights.trackEvent("WinGame"); ... appInsights.trackEvent("LoseGame");
Then we can chart custom event counts, segmenting them by event name:
For diagnostic purposes, there's a custom event
TrackTrace(message) that you can use for execution traces. In the Search and Analytics features, you can search on the contents of the message, which can be longer than an event name.
If you already use a logging framework such as Log4Net, NLog, Log4J, or System.Diagnostic.Trace, then those trace calls can be captured by Application Insights, and will appear alongside the other telemetry. The Visual Studio tools automatically add the appropriate SDK module.
Many applications consist of several components such as a web service and one or more back end processors. Each component will be monitored by a separate Application Insights resource. If your system runs on Azure, you might be using - and monitoring - services such as event hubs and machine learning as well.
To monitor your whole system, you can select the most interesting charts from different apps and pin them to an Azure dashboard, allowing you to keep an eye on the whole system continuously.
In fact, you can create multiple dashboards - for example, a team room dashboard for monitoring general system health; a design dashboard that focuses on the usage of different features; a separate dashboard for components under test; and so on.
Dashboards, like resources, can be shared between team members.
If you're using Visual Studio to develop your app, you'll find several Application Insights tools built in.
The Search window shows events that have been logged. (If you signed in to Azure when you set up Application Insights, you'll be able to search the same events in the portal.)
The free text search works on any fields in the events. For example, search for part of the URL of a page; or the value of a property such as client city; or specific words in a trace log.
Click any event to see its detailed properties.
You can also open the Related Items tab to help diagnose failed requests or exceptions.
The Diagnostics Hub (in Visual Studio 2015 or later) shows the Application Insights server telemetry as it's generated. This works even if you opted only to install the SDK, without connecting it to a resource in the Azure portal.
If you have set up exception monitoring, exception reports will show in the Search window.
Click an exception to get a stack trace. If the code of the app is open in Visual Studio, you can click through from the stack trace to the relevant line of the code.
In addition, in the Code Lens line above each method, you'll see a count of the exceptions logged by Application Insights in the past 24h.
(From Visual Studio 2015 Update 2) If you haven't configured the SDK to send telemetry to the Application Insights portal (so that there is no instrumentation key in ApplicationInsights.config) then the diagnostics window will display telemetry from your latest debugging session.
This is desirable if you have already published a previous version of your app. You don't want the telemetry from your debugging sessions to be mixed up with the telemetry on the Application Insights portal from the published app.
It's also useful if you have some custom telemetry that you want to debug before sending telemetry to the portal.
At first, I fully configured Application Insights to send telemetry to the portal. But now I'd like to see the telemetry only in Visual Studio.
- In the Search window's Settings, there's an option to search local diagnostics even if your app sends telemetry to the portal.
- To stop telemetry being sent to the portal, comment out the line
<instrumentationkey>...from ApplicationInsights.config. When you're ready to send telemetry to the portal again, uncomment it.
Trends is a tool in Visual Studio for visualizing how your app behaves over time.
Choose Explore Telemetry Trends from the Application Insights toolbar button or Application Insights Search window. Choose one of five common queries to get started. You can analyze different datasets based on telemetry types, time ranges, and other properties.
To find anomalies in your data, choose one of the anomaly options under the "View Type" dropdown. The filtering options at the bottom of the window make it easy to hone in on specific subsets of your telemetry.
Live Metrics Stream shows you your application metrics right at this very moment, with a near real time latency of 1 second. This is extremely useful when you’re releasing a new build and want to make sure that everything is working as expected, or investigating an incident in real time.
Unlike Metrics Explorer, Live Metrics Stream displays a fixed set of metrics. The data persists only for as long as it's on the chart, and is then discarded.
Release annotations on metrics charts show where you deployed a new build. They make it easy to see whether your changes had any effect on your application's performance. They can be automatically created by the Visual Studio Team Services build system, and you can also create them from PowerShell.
Release annotations are a feature of the cloud-based build and release service of Visual Studio Team Services.
If something goes wrong with your app, you'll want to know about it immediately.
Application Insights offers three types of alert, which are delivered by email.
Proactive diagnostics** is automatically set up - you don't have to configure it. Provided your site has enough traffic, you'll get an email if there's a rise in failed requests that is unusual for the time of day or request rate. The alert contains diagnostic information.
Here's a sample alert.
A second type of proactive detection discovers correlations between failures and factors such as location, client OS, or browser type.
You can configure metric alerts to tell you when any metric crosses a threshold value for some period - such as failure counts, memory, or page views.
Availability web tests send requests to your site from our servers at various locations around the world. They tell you when your site is unavailable on the internet, or responding slowly.
There are several ways you can get your telemetry data out of the Application Insights portal:
- Continuous Export is ideal if you want to keep large parts of your telemetry for longer than the standard retention period.
- The Export button at the top of a metrics or search blade lets you transfer tables and charts to an Excel spreadsheet.
- Analytics provides a powerful query language for telemetry, and also can export results.
- The Data Access REST API can be used to search for and extract data. It can run Analytics queries.
- If you're looking to explore your data in Power BI, you can do that without using Continuous Export.
There are limits on your usage of Application Insights, which depend to some extent on the pricing scheme that you choose. The main limits are on:
- Telemetry rate per minute
- Data point count per month
- Retention period for data
Sampling is a mechanism for reducing cost and avoiding throttling. It discards a proportion of your telemetry, keeping a representative sample. Associated items (such as exceptions and the requests that caused them) are either retained or discarded together. For ASP.NET applications, sampling is automatic and is applied in the app; otherwise, you can set it to be applied on ingestion to the portal.
Get started at runtime with:
Get started at development time with:
- Questions and Issues:
- Your suggestions: