Managing Agents

In the Log Analytics workspace, you can see at a glance in the Settings | Agents management section whether VMs are connected to this workspace and by which agents. Here you can also configure the data collected, but only for the new Azure Monitor Agent, by clicking Data Collection Rules and creating and linking a data collection rule (Figure 2).

Figure 2: Agent management from the perspective of the Log Analytics workspace; a machine is connected by the legacy agent in this case.

The Legacy agents management setting lets you configure precisely what information the legacy agent collects in the associated workspace. You need to define the information you need in the five tabs: Windows event logs , Windows performance counters , Linux performance counters , Syslog , and IIS logs . Because your selection will cost you money, you need to consider your options carefully up front. As mentioned earlier, unlike dedicated DCRs, the centralized configuration of the Log Analytics Agent applies to all connected VMs without exception, whether in Azure, other clouds, or on-premises.

A word on VM Insights, Container Insights, Application Insights, and others: If you enable VM Insights for the desired VM in Monitoring | Insights , you use Log Analytics, but you can opt for the legacy or new agent during the configuration. However, be careful: If you have run VM Insights with the legacy agent in the past and you are migrating to the new agent, the Azure Portal will warn you of data duplication if both are installed.

To avoid a duplicate configuration, you first need to offboard VM Insights for the VM and then select Monitoring configuration and tell it to use the new agent. By the way, you can also use KQL to find out whether a VM is connected to an agent – and to which one. To do so, use the statement:

Heartbeat
| where OSType == 'Windows'
| where Category != 'Azure Monitor Agent'
| summarize arg_max(TimeGenerated, *) by SourceComputerId
| sort by Computer
| render table

If you click Edit again in the Monitoring configuration dialog, you are first told that VM Insights now supports data collection with Azure Monitor Agent, but that this is still classified as a preview.

As I mentioned earlier, you can use DCRs to configure the Azure Monitor Agent and set them up when provisioning the agent for logs and insights or in advance on the Azure Portal and assign them later. When you use the new agent, DCRs with the MSVMI prefix (if generated automatically) end up in the same default resource group as the respective workspace.

In general, the easiest way to create new DCRs is to search for Data collection rules on the Azure portal. In a new rule, you then have the option to configure Data sources and Resources in the Configuration section (Figure 3). Resources in this example means the VM connected to the workspace by the Azure Monitor Agent. The desired logs and metrics are set up in Data sources . The setup includes both the data source and the Destination , which will need to be Azure Monitor Logs in most cases (i.e., Log Analytics because Azure Monitor Metrics is currently still a preview).

Figure 3: To fine-tune the Azure Monitor Agent, you need to configure a DCR.

Migrating to the New Agent

Right now, Microsoft is using every opportunity it can to get users to use the new Azure Monitor Agent. However, you need to be aware of the numerous construction sites. Of course, Microsoft will not maintain both agents in the long term, and you will need to make the switch by 2024. In the migration phase, Microsoft supports users with two interesting tools [2], the Azure Monitor Agent (AMA) Migration Helper and the DCR Config Generator. Migration Helper is an Azure solution that uses workbooks in Azure Monitor to identify the sources to be migrated and monitor the progress of ongoing migrations because, as described earlier, the Azure Monitor agent's configuration is exclusively based on the assigned data collection rules, whereas the legacy agent inherits its configuration from the Log Analytics workspace to which it is connected. Migration Helper also checks for any downstream dependencies and removes older Operations Management Suite (OMS) agents.

The second tool, the DCR Config Generator, analyzes the existing Log Analytics Agent configuration from your workspaces and, on that basis, automatically generates appropriate data collection rules. You can then choose to assign them manually to VMs already running the new agent with built-in assignment policies or use prebuilt Azure policies that take care of installing the new agent and assigning the DCR.

