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

云监视策略

本文是云监视指南系列教程的一部分。

当组织迁移到云环境时，通过开发人员、运营人员和基础结构工程师的参与来规划和制定有效的监视策略非常重要。 该策略应以增长为导向，以最小方式定义，然后以迭代方式进行优化。 它应始终符合业务需求，并生成一个敏捷组织，可以主动监视业务所依赖的复杂分布式应用程序。

在哪里开始？

若要简化云之旅，请使用云采用框架的策略和规划阶段。 包括所有计划和项目的策略和规划阶段的监视。

例如，检查第一个采用项目如何在 Azure 中建立早期的操作管理。 想象一下云运营模式应该是什么样子的，包括监视的角色。 监视最好采用基于服务的方法，作为一种运营功能，其中监视是一种咨询服务，是向业务及 IT 使用者提供专业知识的提供者。

下面是对健全的监视策略产生强烈影响的重要领域：

• 根据组件及其与其他依赖项的关系监视应用程序的运行状况。 首先是云服务平台、资源、网络，最后是应用程序（通过在适用的情况下收集指标和日志）。 对于混合云模型，包括本地基础结构和应用程序所依赖的其他系统。

• 通过模拟客户与应用程序的典型交互来衡量最终用户在应用程序的性能监视计划中的体验。

• 确保安全要求符合组织的安全合规性策略。

• 优先处理相关和实际事件的警报，例如警告和异常。 根据事件优先级和紧急升级矩阵，将其严重性与其重要性保持一致。

• 仅收集对业务和 IT 组织有用、可度量且可识别的指标和日志。

• 定义与现有 IT 服务管理（ITSM）解决方案（例如补救措施或 ServiceNow）的集成计划，以便生成事件或上游监视。 确定应转发哪些警报，是否需要警报扩充来支持特定的筛选要求，以及如何配置。

• 了解需要可见性的人员，他们需要查看的内容，以及应该如何根据他们的角色和职责将内容可视化。

作为运营管理的核心，IT 组织需要针对构建、运营和管理 IT 服务的方法建立集中治理和严格委派。

初始策略目标

作为架构师或战略规划师，可能需要制定运营管理的早期策略，其中监视起着重要作用。 请考虑以下四个结果：

1. 在云生产服务投入生产时对其进行管理，例如网络、应用程序、安全性和虚拟基础架构。

2. 应用有限的资源来合理化现有的监视工具、技能和专业知识，并使用云监视降低复杂性。

3. 使监视解决方案流程更高效、工作更快且更顺畅、规模化并能够快速地进行更改。

4. 说明组织将如何基于云模型计划和托管监视。 随着组织从 IaaS 过渡到 PaaS，然后再过渡到 SaaS，努力实现降低需求的目标。

确定你有什么

你可能会与指导委员会、建筑师和战略规划师密切合作。 你可能正努力通过评估系统管理的当前状态来制定监视策略，包括人员、合作伙伴、外包、工具、复杂性、差距和风险。 评估将帮助你确定已发现的一系列问题的优先级，并选择改进当前情况的关键机会。 此外，确定可能保留在本地的服务、系统和数据作为一个重要结果。 理想情况下，管理层需要一个计划路线图，但要与已知的规划周期成正比。 讨论未知因素非常重要。

高层建模

当业务确定要迁移到云的服务时，需要仔细投资资源。 对于本地，你拥有监视的所有责任，并投入了大量资金。 例如，针对 SaaS 服务的移动不会消除监视责任。 你将至少决定谁需要访问权限、谁获得警报以及谁需要访问分析。 Azure Monitor 和 Azure Arc 是一项服务，可以灵活地跨所有四个云模型（而不仅仅是 Azure 中的资源）解决监视方案。 考虑常见的云模型，如下所示。 对于 Microsoft 365 服务提供的Microsoft 办公室应用程序，除了 Microsoft Defender for Cloud 之外，还需要包括 Microsoft 365 的安全性和合规性监视。 应在企业网络外部包括标识、终结点管理和设备监视。

监视为策略提供信息

许多策略决策取决于早期监视数据，以便构建指导有限资源并增加信心的功能路线图。 策略还需要监视服务启用情况的实际输入。

考虑监视在以增量方式保护和保护数字资产的策略中扮演的角色：

• 需要活动日志和安全监视来衡量目录使用情况和敏感内容的外部共享，以通知增量方法对保护功能进行分层，并实现与隐私监视的适当平衡。

