Monitor Azure WebJobs Status with Application Insights

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:

http://www.mnazureusergroup.com/2017/12/22/december-2017-meeting-serverless-computing-notes-and-download

For more information on Azure WebJobs check out these two links:

– Run Background tasks with WebJobs in Azure App Service

https://docs.microsoft.com/en-us/azure/app-service/web-sites-create-web-jobs

– Develop and deploy WebJobs using Visual Studio – Azure App Service

https://docs.microsoft.com/en-us/azure/app-service/websites-dotnet-deploy-webjobs

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.

  1. Need an instance of Application Insights
  2. Need an authorization header from the WebJobs REST API.
  3. Need to create a webtest manually or using Visual Studio enterprise.
  4. Create a multi-step availability test in the Application Insights instance utilizing the webtest file.
  5. Create an alert on the availability test to notify when a WebJob is in a non-desired state.
  6. Add the results of the WebJobs availability test to a dashboard in Azure.

Let’s get started.

Read More

OMS and Cherwell ITSM Integration

Microsoft recently released public preview of OMS and ITSM integration. Here is the link for that announcement:

https://blogs.technet.microsoft.com/msoms/2017/05/11/it-service-management-connector-public-preview

Microsoft has built an ITSM connector in OMS. This new ITSM connector can connect to many ITSM solutions out there. The ITSM solutions it can connect to are:

  • System Center Service Manager (SCSM)
  • Cherwell
  • ServiceNow
  • Provance

This new ITSM connector is bi-directional meaning work items can flow from the ITSM solution into OMS and OMS can create work items in the ITSM solution such as incidents, alerts, and events. Hopefully in the future OMS could be used to populate a CMDB and even create application maps from OMS’s Service Map.

I wanted to give this a test run with a test Cherwell instance that I have. There is official documentation for the integrations. The documentation is good however after setting this up I did find that there could be a few more steps spelled out as well as screenshots with the Cherwell piece.

Needed settings from Cherwell:

Before you set the connection in OMS go and get the information you will need. So you will need a username and password of an account that has access to Cherwell, the Cherwell URL, and a Cherwell Client ID.

If you don’t know your Cherwell URL you can get this from the Cherwell client console. Launch Cherwell.

Before you login you can edit the connection to see the URL as shown in the screenshot. You will want to copy this to use in the OMS ITSM connector setup.

Note that you do not want to copy the entire URL. Only copy to the .com like https://test.demo.cherwell.com.

Next we need to generate the Client ID. The Client ID is basically a generated string called the client key used for connecting to Cherwell’s API. To get this client ID Launch the Cherwell Administrator console.

Login and click on Security and then Edit REST API client settings.

A window will pop up and you will need to click on the green plus to create a new one. Give it a name and copy out the Client Key.

Copy this as you will need it later.

Setup in OMS:

Next log into OMS and add the ITSM Connector preview. It is shown in the screenshot below.

After this has been added go to your OMS settings screen click on Connected Sources>ITSM Connector and then click on Add New Connection.

Select Cherwell for the connection type add in your Cherwell settings and save it. If everything worked your OMS is now connected to Cherwell.

Exploring the ITSM Connector:

Next let’s check things out in OMS. Before I did that I first went and created a new incident so I could see this flow over into OMS. So I created the following over in Cherwell:

After doing that I went back into OMS and kicked off a sync because I did not want to wait.

The connector picked up my new incident right away. You can see the dashboard ITSM tile has 2 incidents.

After clicking into this I am brought to the full ITSM dashboard. I then clicked on the Incident tile.

I was then brought to the incident dashboard and I could see the new incident I created.

I clicked on the new incident and it brought me to the OMS search with the details of the incident. Very cool!

I am excited to see cool stuff like this in OMS and integration with many ITSM tools. Look out for more blog posts in the future about ITSM Integration in OMS as well as in Azure Stack.

Read More