Monitor ASP.NET applications using Application Insights and Azure Alerts

Using Application Insights? Learn how to trigger custom alerts for your application.

Photo by Hugo Jehanne on Unsplash

On this third article about Application Insights, we will review how to create custom alerts that trigger based on telemetry emitted by our applications. Creating Alerts on Azure is simple, cheap, fast and adds a lot of value to our operations.

Azure Alerts

But what are Azure Alerts? According to Microsoft:

Azure Alerts proactively notify you when important conditions are found in your monitoring data. They allow you to identify and address issues before the users of your system notice them.

With Azure Alerts we can create custom alerts based on metrics or logs using as data sources:

• Metric values
• Log search queries
• Activity log events
• Health of the underlying Azure platform
• Tests for website availability
• and more...

Customization

The level of customization is fantastic. Alert rules can be customized with:

• Target Resource: Defines the scope and signals available for alerting. A target can be any Azure resource. For example: a virtual machine, a storage account or an Application Insights resource
• Signal: Emitted by the target resource, can be of the following types: metric, activity log, Application Insights, and log.
• Criteria: A combination of signal and logic. For example, percentage CPU, server response time, result count of a query, etc.
• Alert Name: A specific name for the alert rule configured by the user.
• Alert Description: A description for the alert rule configured by the user.
• Severity: The severity of the alert when the rule is met. Severity can range from 0 to 4 where 0=Critical, 4=Verbose.
• Action: A specific action taken when the alert is fired. For more information, see Action Groups.

Can I use Application Insights data and Azure Alerts?

Application Insights can be used as source for your alerts. Once you have your app hooked with Application Insights, creating an alert is simple. We will review how later on this post.

Creating an Alert

Okay so let's jump to the example. In order to understand how that works, we will:

1. Create and configure an alert in Azure targeting our Application Insights instance;
2. Change our application by creating a slow endpoint that will be used on this exercise.

To start, go to the Azure Portal and find the Application Insights instance your app is hooked to and click on the Alerts icon under Monitoring. (Don't know how to do it? Check this article where it's covered in detail).

And click on Manage alert rules and New alert rule to create a new one:

Configuring our alert

You should now be in the Create rule page. Here we will specify a resource, a condition, who should be notified, notes and severity. As previously, I'll use the same aspnet-ai AppInsights instance as previously:

Specifying a Condition

For this demo, we will be tracking response time so for the Configure section, select Server response time:

Setting Alert logic

On the Alert logic step we specify an operator and a threshold value. I want to track requests that take more than 1s (1000ms), evaluating every minute and aggregating data up to 5 minutes:

Action group

On the Add action group tab we specify who should be notified. For now, I'll send it only to myself:

Email, SMS and Voice

If you want to be alerted by Email and/or SMS, enter them below. We'll need them to confirm that notifications are sent to our email and phone:

Confirming and Reviewing our Alert

After confirming, saving and deploying your alert, you should see a summary like:

Testing the Alerts

With our alert deployed, let's do some code. If you want to follow along, download the source for this article and switch to the alerts branch by doing:

git clone https://github.com/hd9/aspnet-ai.git
cd aspnet-ai
git branch alerts

# insert your AppInsights instrumentation key on appSettings.Development.json
dotnet run

That code contains the endpoint SlowPage to simulate slow pages (and exceptions). To test it, make sure you have correctly set your instrumentation key and send a request to the endpoint at https://localhost:5001/home/slowpage and. It should throw an exception after 3s:

Reviewing the Exception in AppInsights

It may take up to 5 minutes to get the notifications. In the meantime, we can explore how AppInsights tracked our exception by going to the Exceptions tab. This is what was captured by default for us:

Clicking on the SlowPage link, I can see details about the error:

So let's quickly discuss the above information. I added an exception on that endpoint because I also wanted to highlight that without any extra line of code, the exception was automatically tracked for us. And look how much information we have there for free! Another reason we should use these resources proactively as much as possible.

Getting the Alert

Okay but where's our alert? If you remember, we configured our alerts to track intervals of 5 minutes. That's good for sev3 alerts but probably to much for sev1. So, after those long 5 minutes, you should get an easier alert describing the failure:

