Introduction

The Log Analytics agent will be retired on August 31, 2024, it is recommended to start planning your migration to Azure Monitor Agent by using the information in the following article: Migrate to Azure Monitor Agent from Log Analytics agent.

This article’s objective is to share a feedback and additional tips concerning this migration.

Benefits

In addition to consolidating and improving on the legacy Log Analytics agents, Azure Monitor Agent provides a variety of immediate benefits, including cost savings, a simplified management experience, and enhanced security and performance.

Target sample design

The following points illustrate a sample design that have been implemented to support, maintain and make sure that the Azure Monitor Agent is deployed.

• Core components

Deploying the Data Collection Rules (DCR), Data Collection Endpoint (DCE) and Managed Identities through Terraform. It has the following benefits:

1. Perform compliance scan through ‘terraform plan’ to guarantee that those resources are properly set with no configuration drift.
2. Create our resources the same way across different Azure subscription environments.

• Agent enrollment

Use built-in policies to deploy the Azure Monitor Agent, the DCR associations at scale and the managed identities associations with our VMs and VMSSs. It has the following benefits:

1. Auto-enrollment, indeed Microsoft provides Azure policies that are set to remediate non compliant resources. For more information you can consult the following article: An Azure Policy journey.
2. The Azure policy compliance panel gives us an overview of the health status of our Azure Monitor Agent deployment.

The following diagram illustrates the mentioned design:

Caution points

In this chapter we will share caution points you should be aware when migrating Azure Monitor Agent from Log Analytics agent.

• Managed Identity

It is recommended to use a User-assigned managed identity for large-scale deployments, you can create a user-assigned managed identity once and share it across multiple Virtual Machines (VM) or Virtual Machines Scale Sets (VMSS).

Before assigning this User-assigned managed identity across multiple VMs or VMSSs make sure to understand how your developers use Azure Managed Identities, if they do.

When authenticating through az cli for exemple you must consider the following caution point ->

If the resource has multiple user assigned managed identities and no system assigned identity, you must specify the client id or object id or resource id of the user assigned managed identity with --username for login. If you don’t, your script might switch to the wrong managed identity, the one needed by the Azure Monitor Agent.

• Azure Monitor Dashboard and Workbook

Validate that Azure Monitor Agent is collecting data as expected and all downstream dependencies.

For exemple we were using the following Kusto query to graph and alert us when disk consumption where high, in our case this information moved from the Log Analytics table InsightsMetrics to the Perf table.

Before →

Now with the Azure Monitor Agent →

• Deployment follow up

Make sure your number of Virtual Machines (VM) and Virtual Machines Scale Sets (VMSS) is equals to the number of resources that send heartbeats through the Azure Monitor Agents.

The following query can be executed from the Azure Resource Graph Explorer, it will display the existing number of VM and VMSS.

The following query can be executed from the Logs panel of the Log Analytics Workspace connected to your Data collection rules (DCR), it will display the number of VM and VMSS that have sent heartbeats.

Conclusion

This migration is well documented by Microsoft but it should be followed carefully especially in complex environments, it is not what we can call a “simple and transparent” migration.

Azure Monitor Agent benefits are definitively great so I would recommend anyone to start this migration as soon as possible.

See you in the Cloud

Jamesdld