通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

从 Log Analytics 代理迁移到 Azure Monitor 代理

  • 项目

Azure Monitor 代理 (AMA) 可以取代 Windows 和 Linux 计算机的 Log Analytics 代理（也称为 Microsoft Monitor 代理 (MMA) 和 OMS），不管是在 Azure 环境中还是在非 Azure 环境（本地和其他云）中。 代理引入了一种简化、灵活的方法，用于使用数据收集规则 (DCR) 配置数据收集。 本文提供有关如何从 Log Analytics 代理成功迁移到 Azure Monitor 代理的指南。

迁移是一项复杂的任务。 使用本文中的信息作为指南，开始规划向 Azure Monitor 代理的迁移。

重要

Log Analytics 代理已于 2024 年 8 月 31 日停用。 此折旧不适用于以独占方式连接到本地 SCOM 安装的 MMA 代理。

在 2024 年 8 月 31 日之后使用 MMA 或 OMS 代理时，应该会出现以下情况。

  • 数据上传：云引入服务将逐渐减少对 MMA 代理的支持，这可能会导致一段时间内 MMA 代理的支持减少和潜在的兼容性问题。 MMA 的引入将保持不变，直到 2025 年 2 月 1 日。
  • 安装：安装旧版代理程序的功能将从 Azure 门户中移除，旧版代理程序的安装策略也将移除。 你仍然可以安装 MMA 代理扩展以及执行脱机安装。
  • 客户支持：你将无法获取有关旧版代理程序问题的支持。
  • 操作系统支持：在弃用旧代理后，不会添加对新的 Linux 或 Windows 发行版（包括 Service Pack）的支持。
  • Log Analytics 代理可以与 Azure Monitor 代理共存。 如果两个代理正在收集相同的数据，预计会看到重复的数据。

 

好处

使用 Azure Monitor 代理可以立即获得以下好处：

Azure Monitor 代理优势概览图。更多详细信息如下所示。

  • 通过使用数据收集规则节省成本：
    • 与旧代理的“全部或全无”方法相比，支持对一台计算机或一部分计算机进行有针对性的精细数据收集。
    • 允许筛选规则和数据转换，以减少上传的总数据量，从而显著降低引入和存储成本。
  • 安全性和性能
    • 通过托管标识和 Microsoft Entra 令牌（用于客户端）增强了安全性。
    • 更高的事件吞吐量，比旧版 Log Analytics (MMA/OMS) 代理高 25%。
  • 更简单的管理，包括高效的故障排除：
    • 支持将数据上传到多个目标（多个 Log Analytics 工作区，即 Windows 和 Linux 上的多宿主），包括跨区域和跨租户数据收集（使用 Azure LightHouse）。
    • 在整个数据收集生命周期（从载入到部署再到随时间推移而进行的更新和更改），针对企业规模“在云中”实现集中式代理配置。
    • 配置中的任何更改都会自动推出到所有代理，而无需客户端部署。
    • 提高对更多功能和服务的透明度和控制，例如 Microsoft Sentinel、Defender for Cloud 和 VM Insights。
  • 单个代理，跨支持的服务器和客户端设备提供所有数据收集需求。 尽管 Azure Monitor 代理当前结合了 Log Analytics 代理，但单一代理才是目标。

开始之前

  • 查看安装 Azure Monitor 代理的先决条件。 若要监视非 Azure 服务器和本地服务器，必须安装 Azure Arc 代理。 Arc 代理让本地服务器能够作为它可面向的资源对 Azure 可见。 安装 Azure Arc 代理不会产生任何额外费用。

  • 验证 Azure Monitor 代理能否满足你的所有需求。 Azure Monitor 代理为数据集合推出了正式发布版 (GA)，并用于各种 Azure Monitor 功能和其他 Azure 服务的数据集合。

  • 验证是否具有安装 Azure Monitor 代理所需的权限。 必须具有在想要监控的计算机上安装代理所需的权限。 有关详细信息，请参阅安装 Azure Monitor 代理所需的权限。

指南概述