• 策略和基线将为合理化目标（迁移、直接迁移或重新架构）提供信息，并提高数据和信息可从本地迁移到云服务的信心。

在本指南的后面部分，发现一些有助于加速采用的常见监视场景或用例。

制定监视体系结构

定义用于监视的当前体系结构和将来的体系结构，以便：

• 在资源受限时合并监视投资。

• 确定监视如何帮助实现未来业务需求的服务。

• 与在云中监视的未来服务和资源保持一致。

• 识别运行状况模型三个维度（深度、广度和跨度）的监视差距。

• 对支持成本效益分析的财务方面、成本和支持因素进行建模。

• 为你需要做出的混合决策提供指导。

监视的一个原则是服务可见性。 若要使服务、资产或组件完全可见，需要平衡此原则的三个方面，即：

1. 通过收集有意义的和相关信号来深入监视。
2. 从堆栈的最低层到应用程序，进行端到端或广度监视。
3. 通过专注于运行状况的各个方面（可用性、性能、安全性和连续性）进行向东到西部的监视。

一些关键问题包括：

• 如何共享安全日志并保护其访问权限？

• 哪些服务将在全球可用，因此能够在服务边缘进行全局监视？

• 网络基础结构与与服务和应用程序终结点的网络连接之间的网络点如何，以指示系统或云提供商是否存在问题？

• 安全操作与运行状况和性能的边界是什么？ 如何向安全操作提供运行状况和状态摘要，以及如何向服务所有者提供相反的情况？

为了组件此体系结构，这里有几个考虑因素：

• 请考虑从服务资产开始的数据流方法，并启动堆栈：基础结构、IoT 设备、移动设备等发出的指标和日志数据。 是否所有项目都在管理到监视工具（中层）之下？ 向上和向外移动（ITSM 工具、全球监视、安全信息和事件管理 (SIEM)、自定义警报扩充等）。

• 是否继续使用 System Center Operations Manager 或其他监视工具。

• 经济成本。

• 业务将如何使用日志和指标。 Azure Monitor 将大量的日志和时序数据引入到监视的性能和运行状况方面，这与安全操作体验类似。 日志和指标是 Azure Monitor 体系结构的两个主要数据组件。 出于以下原因，它们非常重要：

  1. 由于可以构建大规模复杂的云服务，因此问题管理成本会降低。 可以在一个位置分析、关联并确定问题的原因，从而减少直接访问资源的需求，从而提高安全性。

  2. 与 SIEM 类似，Azure Monitor 将合并来自本地资产和 Azure 资源的计算机数据，包括活动日志、租户和订阅数据以及 REST 客户端中的任何日志数据。 可以使用查询语言来分析数据，远远超出了以前可能的数据。

考虑数据流和工具：

• 源和类型：遥测、跟踪、有状态、时序。

• 工具和套件（行）：列：可用性、容量、安全性、连续性和合规性。

• 全球监视或顶层的角色。

• ITSM 集成在重大事件上触发的角色。

在治理计划中考虑单个策略，以用于驱动警报和通知的事件意义。 这是监视策略中的一个重要策略。 下表是一个事件管理优先级模型示例，用于标准化对通知使用的事件、重要性和警报。

制定计划

作为监视专家或系统管理员，你已发现云监视速度更快、更易于建立，可实现价格低廉的演示或价值证明。 若要克服保持演示模式的趋势，需要与策略保持联系，并能够在以生产为中心的监视计划上执行。 由于策略具有大量不确定性和未知情况，因此你不会提前知道所有监视要求。 因此，根据业务和 IT 管理的最低可行方案，确定第一组采用计划。 可以将此功能称为“开始旅程所需的功能”。 下面是两个有助于声明向前运动的计划示例：

• 计划 1： 为了减少当前监视投资的多样性和复杂性，我们将首先投资使用 Azure Monitor 建立核心功能，因为相同的技能和准备情况适用于云监视的其他领域。

• 计划 2： 为了决定如何使用许可证计划进行标识、访问和整体信息保护，我们将帮助安全和隐私办公室在用户迁移到云时建立对用户和内容的早期活动监视，以阐明有关分类标签、数据丢失防护、加密和保留策略的问题。

考虑缩放

考虑策略规模以及谁将定义和标准化“监视即代码”。 组织应计划结合使用以下工具来构建标准化解决方案：

