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.

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

Resetting a users Azure AD Multi factor (MFA) requirement

If you find yourself needing to prompt one of your AAD users to re-set up their MFA method, then the following script should serve that purpose.

Shutting down Azure VMs based on Resource Group tags

Shutting down your non-production VM’s when you’re not using them in a great way to save money. There’s a couple of good Powershell scripts that make this easy to do by Resource Group – but when you want to be a little more granular, and actually automate across resource groups you need a smarter script – this is where Resource tagging comes in.

This script in basically my v1, simple powershell script designed to be run on demand manually. I’ll be publishing the more fully featured version in the Azure Automation Runbook Gallery shortly. That script has had to have a few workarounds put in to deal with issues arising from being a Powershell Workflow and running in Parallel, so I thought it worthwhile to share the simpler version here.

Azure AD B2C – Using the graph API

There’s a really good guide for getting started with CRUD operations in a AAD B2C tenant on the Azure documentation site;
https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-devquickstarts-graph-dotnet/

As per usual, I’ve ended up putting some powershell together to make it a bit more repeatable when I have to do this for multiple AAD tenants.

This particular script creates the application in the AAD tenant. I’ll be posting further scripts that show off doing some clever stuff when I’ve finished testing and polishing them.

Azure ARM Reserved Public Ip Addresses via Powershell

I’ve had the situation where the full allocation of IP addresses are needed up front for firewall configuration. This isn’t so bad when you only need a few, but if you’re going for your full allocation of 20 (or more if you’ve spoken to Microsoft Support) then it can get a little tedious using the Azure Portal UI.

The typical output from this should be something like;

My_IPBag_1 13.79.152.42 Succeeded
My_IPBag_2 13.79.159.10 Succeeded
My_IPBag_3 52.169.176.221 Succeeded
My_IPBag_4 13.79.156.94 Succeeded
My_IPBag_5 13.79.157.129 Succeeded
My_IPBag_6 13.79.153.147 Succeeded
My_IPBag_7 13.79.157.117 Succeeded
My_IPBag_8 13.79.153.183 Succeeded
My_IPBag_9 13.79.154.248 Succeeded
My_IPBag_10 13.79.157.10 Succeeded
My_IPBag_11 13.79.155.174 Succeeded

Note that the assigned IP addresses are not in a continuous range 🙂

If you do try to obtain more than 20 Public IP Addresses in your subscription then you’ll get this friendly error message.

New-AzureRmPublicIpAddress : Cannot create more than 20 public IP addresses with static allocation method for this subscription in this region.

Estimating your annual Azure bill

Following on from my last post when i was tinkering with the Azure EA Billing API…

If you have an Azure Enterprise Agreement, you might want to get a regular idea of where you usage (and money) is heading.

I got the idea from MyFitnessPal, which is a popular nutrition app.  At the end of every day, when you’ve logged your food and told it that you’re finished eating for the day it tells you that; “If every day was like today, then in 5 weeks you’d weigh 160lb’s” (Or something similar).

With utility billing, your usage could fluctuate wildly from day to day so it’s probably best not to take the single estimate without context from other metrics and information… But it’s fun to see what the bill would end up being.

Rather than just providing a straight powershell script, i’ve created a workflow that runs in the Azure Automation platform and submitted it to the public runbook gallery.

“Uses the Microsoft Azure Enterprise Agreement API to estimate your annual Microsoft Azure bill based on the last days usage.

The default Azure EA account is the sample account id and accesskey just so you can see it working before plugging your own details in. You should use the Microsoft Azure Enterprise portal to request your own accesskey.

I recommend adding the script to a daily schedule.

This script requires a credential asset for the your SMTP server in order to send the email.”

Here’s the (v1.0) version of the powershell script;