To install the DCR Config Generator, you need at least Azure PowerShell 5.1 or higher; as usual, Microsoft recommends the latest version, which is version 7. You also need to allocate read access to the workspace and the Azure Az PowerShell module. To generate the DCR Config Generator, simply download the PowerShell script from GitHub [3] and run it in the desired subscription, resource group, and workspace to be specified:

.\WorkspaceConfigToDCRMigrationTool.ps1 -SubscriptionId $subId -ResourceGroupName $rgName -WorkspaceName $workspaceName -DCRName $dcrName -Location $location -FolderPath $folderPath -GetDcrPayload

Among other things, the script can be opened in the context of Visual Studio Code with the Azure extension installed. The top panel shows the script in the editor, and the lower panel the command line in the terminal with the results. The required ResourceGroupName parameter contains the resource group, which in turn contains the target workspace. WorkspaceName defines the target workspace, DCRName the new DCR, and Location the region for the new DCR.

If you omit the FolderPath parameter, Azure uses the current directory by default to store the ARM template files along with associated parameter files, both in JSON format. Depending on the agent's configuration, the script generates two types of ARM templates along with the associated parameter files for Windows and Linux. In the first case, the target area contains Windows performance indicators or Windows events; in the second case, it has Linux performance indicators or syslog events.

You can now use the ARM templates generated in the process to trigger the deployment of the DCR to the specified resource group and subscription. If you use the optional GetDcrPayload parameter, the script generates separate JSON files for the DCR, just in case you want to provision in a different way. You can now bring the DCRs into play with one of the supported approaches, for example, with the Azure portal – search for Template Deployment – or with Azure PowerShell:

New-AzResourceGroupDeployment -location westeurope -ResourceGroupNameDefaultResourceGroup -WEU-TemplateFile $HOME/Downloads/dcr_windows_arm_ template_01-02-2023-22-39-03.json -TemplateParameterFile $HOME/Downloads/dcr_windows_arm_ template_01-02-2023-22-39-03.parameters.json

Either way, the result is the new DCR named New-DCR-windows with performance counters and Microsoft syslog as its data sources and a delivery target of Azure Monitor Logs . All you have to do now is assign the rule to the desired VM in the Resources section.

That said, you will want to use the AMA Migration Helper to monitor the migration of a large number of agents or VMs. It analyzes your current setup, identifying the sources to be covered (e.g., VMs, scale sets, or non-Azure VMs) and displaying the current statuses of the ongoing agent migration processes.

Azure Policy Migration Helper

Microsoft recommends using the Azure Policy service to handle migrations on a larger scale. For example, they provide the Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule policy initiative (Figure 4). You need to assign this policy to the desired scope. In production environments, that would be your Azure subscription or a higher level management group. As a proof of concept, you might want to test the policy in a selected resource group first.

Figure 4: A built-in policy initiative to deploy the Azure Monitor Agent according to the desired DCR.

In the Advanced section of the assignment wizard, you then have the Add resource selector option to restrict the set of evaluated resources further by selecting suitable locations or resource types. This option can help phase in the policy. If you use multiple resource selectors, resources that meet one of the conditions are evaluated. You can add a maximum of 10 selectors. To connect to the previously generated DCR, you then select the desired policy parameters in the Parameters section. You need the resource ID of the DCR, which is its name in this case. In the Remediation section, create a standardization task in the usual way, which will "cure" any non-compliant resources, either when created or after applying the remediation task to your existing resources.

Next, use Review + create to make sure the Azure Monitor Agent is installed on all VMs in the specified subscription and is associated with the previously generated data collection rule. If needed, you can then use the Remediation section of Azure Policy to check whether any Azure resources require standardization and discover the numbers if this is the case. If everything worked out, no resources in your policy definition should need remediation. After waiting for things to complete, check the compliance of your campaign in the Compliance section of the Azure Policy service. This can take up to 30 minutes. Then, after another wait, make sure that your existing data collection rules in the Resources section have been associated with your VMs.