Beginner's Guide to Using Azure Monitor Agent
How to Move from Azure legacy Log Analytics Agents to Azure Monitor: Step-by-Step Guide
Most of you might have come across this notification from Microsoft:
The Log Analytics agent is on a deprecation path and won't be supported after August 31, 2024. Any new data centers brought online after January 1 2024 will not support the Log Analytics agent. If you use the Log Analytics agent to ingest data to Azure Monitor, migrate to the new Azure Monitor agent prior to that date.
Azure Monitor Agent (AMA) replaces the Log Analytics agent, also known as Microsoft Monitor Agent (MMA) and OMS, for Windows and Linux machines, in Azure and non-Azure environments, on-premises and other clouds. The agent introduces a simplified, flexible method of configuring data collection using Data Collection Rules (DCRs). Migration is a complex task. You can find numerous article on how to start planning your migration to Azure Monitor Agent but this blog rather focuses on the exact steps that you need to perform in order to get the work done. So, lets get hands dirty :)
Suppose your environment has VMs that are being monitored via the log analytics agents and now you have to migrate them to Azure monitor (the below steps will be confined to enabling VM insights on VMs):
Current Setup (Legacy):
- A windows VM with log analytics MMA (Microsoft Monitoring Agent) extension and connected to a log analytics workspace
Data ingested in the Perf table from the MMA is shown below:
VM insights is not enabled and no Azure Monitor Agent (AMA) is installed on the VM
Now, to monitor VM guest data, you need to install Azure Monitor Agent on the VM and set up a data collection rule (DCR). The VM Insights feature automatically installs Azure Monitor Agent on your VM
Desired Setup (Azure Monitor Agent):
Platform metrics are collected from Azure resources. They require no configuration and have no cost. Custom metrics are collected from different sources that you configure including applications and agents running on virtual machines.
Metrics are collected from the guest operating system of a virtual machine. You can enable guest OS metrics for Windows virtual machines by using the Azure Monitor Agent
Go to the VM Insights from the left blade menu and click on "Enable"
You will see there is a pre-populated Data collection rule name under the subscription but you might want to create a new DCR based on your namimg convention requirements in your organization. For this, click on "Create New"
Start typing the name of the DCR, keep in mind, that the prefix "MSVMI" will automatically be appended before the name, so write the name without MSVMI, for e.g. "dcr-test-01" as shown below. The prefix "MSVMI" depicts that the DCR will exclusively be created for MicroSoft VMInsights.
Check the Enable processes and dependencies (Map) feature (highlighted) if you want to leverage application component mapping. This basically map application components on a particular VM and across VMs, and discover the dependencies that exist between application components. This information is important for troubleshooting, optimizing performance, and planning for changes or updates to the application infrastructure.
💡The Data Collection Rule (DCR) should be in the same location as the Log Analytics workspace.Click on create and then configure and the DCR will be created. As soon as the deployment succeeds, the following will happen:
a). Azure Monitor Agent (AMA) extension will be installed on the VM
b). DCR will be created and associated to the VM
c). VM Insights will be enabled on the VM
💡VM Insights automatically creates a data collection rule that includes a special data stream required for its operation. Do not modify the VM Insights data collection rule or create your own data collection rule to support VM Insights. To collect additional data, such as Windows and Syslog events, create separate data collection rules and associate them with your machines.
The InsightsMetrics table below can be seen showing up data after installation of AMA extension and over time, the Perf table metrics will converge to the InsightsMetrics table
Check the DCR and you will see the VM is associated now and also the VM Insights monitoring configuration can be seen having the same DCR
Now, go to the log analytics workspace and query the heartbeat table on the Logs section, the same VM will appear having category as "Azure Monitor", this shows that the VM heartbeat is being sent via the AMA to the workspace
The reason why both category are showing is because both agents co-exist in the VM currently. Now next step is to remove the legacy agent (MMA) from the VM and remove the log collection from the legacy agents.
Disconnect the VM from the log analytics workspace and this will uninstall the MMA from the VM leaving only the Azure Monitor Agent as shown below.
Go to Log Analytics Workspace > Legacy Agents Management, remove the performance counters and click on Apply. This will disable the log collection from the legacy agents and save ingestion costs for the workspace by avoiding duplication of logs.
Now, it can be observed that the Heartbeat table returns only the VM with the category of Azure Monitor and the legacy agent is completely removed.
Points to remember:
Any policies (initiatives/definitions) that are responsible for installing legacy agents must be disabled before removing the MMA extension to make sure that they are not reinstalled by the policy
If you are using SCOM along with log analytics agents, remember, the SCOM is configured using MMA extension on the VM, prior planning is required before taking any action
In the next article, we will migrate to Azure monitor using Azure policies which is an actual way to accomplish the activity in an enterprise/organization.
Till then, KEEP LEARNING AND BUILDING !!!
Here are some important references from the official documentation:
Azure Monitor Documentation - https://learn.microsoft.com/en-us/azure/azure-monitor/
Data Collection - https://learn.microsoft.com/en-us/azure/azure-monitor/data-sources