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

Azure Monitor代理（AMA）取代了Log Analytics代理（也称为Microsoft监视器代理（MMA）和OMS），适用于Azure环境和非Azure环境的Windows和Linux计算机，包括本地部署和其他云平台。 代理引入了一种简化、灵活的方法，用于使用数据收集规则 (DCR) 配置数据收集。 本文提供有关如何从 Log Analytics 代理成功迁移到 Azure Monitor 代理的指导。

迁移是一项复杂的任务。 使用本文中的信息来规划迁移到 Azure Monitor Agent。

开始之前

• 查看用于安装 Azure Monitor 代理的 先决条件。 若要监视非Azure和本地服务器，必须安装Azure Arc代理。 Arc 代理使本地服务器在 Azure 中作为其目标资源可见。 安装Azure Arc代理不会产生任何额外费用。

• 验证Azure Monitor代理是否可以满足所有需求。 Azure Monitor代理是数据收集的正式版（GA），用于各种Azure Monitor功能和其他Azure服务的数据收集。

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

高层次指导

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

• 了解代理以及必须迁移多少个代理。
• 了解如何使用工作区。
• 了解配置的解决方案、见解和数据收集。
• 配置您的数据集，并检查这些集合的正确性。
• 了解其他依赖项和服务。
• 删除旧代理。

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 虚拟机的 Azure Monitor 迁移到 Azure Monitor 代理。 对试点服务器组的迁移数据收集与迁移前收集的数据进行验证。 为避免双重引入，只需删除旧代理的工作区配置，即可在测试阶段禁用旧代理的数据收集，而无需卸载代理。 有关详细信息，请参阅 Azure Monitor 中的 Log Analytics 代理数据源

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

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

了解其他依赖项和服务

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

删除旧代理

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

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

但是，如果使用System Center Operations Manager（System Center Operations Manager），请将 MMA 代理部署到继续使用System Center Operations Manager管理的计算机。

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

已知迁移问题

• IIS 日志：启用 IIS 日志收集后，AMA 可能不会填充 sSiteName 表的 W3CIISLog 列。 为旧代理启用 IIS 日志收集时，默认情况下会收集此字段。 如果需要使用 AMA 收集 sSiteName 字段，请启用 IIS W3C 日志记录中的 Service Name (s-sitename) 字段。 有关启用此字段的步骤，请参阅“选择 W3C 字段以记录”。
• SQL 评估解决方案：它现在是 SQL 最佳做法评估的一部分。 部署策略需要每个订阅一个Log Analytics工作区，这不是 AMA 团队建议的最佳做法。

后续步骤

• Azure Monitor 代理迁移辅助工具工作簿
• DCR 配置生成器
• MMA 发现和删除工具