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

从 System Center Operations Manager (SCOM) 迁移到 Azure Monitor

  • 项目

本文为当前使用 System Center Operations Manager (SCOM) 并计划转换到使用 Azure Monitor 实现基于云的监视的客户提供指导，介绍如何将商业应用程序和其他资源迁移到 Azure。

从 SCOM 进行迁移时并没有什么标准过程，你可以依赖 SCOM 管理包延长使用时间，而不是执行快速迁移。 本文介绍了可用于为特定环境确定最佳策略的不同选项和决策标准。

混合云监视

大多数客户都会使用混合云监视策略，该策略允许逐步过渡到云。 这种方法可让你在逐渐熟悉新平台的过程中维持现有的业务流程， 在可以使用 Azure Monitor 来取代 SCOM 功能后，再弃用该功能。 使用多个监视工具会增加复杂性，但这种方法可以让你利用 Azure Monitor 监视下一代云工作负载的能力，同时保留 SCOM 监视服务器软件和工作负载的能力。

在将任何组件迁移到 Azure 之前，你的环境基于本地或托管服务提供商的虚拟机和物理计算机。 它依靠 SCOM 来监视环境（例如物理服务器和网络）中的商业应用程序、服务器软件和其他基础结构组件。 你为服务器软件（例如 IIS、SQL Server 和各种供应商软件）使用标准管理包，并根据具体要求调整这些管理包。 你将为无法使用现有管理包监视的商业应用程序和组件创建自定义管理包，并配置 SCOM 以支持你的业务流程。

将服务移动到云中时，Azure Monitor 将开始收集每个资源的平台指标和活动日志。 你将创建诊断设置来收集资源日志，以便可以使用日志查询和见解以交互方式分析所有可用的遥测数据。

在此过渡期间，你有两个独立的监视工具。 你可以在 Azure 门户中使用见解和工作簿来分析云遥测数据，同时仍可使用操作控制台来分析 SCOM 收集的数据。 由于每个系统都有自己的警报，你需要在 Azure Monitor 中创建与 SCOM 中的通知组等效的操作组。

下表描述了可用于使用 SCOM 和 Azure Monitor 的混合监视环境的不同功能和策略。

方法 说明
双宿主代理 SCOM 使用 Microsoft 管理代理 (MMA)，该代理与 Azure Monitor 使用的 Log Analytics 代理 相同。 你可以将此代理配置为让单台计算机同时连接到 SCOM 和 Azure Monitor。 此配置要求 Azure VM 与本地管理服务器建立连接。

Log Analytics 代理已替换为 Azure Monitor 代理，后者具有显著优势，包括管理更简单以及可以更好地控制数据收集。 这两个代理可以共存于同一台计算机上，使你能够同时连接到 Azure Monitor 和 SCOM。 由于 Azure Monitor 代理具有显著优势，因此此配置是比双重托管旧版代理程序更好的选择。
已连接的管理组 将 SCOM 管理组连接到 Azure Monitor，以便将从 SCOM 代理收集的数据转发到 Azure Monitor。 这类似于使用双宿主代理，但不需要将每个代理都配置为连接到 Azure Monitor。 此策略需要旧版代理程序，因此不能指定使用数据收集规则来进行监视。 而且，除非将每个 VM 都直接连接到 Azure Monitor，否则也不能使用 VM 见解。
SCOM 托管实例（预览） SCOM 托管实例（预览）是 SCOM 在 Azure 中的完整实现，让你可以继续运行在本地 SCOM 环境中运行的相同管理包。 目前，SCOM 与 Azure Monitor 的数据和警报之间没有任何集成，你可以继续使用同一操作控制台来分析运行状况和警报。

SCOM MI 与维持现有的 SCOM 环境和双宿主代理类似，不过你可以在 Azure 中整合自己的监视配置并停用本地组件（如数据库和管理服务器）。 Azure VM 中的代理可以连接到 Azure 中的 SCOM 托管实例，而不是连接到你自己的数据中心的管理服务器。
Azure 管理包 Azure 管理包允许 Operations Manager 根据一组特定的监视方案来发现 Azure 资源并监视其运行状况。 此管理包要求对 Azure 中的每个资源执行额外的配置。 不过，在将业务流程转变为主要依赖 Azure Monitor 之前，在操作控制台中提供 Azure 资源的一些可见性可能会有所帮助。

监视商业应用程序

在使用安装在每个虚拟机上的代理通过 SCOM 监视商业应用程序时，通常需要使用自定义管理包。 Azure Monitor 中的 Application Insights 可监视基于 Web 的应用程序，无论它们是在 Azure、其他云中还是本地。 它可以用于所有应用程序，无论它们是否已迁移到 Azure。

如果你对商业应用程序的监视仅限于 SCOM 中的 .NET 应用性能模板提供的功能，那么你很有可能可在不损失任何功能的情况下迁移到 Application Insights。 事实上，Application Insights 包含大量其他功能，包括：

  • 自动发现和监视应用程序组件。
  • 收集详细的应用程序使用情况和性能数据，例如响应时间、故障率和请求速率。
  • 收集浏览器数据，例如页面视图和加载性能。
  • 检测异常并深入研究堆栈跟踪和相关请求。
  • 使用分布式跟踪和智能检测等功能执行高级分析。
  • 使用指标资源管理器以交互方式分析性能数据。
  • 使用日志查询以交互方式分析收集的遥测数据以及为 Azure 服务和 VM 见解收集的数据。

