Azure Monitor: Metric and Log Alerts

1. The Anatomy of an Azure Monitor Alert

At its core, an alert rule in Azure Monitor watches your telemetry data and fires an alert when a specific condition is met. This process involves a few key components.

There are two primary types of alert rules you'll work with, and choosing the right one is important:

1. Metric Alerts: These are triggered when the value of a specific metric crosses a threshold. They are best for near real-time monitoring of predictable, numeric data like CPU usage, response time, or the number of server errors.
2. Log Alerts: These are triggered based on the results of a KQL query that runs on a schedule against your Log Analytics data. They are incredibly flexible and powerful, allowing you to create alerts for complex conditions, specific error text, or patterns that aren't captured by a single metric.

The table below provides a clear comparison of their features.

For the rest of this lesson, we will create one of each type.

2. Creating a Metric Alert

Let's start with the more straightforward type: a metric alert. We'll set up a rule to notify us if our web application starts generating too many server-side errors. This is a classic use case for metric alerts.

The process involves four main steps: defining the scope (what resource to monitor), the condition (what to look for), the actions (what to do when the alert fires), and the details (naming and describing the rule).

Now, let's watch a short video that demonstrates creating the condition and the action group. Seeing it in the portal will help solidify the concepts from the reading.

Hands-on Exercise: Create a Server Error Alert (10 minutes)

Now it's your turn. Let's apply what you've learned. You will create a metric alert for the App Service you deployed in Module 2.

1. Navigate to your App Service in the Azure portal.
2. In the left-hand navigation pane, under Monitoring, select Alerts.
3. Click Create > Alert rule.
4. The Scope should already be set to your App Service. Proceed to the Condition tab.
5. Click See all signals. In the search box, type Http Server Errors and select that signal.
6. Configure the Alert logic as follows:
   • Threshold: Static
   • Operator: Greater than
   • Aggregation type: Total
   • Threshold value: 5
   • Check every: 1 Minute
   • Lookback period: 5 Minutes
   • This logic means: "Alert if the total number of server errors in the last 5 minutes is greater than 5."
7. Click Next: Actions >.
8. Click Create action group.
   • Basics tab: Select your subscription and resource group. Give the action group a name like EmailAdmins-AG. The display name can be Email Admins.
   • Notifications tab:
     • Notification type: Email/SMS message/Push/Voice
     • Give it a name, e.g., PrimaryAdminEmail.
     • Check the Email box and enter your email address.
     • Click OK, then Review + create, and finally Create.
9. Back on the 'Create an alert rule' page, ensure your new action group is selected.
10. Click Next: Details >.
11. Configure the details:
    • Alert rule name: High Server Error Count
    • Severity: Sev 2 - Warning
12. Click Review + create, then Create.

You have now configured proactive monitoring for server-side failures on your web app!

3. Creating a Log Alert

Metric alerts are great, but what if you need to alert on something more specific? For example, what if you want to know when your application returns a specific error message, or when a user from a particular IP address tries and fails to log in multiple times? This is where log alerts shine.

The foundation of a log alert is a KQL query. You write a query that returns rows when the "bad thing" happens, and the alert rule triggers when the number of rows (or a value within them) crosses a threshold.

The following video provides a concise demonstration of this process, starting from a KQL query and turning it into an active alert rule.

Hands-on Exercise: Create a 'Not Found' Error Alert (10 minutes)

Let's create a log alert to notify you if your application starts generating an unusual number of 404 Not Found errors. This could indicate broken links or scanning activity.

1. Navigate to your Application Insights resource in the Azure portal.
2. Under Monitoring, select Logs.
3. In the query editor, enter the following KQL query. This query counts the number of requests that resulted in a 404 status code over the last 30 minutes.

   requests
   | where resultCode == "404"
   | where timestamp > ago(30m)
   

4. Run the query to ensure it works (it will likely return no results, which is fine).
5. Click New alert rule.
6. On the Condition tab, the query is pre-filled. Configure the Alert logic:
   • Measure based on: Number of results
   • Operator: Greater than
   • Threshold value: 10
   • This logic means: "Alert if the query returns more than 10 rows."
7. Expand the Evaluation section:
   • Check every: 5 Minutes
   • Lookback period: 30 Minutes
   • This means the query will run every 5 minutes and look at the last 30 minutes of data.
8. Click Next: Actions >.
9. This time, click Select action groups. Check the box next to the EmailAdmins-AG you created earlier and click Select. Reusing action groups is a key efficiency.
10. Click Next: Details >.
11. Configure the details:
    • Alert rule name: Excessive 404 Not Found Errors
    • Severity: Sev 3 - Informational
12. Click Review + create, then Create.

You have now set up a more sophisticated alert based on a specific log data pattern!

Conclusion

In this lesson, you have learned how to automate the process of monitoring your applications by creating alert rules. You are no longer required to manually check dashboards or run queries; Azure will now proactively inform you of potential issues.

Key Takeaways:

• Metric alerts are ideal for monitoring simple numeric thresholds on a near real-time basis (e.g., CPU > 90%).
• Log alerts provide maximum flexibility by using KQL queries to detect complex patterns, specific events, or business-logic failures within your log data.
• Every alert rule consists of a Scope (what to monitor), a Condition (the trigger), Actions (what to do), and Details (name and severity).
• Action Groups are reusable components that define how you get notified (email, SMS, etc.) and can be linked to multiple alert rules.

Next Steps

You've now explored how to instrument your code, query the resulting telemetry, and create alerts. The final piece of the monitoring puzzle is visualizing how different parts of your distributed system interact. In our next and final lesson of this module, we will explore the Application Map in Azure Monitor to visualize dependencies and identify performance bottlenecks.