1 00:00:01,340 --> 00:00:05,010 Azure VM Diagnostics Extension. All right, 2 00:00:05,010 --> 00:00:08,460 I have to give you a preliminary warning that Azure VM 3 00:00:08,460 --> 00:00:10,980 monitoring has been undergoing, well, 4 00:00:10,980 --> 00:00:16,660 gradual revision over the last few years, and the story isn't exactly cohesive. 5 00:00:16,660 --> 00:00:20,840 So I'm going to do my best to make it really easy to understand. 6 00:00:20,840 --> 00:00:24,710 The entry level way to monitor Azure VMs, both Windows 7 00:00:24,710 --> 00:00:27,710 Server and Linux, is to enable what you see in the 8 00:00:27,710 --> 00:00:29,980 screenshot, guest‑level monitoring. 9 00:00:29,980 --> 00:00:35,160 Now, draw your attention to this text that's in the virtual machine 10 00:00:35,160 --> 00:00:40,050 Diagnostic settings blade in the Azure portal that Azure collects host‑level 11 00:00:40,050 --> 00:00:45,720 metrics without you having to do anything, basic ones like CPU utilization, 12 00:00:45,720 --> 00:00:50,300 disk and network usage, and you can go into Azure Monitor, for example, and 13 00:00:50,300 --> 00:00:53,140 plot those live metric values. 14 00:00:53,140 --> 00:00:56,930 However, you probably want to get deeper access into those Windows 15 00:00:56,930 --> 00:01:00,050 Server VMs, Performance Monitor, for example, 16 00:01:00,050 --> 00:01:02,840 Event Viewer. To do that, like I said, 17 00:01:02,840 --> 00:01:08,570 an entry point is to inject the Azure VM diagnostics extension into that VM. 18 00:01:08,570 --> 00:01:12,650 Now that requires a diagnostic storage account because the 19 00:01:12,650 --> 00:01:15,770 diagnostic settings are stored in the blob and table 20 00:01:15,770 --> 00:01:18,250 services of a storage account. 21 00:01:18,250 --> 00:01:21,690 And another benefit of this guest‑level monitoring is that 22 00:01:21,690 --> 00:01:24,680 it's free outside of the cost of the storage that you 23 00:01:24,680 --> 00:01:26,540 consume in your storage account. 24 00:01:26,540 --> 00:01:28,860 However, there's a much better, 25 00:01:28,860 --> 00:01:32,530 more robust way, in my opinion, to do virtual machine 26 00:01:32,530 --> 00:01:35,150 troubleshooting. This is fine, but ultimately you're going to have 27 00:01:35,150 --> 00:01:39,310 to go into the storage account and parse through tables and JSON 28 00:01:39,310 --> 00:01:41,640 files. Ain't nobody got time for that, 29 00:01:41,640 --> 00:01:47,100 especially if you're managing multiple Azure virtual machines. So what we 30 00:01:47,100 --> 00:01:51,540 see in this screenshot is the Extensions + applications blade for an Azure 31 00:01:51,540 --> 00:01:54,510 VM, and I want to draw your attention here. 32 00:01:54,510 --> 00:01:56,880 You see the Microsoft.Insights.VMDiagnosticsSettings. 33 00:01:56,880 --> 00:02:01,130 That's the extension for the IaaS agent, 34 00:02:01,130 --> 00:02:03,920 the guest‑level basic monitoring. 35 00:02:03,920 --> 00:02:07,730 But you'll notice that this particular VM also has something 36 00:02:07,730 --> 00:02:10,640 called the MicrosoftMonitoringAgent on it. 37 00:02:10,640 --> 00:02:13,730 That is also called the Log Analytics agent, 38 00:02:13,730 --> 00:02:16,070 also called the Azure Monitor agent. 39 00:02:16,070 --> 00:02:20,110 And that's the second generation, the next gen of monitoring. 40 00:02:20,110 --> 00:02:26,220 It's what I recommend you use. Now, don't worry too much if your Azure VMs 41 00:02:26,220 --> 00:02:30,820 have both agents. Microsoft has certainly been asked that question a lot in 42 00:02:30,820 --> 00:02:34,140 the past. They don't conflict with each other. 43 00:02:34,140 --> 00:02:38,990 The idea is you could just use the Microsoft Monitoring Agent and use Log 44 00:02:38,990 --> 00:02:42,900 Analytics and not enable the VM diagnostic settings. 45 00:02:42,900 --> 00:02:46,780 But Microsoft says that you might have a better experience when you're plotting 46 00:02:46,780 --> 00:02:52,380 metrics in Azure Monitor when you've got the VM diagnostic settings agent. So, 47 00:02:52,380 --> 00:02:55,870 I tend to install them both and just ignore it. 48 00:02:55,870 --> 00:03:00,710 I have not seen a noticeable performance decrease on those virtual 49 00:03:00,710 --> 00:03:04,840 machines when they have both agents installed. 50 00:03:04,840 --> 00:03:08,870 Lastly, once you enable the guest‑level diagnostic settings, 51 00:03:08,870 --> 00:03:10,900 this is what the interface looks like. 52 00:03:10,900 --> 00:03:14,530 I want you to see it's basic. You have access to performance 53 00:03:14,530 --> 00:03:17,460 counters, and event logs, and crash dump data. 54 00:03:17,460 --> 00:03:21,980 But again, I want to repeat that all of this data is being stored in a 55 00:03:21,980 --> 00:03:25,120 storage account for just this single virtual machine. 56 00:03:25,120 --> 00:03:30,190 So that means being able to report on event logs and performance counters 57 00:03:30,190 --> 00:03:38,000 for multiple Azure virtual machines represents a problem, and this is why we've got Log Analytics.