使用以下指南来规划和执行迁移：

  • 了解代理以及需要迁移的代理数量。
  • 了解如何使用工作区。
  • 了解配置的解决方案、见解和数据集合。
  • 配置数据集合并验证集合。
  • 了解其他依赖项和服务。
  • 删除旧代理。

Azure Monitor 代理迁移帮助程序工作簿是工作簿形式的 Azure Monitor 解决方案，可以帮助完成上面概述的每个步骤。 本指南引用了迁移过程每个阶段的工作簿和其他工具。 有关详细信息，请参阅 Azure Monitor 代理迁移帮助程序工作簿。

了解代理

使用 DCR 生成器自动将旧版代理配置转换为数据收集规则。1 若要帮助了解代理，请查看以下问题：

问题 操作
必须迁移多少个代理？ 了解必须迁移的代理数。
是否有任何部署在 Azure 之外的代理？

这些代理是部署在你自己的数据中心还是其他云环境中？

 对于 Azure 之外的服务器，必须首先部署 Azure ARC Connected Machine Agent。 有关详细信息，请参阅 Azure Connected Machine Agent 概述。
是否在使用 System Center Operations Manager (SCOM)？

你对 SCOM 的未来有何计划？

 如果打算继续使用 SCOM，请开始评估 SCOM 托管实例。 有关详细信息，请参阅 SCOM 托管实例。
你现在如何部署代理？ 如果使用任何自动化方法来部署旧代理，请考虑何时停止新服务器的自动部署，并开始专注于部署新代理。 停止新服务器的自动部署有助于确保不会继续增加迁移工作量，并让你专注于要迁移的代理的现有清单。

Azure Monitor 代理迁移帮助程序工作簿可以帮助了解需要迁移的代理数量。 有关详细信息，请参阅 Azure Monitor 代理迁移帮助程序工作簿 - 代理。|

了解工作区、解决方案、见解和数据集合

在迁移之前，请了解 Log Analytics 工作区的使用方式。 检查工作区是否都在使用中，以及哪些代理正在将其遥测数据发送到哪些工作区。 随着时间的推移，系统会创建许多工作区，并且可能不清楚哪些工作区实际正在使用中，哪些工作区用于收集遥测数据，以及从哪些服务器收集遥测数据。 迁移是清理和合并工作区的好机会。

查看工作区时，请注意配置了哪些解决方案。 这些信息对于了解要收集的数据以及如何使用这些数据非常重要。

Azure Monitor 代理迁移帮助程序工作簿可以帮助了解你拥有哪些工作区、每个工作区中实现的解决方案以及你上次使用该解决方案的时间。 我们为每个解决方案都给出了迁移建议。 有关详细信息，请参阅 Azure Monitor 代理迁移帮助程序工作簿 - 工作区

你还可以使用 Azure Monitor 工作区审核工作簿来帮助了解工作区。 若要使用 Azure Monitor 工作区审核工作簿，请从 GitHub 存储库复制工作簿并将其导入 Log Analytics 工作区。

此工作簿会收集所有 Log Analytics 工作区，并为每个工作区显示以下内容：

  • 向工作区发送数据的所有数据源。
  • 将检测信号发送到工作区的代理。
  • 向工作区发送数据的资源。
  • 向工作区发送数据的任何 Application Insights 资源。

有关详细信息，请参阅 Azure Monitor 工作区审核工作簿。

配置数据集合并验证集合

配置数据集合时，请考虑以下步骤：

  • 确定可用于此过程的服务器试点组。 在大规模部署之前，使用试点服务器验证数据。

  • 使用 DCR Config Generator 转换工作区中配置的数据收集，并将作为数据收集规则部署回环境中。 有关 DCR Config Generator 的详细信息，请参阅 DCR Config Generator。

  • 将虚拟机的 VM Insights 或 Azure Monitor 迁移到 Azure Monitor 代理。 对试点服务器组的迁移数据收集与迁移前收集的数据进行验证。 为避免双重引入，只需删除旧版代理程序的工作区配置，即可从旧版代理程序禁用数据收集，而无需卸载代理。 有关详细信息，请参阅 Azure Monitor 中的 Log Analytics 代理数据源

  • 验证新数据以确保没有差距。 将旧版代理引入的数据与 Azure Monitor 代理引入的数据进行比较。 使用 KQL 根据代理类型比较来自每个代理的等效数据。

  • 使用 Azure 策略大规模规划部署。 使用内置策略大规模部署扩展和 DCR 关联。 使用策略还可以确保为新的计算机自动部署扩展和 DCR 关联。 有关大规模部署的详细信息，请参阅管理 Azure Monitor 代理 - 使用 Azure 策略。