If you registered your phone number, you should also get an SMS. I got both with the SMS arriving a few seconds before the email.

Reviewing Alerts

After the first alert send, you should now have a consolidate view under your AppInsights instance where you'd be able to view previously send alerts group by severity. You can even click on them to get information and telemetry related to that event. Beautiful!

Types of Signals

Before we end, I'd like to show some of the signals that are available for alerts. You can use any of those (plus custom metrics) to create an alert for your cloud service.

Conclusion

Application Insights is an excellent tool to monitor, inspect, profile and alert on failures of your cloud resources. And given that it's extremely customizable, it's a must if you're running services on Azure.

More about AppInsights

Want to know more about Application Insights? Consider reading the following articles:

1. Adding Application Insights telemetry to your ASP.NET Core website
2. How to suppress Application Insights telemetry
3. How to profile ASP.NET apps using Application Insights

References

• Overview of alerting and notification monitoring in Azure
• Create, view and manage Metric Alerts Using Azure Monitor
• Understand how metric alerts work in Azure Monitor
• Create an alert rule

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Creating ASP.NET Core websites with Docker
• Configuration in .NET Core console applications
• Deploying Docker images to Azure App Services
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Hosting NuGet packages on GitHub
• Building and Running ASP.NET Core apps on Linux 
• Migrating NServiceBus backends to Azure WebJobs
• Enabling ASP.NET error pages using Azure Serial Console
• Creating a Ubuntu Desktop instance on Azure 
• Why I use Fedora Linux 
• Windows Subsystem for Linux, the best way to learn Linux on Windows
• How I fell in love with i3
  

For more posts about AppInsights, please click here.

How to suppress Application Insights telemetry

Application Insights is an excellent tool to capture telemetry for your application but it may be too verbose. On this post we will review how to exclude unnecessary requests.

Photo by Michael Dziedzic on Unsplash

On a previous post we learned how to add Application Insights telemetry to ASP.NET applications. Turns out that we also saw that a lot of unnecessary telemetry was being sent. How to filter some of that telemetry?

On this post we will explain how to suppress telemetry by using AppInsights' DependencyTelemetry and ITelemetryProcessor.

Understanding telemetry pre-processing

You can write and configure plug-ins for the Application Insights API to customize how telemetry can be enriched and processed before it's sent to the Application Insights service in four different ways:

1. Sampling - reduces the volume of telemetry without affecting statistics. Keeps together related data points so we can navigate between points when diagnosing a problem.
2. Filtering with Telemetry Processors - filters out telemetry before it is sent to the server. For example, you could reduce the volume of telemetry by excluding requests from robots. Filtering is a more basic approach to reducing traffic than sampling. It allows you more control over what is transmitted, but affects your statistics.
3. Telemetry Initializers - lets you add or modify properties to any telemetry sent from your app. For example, you could add calculated values; or version numbers by which to filter the data in the portal.

Suppressing Dependencies

So let's create a custom filter that will suppress some of that telemetry. For example, below I show all the telemetry that was automatically sent from my application to Azure with just one line of code. Our code will suppress the data shown in yellow.

Creating a Telemetry Processor

There are different types of telemetry filters being RequestTelemetry and DependencyTelemetry the most common. These classes contain properties that are useful for our logic. So let's create a filter that excludes requests to favicon.ico, bootstrap, jquery, site.css and site.js.

To get rid of some of these requests, we will implement a custom filter that I named SuppressStaticResourcesFilter to ignore requests those static resources. Our telemetry processor should implement the interface ITelemetryProcessor. Note the logic to exclude requests in the Process method:

Registering a Telemetry Processor

Now, we just need to wire it up on the initialization of our app. As stated on this document, the initialization is different for ASP.NET Core and ASP.NET MVC. Let's take a look at each of them.

The registration of a telemetry processor in ASP.NET Core is done in Startup.cs:
Configuring a telemetry processor on ASP.NET is done in Global.asax:
Wait a couple of minutes for the telemetry to show up online. You should no longer see those requests targeting static resources:

How many filters?

Well, that's up to you. You could create as many filters as you want. The only change would be on the initialization. For example, assuming For ASP.NET Core web apps, it would look like:

public void ConfigureServices(IServiceCollection services)
{
    services.AddApplicationInsightsTelemetry();
    services.AddApplicationInsightsTelemetryProcessor<SuppressStaticResourcesFilter>();
    services.AddApplicationInsightsTelemetryProcessor<YourOtherFilter1>();
    services.AddApplicationInsightsTelemetryProcessor<YourOtherFilter2>();
    services.AddControllersWithViews();
}

For classic ASP.NET MVC Web, the initialization would be:

var builder = TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
builder.Use((next) => new SuppressStaticResourcesFilter(next));
builder.Use((next) => new YourOtherFilter1(next));
builder.Use((next) => new YourOtherFilter2(next));
builder.Build();

Enabling based on LogLevel

To finish up, we could  extend the solution above by enabling the telemetry processors based on your LogLevel. For example, the code below wouldn't register processors to suppress data if LogLevel == debug:

public void ConfigureServices(IServiceCollection services)
{
     services.AddApplicationInsightsTelemetry();
     if (logLevel != "debug")
     {
          services.AddApplicationInsightsTelemetryProcessor<SuppressStaticResourcesFilter>();
     }
     services.AddControllersWithViews();
}

Conclusion

On this post we extended the discussion on How to add Application Insights telemetry to ASP.NET websites and reviewed how to suppress some of that telemetry. I hope it's clear how to register your telemetry processor and how/when to use RequestTelemetry and DependencyTelemetry.

If you're using Azure, AppInsights may be a valuable asset for your organization as it provides a simple, fast, centralized and customizable service to access your logs. For more information about AppInisights, check the official documentation.

References

• Filtering and preprocessing telemetry in the Application Insights SDK
• Application Insights API for custom events and metrics
• DependencyTelemetry Class 
• ITelemetryProcessor

More about AppInsights

Want to know more about Application Insights? Consider reading previous articles on the same topic:

1. Adding Application Insights telemetry to your ASP.NET Core website
2. Monitor ASP.NET applications using Application Insights and Azure Alerts
3. How to profile ASP.NET apps using Application Insights

Source Code

The source code used on this article is available on GitHub on the telemetry branch.

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Creating ASP.NET Core websites with Docker
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Hosting NuGet packages on GitHub
• Configuration in .NET Core console applications
• Deploying Docker images to Azure App Services
• Building and Running ASP.NET Core apps on Linux 
• Running NServiceBus on Azure WebJobs
• Enabling ASP.NET error pages using Azure Serial Console
• How to create a Ubuntu Desktop instance on Azure 
• Why I use Fedora Linux 
• Windows Subsystem for Linux, the best way to learn Linux on Windows
• How I fell in love with i3
  

For more posts about .NET Core, please click here.

Adding Application Insights to a ASP.NET Core website

Application Insights may be an excellent resource for your applications and services running on Azure. Read to understand why.

Photo by SOCIAL.CUT on Unsplash

On a previous post, we discussed how to build and deploy WebJobs on Azure. Given that today it's common to have multiple instances of our apps and services (like WebJobs) running at the same time on the cloud, it's important to plan and carefully implement our logging strategy. Turns out that on Azure, the best way to do so is by using Application Insights.

On this post we will learn:

• What's Application Insights (AppInsights)
• What do we gain by using AppInsights
• How to add AppInsights to an ASP.NET Core website
• How to create and configure AppInsights on Azure
• How to send telemetry to our Azure AppInsights instance
• How to interpret AppInsights data on Azure

What is Application Insights

So first, let's understand what's Application Insights. According to Microsoft:

Application Insights is an extensible Application Performance Management (APM) service for developers and DevOps professionals. Use it to monitor your live applications. It will automatically detect performance anomalies, and includes powerful analytics tools to help you diagnose issues and to understand what users actually do with your app. It's designed to help you continuously improve performance and usability. It works for apps on a wide variety of platforms including .NET, Node.js and Java EE, hosted on-premises, hybrid, or any public cloud.

Services provided by AppInsights

Below I list some services provided by AppInsigths:

• HTTP request rates, response times, and success rates
• Dependency (HTTP & SQL) call rates, response times, and success rates
• Exception traces from both server and client
• Diagnostic log traces
• Page view counts, user and session counts, browser load times, and 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

