通过

从 System Center Operations Manager 迁移到 Azure Monitor

本文为使用 System Center Operations Manager 的客户提供了指导，并计划在将业务应用程序和其他资源迁移到 Azure 时使用 Azure Monitor 进行基于云的监视。

从 System Center Operations Manager 迁移没有标准过程。 可以长期依赖 SCOM 管理包，而不是执行快速迁移。 本文介绍可用于确定特定环境的最佳策略的不同选项和决策条件。

混合云监视

大多数客户都使用 混合云监视 策略，使你能够逐步过渡到云。 此方法使你能够保持现有业务流程，因为你更熟悉新平台。 只有在 Azure Monitor 可以取而代之的情况下，才弃用 System Center Operations Manager 功能。 多个监视工具增加了复杂性。 但是，它们使你能够利用 Azure Monitor 监控下一代云工作负载的功能。 同时，可以保留 System Center Operations Manager 监视服务器软件和工作负载的能力。

将任何组件移动到 Azure 之前，环境基于位于本地或托管服务提供商的虚拟机和物理计算机。 它依赖于 System Center Operations Manager 监视环境中的业务应用程序、服务器软件和其他基础结构组件，例如物理服务器和网络。 对服务器软件（如 Internet Information Service（IIS）、SQL Server 和各种供应商软件使用标准管理包，并针对特定要求优化这些管理包。 为无法通过现有管理包监视的业务应用程序和组件创建自定义管理包。 还可以配置 System Center Operations Manager 以支持业务流程。

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

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

下表介绍了使用 System Center Operations Manager 和 Azure Monitor 的混合监视环境可用的不同功能和策略。

方法 DESCRIPTION
双宿主代理 System Center Operations Manager 使用与 Azure Monitor 使用的 Log Analytics 代理 相同的Microsoft管理代理（MMA）。 可以将这个代理程序配置为使单台计算机同时连接到 System Center Operations Manager 和 Azure Monitor。 此配置确实要求 Azure VM 与本地管理服务器建立连接。

Log Analytics 代理被 Azure Monitor 代理取代，它提供显著优势，包括更简单的管理并更好地控制数据收集。 这两个代理可以共存在同一台计算机上，使你能够连接到 Azure Monitor 和 System Center Operations Manager。 由于 Azure Monitor 代理具有显著优势，因此此配置是比双重托管旧版代理程序更好的选择。
已连接的管理组 将 SCOM 管理组连接到 Azure Monitor ，将从 System Center Operations Manager 代理收集的数据转发到 Azure Monitor。 此设置类似于使用双宿主代理，但不需要将每个代理配置为连接到 Azure Monitor。 此策略需要旧代理，因此不能使用数据收集规则（DCR）指定监视。 除非将每个 VM 直接连接到 Azure Monitor，否则无法使用 VM 分析。
SCOM 托管实例 SCOM 托管实例 是 Azure 中 System Center Operations Manager 的完整实现，允许你继续运行在本地 System Center Operations Manager 环境中运行的相同管理包。 可以继续使用同一操作控制台来分析系统运行状况和警报。 还可以在 Azure Monitor 中查看警报并分析 Grafana 中的 System Center Operations Manager 数据。

SCOM MI 类似于维护现有的 System Center Operations Manager 环境和双宿主代理，尽管可以在 Azure 中合并监视配置并停用本地组件（如数据库和管理服务器）。 来自 Azure VM 的代理可以连接到 Azure 中的 System Center Operations Manager 托管实例，而不是连接到自己的数据中心中的管理服务器。
Azure 管理包 Azure 管理包允许 Operations Manager 根据一组特定的监视方案发现 Azure 资源并监视其运行状况。 此管理包确实需要为 Azure 中的每个资源执行额外的配置。 不过，在改进业务流程以专注于 Azure Monitor 之前，在运营控制台中展示部分 Azure 资源的可见性或许会有所帮助。

监视业务应用程序

