Azure Alerts — Define alert rule in your application service to catch failed requests by Webhook!

When you are an API provider or a platform developer with an API, monitoring your service and identifying possible improvements is one of the basic steps of providing a good solution. Therefore, the monitoring components and the outputs of these components are very important. In line with these outputs, unforeseen behaviors can be detected and improvements are made accordingly.

3 main reasons for the importance of API Monitoring.

1. General website tracking solutions may not contain API specific tracking.
2. The solution we provide is our responsibility.
3. In large-scale API solutions, there may be resources that are not updated and / or not working. System errors caused by these undetected resources reduce customer revenue and reduce user satisfaction.

In this article, I will be showing how your API solution hosted in Azure application service can be monitored with the customized Alert + Alert Rule mechanism.

Let’s assume very simply that we have an API. This API should return successful response as well as unsuccessful (500) response. A simple API to implement our mentioned scenario.

[ApiController]
    [Route("[controller]")]
    public class TrialController : ControllerBase
    {
        [HttpGet]
        [Route("base")]
        public IEnumerable<WeatherForecast> Base()
        {
            throw new Exception("Base exception is thrown in trial controller.");
        }
 
 
        [HttpGet]
        [Route("argument")]
        public IEnumerable<WeatherForecast> Argument()
        {
 
            throw new ArgumentNullException("Argument null exception is thrown in trial controller.");
        }
    }

In the Azure application service, let’s go to the Alerts section:

Alerts

With the link of Manage Alert Rules, We browse the available alert rules:

App service Alert rules

So here, I am going to demostrate how to create “Failed Requests — Server Errors Alert rule”. Click to browse new alert rule adding section.

An alert rule must have:

• Resource (our Application Service)
• Condition ( Whenever the total http5xx is greater than 1)
• Action (Webhook)
• Alert rule details (Critical)

Azure alert rule

At the first section (resource), we define scope of the alert rule. Here, the scope is our Application Service.

At the second section (condition), we define the condition for the alert being triggered. There are signal types. We go with the metrics and select the Http Server Errors:

Azure alert signals

Once we select the server errors, we indicate additional configuration for this signal:

Signal configuration

It is splitted by dimension ( Instance) and the condition should be defined as Greater than 1 as follows:

Azure alert signal configuration

On the alert rule creation pane, we define action:

Before creating action, lets create a webhook to receive webhook messages:

Please check the : https://pipedream.com/

Connect APIs, Remarkably Fast - Pipedream

With pipedream, define a fake webhook to see interation once the Azure pushes the payload.

Here the webhook URI:
https://f742a67f40906616200a129058b2870e.m.pipedream.net

In action group, we define action type as webhook. Please notice that notifications can be indicated here as well.

Azure action group

Once we defined all configuration, our alert rule is as follows:

Azure alert rule

So, we are able to see alerts in Alerts pane as well:

Application Service — Alerts pane

An example payload in pipedream:

Webhook payload

Azure Alert Payload:

Azure Monitor Common Alert Schema

A gif for the flow:

Azure Alert Payload

Conclusion

We observed that the Alert specific payload can be obtained via webhook. This is how we can monitor failed API results by manipulating the common payload or customized payload.