Along with the preceding, there are associated diagnostic and analytics tools available for alerting and monitoring with various different customizable metrics. With its own query language and customizable dashboards, Application Insights is an excellent tool for any cloud service.

Why AppInsights?

Let's review then why and when should we use AppInsights. I usually recommend if:

• Your project runs on the cloud
• You run services on Azure
• You want to gain insights on how your application runs on the cloud
• You want to consolidate telemetry
• You're building an App Service, Cloud Service, WebJob or Azure Functions
• You have a moderately modern application

Desktop apps could also benefit from AppInsights this but I'd only recommend it if the developers want to learn from the telemetry submitted by their users. Remember, that an active connection should exist for the data to be pushed to Azure.

How does Application Insights work?

Once plugged to your application, AppInsights will send automatic and custom telemetry to Azure and will be available from multiple sources. The diagram below summarizes how it works:

Source: Microsoft Docs

Building our App

So let's now build our app. This post focus on .NET Core but you could also target .NET Framework. I will also try do do use .NET Core's CLI as much as possible because it not only helps us solidify the tool but also because I'm running .NET Core 3.0 which's still not supported yet by Visual Studio 2017.

Scaffolding a simple ASP.NET Core MVC WebApp using the CLI

So let's scaffold a simple ASP.NET MVC web app using the CLI. Open a Windows Terminal, navigate to the folder where you store your projects and type:

C:\src>dotnet new mvc -n aspnet-ai
The template "ASP.NET Core Web App (Model-View-Controller)" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore/3.1-third-party-notices for details.

Processing post-creation actions...
Running 'dotnet restore' on aspnet-ai\aspnet-ai.csproj...
  Restore completed in 136.74 ms for C:\src\aspnet-ai\aspnet-ai.csproj.

Restore succeeded.

In case you're insterested in knowing which options you have available for any project, use the --help flag. For example, to view the options for a React project, type:

dotnet new react --help

The --help flag can also be used to get information about different operations including scaffolding console, Windows forms, etc:

dotnet new --help

Testing our App

Runnning our app is as simple as typing dotnet run on the command line. The CLI then builds and runs our app:

C:\src\aspnet-ai>dotnet run
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\src\aspnet-ai

We can confirm the site is running by navigating to :

Adding AppInisights telemetry to our website

With the app running, let's add a reference to the Microsoft.ApplicationInsights NuGet package in our application. Back to the terminal, type  dotnet add package Microsoft.ApplicationInsights.AspNetCore :

C:\src\aspnet-ai>dotnet add package Microsoft.ApplicationInsights.AspNetCore
  Writing C:\Users\bruno.hildenbrand\AppData\Local\Temp\tmp3FE8.tmp
info : Adding PackageReference for package 'Microsoft.ApplicationInsights.AspNetCore' into project 'C:\src\aspnet-ai\aspnet-ai.csproj'.
info : Restoring packages for C:\src\aspnet-ai\aspnet-ai.csproj...

(...)

info : Package 'Microsoft.ApplicationInsights.AspNetCore' is compatible with all the specified frameworks in project 'C:\src\aspnet-ai\aspnet-ai.csproj'.
info : PackageReference for package 'Microsoft.ApplicationInsights.AspNetCore' version '2.12.1' added to file 'C:\src\aspnet-ai\aspnet-ai.csproj'.
info : Committing restore...
info : Writing assets file to disk. Path: C:\src\aspnet-ai\obj\project.assets.json
log  : Restore completed in 8.68 sec for C:\src\aspnet-ai\aspnet-ai.csproj.

To confirm that the reference was successfully added to our project, check the contents of ItemGroup/PackageReference  section:

C:\src\aspnet-ai>more aspnet-ai.csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>aspnet_ai</RootNamespace>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.1" />
  </ItemGroup>
</Project>

Initializing the AppInsights Framework

Next, we initialize AppInsights by adding the following call on your Startup class:

public void ConfigureServices(IServiceCollection services)
{
    // enable Application Insights telemetry
    services.AddApplicationInsightsTelemetry();
}

Creating an Application Insights resource

