Читати англійською Редагувати

Поділитися через

Migrate to Azure Monitor Agent from Log Analytics agent

  • Стаття

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). This article provides guidance on how to implement a successful migration from the Log Analytics agent to Azure Monitor Agent.

Migration is a complex task. Start planning your migration to Azure Monitor Agent using the information in this article as a guide.

Важливо

The Log Analytics agent was retired on August 31, 2024. This deprecation does not apply to MMA agent connected exclusively to an on-premises SCOM installation.

You can expect the following when you use the MMA or OMS agent after August 31, 2024.

  • Data upload: Cloud ingestion services will gradually reduce support for MMA agents, which will result in loss of ingestion support and potential compatibility issues for MMA agents over time. Upload capabilities will not be deployed to new regions
  • Installation: The ability to install the legacy agents will be removed from the Azure Portal and installation policies for legacy agents will be removed. You can still install the MMA agents extension as well as perform offline installations.
  • Customer Support: You will not be able to get support for legacy agent issues.
  • OS Support: Support for new Linux or Windows distros, including service packs, won't be available after the deprecation of the legacy agents.
  • Log Analytics Agent can coexist with Azure Monitor Agent. Expect to see duplicate data if both agents are collecting the same data.

Before you begin

  • Review the prerequisites for installing Azure Monitor Agent. To monitor non-Azure and on-premises servers, you must install the Azure Arc agent. The Arc agent makes your on-premises servers visible to Azure as a resource it can target. You don't incur any additional cost for installing the Azure Arc agent.

  • Verify that Azure Monitor Agent can address all of your needs. Azure Monitor Agent is General Availability (GA) for data collection and is used for data collection by various Azure Monitor features and other Azure services.

  • Verify that you have the necessary permissions to install the Azure Monitor Agent. You must have the necessary permissions to install the agent on the machines you want to monitor. For more information, see Permissions required to install the Azure Monitor Agent.

High level guidance

Use the following guidance to plan and execute your migration:

  • Understand your agents and how many you have to migrate.
  • Understand how you're using your workspaces.
  • Understand which solutions, insights, and data collections that are configured.
  • Configure your data collections and validate the collections.
  • Understand additional dependencies and services.
  • Remove the legacy agents.

The Azure Monitor Agent Migration Helper workbook is a workbook-based Azure Monitor solution that can help you at each of the steps outlined above. This guide references the workbook and other tools at each stage of the migration process. For more information, see Azure Monitor Agent Migration Helper workbook.

Understand your agents

Use the DCR generator to convert your legacy agent configuration into data collection rules automatically.1 To help understand your agents, review the following questions:

Question Actions
How many agents do you have to migrate ? Understand the number of agents you have to migrate.
Do you have any agents that are deployed outside of Azure?

Are these agents deployed in your own data center or in another cloud environment?

 For servers that are outside of Azure, you must first deploy the Azure ARC Connected Machine Agent. For more information, see Overview of Azure Connected Machine agent.
Are you using System Center Operations Manager (SCOM) ?

What your intended plan for SCOM going forward?

 If you're planning on continuing to use SCOM, start evaluating SCOM Managed Instance. For more information, see SCOM Managed Instance.
How are you deploying your agents today? If you're using any automated methods to deploy the legacy agent, consider when to stop those automated deployments for new servers, and start focusing on deploying the new agent. Stopping automated deployment for new servers helps ensure that you don't keep adding to your migration effort and lets you focus on the existing inventory of agents to migrate.

The Azure Monitor Agent Migration Helper Workbook can help you understand how many agents you have to migrate. For more information, see Azure Monitor Agent migration helper workbook- Agents.|

Understand your workspaces, solutions, insights, and data collections

Before migration, understand how your Log Analytics workspaces are being used. Check if they're all in use and which agents are sending their telemetry to which workspaces. Many workspaces get created over time, and it can become unclear which workspaces are actually in use, which workspaces are being used to collect telemetry, and from which servers. Migration is a good opportunity to clean up and consolidate your workspaces.

When looking at your workspaces, note which solutions are configured. This information is important to understand what data you're collecting and how you're using it.

The Azure Monitor Agent Migration Helper Workbook can help you understand which workspaces you have, and the solutions implemented in each workspace, and when you last used the solution. Each solution has a migration recommendation. For more information, see Azure Monitor Agent migration helper workbook- Workspaces

