External monitoring of Azure web apps with Statuscake

The problem with monitoring from within the platform your app lives in, is that you’re unaware of any connectivity problems that exists outside of your environment. True, you’re not wanting to be monitor Internet weather either but in reality having both monitoring systems is a must.

Statuscake, is an endpoint monitoring service that offers a bunch of features around web endpoint monitoring – but i’ll just be looking at the most basic http check which will look for a 200 response.
*There are many other services available that perform this function – including Pingdom which I’ve used for years (and actually monitors this blog).*
When I first found Statuscake, years ago – it offered more monitoring servers in the UK than any other provider so provided the USP. What I liked about it was the API and the service it provides as part of its free tier.

statuscake monitoring

I’ve written several automation scripts against it’s API and have one blog post here.

Now that we’re happy with Endpoint monitoring through Statuscake, here’s the powershell functions I’ve written to perform a bunch of standard tasks.

So how can we get some monitoring action happening from Azure? Let’s stick to powershell and start using the Azure cmdlets to query all the Web App endpoints. Once we have the list of Azure addresses, we can then query Statuscake to see which one’s do not yet have a monitor set up – then add it. In this way we can host the powershell in Azure Automation to run on a scheduled basis.

What this will give you for free, is a record of availability and performance metrics. It can be extended to alert you upon detected downtime. In short, you’ve got nothing to lose by monitoring all your Azure App Services automatically. In fact a side benefit of the monitoring will be that in the event your Web Application app pools go to sleep, monitoring will keep them alive.

Powershell scripts available on GitHub.

Azure Powershell on linux on windows

In the Windows 10 Anniversary update you’re able to install the “Windows Subsystem for Linux”, see the Bash on Ubuntu on Windows blog.

Then in August we announced that Powershell had been opensourced and available on linux : https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/.

The version of Ubuntu that gets installed is 14.04 – which is supported by Powershell. So obviously the first thing you’ll want to do on your Windows 10 OS, is install Bash then Powershell and then the Azure module for Powershell. If only for a change of scenery and a bit of script-inception.

Installing Azure Powershell on Linux, in Windows

Azure API Management Soap Facade

When you’ve got an old web service that’s needing to be consumed by a mobile app (which loves binding json) – but you can’t change the code of your webservice, you’ve got 1 real option available. Create a fa├žade for the web service.
The main benefit is of course that the mobile app can consume the json directly, without conversion. But API Management also gives you the ability to manage multiple Api’s, protect the API’s (security/throttling), monitor/monetise the API’s and more importantly introduce a caching layer.

Here’s a great guide that a fellow Softie’s written, which takes you through the whole process with a great explanation.
http://houghtonweb.co.uk/index.php/2016/06/01/using-azure-api-management-to-convert-soap-api-xml-to-json/

To take it a little further, if you don’t want to submit a SOAP-esque json docment then you need to do a little more policy authoring. My service doesn’t require anything in the request body, just 2 querystring parameters.

The key parts in the policy below are;

  • Wrap the SOAP envelope in CDATA tags
  • Use tokens in your SOAP packet, and replace them after setting the request body
  • Set the header to text/xml after setting the body
  • Use an Eventhub to debug the new body of the request you’re making. This site is really helpful in getting the Eventhub working with APIM
  • Convert the response to Json
  • Consider replacing some of the response Soap envelope tags and xml namespace tags

Creating a swagger definition for an Azure Logic Apps Http Request endpoint

If you’ve created a Logic App with a HTTP Request trigger, then next logical thing to do is expose it for consumption (Like in Azure API Management).
Swagger is now the defacto way of describing API’s, and it makes sense that you’d want to create one for your logic app. I’m sure this will make it in there as a feature soon, but for the moment you need to roll your own.

The LogicAppsRequestSchema is exactly the same Json schema that you used in the HTTP Request Trigger action, so keep that handy. The text in bold are the areas you need to replace with your own.

I find that http://editor.swagger.io is the best tool for creating the Swagger files.
The validation is great (although it doesn’t like the default values for the parameters, which as far as i can gather are valid).

{
"swagger": "2.0",
"info": {
"title": "Friendly name for your logic app",
"description": "Some kind of description about what it does",
"version": "1.0.0"
},
"host": "aprodinstance.anazureregion.logic.azure.com:443",
"schemes": [
"https"
],
"basePath": "/workflows/yourworkflowid/triggers/manual",
"produces": [
"application/json"
],
"paths": {
"/run": {
"post": {
"consumes": [
"application/json"
],
"operationId": "Friendly text",
"summary": "Friendly text",
"description": "Friendly text",
"parameters": [
{
"name": "api-version",
"in": "query",
"description": "api-version",
"required": true,
"default": "2016-06-01",
"type": "string"
},
{
"name": "sp",
"in": "query",
"description": "sp",
"required": true,
"default": "%2Ftriggers%2Fmanual%2Frun",
"type": "string"
},
{
"name": "sv",
"in": "query",
"description": "sv",
"required": true,
"default": "1.0",
"type": "string"
},
{
"name": "sig",
"in": "query",
"description": "sig",
"required": true,
"default": "thesignaturepartinyourlogicapphttpurl",
"type": "string"
},
{
"name": "body",
"in": "body",
"description": "The json you want to submit",
"required": true,
"schema": {
"$ref": "#/definitions/LogicAppsRequestSchema"
}
}
],
"responses": {
"200": {
"description": "Logic Apps response",
"schema": {
"$ref": "#/definitions/LogicAppsResponse"
}
}
}
}
}
},
"definitions": {
"LogicAppsRequestSchema":
{
"type": "object",
"required": [
"Header",
"StartOfDuty"
],
"properties": {
"Obj1": {
"properties": {
"Prop1": {
"type": "string"
}
"required": ["rop1"],
"type": "object"
},
"Obj2": {
"properties": {
"Prop1": {
"type": "string"
}
"required": ["Prop1"],
"type": "object"
}
}
}
,
"LogicAppsResponse": {
"type": "object",
"properties": {
"success": {
"type": "boolean",
"description": "Just a simple response property. You could template return objects/ error messages etc."
}
}
}
}
}

Cascading Resource Group Tags in Azure

Resource Manager Policies in Azure are the way to define and enforce a tagging system.
You can define in a json format rules that must be adhered to for new resources that are deployed.
eg.

For resources that you’ve already created, you’ll need to decide on the appropriate strategy. One that I’ve recently put together is a script that cascades the tags you define at the Resource Group level down to the individual resources (VM’s, vNETs, etc etc).

It doesn’t override any of the existing tags that a resource has, simply ensuring that each of the resources has at a minimum the tags that are defined at the Resource Group level.

This version isn’t optimised for running on a schedule in Azure Automation as it’s not a powershell workflow so doesn’t parallelise the foreach loops.

For the latest version, use the GitHub link.
https://github.com/Gordonby/PowershellSnippets/blob/master/Add-ResourceGroupTagsToResources.ps1