Let's now get started with AppInsights on Azure. On this section we will understand how to create an AppInsights instance on Azure and how to integrate it with our .NET Core app. The first thing to do to upload telemetry to AppInisghts in Azure is to create a resource for it. In Azure, click Create Resource and type Application Insights. Enter the requested information, for example:

After created, open your AppInsights resource and copy that instrumentation key (upper-right corner) as we'll need in the next step.

I like to create dashboards for each of my projects in Azure and also let available there the related AppInsights resources.

Setting the Instrumentation Key

Then, we need to configure a telemetry key in our appSettings.json file. Just paste the snippet below above the "Logging" section replacing <appInsights-key> with your Instrumentation Key:

"ApplicationInsights": {
    "InstrumentationKey": "<appInsights-key>"
}

Tip: You could also replace that via the command line if you're running a more capable OS 😊:

sed -i 's/<your-key>/<instrumentation-key>/' *.json

Run your application again. Your data should be available online in a couple of minutes. Let's now try to understand some of that data.

Understanding the telemetry

If everything was correctly configured, you should already see telemetry on Azure. Wondering why? It's because AppInisghts monitors a lot of things by default. To view your data, click on the Search tab of your AppInishgts resource and click Refresh:

It's also important to remember the main categories your data will fall into:

• Request - a regular request to a resource on your site
• Exception - an exception on your site
• View - a custo page view 
• Dependency - a call to an external resource (such as Sql Database, mail server, cache, etc)
• Availability - will list availabilit requests to your app (another AppInsights feature).

Let's now create a custom telemetry to understand how it works.

Tracking Custom Events

To create custom telemetry we should use the TrackEvent method from the TelemetryClient class. TelemetryClient is required to post telemetry data to Azure. For an ASP.NET Core project, the TelemetryClient can be injected in our controller with:

Then, we use our telemetry client to post custom events with:

Reviewing our custom telemetry

In the above code we used the TrackEvent method of The TelemetryClient. That means that we're telling Azure to classify our telemetry as a Custom event. You can see in yellow This is the result of that message:

Clicking on the event shows the transaction:

And clicking on Custom Event we see more info. Note that we can also add custom metrics to our events:

Tracking Exceptions

A common solution to tracking exceptions would be leveraging the global exception handler. In .NET Core 3.0 that's done with:
Then we can review the result as shown below:

Common Questions

I think we covered the most essential bits with respect to AppInsights and ASP.NET Core web apps. Let's now review related and commonly asked questions regarding this implementation.

Suppressing Telemetry

You may be thinking that we have a lot more data than simply those Privacy requested logs I added to the code. As mentioned, AppInishgts automatically monitors lots of events in our applications. Yes, that's awesome but also brings drawbacks.We'll see in a future post how to suppress unnecessary data from our telemetry.

Where's my data?

If you don't see your data, please wait a little longer. It usually takes some time (up to 5 minutes) to get your telemetry online. Check also your Instrumentation Key. Remember, the SDK won't crash your application so debug to confirm it's working before deploying.

Deleting telemetry

You got your data on AppInsights and you realize that there's a lot there that you'd like to delete. How do we do it? We don't. Microsoft describes it on Data collection, retention, and storage in Application Insights, that the data cannot be deleted. And it makes sense. You should think of your telemetry as Event Sourcing. It's also better to have a lot than none.

But in case you really need it, a simple workaround would be creating another instance and using it.

Conclusion

On this post we reviewed how to add, configure, customize and inspect Application Insights telemetry from ASP.NET Core web applications and Azure. AppInsights is a fantastic tool to capture telemetry from your application if you're using Azure. I hope that this post demoed the most essential aspects of AppInsights including what's necessary within Azure.

What could we do next?

Looking for other ideas? Please consider:

1. Plugging alerts on some of our events: we could configure Azure Alerts hooked into our application insights telemetry to alert on specific events. While this is out of scope for this post, I urge you to take a look at the feature. It's very nice indeed.
2. Suppressing telemetry: you may think that you got more data than you need. Try to extend this example by suppressing some of the auto-submitted telemetry;
3. Adding AppInsights to other types of applications: as discussed, we could also leverage AppInsights in everything that can communicate to the cloud - including our console applications, windows services and Windows Form apps.
4. .NET Framework: this example was designed for .NET Core and won't run on .NET Framework. Despite the major changes in the API, the functionality on Azure and use of TelemetryClient class remains the same.
5. .NET Core 3.0 and VS17: this example was written against the version 3.0 .NET Core framework and as of this post was not friendly with my Visual Studio 2017. Run it from the command line as instructed above as it will fail from VS17.

