So imagine if we refactored this query to show CPU
usage for a particular machine,
where the average value was only greater than a certain percentage over 80%,
let's say.
The idea is that you can then feed that logic into an alert rule.
Of course, it's not going to work here.
So let me, okay, so let's come back from the playground back to my subscription.
Notice that I'm looking at my subscription scope here.
And let's just look at a quick example of how we can
build an alert rule on a KQL query.
Let me change the query in question here.
So we're looking at Perf, where the ObjectName is Memory,
the counter is % Committed Bytes In Use.
We're doing a summarization where the value is very high,
so this is going to identify memory‑constrained virtual machines,
all right?
Just a quick example.
And the idea is whenever this query returns a row, we want to fire the alert.
So let's create a new alert rule. The Details is going to
show an error until we give it a name,
so I'm going to call this memoryConstrainedVMs,
and we'll go back to Condition.
Here's the query, and then basically,
we're going to specify that if the alert logic returns greater than,
say, 0 rows every 5 minutes, we're going to fire the alert.
When you create a log search alert,
what happens is Azure runs the query over and over and over again,
and that will have a cost associated with it,
but you get the benefit of having really granular alert criteria.
So then for our action groups, we can create an action group.
Those are created as separate resources.
I'll call this one ar1.
That has a notification step,
you can either do emailing and Azure Resource Manager role holder,
or you can do email, SMS, push, and voice.
Actions, as I said before, allow you to run code in various contexts.
I'm just going to bring in a resource manager role
that lets all the owners know, and I'll call this owner‑notification,
won't do any actions now or taxonomic tags.
We can test the action group. That's kind of cool.
That's in public preview, I haven't seen that before.
But create to finish the creation of that resource.
And the idea,
the reason why the action groups are separate resources is that you
can reuse them in multiple alert‑rule definitions.
So here we have an alert rule finishing up that will run a log query on a
loop. Whenever it returns anything in more than 0 results, it's going to fire off the action group.