Monitoring Azure Web Jobs Availability

...and now for something non-Sitecore related!

I help run a friend's small family business website in Azure where we use PDF generation through an Azure Web Job which runs on the same App Service Plan as their website (to save on costs).

Recently we've been seeing issues where the Web Job decides to suddenly stop, and I have to manually restart it - easy enough, but very frustrating (and they have to ping me to tell me when they notice).  While I look into the cause of the issues I thought it was worth setting up some alerts so that I can be a bit proactive and start the Web Job before they notice (if possible).

You might think that this is a simple case of setting up a standard Alert in Azure Monitor, but Web Jobs work differently (effectively, behind-the-scenes) and there is no easy way to do this out of the box. 

Fortunately, there are a few blogs around such Monitoring Azure WebJobs Health with Application Insights – Kloud Blog, which can show you the way. Unfortunately most, if not all, suggest an old method of using Visual Studio to record a test rather than using some of the newer functionality of App Insights which supports headers. Now it's a nice and simple process!

So without further ado, the steps:

1. From the Azure Portal, download your publishing profile - containing the username and password to access your Kudu environment, including deployments and APIs used to fetch Web Job status
   
   
   
   
   
2. Calculate the Kudu API endpoint where you can see the status of your Web Job
   https://your-web-app.scm.azurewebsites.net/api/triggeredwebjobs/YourWebJob
3. Use Postman or a tool like Basic Authentication Generator to calculate the base64 encoded username + password to use in your Authorization header.
   You should be able to call the endpoint in Postman and see an example
   
   
   
   
   
4. Create an availability check in App Insights which calls your endpoint with the Authorization header and checks for a status of "Running"
   
   
   
   
   
5. Create an Alert in Azure Monitor which alerts you if the health check fails
   
   
   
   
   
   

Azure bug in SCM Uri for slots

I thought I'd raise some more attention (mostly out of pure frustration) to a bug in the Azure API that I came across today.

Rackspace, as one of our client's hosting providers, uses a guid as the Sitecore deployment ID, and so it is prepended to all the resource names.  This creates quite long app names, and combining that with a slot name (eg. 'cm-staging'), means that Azure drops some characters in the middle to maintain a 40 character hostname.
eg.
app name: 3dd1a584-abc6-4019-a917-633cb1dbfb40-prod-cm
slot name: cm-staging
becomes: 3dd1a584-abc6-4019-a917-633cb1dbfb40-pro-cm-staging.scm.azurewebsites.net

This unfortunately means that one can't simply use 'webappname-slotname'.azurewebsites.net as the URL, and it requires an API call to find out what Azure has generated.

We are using the Kudu API to run a script on our web apps (and slots) which means making REST calls to <webapp/slot>.scm.azurewebsites.net and this Kudu/scm URL is nicely provided in the publishing profile which can be retrieved with a simple Azure REST call.

Unfortunately the Azure API appears to do a simple 'webappname-slotname', and doesn't generate the 40 character URL which Azure actually uses.
ie. the URL that is returned: 3dd1a584-abc6-4019-a917-633cb1dbfb40-prod-cm-cm-staging.scm.azurewebsites.net

This has apparently been raised to Microsoft who are working on the issue.  However, rather than using the 'hostnames' property, you need to filter on the 'EnabledHostNames' property.

If I could make a suggestion: do your best to avoid using guids in your app names, or really long app names for that matter, it causes a world of pain.