不过，在某些情况下，你可能需要在 Application Insights 之外继续使用 SCOM，直到你能够实现所需的功能。 你可能需要继续使用 SCOM 的示例包括：

  • 可用性测试用于对应用程序的可用性和响应能力进行监视并发出警告，它需要来自 Web 测试代理的 IP 地址的传入请求。 如果你的策略不允许这种访问，你可能需要继续使用 SCOM 中的 Web 应用程序可用性监视器。
  • 在 SCOM 中，你可以为可用性测试设置任何轮询间隔，让许多客户每 60-120 秒检查一次。 Application Insights 的最小轮询间隔为 5 分钟，这对于某些客户而言可能太长了。
  • SCOM 中的大量监视任务都是通过收集应用程序生成的事件和在本地代理上运行脚本来执行的。 这些都不是 Application Insights 中的标准选项，因此，你可能需要通过一些自定义操作来满足你的业务需求。 这可能包括使用 Log Analytics 工作区中存储的事件数据的自定义警报规则，以及使用混合 runbook 辅助角色在虚拟机来宾操作系统中启动的脚本。
  • 根据应用程序编写语言的不同，你可能只能使用可与 Application Insights 一起使用的工具。

按照本指南其他部分的基本策略，继续为商业应用程序使用 SCOM，但也利用 Application Insights 提供的附加功能。 当你能够用 Azure Monitor 取代其关键功能时，就可以开始停用自定义管理包。

监视虚拟机

根据虚拟机上运行的工作负载的要求，在混合环境中监控虚拟机上的软件时通常会组合使用 Azure Monitor 和 SCOM。 在 Azure 中创建一个虚拟机后，系统会自动开始收集该 VM 主机的平台指标和活动日志。 请启用建议的警报，以获得有关 VM 主机常见错误（例如服务器关闭和 CPU 利用率过高）的通知。

请启用 VM 见解以安装 Azure Monitor 代理并开始从客户端操作系统收集常见性能数据。 这可能与已在 SCOM 中收集的某些数据重叠，但能让你开始查看随时间推移的趋势，并监视 Azure VM 和其他云资源。 你还可以选择启用映射功能，以便深入了解虚拟机上运行的进程及其与其他服务的依赖关系。

请继续使用管理包，以实现 Azure Monitor 中的其他功能无法提供的功能。 这包括用于关键服务器软件（如 IIS、SQL Server 或 Exchange）的管理包。 你也可能有为本地基础结构开发的自定义管理包，这些管理包是 Azure Monitor 无法提供的。 如果 SCOM 已紧密集成到你的操作流程中，则在实现服务操作的现代化并能够使用 Azure Monitor 和其他 Azure 服务对其进行扩充或取代之前，另请继续使用 SCOM。

注意

如果使用 Log Analytics 代理而不是 Azure Monitor 代理启用 VM 见解，则无需在 VM 上安装其他代理。 不过，建议使用 Azure Monitor 代理，因为该代理在监视云中的 VM 方面进行了重大改进。 维持多个代理虽然比较复杂，但却能提供在数据收集规则中定义监视的功能，让你能够为不同的 VM 集配置不同的数据收集（类似于设计管理包的策略）。

迁移 VM 工作负载的管理包逻辑

没有迁移工具可将 SCOM 管理包转换为 Azure Monitor，因为它们的逻辑与 Azure Monitor 数据收集存在根本上的不同。 迁移管理包逻辑的重点通常为分析 SCOM 收集的数据，并确定 Azure Monitor 可以复制的监视方案。 当你自定义 Azure Monitor 以满足对不同应用程序和组件的要求时，你就可以开始停用 SCOM 中的各种管理包和旧版代理程序。

SCOM 中的管理包包含规则和监视器，这些规则和监视器将数据收集和生成的警报组合成单个端到端工作流。 已被 SCOM 收集的数据很少用于警报。 Azure Monitor 将数据收集和警报分成单独的进程。 预警规则访问已从代理收集的 Azure Monitor 日志和 Azure Monitor 指标中的数据。 此外，规则和监视器通常只关注特定的数据，例如特定事件或性能计数器。 Azure Monitor 中的数据收集规则通常更广泛，在单个 DCR 中收集多组事件和性能计数器。

有关为常见监视方案创建数据收集和警报的指导，请参阅以下内容：

不要尝试复制管理包的整个功能，而是分析管理包提供的关键监视。 请确定是否可以使用其他方法来复制这些监视要求。 在许多情况下，你可以在 Azure Monitor 中配置数据收集和警报规则，这些规则将重现丰富的功能，足以让你停用某个特定管理包。 管理包通常包含成百上千个规则和监视器。

一种策略是重点关注在环境中触发警报的监视器和规则。 请参阅 Operations Manager 中可用的现有报告，例如“警报”和“最常见警报”，可以帮助您识别一段时间内的警报。 你还可以对操作数据库运行以下查询，以评估最常见的近期警报。

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

评估输出，以确定有关迁移的特定警报。 忽略任何已过时或已知有问题的警报。 查看管理包，确定永不触发的任何感兴趣的关键警报。

综合事务

管理包通常使用那些连接到在计算机上运行的应用程序或服务的综合事务来模拟用户连接或实际用户流量。 如果应用程序可用，则可以假定计算机正常运行。 Azure Monitor 中的 Application Insights 可用性测试提供了此功能。 仅适用于可通过 Internet 访问的应用程序。 对于内部应用程序，必须打开防火墙以允许通过执行测试的特定 Microsoft URL 进行访问。 或者，可以继续使用现有的管理包。

后续步骤