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

Azure Monitor 代理 (AMA) 可以取代 Windows 和 Linux 计算机的 Log Analytics 代理（也称为 Microsoft Monitor 代理 (MMA) 和 OMS），不管是在 Azure 环境中还是在非 Azure 环境（本地和其他云）中。 代理引入了一种简化、灵活的方法，用于使用数据收集规则 (DCR) 配置数据收集。 本文提供有关如何从 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 生成器自动将旧版代理配置转换为数据收集规则。¹ 若要帮助了解代理，请查看以下问题：

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 策略。

了解其他依赖项和服务

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

删除旧代理

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

如果不需要在任何计算机上保留 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，直到新服务“自动更新管理器”准备就绪。

后续步骤

• Azure Monitor 代理迁移帮助程序工作簿
• DCR Config Generator
• MMA 发现和删除工具