More about AppInsights

Want to know more about Application Insights? Consider reading the following articles:

1. How to suppress Application Insights telemetry
2. Monitor ASP.NET applications using Application Insights and Azure Alerts
3. How to profile ASP.NET apps using Application Insights

Source Code

As always, the source code used on this post is available on GitHub.

References

• What is Azure Application Insights?
• Instrumentation Key 
• TelemetryClient class
• Data collection, retention, and storage in Application Insights
• Installing the .NET Core SDK
• Microsoft.ApplicationInsights.AspNetCore | NuGet.org
• Application Insights for ASP.NET Core applications
• ASP.NET Core 3.0 Exception Handling

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Creating ASP.NET Core websites with Docker
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Hosting NuGet packages on GitHub
• Configuration in .NET Core console applications
• Deploying Docker images to Azure App Services
• Distributed caching in ASP.NET Core using Redis, MongoDB and Docker
• How to build and run ASP.NET Core apps on Linux 
• How to create a Ubuntu Desktop on Azure
• How to Enable ASP.NET error pages using Azure Serial Console
• NServiceBus on Azure WebJobs
• How I fell in love with i3

Running NServiceBus on Azure WebJobs

On this post we will learn how to build and deploy NServiceBus on Azure WebJobs.

Photo by True Agency on Unsplash

Most of us aren't there yet with microservices. But that doesn't mean we shouldn't upgrade our infrastructure to reduce costs, increase performance, enhance security, simplify deployment, and scaling using simpler/newer technologies. On this article let's review how to deploy NServiceBus on Azure WebJobs and discuss:

• why use WebJob
• how to upgrade your NSB endpoints as Azure WebJob;
• the refactorings you'll need
• how to build, debug, test and deploy our WebJob;
• production considerations

If you're starting a new project or have a light backend, I'd recommend you to consider going serverless on Azure Functions or AWS Lambda with SQS.

Introduction

On Azure, NServiceBus is usually deployed on Cloud Services or Windows Services. The major problem with both is that, by being Platform on a Service (PAAS) they are difficult to update, secure, scale out and have to be managed separately.

Depending on your usage, migrating your NSB backend to Azure WebJobs could be a good alternative to reduce costs, maintenance and increase security. Plus, since webjobs are scaled out automatically with your Azure App Services, you would literally get autoscaling on your NSB backend for free!

Azure WebJobs

So let's start by quikcly recapping what are webjobs. According to Microsoft, webjobs are

a feature of Azure App Service that enables you to run a program or script in the same context as a web app, API app, or mobile app. There is no additional cost to use WebJobs.

In other words, a WebJob is nothing more than a script or an application run by Azure. Currently supported formats are:

• .cmd, .bat, .exe (using Windows cmd)
• .ps1 (using PowerShell)
• .sh (using Bash)
• .php (using PHP)
• .py (using Python)
• .js (using Node.js)
• .jar (using Java)

As of the creation of this post, Azure still didnt' support WebJobs on App Service on Linux.

Types of WebJobs

WebJobs can be triggered and continuous. The differences are:

• Continuous WebJobs: start immediately, can be run in parallel or be restricted to a single instance.
• Triggered WebJobs: can be triggered manually or on a schedule and run on a single instance selected by Azure.

Since backend services like NServiceBus and MassTransit traditionally run continuously on the background, this post will focus on continuous WebJobs.

Benefits of running NServiceBus on WebJobs

So what are the benefits of transitioning our NServiceBus hosts to WebJobs? In summary, this appoach will:

• reduce your costs as no VMs or Cloud Services are required
• allow your backend to scale up automatically with your Azure App Service
• eliminates your concerns about maintenance/upgrade/patch and security
• is way simpler to deploy
• differently than NServiceBus Host, is not being deprecated

So let's review how it works.

Migrating NServiceBus backends to WebJobs