• Azure 资源管理器模板。
• Azure Policy 监视计划定义和策略。
• GitHub 为脚本、代码和文档建立源代码管理。

考虑隐私和安全性

在 Azure 中，需要保护资源发出的某些监视数据以及 Azure 中记录的控制平面操作（称为活动日志）。 此外，记录用户活动（如 Microsoft Entra 登录和审核日志）的专用日志（如果已集成），Microsoft 365 统一审核日志都包含可能需要根据隐私法保护的敏感数据。

监视策略应包括以下操作：

• 将非监视数据与监视数据分开。
• 限制对资源的访问。

考虑业务连续性

Azure Monitor 收集、索引和分析实时计算机和资源生成的数据，以支持操作并帮助推动业务决策。 在极少数情况下，整个区域中的设施都可能会变得无法访问（例如由于网络故障）。 或自然灾害等原因造成的完全失去联系。 将这些服务转移到云中时，规划不侧重于基础结构复原和高可用性。 相反，它正在规划：

• 从 Azure 中所有依赖的服务和资源、从其他云中的资源以及从本地进行数据引入的可用性。
• 见解、解决方案、工作簿和其他可视化效果、警报、与 ITSM 的集成，以及 Azure 中支持操作要求的其他控制平面服务的数据可用性。

创建恢复计划，确保其中涵盖了数据还原、网络中断、依赖服务故障和区域范围的服务中断。

考虑成熟度

监视策略将增长和发展。 最好先收集数据，这有助于确定策略。 需要的第一个监视解决方案是确保可观测性的解决方案，包括响应式流程，例如事件和问题管理。

• 创建一个或多个 Log Analytics 工作区。

• 启用代理。

• 启用资源诊断设置。

• 启用初始警报规则。

当你对 Azure Monitor 功能充满信心时，可以通过扩展日志集合、启用和使用见解和指标的焦点，以及定义日志搜索查询，从而驱动运行状况或运行不正常的数据的度量和计算，从而开始衡量运行状况指标。

作为学习周期的一部分，你将获得监视数据和见解，了解经理的掌握情况，并确保适当的使用者拥有所需的监视数据。 学习周期包括不断调整和优化初始监视计划，以适应、改进服务并为采用计划提供信息。

DIKW 模型通常用于学习。 操作和决策从数据转移到信息、知识和智慧。

监视是在 Azure 中构建的服务的基础。 你的策略可以解决新式监视的这五个规则，以帮助定义最小可行监视，并获得对步骤的信心。 将你的功能从被动转变为主动并将其覆盖范围扩大到最终用户只是目标之一。

• 监视： 首先，应专注于建立监视，以观察 Azure 服务和资源的运行状况和状态。 配置基本监视，然后使用 Azure Policy 和 Azure 资源管理器模板实现自动化，以建立服务及其保证的初始可见性：可用性、性能或容量、安全性和配置符合性。 例如，基于 Azure Monitor 的最小可行设置，配置用于监视和诊断的资源，设置警报和见解。 包括监视使用者、定义事件和基于事件触发、服务工作（例如事件和问题）的知识和就绪情况。 成熟度的一个指标是，可以自动执行多少操作来减少手动观察运行状况和状态的不必要人工成本。 了解哪些服务运行正常与对运行不正常的服务发出警报一样重要。

• 衡量：配置来自所有资源的指标和日志的收集，以监视作为问题的症状/条件，这些症状/条件指示对服务可用性的潜在或实际影响，或对服务/应用程序使用者的影响。 例如：

  • 在应用程序中使用功能时，它是显示响应时间延迟、选择某些内容时返回错误还是无响应？

  • 通过衡量服务或应用程序的效用来确保服务符合服务协议。

• 响应：根据要观察和衡量的已知问题的上下文，基于归类为事件、问题或更改的内容，评估属于 bug、自动修正或需要手动响应的内容。

• 学习和改进： 通过这两个相互依赖的学科，提供程序和使用者参与学习周期。 它们通过见解、报表和工作簿使用监视数据。 使用这些方法来优化和优化监视配置，以持续改进目标服务。 更改也很重要。 监视配置随着业务、技术、云提供商和其他服务的更改而发生变化，以改进服务保修。

