1 00:00:01,240 --> 00:00:06,140 Lastly, let's look at troubleshooting Azure VM performance issues. 2 00:00:06,140 --> 00:00:10,840 What I want to do here is give you six inbox native Microsoft Azure 3 00:00:10,840 --> 00:00:15,370 tools that will help you generate performance baselines for your 4 00:00:15,370 --> 00:00:19,260 Azure VMs. And the benefit of a performance baseline is that you 5 00:00:19,260 --> 00:00:23,560 then can more easily see deviations and alert on those. I had 6 00:00:23,560 --> 00:00:24,980 mentioned Resource Health. 7 00:00:24,980 --> 00:00:30,000 This is a great way to report and alert on when there's a platform issue on 8 00:00:30,000 --> 00:00:34,530 Microsoft's side and you're trying to resolve that question of is the 9 00:00:34,530 --> 00:00:39,610 problem with myself and my configuration or is there something happening on 10 00:00:39,610 --> 00:00:44,510 the Azure fabric, all right? Azure Monitor VM insights is a collection of 11 00:00:44,510 --> 00:00:46,840 curated performance views. 12 00:00:46,840 --> 00:00:49,970 This does require that you have a Log Analytics workspace 13 00:00:49,970 --> 00:00:54,210 deployed and that you've enrolled or onboarded your Azure VMs to 14 00:00:54,210 --> 00:00:58,210 that workspace. But VM insights can save you a lot of work where 15 00:00:58,210 --> 00:01:00,840 otherwise you'd have to know, for example, 16 00:01:00,840 --> 00:01:06,070 what are the most important metrics to look at? What KQL or Kusto Query 17 00:01:06,070 --> 00:01:10,510 Language queries should I base my monitoring on for performance tuning, 18 00:01:10,510 --> 00:01:16,020 you see? Metrics Explorer is good if you do know what metrics you're most 19 00:01:16,020 --> 00:01:20,180 interested in. With Windows Server, of course, there are metrics like 20 00:01:20,180 --> 00:01:25,440 percent, CPU time, and average disk queue length, and disk I/O. All of 21 00:01:25,440 --> 00:01:30,400 that kind of stuff is surfaced, and you can plot those in live charts. And 22 00:01:30,400 --> 00:01:31,170 then again, 23 00:01:31,170 --> 00:01:34,750 you can build alerts based on those metrics. If 24 00:01:34,750 --> 00:01:36,720 you're using Azure Log Analytics, 25 00:01:36,720 --> 00:01:40,740 you're taking all of the Windows Server performance telemetry, 26 00:01:40,740 --> 00:01:44,220 putting it into a Log Analytics workspace, and you then can use the 27 00:01:44,220 --> 00:01:48,340 unified Kusto Query Language in order to report an alert. 28 00:01:48,340 --> 00:01:50,740 Resizing VM is a quick fix. 29 00:01:50,740 --> 00:01:53,140 Now there's going to be a cost implication, of course, 30 00:01:53,140 --> 00:01:56,540 particularly if you're resizing to a larger size. 31 00:01:56,540 --> 00:02:00,940 But this is one of the great conveniences in my experience of cloud computing. 32 00:02:00,940 --> 00:02:05,180 If you determine after conducting a performance baseline that the server 33 00:02:05,180 --> 00:02:08,590 needs more CPU, RAM, network, and storage support, 34 00:02:08,590 --> 00:02:09,900 you absolutely can do that. 35 00:02:09,900 --> 00:02:14,010 You can resize, and boom! Instantly, after a single 36 00:02:14,010 --> 00:02:17,340 restart, that VM has more capacity. 37 00:02:17,340 --> 00:02:22,740 Likewise, if you're using the standard storage SKU, or stock keeping unit, 38 00:02:22,740 --> 00:02:25,940 you can boost that with a couple of mouse clicks to use, 39 00:02:25,940 --> 00:02:26,370 say, 40 00:02:26,370 --> 00:02:30,640 the standard SSD or the premium SSD to get much more 41 00:02:30,640 --> 00:02:37,000 predictable storage I/O. Now let's do a demo and convert a lot of this theory into practice.