Merge pull request #235402 from ericd-mst-github/erd-extensions-vm

freshness review

Author: prmerger-automator[bot]

articles/virtual-machines/extensions/diagnostics-template.md

@@ -7,16 +7,17 @@ ms.subservice: extensions
 ms.custom: devx-track-arm-template
 ms.author: gabsta
 author: GabstaMSFT
+ms.reviewer: erd
 ms.collection: windows
-ms.date: 05/31/2017
+ms.date: 04/21/2023
 ---
 # Use monitoring and diagnostics with a Windows VM and Azure Resource Manager templates
 The Azure Diagnostics Extension provides the monitoring and diagnostics capabilities on a Windows-based Azure virtual machine. You can enable these capabilities on the virtual machine by including the extension as part of the Azure Resource Manager template. See [Authoring Azure Resource Manager Templates with VM Extensions](../windows/template-description.md#extensions) for more information on including any extension as part of a virtual machine template. This article describes how you can add the Azure Diagnostics extension to a windows virtual machine template.
 
 ## Add the Azure Diagnostics extension to the VM resource definition
 To enable the diagnostics extension on a Windows Virtual Machine, you need to add the extension as a VM resource in the Resource Manager template.
 
-For a simple Resource Manager based Virtual Machine add the extension configuration to the *resources* array for the Virtual Machine:
+For a simple Resource Manager based Virtual Machine, add the extension configuration to the *resources* array for the Virtual Machine:
 
 ```json
 "resources": [
@@ -65,11 +66,11 @@ The *publisher* property with the value of **Microsoft.Azure.Diagnostics** and t
 
 The value of the *name* property can be used to refer to the extension in the resource group. Setting it specifically to **Microsoft.Insights.VMDiagnosticsSettings** enables it to be easily identified by the Azure portal ensuring that the monitoring charts show up correctly in the Azure portal.
 
-The *typeHandlerVersion* specifies the version of the extension you would like to use. Setting *autoUpgradeMinorVersion* minor version to **true** ensures that you get the latest Minor version of the extension that is available. It is highly recommended that you always set *autoUpgradeMinorVersion* to always be **true** so that you always get to use the latest available diagnostics extension with all the new features and bug fixes.
+The *typeHandlerVersion* specifies the version of the extension you would like to use. Setting *autoUpgradeMinorVersion* minor version to **true** ensures that you get the latest Minor version of the extension that is available. It's highly recommended that you always set *autoUpgradeMinorVersion* to always be **true** so that you always get to use the latest available diagnostics extension with all the new features and bug fixes.
 
-The *settings* element contains configurations properties for the extension that can be set and read back from the extension (sometimes referred to as public configuration). The *xmlcfg* property contains xml based configuration for the diagnostics logs, performance counters etc that are collected by the diagnostics agent. See [Diagnostics Configuration Schema](../../azure-monitor/agents/diagnostics-extension-schema-windows.md) for more information about the xml schema itself. A common practice is to store the actual xml configuration as a variable in the Azure Resource Manager template and then concatenate and base64 encode them to set the value for *xmlcfg*. See the section on [diagnostics configuration variables](#diagnostics-configuration-variables) to understand more about how to store the xml in variables. The *storageAccount* property specifies the name of the storage account to which diagnostics data is transferred.
+The *settings* element contains configurations properties for the extension that can be set and read back from the extension (sometimes referred to as public configuration). The *xmlcfg* property contains xml based configuration for the diagnostics logs, performance counters etc. that are collected by the diagnostics agent. See [Diagnostics Configuration Schema](../../azure-monitor/agents/diagnostics-extension-schema-windows.md) for more information about the xml schema itself. A common practice is to store the actual xml configuration as a variable in the Azure Resource Manager template and then concatenate and base64 encode them to set the value for *xmlcfg*. See the section on [diagnostics configuration variables](#diagnostics-configuration-variables) to understand more about how to store the xml in variables. The *storageAccount* property specifies the name of the storage account to which diagnostics data is transferred.
 
-The properties in *protectedSettings* (sometimes referred to as private configuration) can be set but cannot be read back after being set. The write-only nature of *protectedSettings* makes it useful for storing secrets like the storage account key where the diagnostics data is written.
+The properties in *protectedSettings* (sometimes referred to as private configuration) can be set but can't be read back after being set. The write-only nature of *protectedSettings* makes it useful for storing secrets like the storage account key where the diagnostics data is written.
 
 ## Specifying diagnostics storage account as parameters
 The diagnostics extension json snippet above assumes two parameters *existingdiagnosticsStorageAccountName* and
@@ -90,7 +91,7 @@ The diagnostics extension json snippet above assumes two parameters *existingdia
 }
 ```
 
-It is best practice to specify a diagnostics storage account in a different resource group than the resource group for the virtual machine. A resource group can be considered to be a deployment unit with its own lifetime, a virtual machine can be deployed and redeployed as new configurations updates are made it to it but you may want to continue storing the diagnostics data in the same storage account across those virtual machine deployments. Having the storage account in a different resource enables the storage account to accept data from various virtual machine deployments making it easy to troubleshoot issues across the various versions.
+It's best practice to specify a diagnostics storage account in a different resource group than the resource group for the virtual machine. A resource group can be considered to be a deployment unit with its own lifetime, a virtual machine can be deployed and redeployed as new configurations updates are made it to it but you may want to continue storing the diagnostics data in the same storage account across those virtual machine deployments. Having the storage account in a different resource enables the storage account to accept data from various virtual machine deployments making it easy to troubleshoot issues across the various versions.
 
 > [!NOTE]
 > If you create a windows virtual machine template from Visual Studio, the default storage account might be set to use the same storage account where the virtual machine VHD is uploaded. This is to simplify initial setup of the VM. Re-factor the template to use a different storage account that can be passed in as a parameter.
@@ -133,9 +134,9 @@ The following example shows the xml for metrics definitions:
 </Metrics>
 ```
 
-The *resourceID* attribute uniquely identifies the virtual machine in your subscription. Make sure to use the subscription() and resourceGroup() functions so that the template automatically updates those values based on the subscription and resource group you are deploying to.
+The *resourceID* attribute uniquely identifies the virtual machine in your subscription. Make sure to use the subscription() and resourceGroup() functions so that the template automatically updates those values based on the subscription and resource group you're deploying to.
 
-If you are creating multiple Virtual Machines in a loop, you have to populate the *resourceID* value with an copyIndex() function to correctly differentiate each individual VM. The *xmlCfg* value can be updated to support this as follows:
+If you're creating multiple Virtual Machines in a loop, you have to populate the *resourceID* value with an copyIndex() function to correctly differentiate each individual VM. The *xmlCfg* value can be updated to support this as follows:
 
 ```json
 "xmlCfg": "[base64(concat(variables('wadcfgxstart'), variables('wadmetricsresourceid'), concat(parameters('vmNamePrefix'), copyindex()), variables('wadcfgxend')))]",
@@ -148,7 +149,7 @@ The Metrics configuration above generates tables in your diagnostics storage acc
 
 * **WADMetrics**: Standard prefix for all WADMetrics tables
 * **PT1H** or **PT1M**: Signifies that the table contains aggregate data over 1 hour or 1 minute
-* **P10D**: Signifies the table will contain data for 10 days from when the table started collecting data
+* **P10D**: Signifies the table contains data for 10 days from when the table started collecting data
 * **V2S**: String constant
 * **yyyymmdd**: The date at which the table started collecting data
 
@@ -157,7 +158,7 @@ Example: *WADMetricsPT1HP10DV2S20151108* contains metrics data aggregated over a
 Each WADMetrics table contains the following columns:
 
 * **PartitionKey**: The partition key is constructed based on the *resourceID* value to uniquely identify the VM resource. For example: `002Fsubscriptions:<subscriptionID>:002FresourceGroups:002F<ResourceGroupName>:002Fproviders:002FMicrosoft:002ECompute:002FvirtualMachines:002F<vmName>`
-* **RowKey**: Follows the format `<Descending time tick>:<Performance Counter Name>`. The descending time tick calculation is max time ticks minus the time of the beginning of the aggregation period. For example if the sample period started on 10-Nov-2015 and 00:00Hrs UTC then the calculation would be: `DateTime.MaxValue.Ticks - (new DateTime(2015,11,10,0,0,0,DateTimeKind.Utc).Ticks)`. For the memory available bytes performance counter the row key will look like: `2519551871999999999__:005CMemory:005CAvailable:0020Bytes`
+* **RowKey**: Follows the format `<Descending time tick>:<Performance Counter Name>`. The descending time tick calculation is max time ticks minus the time of the beginning of the aggregation period. For example if the sample period started on 10-Nov-2015 and 00:00Hrs UTC then the calculation would be: `DateTime.MaxValue.Ticks - (new DateTime(2015,11,10,0,0,0,DateTimeKind.Utc).Ticks)`. For the memory available bytes performance, counter the row key looks like: `2519551871999999999__:005CMemory:005CAvailable:0020Bytes`
 * **CounterName**: Is the name of the performance counter. This matches the *counterSpecifier* defined in the xml config.
 * **Maximum**: The maximum value of the performance counter over the aggregation period.
 * **Minimum**: The minimum value of the performance counter over the aggregation period.