1
00:00:01,140 --> 00:00:02,840
Performance Monitor.

2
00:00:02,840 --> 00:00:05,510
Now, Performance Monitor, like Event Viewer, has been

3
00:00:05,510 --> 00:00:09,740
around since the Windows NT days, many, many years indeed.

4
00:00:09,740 --> 00:00:13,220
Performance Monitor is the native Windows system monitoring tool.

5
00:00:13,220 --> 00:00:17,120
I'm going to say it's a native tool, because it's not the only option.

6
00:00:17,120 --> 00:00:20,300
The two main ways to use Performance Monitor are to gather

7
00:00:20,300 --> 00:00:23,840
real‑time statistics, and that's directly analogous to the

8
00:00:23,840 --> 00:00:26,740
Azure Monitor metrics explorer in Azure.

9
00:00:26,740 --> 00:00:30,070
And then we have the data collector set, or DCS,

10
00:00:30,070 --> 00:00:35,110
which is where you're aggregating metric and log values over time.

11
00:00:35,110 --> 00:00:39,860
You can gather performance counters, that's primarily metric data,

12
00:00:39,860 --> 00:00:42,740
time‑sampled numeric readings.

13
00:00:42,740 --> 00:00:48,160
Event traces are, again, notifications of state changes. And you can also

14
00:00:48,160 --> 00:00:51,850
include system configuration, so you could look at, for example,

15
00:00:51,850 --> 00:00:56,810
registry keys and values and note when they change. Best practice with

16
00:00:56,810 --> 00:01:01,690
Performance Monitor is the application is a Win32 app and it does have its

17
00:01:01,690 --> 00:01:05,020
own overhead, so it's best to capture remotely.

18
00:01:05,020 --> 00:01:08,360
You don't want to start a data collector set on the machine that you're

19
00:01:08,360 --> 00:01:12,640
monitoring, because you don't want to artificially inflate or affect those

20
00:01:12,640 --> 00:01:16,440
numbers with the overhead of perfmon itself.

21
00:01:16,440 --> 00:01:19,540
Terms of the Performance Monitor terminology, this might show

22
00:01:19,540 --> 00:01:22,090
up on your exam, so I want to go over it.

23
00:01:22,090 --> 00:01:27,160
The rudimentary diagram you see here is of a four‑core central processing

24
00:01:27,160 --> 00:01:32,570
unit, or a processor, and if we wanted to look at processor utilization on

25
00:01:32,570 --> 00:01:37,980
that CPU, we would dial up the Object, that's the top level of the object

26
00:01:37,980 --> 00:01:41,140
model, in this case it would be Processor.

27
00:01:41,140 --> 00:01:46,390
The Counter is the specific measurement metric, % Processor Time in

28
00:01:46,390 --> 00:01:50,670
this example. And then the most granular level of the Performance

29
00:01:50,670 --> 00:01:55,870
Monitor object model is the Instance. _Total is going to take an

30
00:01:55,870 --> 00:01:59,040
average of all four cores in this example,

31
00:01:59,040 --> 00:02:02,230
but if you wanted to gather readings on just a single core,

32
00:02:02,230 --> 00:02:05,130
you absolutely can index it out and do that.

33
00:02:05,130 --> 00:02:08,380
That will go a long way I think in your troubleshooting, just having a

34
00:02:08,380 --> 00:02:14,400
good grasp of this much of the perfmon terminology. No surprise,

35
00:02:14,400 --> 00:02:18,220
Windows PowerShell has native support for working with Performance

36
00:02:18,220 --> 00:02:22,020
Monitor programmatically. In this example, we're using the Get‑Counter

37
00:02:22,020 --> 00:02:33,000
cmdlet to grab % Processor Time, we're doing a sample interval of every 2 seconds.