Migrating NServiceBus backend to WebJobs couldn't be simpler. Since, NSB's official documentation does not clearly describes a migration process, let's address it here. Essentially you'll have to:

• transform your host project in a console application
• add a startup class and refactor the endpoint initialization
• add a reference Microsoft.Azure.WebJobs so you can use the WebJob Api (optional)

Transforming our Host in a Console Application

The first part of our exercise requires converting our NServiceBus endpoint to a WebJob. Since WebJobs are essentially executable files we can start by simply transforming our endpoint project from a Class Library to a Console Aplication:

Referencing the WebJob package

As recommended, to leverage the Azure Api we'll have to add the Microsoft.Azure.WebJobs NuGet package to our solution. After that package is added, we'll also have to refactor our Main method to correctly initialize and shutdown our bus.

Adding a Startup class

Next, we have to add a startup class to our project. Essentially the compiler just needs a static void Main() method inside our solution so the project can be initialized. This is a simple example:
From here, not much will change. In summary, you will have to:

• Remove the NServiceBus.Host pakage from the solution
• Remove IWantToRunWhenEndpointStartsAndStops as it's no longer necessary
• Refactor some of your settings because your deployment will likely change.
• Optionally, add some sort of centralized logging like Application Insights since your backend will run in multiple instances. And having a consolidated logging infrastructure wouldn't hurt.

Potential Problems

If you updated to the 3.x series of the Microsoft.Azure.WebJobs NuGet package, you probably realized that Microsoft aligned .NET Core and the .NET Framework on this release, already preparing for .NET 5. While that's excellent news, I you may also have conflicting dependencies and build errors as the one listed below.

error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

That error can be fixed by:

1. Referencing the NETStandard.Libray NuGet package on your WebJob;
2. Adding <Reference Include="netstandard" /> just below the <ItemGroup> section on your WebJob's csproj file.

Building, testing and debugging the solution

After upgrading packages, refactoring code and fixing dependencies issues, we'll now have to fix potential build errors, and assert that the unit-tests are passing for the solution solution. Since I don't expect any major issues here, guess we can move ahead and review necessary changes for debugging.

Debugging

Because we transformed our NServiceBus endpoint in a console app, we remain able to start it on debug as previously. However there are some important details ahead. Make sure you set your WebJob project to start when debugging. To do so, we have to configure our solution to start multiple projects at the same time by right-clicking your solution, clicking Startup scripts, selecting Multiple startup projects and setting the Action column to Start for the projects you want to start.

Now set your Azure Storage connection string so you can debug your project with Azure.

Running Locally

But if you want to run the WebJob using the development connection string ("UseDevelopmentStorage=true"), you will realize that the initialization fails. WebJobs can't run with the Azure Storage Emulator:

System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException:
   Failed to validate Microsoft Azure WebJobs SDK Storage account.
   The Microsoft Azure Storage Emulator is not supported, please use a Microsoft Azure Storage account 
hosted in Microsoft Azure.
   at Microsoft.Azure.WebJobs.Host.Executors.StorageAccountParser.ParseAccount(String connectionString,
String connectionStringName, IServiceProvider services)
   at Microsoft.Azure.WebJobs.Host.Executors.DefaultStorageAccountProvider.set_StorageConnectionString(String value)
   at Microsoft.Azure.WebJobs.JobHostConfiguration.set_StorageConnectionString(String value)
   at ATIS.Services.Program.d__1.MoveNext() in C:\src\ATIS\ATIS.Services\Program.cs:line 49
   --- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()

So if we have a console application ready to run, why do even have to start the Jobhost at all?

That's a common scenario in which we want to run a different logic on debug and release modes, I usually resort to preprocessor directives where I have different implementations for debug and release. The next snippet shows it on line 15:

Going Async

To finish, let's make code asynchronous. The two previous snippets could be refactored into  something like:

Deployment

Now let's discuss deployment. Three important things to note:

1. Variable collisions - you will probably have to change or rename variables since some of them may overlap;
2. Changes in the deployment process - to be run as a WebJob, your backend will have to be deployed with your web app;
3. Transformations - will probably have to change some transformations so they're also available for the backend.

Deploying your WebJob

