Within the Azure App Service is something called WebJobs that enables developers to run a script or program in the background within the same context as a web app, API app, or mobile app. Wejobs are included in app service with no extra cost. Webjobs are often used to run regular jobs and batch work as background services. Webjobs exist to make it easier to develop, run background tasks, and scale your web applications.
Webjobs have been around for a while and are considered a part of the serverless computing available on Azure. Today Azure Functions another newer and improved serveless technology service the evolution of WebJobs. When developers need serverless today Azure Functions is typically chosen over webjobs. There are certain cases and scenarios when webjobs are still used instead of Azure Functions and I will not be diving into that topic in this blog post. For more information on when to use what serverless technology on Azure check out the following links:
– A comparison between WebJobs and Functions: Choose between Flow, Logic Apps, Functions, and WebJobs.
– Minnesota’s Azure user group meeting from December 2017 covered comparing the various serverless technologies in Azure. It was presented by Joe Koletar. The meeting notes and PowerPoint download can be found here:
For more information on Azure WebJobs check out these two links:
– Run Background tasks with WebJobs in Azure App Service
– Develop and deploy WebJobs using Visual Studio – Azure App Service
I recently needed to setup monitoring for Azure webjobs status. In this environment there was a mix of continuous webjobs along with some triggered webjobs. Monitoring WebJobs is different compared to monitoring other Azure App Services such as web apps. Web apps can easily be monitored for up/down status and performance for things like in/out traffic, usage, and errors. Background services like WebJobs does not have a defined start or end to the work they do. WebJobs either run continuously or for short amounts of time to perform a task. In this case performance was not a concern but the status of the WebJobs was needed. You can see the status of the WebJobs in the Azure portal as shown in the following screenshot.
The problem here is this is not on a monitoring dashboard, you have to navigate here to see it, you need to click the refresh button for an update, and there is no alert setup when the status is in a non-desired state.
WebJobs does come with a logs website that shows the status of all of your WebJobs and more. This logs site is shown in the following screenshot:
The logs site is nice but the issue with it is that you have to be on the site to see the status of the WebJobs along with the previously mentioned issues viewing the status in the Azure portal. A good solution for monitoring the WebJobs would be a way to check the heartbeat of the WebJobs, the status, and alert you if one of the WebJobs is in a non-desired state. The good news is that this can be accomplished utilizing Application Insights. This is not new but does take some effort to setup. I am going to detail how to set this up. Here is a summary of what needs to be done.
- Need an instance of Application Insights
- Need an authorization header from the WebJobs REST API.
- Need to create a webtest manually or using Visual Studio enterprise.
- Create a multi-step availability test in the Application Insights instance utilizing the webtest file.
- Create an alert on the availability test to notify when a WebJob is in a non-desired state.
- Add the results of the WebJobs availability test to a dashboard in Azure.
Let’s get started.