You can also use the Azure Monitor Workspace Auditing workbook to help you understand your workspaces. To use the Azure Monitor Workspace Auditing workbook, copy the workbook from the GitHub repository and import it into your Log Analytics workspace.

This workbook collects all of your Log Analytics workspaces and shows you the following for each workspace:

  • All data sources that are sending data to the workspace.
  • The agents that are sending heartbeats to the workspace.
  • The resources that are sending data to the workspace.
  • Any Application Insights resources that are sending data to the workspace.

For more information, see Azure Monitor Workspace Auditing workbook.

Configure your data collections and validate the collections

When configuring your data collections, consider the following steps:

  • Identify a pilot group of servers that you can use for this process. Use the pilot servers to validate the data before you deploy at scale.

  • Use the DCR Config Generator to transform the data collections that are configured in the workspace and deploy them as data collection rules back into your environment. For more information on the DCR Config Generator, see DCR Config Generator.

  • Migrate VM Insights or Azure Monitor for Virtual Machines to the Azure Monitor Agent. Validate the migrated data collections for the pilot group of servers compared with what was collected before migration. To avoid double ingestion, you can disable data collection from legacy agents during the testing phase without uninstalling the agents yet, by removing the workspace configurations for legacy agents. For more information, see Log Analytics agent data sources in Azure Monitor

  • Validate the new data to ensure there are no gaps. Compare the data ingested by legacy agent data to Azure Monitor Agent. Use KQL to compare equivalent data from each agent based on agent type.

  • Plan deployment at scale using Azure policy. Use built-in policies to deploy extensions and DCR associations at scale. Using policy also ensures automatic deployment of extensions and DCR associations for new machines. For more information on deploying at scale, see Manage Azure Monitor Agent - Use Azure policies.

Understand additional dependencies and services

Before migration it's important to understand how your other services are impacted.

Service Impact
Update Management If you're using Update Management under Azure Automation, you must migrate to Azure Update Manager.

Azure Update Manager has its own agent and is decoupled from the Azure Monitor agent.

Update Management will be deprecated at the end of August 2024. We recommend migrating to Azure Update Manager.

For more information, see Move from Automation Update Management to Azure Update Manager.

The AMA migration Helper workbook shows you which of your machines are using the update Management solution today and how to migrate them. For more information, see Azure Monitor Agent migration helper workbook- Update management.
Change Tracking and Inventory If you're using Change Tracking and Inventory, you must migrate to Azure Automation.

Change Tracking and Inventory are also part of Azure Automation. While Azure Monitor Agent has a change tracking and inventory solution, you must create a data collection rule. For more information, see Manage change tracking and inventory using Azure Monitoring Agent.
Defender for cloud If you're using Defender for Cloud for your service or Defender for servers and you have P2 enabled or plan to enable P2 for your servers, change your agent deployment in Defender for Cloud from the legacy agent deployment to agent-less scanning.

If you're using Defender for Cloud to collect security events, create a custom data collection rule to collect those events.
Microsoft Sentinel If you're using Microsoft Sentinel, the solutions that were using the legacy agent have been converted to Azure Monitor Agent based solutions, and can be updated.

Remove the legacy agents

As part of your migration planning, plan to remove the legacy agent once migration is complete to avoid duplication of data collection.

If you don't need to retain the MMA on any of your machines, use the MMA Discovery and Removal tool to remove the agent at scale. For more information on the MMA Discovery and Removal tool, see MMA Discovery and Removal tool.

If however you're using System Center Operations Manager (SCOM), keep the MMA agent deployed to the machines that you'll continue managing with System Center Operations Manager.

A SCOM Admin Management Pack exists and can help you remove the workspace configurations at scale while retaining the SCOM Management Group configuration. For more information on the SCOM Admin Management Pack, see SCOM Admin Management Pack.

Known Migration Issues

  • IIS Logs: When IIS log collection is enabled, AMA might not populate the sSiteName column of the W3CIISLog table. This field gets collected by default when IIS log collection is enabled for the legacy agent. If you need to collect the sSiteName field using AMA, enable the Service Name (s-sitename) field in W3C logging of IIS. For steps to enable this field, see Select W3C Fields to Log.
  • SQL Assessment Solution: This is now part of SQL best practice assessment. The deployment policies require one Log Analytics Workspace per subscription, which isn't the best practice recommended by the AMA team.

Next steps