This blog post series will cover two approaches which can be used to help to customize how alerts are formatted when they come from Azure Monitor for Log Analytics queries. For this first blog post we will take a simple approach to making these alerts more useful – cleaning up the underlying query.
In Azure Monitor, you can define alerts based on a query from Log Analytics. For details on this process to add an alert see this blog post. This blog post will focus on how you can clean up the query results to make a cleaner alert.
Cleaning up query results
For today’s blog item we’ll start with what I would have used normally as a query for an alert:
Perf
| where (ObjectName == “Processor”
or ObjectName == “System”) and CounterName == “% Processor Time”
| where CounterValue > 40
| sort
by TimeGenerated desc
The query provides all fields because we aren’t restricting what to return.
This will generate the alert as expected, and here’s the resulting email of that alert.
One of the Microsoft folks pointed out to me that if I cleaned up my query it would clean up the results and therefore it would clean up the email which is being sent out (thank you Oleg!). We can take a first stab at cleaning this up by just restricting which fields we are returning with a project statement:
Perf
| where (ObjectName == "Processor"
or ObjectName == "System") and CounterName == "% Processor Time"
| where CounterValue > 40
| project Computer, CounterValue, TimeGenerated
Here’s the resulting email of the new alert:
For queries which are run directly in the portal, we can clean this up further by adding some extends which provide information on our various fields.
Perf
| where (ObjectName == "Processor"
or ObjectName == "System") and CounterName == "% Processor Time"
| where CounterValue > 40
| extend ComputerText = "Computer Name"
| extend CounterValueText = "% Processor Utilization"
| extend TimeGeneratedText = "Time Generated"
| project ComputerText, Computer, CounterValueText, CounterValue, TimeGeneratedText, TimeGenerated
A sample result is below:
This is the query that we will use for the actual email alert, but we’ll showcase one more example in case it’s helpful. We can even move this to more of a sentence format for alerts such as this:
Perf
| where (ObjectName == “Processor”
or ObjectName == “System”) and CounterName == “% Processor Time”
| where CounterValue > 40
| extend CounterValueText = “% Processor Utilization”
| extend Text1 = ” had a high “
| extend Text2 = ” of “
| extend Text3 = ” at “
| extend Text4 = “.”
| project Computer, Text1, CounterValueText, Text2, CounterValue, Text3, TimeGenerated, Text4
A sample result for this query is below:
If we compare the original alert to the new alert side by side shows how much this one simple change can make to clean up and make your alerts more useful: (Original on left, new on right)
The alert on the right-hand side helps to remove the clutter by decreasing the number of fields shown in the results section of the email. It also shortens the email by about a third making it easier to find what you are looking for as you can see based on the examples above.
Summary
If you want to make your current alerts more useful, use a project command to restrict the fields which are sent in the email (IE: Clean up the Log Analytics query). This is quick to put in place and results in a much more readable email alert.
P.S. The email above on the right is, however, a long way from my optimal email format, shown below:
The above approach to alerting from Log Analytics we will cover in the next blog post in this series! Would you like to know more? Get in touch with us here.