The Azure Monitor agent (AMA) is the agent replacing all of Azure Monitor’s monitoring agents (Log Analytics, Telegraph and Diagnostics extension). The Log Analytics agent will be retired on 31 August, 2024 so customers should start assessing, planning and migrating whenever possible to this new agent. In the first part of this series, we went through how to plan, assess and test the migration in a test environment. In this post, we will go through performing the migration at scale in production.

TIP If you need a quick crash course on what the Azure Monitor agent is all about, check out this blog post.

Current setup

I have two resource groups, one for test workloads and one for production workloads. Each of them has a mix of Windows and Linux VMs and a Windows Azure Arc-enabled servers.

In production, we have a Windows VM, a Linux VM and a Windows Azure Arc-enabled server. All of them are connected to a production Log Analytics workspace using the legacy Log Analytics agent.

Installation of the legacy agent and the connection to the workspace are done using Azure Policy since this is a production environment.

I can see that data is already flowing into my workspace by looking at VM insights.

And also Defender for Cloud is reporting that the Log Analytics agent is installed and showing recommendations for my test VMs.

Migration preparation

1. In part one, we have tested the migration side-by-side on the different resources we have to make sure that all needed logs, metrics and solutions are working properly using the Azure Monitor Agent.
2. We need to export the data collection configuration to create the new Data Collection rules for both Windows and Linux
3. We need to disable the data collection on the workspace to avoid unnecessary costs and duplicate data, since this is a production environment which will have much more resources than our test one.

One of the useful tools available to give you oversight over the migration is the AMA migration helper workbook which shows you an up-to-date status of your migration in terms of agents installation, servers reporting, solutions installed on the workspace,…etc

Creating the new Data Collection rules

We will use the Data Collection rule config export script to generate ARM templates that will be used to deploy the new rules.

Now, to deploy the generate AMR templates for the Windows and Linux rules.

We can validate that the created rules have the data sources already configured in our Log Analytics workspace.

The last preparation step is to disable data collection on the workspace.

Deploying the agents

When deploying the Azure Monitor agent, you can use the virtual machine’s system-managed identity or use a user-assigned managed identity to grant the necessary permissions. For Azure Arc-enabled VMs it’s only possbile to use the system-managed identity, for Azure VMs its recommended to use a user-assigned managed identity for better scale. In our case we will create a user-assigned managed identity and assign it to the VMs.

Now, we are ready to deploy the agents using Azure Policy. You can see that the option Bring your own user-assigned managed identity is set to true since we will use a pre-created and assigned identity.

We will deploy two additional policies for Azure Arc-enabled servers. Now we can see all the policies assigned to our production resource group.

After about 15 minutes, we can see the remediation tasks have completed to deploy the agents and associate them with the newly created Data Collection rules.

Looking at the extensions tab in our VMs, we can see that the agent has been successfully deployed.

We can see also the VMs already associated with the Data Collection rules.

Now, to validate that the new agents are sending Heartbeat to the workspace, we run the following query to confirm that everything is configured correctly.

We need to also assigne the VM Insights Data Collection rule that we created in Part 1 to make sure our production VMs are sending the needed data for Insights to populate.

Looking back at the migration helper workbook, we can see that we have the agents deployed successfully with Data Collection rules associated. The only remaining step is to uninstall the legacy agent.

Uninstalling the Log Analytics agent

After we can see that the new agent is sending heartbeat and collecting data, we will start uninstalling the legacy agent and remove the data collection settings from the workspace to complete the migration. Let’s start by uninstalling the Log Analytics agent extension.

Validating the migration

After some time, checking back on the migration workbook, we can see that our migration is successfully completed.

Recap

In this post, we have migrated to the new Azure Monitor agent in a production environment using Azure Policy on Azure and Azure Arc servers at scale.

References

• Azure Monitor agent landing page
• Azure Monitor agent and DCR overview video
• Azure Monitor agent discussion with the product group
• Azure Monitor agent migration guidance
• Azure Monitor agent migration tools

Share on: