Introduction to App Insights
Application insights is a great measurement tool which provides you more insights into the usage of your application. This will help you solve exceptions; performance problems and it can even be helpful to improve the user experience of your application. This service can be used for several types of applications, web, mobile and windows applications. Multiple programming languages are supported like .NET, PHP, Python, Ruby and many more. Application Insights is a tool for developers.
What kind of telemetry data is available in App Insights?
The default installation of Application Insights collects several kind of telemetry data:
|
Page views
|
Speak for itself, tracks all page views.
|
|
Requests
|
All requests, pages, images, stylesheets, scripts, etc.
|
|
Exceptions
|
All requests that return exceptions are tracked. 400 and 500 status codes.
|
|
Dependencies
|
Queries to the database or calls to external web services.
|
|
Trace
|
Trace information is tracked.
|
|
Events
|
Events can be tracked via the API. I'll explain how you can do this in the next section.
|
|
Performance counters
|
Performance counters provides telemetry data about your servers.
|
|
Availability
|
Availability tests can be created in the portal. This can be either URL ping tests or multi-step tests.
|
Enriching telemetry data with Telemetry Initializers
Telemetry initializers can be useful to enrich the telemetry data that is pushed to Application Insights. The Microsoft.ApplicationInsights.Web package includes initializers that we can use out of the box. We can enable those in the applicationinsights.config or via code. Let's look at the ClientIpHeaderTelemetryInitializer which ships with the package. This class inherits the WebTelemetryInitializerBase class, the OnInitializationTelemetry method needs to be implemented. This method will set the additional information on the telemetry data.
/// </summary>
/// Implements initialization logic.
/// </summary>
/// <param name="platformContext">Http context.</param>
/// <param name="requestTelemetry">Request telemetry object associated with the current request.</param>
/// <param name="telemetry">Telemetry item to initialize.</param>
protected override void OnInitializeTelemetry(HttpContext platformContext, RequestTelemetry requestTelemetry, ITelemetry telemetry){
if (string.IsNullOrEmpty(telemetry.Context.Location.Ip))
{
LocationContext location = requestTelemetry.Context.Location;
if (string.IsNullOrEmpty(location.Ip))
{
this.UpdateRequestTelemetry(platformContext, location);
}
telemetry.Context.Location.Ip = location.Ip;
}
}
This initializer will set the user IP on every telemetry data that is pushed. What I mention is that we can either configure this initializer in the config or in code:
<TelemetryInitializers>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector" />
<Add Type="Microsoft.ApplicationInsights.WindowsServer.AzureRoleEnvironmentTelemetryInitializer, Microsoft.AI.WindowsServer" />
<Add Type="Microsoft.ApplicationInsights.WindowsServer.AzureWebAppRoleEnvironmentTelemetryInitializer, Microsoft.AI.WindowsServer" />
<Add Type="Microsoft.ApplicationInsights.WindowsServer.BuildInfoConfigComponentVersionTelemetryInitializer, Microsoft.AI.WindowsServer" />
<Add Type="Microsoft.ApplicationInsights.Web.WebTestTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.SyntheticUserAgentTelemetryInitializer, Microsoft.AI.Web">
<Filters>search|spider|crawl|Bot|Monitor|AlwaysOn</Filters>
<Add Type="Microsoft.ApplicationInsights.Web.ClientIpHeaderTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.OperationNameTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.OperationCorrelationTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.UserTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.AuthenticatedUserIdTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.AccountIdTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.SessionTelemetryInitializer, Microsoft.AI.Web" />
</TelemetryInitializers>
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
TelemetryConfiguration.Active.TelemetryInitializers.Add(new ClientIpHeaderTelemetryInitializer());
}
Of course, you could create your own initializer by inheriting the WebTelemetryInitializerBase (or ITelemetryInitializer) class and configure it.
Signup for a live Demo Today!
Learn how Cloud Assert can build an effective Hybrid Cloud Platform
Filter out telemetry data with Telemetry Processors
With telemetry processors, you can filter out data that you don't want in Application Insights. There are two reasons why you should do this, first you don't want data in Application Insights that you will not analyse. The portal has some good search and filter capabilities, but less is more. Second, one of the goals when using Azure services should be reducing the costs. You'll be charged for the data that is pushed to Application Insights, you need to consider what data is valuable for you. Like the initializer, you can configure a processor either in the configuration file or via code. You can create your own processor by inheriting the ITelemetryProcessor interface. Below an example of filtering out all requests that return a 404 response code and how could configure the processor.
public class NotFoundFilter : ITelemetryProcessor
{
private ITelemetryProcessor Next { get; set; }
public NotFoundFilter(ITelemetryProcessor next)
{
this.Next = next;
}
public void Process(ITelemetry item)
{
var request = item as RequestTelemetry;
if (request != null &&
request.ResponseCode.Equals(((int)HttpStatusCode.NotFound).ToString(), StringComparison.OrdinalIgnoreCase))
{
// To filter out an item, just terminate the chain:
return;
}
// Send everything else:
this.Next.Process(item);
}
}
<TelemetryProcessors>
<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector" />
<Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
</Add>
<Add Type="ApplicationInsightDemoSite.NotFoundFilter, ApplicationInsightDemoSite" />
</TelemetryProcessors>
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
TelemetryConfiguration.Active.TelemetryInitializers.Add(new ClientIpHeaderTelemetryInitializer());
var builder = TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;
builder.Use((next) => new NotFoundFilter(next));
builder.Build();
}
Track telemetry data yourself with the API
A lot of telemetry data is collected and available in Application Insights. An API is provided by Microsoft to customize tracking, for example, enrich the telemetry data with other useful information, filter out data and push your own data to Application Insights.
In a web application, we either can use the JavaScript API or the C# API. Whether you are using the client or server-side API, it's super simple. Events can be used to provide more insights how visitors are using your web application. Again, we can push events both client and server side. An example of a client-side event can be that a visitor opens/close a popup or use filters/categories on a complex search page. Let's start with an example how you can push a client-side event. In the code snippet, an event is pushed when an anchor with the class 'home-page-link' is clicked.
$(document).ready(function() {
$(".home-page-link").click(function() {
window.appInsights.trackEvent("homePageLinkClicked", $(this).text());
});
});
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
if (!ModelState.IsValid)
{
return View(model);
}
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, change to shouldLockout: true
var result = await SignInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, shouldLockout: false);
switch (result)
{
case SignInStatus.Success:
return RedirectToLocal(returnUrl);
case SignInStatus.LockedOut:
return View("Lockout");
case SignInStatus.RequiresVerification:
return RedirectToAction("SendCode", new { ReturnUrl = returnUrl, RememberMe = model.RememberMe });
case SignInStatus.Failure:
default:
var dic = new Dictionary<string, string>();
dic.Add("email", model.Email);
_telemetryClient.TrackEvent("InvalidLogin", dic);
ModelState.AddModelError("", "Invalid login attempt.");
return View(model);
}
}
In the second code snippet, the TrackEvent method from the TelemetryClient class is called. You can pass additional data for this event in the second parameter of the method. In this example, I push an event when the visitor fails to login. The entered email address is set in the dictionary. The additional data for an event will appear in Application Insights.
By default, the post parameters aren't pushed to Application Insights. We could send this information in two ways. We can create a telemetry initializer and enrich the telemetry data with the post parameters. Or we can use the Track method (JavaScript or C#) to push this information to Application Insights.
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> ForgotPassword(ForgotPasswordViewModel model)
{
if (ModelState.IsValid)
{
var postVariables = Request.Form.ToString();
var dic = new Dictionary<string, string>();
dic.Add("Post", postVariables);
_telemetryClient.TrackTrace("Forgot password url", dic);
var user = await UserManager.FindByNameAsync(model.Email);
if (user == null || !(await UserManager.IsEmailConfirmedAsync(user.Id)))
{
return View("ForgotPasswordConfirmation");
}
}
return View(model);
}
Events and trace information are just two examples of custom telemetry data that we can push ourselves. Other methods for pushing data are:
· TrackAvailability
· TrackDependency
· TrackException
· TrackMetry
· TrackPageView
· TrackRequest
Be aware that you don't track unnecessary data. Only do this when this can be valuable to solve issues, understand the usage of your application or other valid reasons.
Signup for a live Demo Today!
Learn how Cloud Assert can build an effective Hybrid Cloud Platform
Conclusion
Application Insights gives a lot of insights into the usage and performance of your application. You can investigate your data in the portal in several ways. When you're not satisfied with the telemetry data that's tracked by default, you can track telemetry data yourself by using the server or client-side API. This can help you solve exceptions and improve the performance of your application.