了解其他依赖项和服务

在迁移之前，请务必了解其他服务会受到的影响。

服务 影响
更新管理 如果在 Azure 自动化下使用更新管理，则必须迁移到 Azure 更新管理器。

Azure 更新管理器有自己的代理，并且与 Azure Monitor 代理分离。

更新管理将在 2024 年 8 月底弃用。 建议迁移到 Azure 更新管理器。

有关详细信息，请参阅从自动化更新管理迁移到 Azure 更新管理器。

AMA 迁移助手工作簿会显示哪些计算机当前正在使用更新管理解决方案以及如何迁移它们。 有关详细信息，请参阅 Azure Monitor 代理迁移帮助程序工作簿 - 更新管理。
更改跟踪和清单 如果使用更改跟踪和清单，则必须迁移到 Azure 自动化。

更改跟踪和清单也是 Azure 自动化的一部分。 虽然 Azure Monitor 代理具有更改跟踪和清单解决方案，但你必须创建数据收集规则。 有关详细信息，请参阅使用 Azure Monitoring Agent（预览版）启用更改跟踪和清单。
Defender for cloud 如果你正在为服务使用 Defender for Cloud 或为服务器使用 Defender，并且已启用 P2 或计划为服务器启用 P2，请将 Defender for Cloud 中的代理部署从旧版代理部署更改为无代理扫描。

如果使用 Defender for Cloud 收集安全事件，请创建自定义数据集合规则来收集这些事件。
Microsoft Sentinel 如果使用的是 Microsoft Sentinel，则使用旧版代理的解决方案已转换为基于 Azure Monitor 代理的解决方案，并且可以更新。

删除旧代理

在迁移规划过程中，计划在迁移完成后删除旧代理，以避免出现重复的数据收集。

如果不需要在任何计算机上保留 MMA，请使用 MMA 发现和删除工具大规模删除代理。 有关 MMA 发现和删除工具的详细信息，请参阅 MMA 发现和删除工具。

但是，如果你正在使用 System Center Operations Manager (SCOM)，请将 MMA 代理部署到将继续使用 System Center Operations Manager 管理的计算机上。

SCOM 管理包存在，可以帮助你大规模删除工作区配置，同时保留 SCOM 管理组配置。 有关 SCOM 管理员管理包的详细信息，请参阅 SCOM 管理员管理包。

已知迁移问题

  • IIS 日志：启用 IIS 日志收集后，AMA 可能不会填充 W3CIISLog 表的 sSiteName 列。 为旧代理启用 IIS 日志收集时，默认情况下会收集此字段。 如果需要使用 AMA 收集 sSiteName 字段，请启用 IIS W3C 日志记录中的 Service Name (s-sitename) 字段。 有关启用此字段的步骤，请参阅“选择 W3C 字段以记录”。
  • SQL 评估解决方案：这现在是 SQL 最佳做法评估的一部分。 部署策略要求每个订阅一个 Log Analytics 工作区，这不是 AMA 团队建议的最佳做法。
  • Microsoft Defender for Cloud：正在迁移到无代理解决方案。 某些功能不会在弃用日期前准备就绪。 对于使用文件集成监视 (FIM)、终结点保护发现建议、操作系统错误配置（Azure 安全基准 (ASB) 建议）和自适应应用程序控制的计算机，客户应继续使用 MMA。
  • 更新管理正在迁移到无代理解决方案，但不会在 MMA 弃用日期前准备就绪。 使用更新管理的客户应继续使用 MMA，直到新服务“自动更新管理器”准备就绪。

后续步骤