Azure Monitor: How to View Alerts Triggered on a Resource in a Timeline View

Azure alerts enable you to receive notifications or take automated actions based on predefined conditions occurring within your Azure resources.

In this article, I will demonstrate a straightforward method for monitoring alerts triggered by specific alert rule(s) within a designated timeframe for a resource. This approach enables us to promptly identify any issues and correlate them with other incidents that occurred during the same period. 

Additionally, it facilitates cross-referencing with metrics such as CPU usage, memory consumption, and more, within the same time interval.

Let's pick a resource. I'll choose Azure Front Door where my alerts are configured.

Navigate to Alerts blade in Monitoring section.

Choose the "View as timeline" option, as illustrated in the diagram below.

Upon selecting that option, alerts will be displayed in a chronological timeline.

You can click on a bubble to access more detailed information.

Upon clicking on a specific incident, you will be provided with comprehensive details.

Detecting malicious requests from bots with Azure monitor and securing workloads using WAF

There are bots and botnets on the internet constantly attempting to exploit vulnerabilities in applications for their advantage. Since Azure public IP ranges are readily available, the risk of such attacks is ever-present. IP ranges are available for various reasons and it is our responsibility to safeguard our assets.

In this article I will demonstrate how to identify such attempts to gain unauthorized access to our precious applications using Azure Monitor - Application Insights. Additionally, I'll illustrate how to safeguard our resources with Azure Front Door - Web Application Firewall (WAF).

Let's explore the process of detecting malicious attempts from bots.

Navigate to Application Insights and go to the Failures tab. You will notice a substantial number of errors in the 400 category, particularly 404 errors as per the image below.

Let's identify the origin of those requests. There are several methods to achieve this. But I prefer the following approach. Navigate to Usage > Events > View More Insights.

Based on the origins of the requests, I can confirm that they are not acceptable.

Now that we have identified a risk, the next step is to safeguard our applications. If you have configured Azure WAF, the process is straightforward.

Let's navigate to  Web Application Firewall (WAF).

I have enabled only the Microsoft_DefaultRuleSet_2.1 as the set of rules in our WAF to filter requests. Unfortunately, it doesn't include any rules to filter requests from bots.

Fortunately, we can address this by adding an additional ruleset to my default rules. To add an additional ruleset, click on Managed Rules, and then click on the Assign button. In the Additional rule set option, select Microsoft_BotManagedRuleSet_1.0, as shown below.

Once it is applied, it will add another set of rules to handle bots

That concludes the necessary steps. Our application is now in good hands.

Analyzing Worst-Case latency experience with Azure Monitor - Application Insights

This article discusses how we can identify and analyze the worst case response of an application/API with Azure Monitor - Application Insights.

We can start the analysis with the Performance blade of the Application Insights workspace.

By default it provides a glimpse of average response.

However, our focus lies in identifying the worst-performing results. Let's transition to the 99th percentile.

We've identified a culprit. There's a conspicuous outlier. Now, let's delve deeper. Our goal is to pinpoint the root cause. Is it within our codebase, or is it linked to a dependency?

There are several avenues to explore this, but I find the Transaction Search feature to be the most effective. Let's navigate to that.

For now, we won't filter by API name, but it's advisable to choose the 99th percentile.

We can observe the peak request there. Let's refine our view by selecting only "Request & Dependency" as filters.

We've already got the answer. It appears to be due to a dependency, as indicated by the yellow line on the graph.

We can even delve deeper to the leaf level to identify the specific request and dependency. Let's narrow down the time period and revisit the results.

Here are the results I obtained in the results section.

This discovery is the starting point for my optimization. We can proceed to take the necessary actions regarding the dependencies.

How to use Azure Monitor - Application Insights to identify performance bottlenecks with dependent resources

When implementing services, we frequently rely on other services or resources. To ensure the efficiency of our solution, it's crucial to pinpoint performance bottlenecks within our system. These bottlenecks can originate from our own codebase or may stem from dependent services, such as external APIs.

You are in safe hands if you have configured Azure Monitor - Application Insights with your solution.

One valuable starting point is to explore Application Insights - Application Map. In the diagram below, you'll notice that calls to External API 2 are slower, as highlighted by the red arrow.

We can further drill down by clicking on the red arrow (the link from our API to External API 2) to identify exactly what API endpoints are slower.

When you click on it, another blade will open, revealing a sample of the slowest calls and offering the option to delve deeper into performance issues. Let's click on the 'Investigate Performance' button.

This action will unveil an informative dashboard that provides a snapshot of performance with regards to the execution of External API 2.

As you can observe, there are certain slow API calls. If you wish to examine samples, simply click on a slow API call and select the 'Samples' button. Then, choose a specific sample to access more detailed information.

In most cases, this information should be adequate to identify performance issues and make improvements.