Search is a feature of Application Insights that you use to find and explore individual telemetry items, such as page views, exceptions, or web requests. And you can view log traces and events that you have coded.
(For more complex queries over your data, use Analytics.)
Where do you see Search?
In the Azure portal
You can open diagnostic search explicitly from the Application Insights Overview blade of your application:
It also opens when you click through some charts and grid items. In this case, its filters are pre-set to focus on the type of item you selected.
For example, on the Overview blade, there's a bar chart of requests classified by response time. Click through a performance range to see a list of individual requests in that response time range:
The main body of Diagnostic Search is a list of telemetry items - server requests, page views, custom events that you have coded, and so on. At the top of the list is a summary chart showing counts of events over time.
Click Refresh to get new events.
In Visual Studio
In Visual Studio, there's also an Application Insights Search window. It's most useful for displaying telemetry events generated by the application that you're debugging. But it can also show the events collected from your published app at the Azure portal.
Open the Search window in Visual Studio:
The Search window has features similar to the web portal:
The Track Operation tab is available when you open a request or a page view. An 'operation' is a sequence of events that is associated with to a single request or page view. For example, dependency calls, exceptions, trace logs, and custom events might be part of a single operation. The Track Operation tab shows graphically the timing and duration of these events in relation to the request or page view.
Inspect individual items
Select any telemetry item to see key fields and related items. If you want to see the full set of fields, click "...".
Filter event types
Open the Filter blade and choose the event types you want to see. (If, later, you want to restore the filters with which you opened the blade, click Reset.)
The event types are:
- Trace - Diagnostic logs including TrackTrace, log4Net, NLog, and System.Diagnostic.Trace calls.
- Request - HTTP requests received by your server application, including pages, scripts, images, style files, and data. These events are used to create the request and response overview charts.
- Page View - Telemetry sent by the web client, used to create page view reports.
- Custom Event - If you inserted calls to TrackEvent() in order to monitor usage, you can search them here.
- Exception - Uncaught exceptions in the server, and those that you log by using TrackException().
- Dependency - Calls from your server application to other services such as REST APIs or databases, and AJAX calls from your client code.
- Availability - Results of availability tests.
Filter on property values
You can filter events on the values of their properties. The available properties depend on the event types you selected.
For example, pick out requests with a specific response code.
Choosing no values of a particular property has the same effect as choosing all values. It switches off filtering on that property.
Narrow your search
Notice that the counts to the right of the filter values show how many occurrences there are in the current filtered set.
In this example, it's clear that the 'Rpt/Employees' request results in most of the '500' errors:
Find events with the same property
Find all the items with the same property value:
Search the data
To write more complex queries, open Analytics from the top of the Search blade.
You can search for terms in any of the property values. This is particularly useful if you have written custom events with property values.
You might want to set a time range, as searches over a shorter range are faster.
Search for complete words, not substrings. Use quotation marks to enclose special characters.
|string||is not found by||but these do find it|
united AND states
Here are the search expressions you can use:
||Find all events in the time range whose fields include the word "apple"|
||Find events that contain both words. Use capital "AND", not "and".|
||Find events that contain either word. Use "OR", not "or".
||Find events that contain one word but not the other.|
If your app generates a lot of telemetry (and you are using the ASP.NET SDK version 2.0.0-beta3 or later), the adaptive sampling module automatically reduces the volume that is sent to the portal by sending only a representative fraction of events. However, events that are related to the same request are selected or deselected as a group, so that you can navigate between related events.
Create work item
You can create a bug in GitHub or Visual Studio Team Services with the details from any telemetry item.
The first time you do this, you are asked to configure a link to your Team Services account and project.
(You can also configure the link on the Work Items blade.)
Save your search
When you've set all the filters you want, you can save the search as a favorite. If you work in an organizational account, you can choose whether to share it with other team members.
To see the search again, go to the overview blade and open Favorites:
If you saved with Relative time range, the re-opened blade has the latest data. If you saved with Absolute time range, you see the same data every time. (If 'Relative' isn't available when you want to save a favorite, click Time Range in the header, and set a time range that isn't a custom range.)
Send more telemetry to Application Insights
In addition to the out-of-the-box telemetry sent by Application Insights SDK, you can:
- Capture log traces from your favorite logging framework in .NET or Java. This means you can search through your log traces and correlate them with page views, exceptions, and other events.
- Write code to send custom events, page views, and exceptions.
Q & A
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.