Tag Archives: Target

Azure Monitor – Failures and Triggering an Alert from Application Insights

Azure Application Monitoring allows for a lot more functionality than just Application Insights. In this post, I’m going to walk through setting up and triggering an an alert.

Before we trigger an alert, we need to have something to trigger an alert for. If you’re reading this, you may already have an app service deployed into Azure, but for testing purposes, I’ve created a fresh MVC template, and added the following code:

This will cause an error when the privacy menu option is pressed, around 1 in 3 times (ctrl-f5 can give you several).


If you have Application Insights set-up for the app service, you can select the Failures blade:

Looking at this image, there’s three points of particular interest. First, I’ve selected the Exceptions tab – this lets me see only the requests and any exceptions that resulted. As you can see, there was a spike where I’ve highlighted. Finally, on the right-hand side of the screen, the exceptions are broken down by type; in this case, I only have one. I can drill into this by selecting the count, or by selecting Samples at the bottom.

The next step is to set up an alert when I get a given number of exceptions.

Creating an Alert

To set up a new alert, select Alerts under Monitoring:

As you can see, it tells us that we have no alerts. In fact, there’s a distinction to be drawn here; what this means is that no alerts have actually been activated. To create a new Alert Rule select Create -> Alert rule:

In creating a new alert, there’s three main things to consider: scope, condition, and action.


The scope of the alert is what it can monitor: that is, what do you want to be alerted about. In our case, that’s the app service:


The next section is condition. There are many options here, but the one that we’re interested for this is Exceptions:

After selecting this, you’ll be asked about the Signal Logic – that is, what is it about the exceptions that you wish to cause an alert. In our case, we want an alert where the number (count) of exceptions exceeds 3 in a 5 minute period:

Once you select this, it’ll give you an idea of what this might cost. In my tests so far, this has been around $1 – 2 / year or so.


The next section is Actions: once the alert fires, what do you want it to do? This brings into play Action Groups. Here, we’ll create a new Action Group

You can tell it here to e-mail, send an SMS, etc.:

It is not obvious (at least to me) from the screen above, but on the right-hand side, you need to select OK before it will let you continue.

We’re going to skip the other tabs in the Action Group and jump to Review + create, then select Create. This will bring you back to the Actions tab, and select that as the default action. You’ll also get a notification that you’re in that action group:

Finally, in Details you can name the alert, and give it a severity; for example:

Once you create this, you’ll be taken back to the Alerts tab – which will still, and confusingly, be empty. You can see your new Alert in the Alert rules section:

Triggering the Alert

To trigger the alert, I’m now going to force my site to crash (as described earlier) – remember that the condition is greater than 3. Once I get four exceptions, I wait for the alert to trigger. At this point, I should get an e-mail, telling me that the alert is triggered:

Finally, we can see that this triggered in the Alerts section. If you drill into this, it will helpfully tell you why it has triggered:

Once the period has passed, and the exceptions have dropped below 4, you’ll get another mail informing you that the danger has passed.


We’ve just scratched the surface of Azure Alerts here, but even this gives us a taste for how useful these things are. In future posts, I’m going to drill into this a bit further.

Beginner’s Guide to Docker – Part 2 – Debugging a Docker Build

In this post I covered the very basics of getting started with Docker. Once you start to experiment, you’ll need to learn how to debug and investigate some of the unexpected things that happen.


In this post, you’ll see references to WebbApplication4 and WebApplication5. This is simply because, during creating the post, I switched, didn’t realise the screenshots were a mix of both, and now don’t consider it worth my time to change. Just consider the two interchangeable.

Asp.Net 5

For this example, we’ll use the default dockerfile that comes with Asp.Net 5; however, we’ll build it up ourselves. Just build a new Asp.Net project.

When setting this up, do not enable docker support:

If we had enabled docker support, we would get a docker file – so let’s build that (this is taken directly from that file). We’ll put it in the same directory as the sln file.

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
COPY ["WebApplication4/WebApplication4.csproj", "WebApplication4/"]
RUN dotnet restore "WebApplication4/WebApplication4.csproj"
COPY . .
WORKDIR "/src/WebApplication4"
RUN dotnet build "WebApplication4.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication4.csproj" -c Release -o /app/publish

FROM base AS final
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication4.dll"]

To give a quick rundown of what’s happening in this file:
– Where you can see `AS base`, `AS build`, etc, these are known as stages (we’ll come back to that).
– The `FROM` statements are telling docker to build on an existing image.
– WORKDIR changes the running directory inside the container: if this directory doesn’t exist, then the command will create it.
– COPY does what you would think: copies whatever you tell it from the first parameter (the host machine) into the second (the docker container)
– RUN executes a command in the container.
– Finally, ENTRYPOINT tells docker what to do when it starts the container – it our case, we’re running `dotnet WebApplication4.dll`.

Building and Running

To build the image, go to the application’s solution directory (where your sln file is located):

docker build -t pcm-web-app-4 . 

Once the image builds successfully, you can run it like this:

docker run pcm-web-app-4 -p 1234:80

In this post, we’re going to be more interested in debugging the build itself that running the container. Having said that, we should quickly visit the port mapping (-p); the command above is mapping the port 80 inside the container (in the docker file, we issues an EXPOSE on that port) to post 1234 on the host (so you would navigate to localhost:1234 on the host machine to connect).

Listing Docker Containers, Stopping, Killing, and Attaching

You can list running docker containers by issuing the command:

docker ps

Once you have the container ID (highlighted in the image), you can do various things with it.


To attach to the instance:

docker attach 229

Notice that I only used the first three letters of the container instance ID? That’s because docker will let you abridge the ID to the smallest unique set of numbers. This will attach to the container, and you can browse around.

Stop and Kill

If you want to remove an instance, the command is:

docker stop 229

Which will stop the current instance. However, the instance is still there. You can see it by calling:

docker ps -a

To remove the instance completely, you’ll need to call:

docker rm 229

However, you will only be able to remove the container once it’s stopped.

Now that we’ve covered some basics, let’s get into the debugging.


The first useful tip here is to use the target parameter. To build the dockerfile above, you may do something like this (as shown above):

docker build -t web-app-5 . 

That will build the entire image; but if you get an issue, it may fail at an intermediate stage; in that case, you can break down the build; for example:

docker build --target build -t pcm-web-app-5 .

You can then have a look around at the build files by attaching to the container:

docker run -it pcm-web-app-5

A similar technique can be used if you’re getting issues with the entry point not functioning as expected.


In the dockerfile, you can simply comment out the ENTRYPOINT:

#ENTRYPOINT ["dotnet", "WebApplication5.dll"]

Now, if you run the container; for example:

docker run -d -it pcm-web-app-5

-d launches the container in detached mode; you can then attach:

docker attach eb5

You can then manually run the entry point; for example:

Finally, let’s see how we can see details of a running container.

Inspecting the Container

While the container is running, there’s a set of metadata that is accessible. This contains things like the IP, ports, Mac Address, Name, etc… To view this, call:

docker inspect <container ID>

For example:

docker inspect 41b

There’s a lot of information here, and you can traverse it by using the -f parameter to specify a specific attribute. For example:

docker inspect -f '{{ .State.Status }}' 07a

This will show specific properties without the need to scroll through the full JSON.