通常，您需要定制的管理包，通过安装在每个虚拟机上的代理，利用 System Center Operations Manager 监视您的业务应用程序。 Azure Monitor 中的 Application Insights 监视基于 Web 的应用程序，无论是位于 Azure、其他云还是本地。 无论是否将其迁移到 Azure，都可以将其用于所有应用程序。

如果监视业务应用程序仅限于 System Center Operations Manager 中 .NET 应用性能模板 提供的功能，则很可能迁移到 Application Insights 且不会丢失功能。 事实上，Application Insights 包含大量其他功能，包括：

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

但在某些情况下，除了 Application Insights 之外，你可能还需要继续使用 System Center Operations Manager，直到你能够实现所需的功能。 可能需要继续使用 System Center Operations Manager 的示例包括：

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

遵循本指南其他部分中的基本策略，继续对业务应用程序使用 System Center Operations Manager，但利用 Application Insights 提供的其他功能。 如果您能够用 Azure Monitor 替换关键功能，可以开始逐步淘汰自定义管理包。

监视虚拟机

监视混合环境中的虚拟机上的软件通常使用 Azure Monitor 和 System Center Operations Manager 的组合，具体取决于 VM 上运行的工作负荷的要求。 一旦在 Azure 中创建虚拟机，VM 主机 的平台指标 和活动 日志 就会自动开始收集。 启用建议的警报，以通知您 VM 主机的常见错误，例如服务器宕机和 CPU 高利用率。

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

继续对 Azure Monitor 中的其他功能未提供的功能使用管理包。 这包括关键服务器软件（如 IIS、SQL Server 或 Exchange）的管理包。 还可以为无法通过 Azure Monitor 访问的本地基础结构开发自定义管理包。 如果已紧密集成到您的业务流程中，请继续使用 System Center Operations Manager。 一旦您能够将您的服务运营现代化，Azure Monitor 和其他 Azure 服务可以增强或替换它。

注释

如果使用 Log Analytics 代理而不是 Azure Monitor 代理启用 VM 见解，则无需在 VM 上安装其他代理。 不过，建议使用 Azure Monitor 代理，因为它在监视云中的 VM 方面有显著改进。 在数据收集规则中定义监视的功能弥补了维护多个代理的复杂性。 这些规则允许为不同的 VM 集配置不同的数据收集，类似于设计管理包的策略。

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

没有用于将 SCOM 管理包转换为 Azure Monitor 的迁移工具，因为它们的逻辑与 Azure Monitor 数据收集基本不同。 迁移管理包逻辑通常侧重于分析 System Center Operations Manager 收集的数据，并确定 Azure Monitor 可复制的监视方案。 自定义 Azure Monitor 以满足不同应用程序和组件的要求时，可以开始停用 System Center Operations Manager 中的不同管理包和旧代理。

System Center Operations Manager 中的管理包包含将数据收集和生成的警报合并到单个端到端工作流的规则和监视器。 已经由 System Center Operations Manager 收集的数据很少用于警报。 Azure Monitor 将数据收集和警报分为单独的进程。 警报规则访问从代理收集的 Azure Monitor 日志和 Azure Monitor 指标的数据。 此外，规则和监视器通常侧重于特定数据，例如特定事件或性能计数器。 Azure Monitor 中的数据收集规则通常更广泛地在单个 DCR 中收集多组事件和性能计数器。

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

与其尝试复制管理包的全部功能，不如分析每个管理包提供的关键监视。 确定是否可以使用备用方法复制这些监视要求。 在许多情况下，可以在 Azure Monitor 中配置数据收集和警报规则，这些规则可以提供足够的功能，使您能够停用特定的管理包。 管理包通常包括数百甚至数千个规则和监视器。

一种策略是重点关注在环境中触发警报的监视器和规则。 请参阅 Operations Manager 中提供的现有报表，例如 警报 和 最常见的警报，可帮助识别一段时间内的警报。 还可以对 Operations Database 运行以下查询，以评估最常见的最新警报。

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 进行访问。 或者，可以继续使用现有的管理包。

后续步骤