A continuous webjob should be deployed with your Azure App Service on App_data/jobs/continuous. Triggered jobs should go into the App_data/jobs/triggered folder. The screenshot below shows them running in my AppService:

Another way to confirm that is by using the Azure Serial Console and cding into that folder:

Changing the Deployment Process

So how do we get our WebJobs on App_data/jobs/continuous? Well, that will obviously depend on how you're deploying your services. The most common deployment strategies are:

1. ClickOnce from Visual Studio
2. Custom PowerShell scripts
3. Using an automated deployment tool (ex. Azure DevOps, CircleCI, AppVeyor, Octopus Deploy, etc)
4. By hand 😢 

Let's discuss the two most common ways: NuGet packages and PowerShell Scripts.

NuGet Packaging

A common way to package code is building NuGet Packages. I won't extend much into that as it's outside of the scope of this post but I want to highlight that getting our project within our NuGet package is very simple. If you're already building NuGet packages, by simply add a reference to your project on the <files> section, we're telling msbuild to package our project with our web application:

PowerShell

If your CI/CD supports PowerShell, we could add the below snippet in a step just before the release:

# PowerShell Copy-Item ..\MyApp.Backend\bin\release App_Data\jobs\continuous\MyApp.Backend -force -recurse

Post-build event

Another alternative would be running a specific command you your post-build event. Just keep in mind that this would also slow your local builds unless if add some contitional around it:

# xcopy xcopy /Q /Y /E /I ..\MyApp.Backend\bin\release App_Data\jobs\continuous\MyApp.Backend

Testing Considerations

With the deployment out of the way, let's what should be considered when testings:

1. Performance - I didn't see any degradation performance changes but that could not be your case. Test and compare the performance of this implementation.
2. Failures - A crashing WebJob won't crash your App Service but, have you tested edge cases?
3. Scale - the number of instances can be different from your current setup. Can you guarantee that no racing conditions exist? 
4. Logging - Do you need to change how your application logs its data? Are the logs centralized and easily accessible?
5. Remoting - Because you departed Windows VMs and Cloud Services doesn't mean that you can't access the instance remotely. The Azure Serial Console is an excellent tool to manage and inspect some aspects of your job.

Production Considerations

Still there? So let's finish this post with some considerations about running NServiceBus on WebJobs in production. I expect you tested your application against the items highlighted on the previous section.

I'd recommend that before going to production that you:

• build some metrics - around the performance before deploying so you know what to expect;
• use Azure Deployment Slots - to validate production before setting it live;
• doubletriple-check your configuration - because it's a new deployment to a new environment and some configurations were changed, weren't they?
• keep an eye on the logs - as we always do, right? 😊 
• do a post-mortem after the deployment - so your team reflects on the pros/cons of this transition.

Final Thoughts

Migrating NServiceBus from VMs to WebJobs was a refreshing and cost-saving experience. Over time, we felt the heavy burden of managing VMs (security patches, firewalling, extra configuration, redundancies, backups, storage, vNets, etc) not to mention how difficult it is to scale them out. Because WebJobs scale out automatically with the App Service at virtually no extra cost, we definitely gained a lot with this change. Some of the positive impacts I saw were:

• quicker deployments
• easier to scale out
• cheaper to run
• more secure
• reduced zero ops
• simpler deployments
• decent performance

If you're starting a new project or have a light backend, I'd recommend you to consider going serverless on Azure Functions or AWS Lambda with SQS.

More about NServiceBus?

Want to read other posts about NServiceBus, please also consider:

• Custom Security on NServiceBus Endpoints
• MassTransit, a real alternative to NServiceBus?
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core

References

• NServiceBus Host
• Azure App Services
• Self Hosting in Azure WebJobs
• Azure Storage Emulator
• What is PaaS? Platform as a Service
• What is Azure Application Insights?
• MSBuild - Visual Studio
• Developer Command Prompt for Visual Studio
• Create a NuGet package using MSBuild

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Adding Application Insights telemetry to your ASP.NET Core website
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core
• Creating ASP.NET Core websites with Docker
• Deploying Docker images to Azure App Services
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Hosting NuGet packages on GitHub
• Configuration in .NET Core console applications
• How to build and run ASP.NET Core apps on Linux