1
00:00:01,040 --> 00:00:05,070
So imagine if we refactored this query to show CPU

2
00:00:05,070 --> 00:00:07,360
usage for a particular machine,

3
00:00:07,360 --> 00:00:13,970
where the average value was only greater than a certain percentage over 80%,

4
00:00:13,970 --> 00:00:14,840
let's say.

5
00:00:14,840 --> 00:00:18,610
The idea is that you can then feed that logic into an alert rule.

6
00:00:18,610 --> 00:00:20,940
Of course, it's not going to work here.

7
00:00:20,940 --> 00:00:25,320
So let me, okay, so let's come back from the playground back to my subscription.

8
00:00:25,320 --> 00:00:28,440
Notice that I'm looking at my subscription scope here.

9
00:00:28,440 --> 00:00:30,810
And let's just look at a quick example of how we can

10
00:00:30,810 --> 00:00:34,340
build an alert rule on a KQL query.

11
00:00:34,340 --> 00:00:36,700
Let me change the query in question here.

12
00:00:36,700 --> 00:00:40,250
So we're looking at Perf, where the ObjectName is Memory,

13
00:00:40,250 --> 00:00:42,810
the counter is % Committed Bytes In Use.

14
00:00:42,810 --> 00:00:47,340
We're doing a summarization where the value is very high,

15
00:00:47,340 --> 00:00:52,160
so this is going to identify memory‑constrained virtual machines,

16
00:00:52,160 --> 00:00:52,570
all right?

17
00:00:52,570 --> 00:00:54,740
Just a quick example.

18
00:00:54,740 --> 00:01:00,220
And the idea is whenever this query returns a row, we want to fire the alert.

19
00:01:00,220 --> 00:01:03,590
So let's create a new alert rule. The Details is going to

20
00:01:03,590 --> 00:01:05,520
show an error until we give it a name,

21
00:01:05,520 --> 00:01:10,740
so I'm going to call this memoryConstrainedVMs,

22
00:01:10,740 --> 00:01:13,040
and we'll go back to Condition.

23
00:01:13,040 --> 00:01:16,640
Here's the query, and then basically,

24
00:01:16,640 --> 00:01:21,450
we're going to specify that if the alert logic returns greater than,

25
00:01:21,450 --> 00:01:25,840
say, 0 rows every 5 minutes, we're going to fire the alert.

26
00:01:25,840 --> 00:01:27,720
When you create a log search alert,

27
00:01:27,720 --> 00:01:32,870
what happens is Azure runs the query over and over and over again,

28
00:01:32,870 --> 00:01:35,320
and that will have a cost associated with it,

29
00:01:35,320 --> 00:01:40,840
but you get the benefit of having really granular alert criteria.

30
00:01:40,840 --> 00:01:44,000
So then for our action groups, we can create an action group.

31
00:01:44,000 --> 00:01:46,940
Those are created as separate resources.

32
00:01:46,940 --> 00:01:48,250
I'll call this one ar1.

33
00:01:48,250 --> 00:01:51,640
That has a notification step,

34
00:01:51,640 --> 00:01:56,000
you can either do emailing and Azure Resource Manager role holder,

35
00:01:56,000 --> 00:02:00,240
or you can do email, SMS, push, and voice.

36
00:02:00,240 --> 00:02:06,940
Actions, as I said before, allow you to run code in various contexts.

37
00:02:06,940 --> 00:02:10,600
I'm just going to bring in a resource manager role

38
00:02:10,600 --> 00:02:16,640
that lets all the owners know, and I'll call this owner‑notification,

39
00:02:16,640 --> 00:02:21,240
won't do any actions now or taxonomic tags.

40
00:02:21,240 --> 00:02:23,550
We can test the action group. That's kind of cool.

41
00:02:23,550 --> 00:02:26,540
That's in public preview, I haven't seen that before.

42
00:02:26,540 --> 00:02:29,390
But create to finish the creation of that resource.

43
00:02:29,390 --> 00:02:30,010
And the idea,

44
00:02:30,010 --> 00:02:33,550
the reason why the action groups are separate resources is that you

45
00:02:33,550 --> 00:02:38,240
can reuse them in multiple alert‑rule definitions.

46
00:02:38,240 --> 00:02:44,850
So here we have an alert rule finishing up that will run a log query on a

47
00:02:44,850 --> 00:02:54,000
loop. Whenever it returns anything in more than 0 results, it's going to fire off the action group.