为了帮助你使监视计划与策略保持一致，请使用下表对发生的不同监视场景进行更详细的分类。 请记住，在规划阶段之前引入的五个合理化 Rs。 如果使用的是 System Center Operations Manager，可以使用混合和云选项来使投资合理化。

类型	监视目标	示例目标
1	仅限本地	System Center Operations Manager。 继续监视服务、基础结构，在自有数据中心内建立应用程序层网络，无需考虑云。
2	本地到云	继续使用 System Center Operations Manager，并应用 Microsoft 365 和 Azure 管理包。
3	本地到/与云（合作），其中服务在云和本地运行	使用 Azure Monitor 建立初始监视。 连接 Azure Monitor 到 System Center Operations Manager 或 System Center Operations Manager 托管实例（预览版）和警报源，例如 Zabbix 或 Nagios。 部署 Azure Monitor 监视代理，使用 System Center Operations Manager 实现多宿主，它们在其中协同监视。
4	混合迁移	监视迁移，例如 Microsoft Exchange Server 迁移到 Microsoft 365 Exchange Online。 Exchange Online 服务运行状况和服务使用情况、安全性和合规性，全部来自 Microsoft 365。 可以使用 System Center Operations Manager 托管实例（预览版）。 如果使用 System Center Operations Manager，则在迁移完成之前，请逐步解除与 System Center Operations Manager 本地的监视交换。
5	永久混合	System Center Operations Manager 托管实例（预览版）、Microsoft Entra ID、Azure Monitor、Microsoft Defender for Cloud、Intune 等;一系列用于混合数字资产的工具。
6	云原生	Azure Monitor、Azure Policy、Microsoft Defender for Cloud、Microsoft 365、Azure 服务运行状况、Azure 资源运行状况等。
7	多云拥有的租户（合并）	集中监视多个租户。 Azure Lighthouse、Azure Policy、Azure Monitor 和 Microsoft Sentinel。
8	多云生态系统	集中监视不同的云提供商：Microsoft、Amazon、Google 等。
9	提供程序 > 使用者	作为云提供商监视解决方案和服务。

制定监视要求

在完成此过程的过程中，你的策略可能会显示最终还有很多工作要做。 最终，监视应扩展到企业网络到工作场所、设备和终结点，并进一步向外扩展到标识即安全边界。 与数据中心和工作区思维模式相比，使用云监视定义的新边缘是一种强大的推动因素。

可以使用 Azure 逐步管理本地资源的所有或某些方面，即使是在本地保留的服务。 你还希望制定一个策略，根据业务采用的云服务模型，根据业务采用的云服务模型，根据业务采用的策略定义责任的监视边界。 即使对于基于 IaaS 的服务，你也会通过 Azure 服务运行状况获取指标、日志、视图和警报功能。 可以使用资源运行状况从 Azure 资源的可用性监视配置警报。 使用 SaaS 服务（如 Microsoft 365），已提供很多功能，你需要配置对门户、仪表板、分析和警报的适当访问权限。 从服务的角度来看，具有分布式组件（例如 Microsoft 365 Exchange Online）的大型服务具有许多目标，而不仅仅是需要观察其运行状况和状态。

主要目标	目标和结果
运行状况和状态监视	在可用性、容量、性能、安全性和符合性等方面整体观察、测量、了解和改进服务或组件的长期保证，包括服务水平。 运行正常的系统、服务或组件处于联机状态，并且执行良好、安全且合规。 运行状况监视包括日志，并且是有状态的，具有实时运行状态和指标。 它还包括侧重于服务使用情况的趋势报告、见解和趋势。
实用工具监视	观察、衡量、学习和改进系统如何交付价值的质量或定性方面。 用户体验是一种监视用例。
安全监视	观察、衡量、了解并改进保护，以支持网络安全策略和功能，如安全操作、标识和访问、信息保护、隐私、威胁管理和符合性。 使用 Microsoft Defender for Cloud 和 Microsoft Sentinel 以及 Microsoft 365 进行监视。
成本监视	作为新的主要目标，使用 Azure Monitor 和 Azure 成本管理 + 计费来监视使用情况并估算成本。 使用 Azure 成本管理 + 计费 API，可通过多维分析来探索成本和使用情况数据。

第三级目标	目标和结果
活动监视	从 Azure 活动日志、审核日志和 Microsoft 365 统一审核日志等源观察、衡量、了解并改进使用情况、安全性和符合性，以了解订阅级别事件、资源操作、用户和管理员活动、内容、数据，并满足你在 Azure 和 Microsoft 365 中的安全性和符合性需求。
服务使用情况	服务所有者需要分析和见解，通过服务使用情况报告、分析和见解来衡量、了解并改进 Azure 和 Microsoft 365 服务（IaaS、PaaS、SaaS）的使用情况。 确保计划包括谁需要访问管理门户、仪表板、见解和报表。
服务和资源运行状况	观察云资源的运行状况，以及来自 Microsoft 的服务中断和建议，随时了解有关事件和维护的信息。 将资源运行状况纳入资源可用性的监视，并对可用性更改发出警报。
容量和性能监视	为支持运行状况监视，你的需求可能需要更深入和更专业化。
更改和符合性监视	观察、衡量、了解并改进资源的配置管理，现在应该在制定过程中包括安全性（这受正确使用 Azure Policy 的影响），以标准化监视配置并强制实施安全强化。 用于筛选对资源进行的关键更改的日志数据。
标识和访问监视	观察、测量、学习和改进 Active Directory、Microsoft Entra ID 和标识管理的使用情况和安全性，以集成用户、应用程序、设备和其他资源，无论他们身在何处。
信息保护	Azure 信息保护，具体取决于计划，包括对跨 Azure 和 Microsoft 的可靠信息保护策略至关重要的使用情况分析。
隐私监视	组织面临日益扩大的隐私需求，包括保护数字资产、数据分类和数据丢失防护，以缓解隐私泄露和违规的风险。 Microsoft 365 信息保护包括监视功能，这些功能也可以与 Azure Monitor 集成。
威胁管理和集成威胁防护	云将安全监视的独立传统角色与运行状况监视结合在一起。 例如，集成威胁防护涉及到监视，以加速零信任的最佳状态。 Microsoft Defender for Identity 允许集成 Active Directory 安全相关信号，以检测混合环境中的高级攻击。

敏捷解决方案版本

最终，你将把监视配置或解决方案交付到生产中。 考虑一种标准、简单的分类，以提高与消费者、经理和 IT 运营的沟通。 敏捷 DevOps 方法可确保监视嵌入在将构建和运营云服务的团队中。 尽管传统的项目管理工作正常，但它速度不够快，通常也不会被运营团队接受为标准做法。

在你的策略和运营模型中包括你传达监视计划、目标和配置（解决方案）的方式。 例如，你可能会如何使用 Azure Boards：

敏捷术语	要包括的内容	示例
长篇故事	广泛的监视， 监视策略计划	合并 Azure 云监视， 混合云监视， 私有云监视， 建立核心监视服务
功能	单个监视， 计划和项目	监视要求， 监视使用者和提供程序， 目标 工具 计划
用户情景和任务	最终结果是一个监视配置或解决方案	网络监视（例如 ExpressRoute）， 标准化的 IaaS VM 监视（例如，用于 VM 的 Azure Monitor、Application Insights、Azure Policy、设置、策略、报表、工作区）。

建立最低治理

尽快确定你打算如何治理云监视投资。 请记住，Azure Monitor 是一种 租户 服务，可跨管理组和订阅进行可见性，并且 Azure 基于角色的访问控制可以限制用户权限。

定义谁将在 Azure 中拥有哪一级别的访问权限，以支持他们的角色和职责。 应尽早为监视使用者设置“读取者”角色访问权限，然后控制谁被授予“参与者”角色。

首先，确定哪些角色将在 Azure 中作为治理框架的一部分拥有和管理资源组：

• 确定监视团队还是一个或多个资源和资源组的管理员将具有对“监视参与者”角色的特权访问权限。

• 选择应被授予“监视读取者”角色的使用者，该角色允许访问 Azure Monitor 中的功能，并调查每个 Azure 资源随附的监视部分中的问题。

• 选择哪些管理员需要访问其他 Azure 读取者角色，例如报表读取者角色。

总的来说，你的监视使用者角色可能需要广泛的访问权限，而你的开发人员和系统管理员只需要基于角色的访问权限以访问某些 Azure 资源。 另一个限制是，确保免除读者访问敏感监视数据（例如安全日志、登录日志和用户活动日志）的权限。

制定就绪计划

尽早制定就绪计划，帮助 IT 人员采用新的技能、实践和技术以进行 Azure 中的云监视。 请考虑技能准备指南。

后续步骤

云部署模型的监视策略