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

有关设计和创建监视系统的建议

  • 项目

适用于此 Azure Well-Architected 框架卓越运营清单建议：

OE：07 设计和实现监视系统，以验证设计选择，并为未来的设计和业务决策提供信息。 此系统捕获并公开从工作负载的基础结构和代码发出的操作遥测、指标和日志。

相关指南： 检测应用程序的建议

本指南介绍有关设计和创建监视系统的建议。 若要有效监视工作负载的安全性、性能和可靠性，需要一个具有自身堆栈的综合系统，为所有监视、检测和警报功能提供基础。

定义

术语 定义
日志 录制的系统事件。 日志可以包含结构化或自由格式文本格式的不同类型的数据。 它们包含时间戳。
指标 定期收集的数值。 指标描述特定时间系统的某些方面。

关键设计策略

若要为工作负载实现全面的监视系统设计，请遵循以下核心原则：

  • 只要可行，请利用平台提供的监视工具，这些工具通常需要很少的配置，并且可以深入了解可能难以完成的工作负载。

  • 从整个工作负载堆栈收集日志和指标。 所有基础结构资源和应用程序功能都应配置为生成标准化、有意义的数据，并且需要收集数据。

  • 将收集的数据存储在标准化、可靠且安全的存储解决方案中。

  • 处理存储的数据，以便分析和可视化解决方案可以处理这些数据。

  • 分析已处理的数据以准确确定工作负载的状态。

  • 在工作负载团队和其他利益干系人的有意义的仪表板或报表中可视化工作负载的状态。

  • 为智能定义的阈值配置可操作的警报和其他自动响应，以便在出现问题时通知工作负载团队。

  • 在整体工作负载测试实践中包括监视和警报系统。

  • 确保监视和警报系统处于持续改进的范围内。 生产中的应用程序和基础结构行为提供了持续学习的机会。 将这些课程纳入监视和警报设计。

  • 将收集和分析的监视数据关联回 系统和用户流 ，以将流的运行状况与数据相关联，以及工作负载的总体运行状况。 根据流分析数据将有助于使可观测性策略与 运行状况模型保持一致。

应尽可能自动执行监视系统的所有功能，并且它们应每天持续运行。

此工作流管道演示了监视系统：

显示综合监视系统作为管道的各个阶段的示意图。

集合

注意

需要检测应用程序以启用日志记录。 有关详细信息，请参阅 检测指南。

应配置所有工作负载组件（无论是基础结构资源还是应用程序功能），以捕获遥测和/或日志和指标等事件。

日志主要用于检测和调查异常。 通常，日志由工作负载组件生成，然后发送到监视平台或通过自动化由监视平台拉取。

指标主要用于 生成运行状况模型 以及确定工作负载性能和可靠性的趋势。 指标也可用于确定客户的使用行为趋势。 这些趋势有助于从客户的角度指导有关改进的决策。 通常，指标在监视平台中定义，监视平台和其他工具轮询工作负载以捕获指标。

应用程序数据

对于应用程序，收集服务可以是应用程序性能管理 (APM) 工具，该工具可以从生成检测数据的应用程序自主运行。 启用 APM 后，可以清楚地了解重要指标，实时和历史。 使用适当级别的日志记录。 详细日志记录可能会产生大量成本。 根据环境设置日志级别。 例如，较低环境不需要与生产环境相同的详细级别。

应用程序日志支持端到端的应用程序生命周期。 日志记录对于了解应用程序在各种环境中如何运行、发生哪些事件以及发生这些事件的条件至关重要。

建议跨所有主要环境收集应用程序日志和事件。 如果这样做可行，请为每个环境使用不同的数据存储，尽可能多地分隔环境之间的数据。 使用筛选器可确保非关键环境不会使生产日志的解释复杂化。 最后，应用程序中的相应日志条目应捕获其各自事务的相关 ID。

应使用计算机可读数据点（而不是非结构化字符串类型）以结构化数据类型捕获应用程序事件。 使用已知架构的结构化格式可以更轻松地分析日志。 此外，可以轻松为结构化数据编制索引和进行搜索，并且可以大大简化报表。

数据应采用独立于计算机、操作系统或网络协议的不可知格式。 例如，以自描述格式（如 JSON、MessagePack 或 Protobuf）而不是 ETL/ETW 发出信息。 标准格式使系统能够构造处理管道。 可以轻松集成以标准格式读取、转换和发送数据的组件。

基础结构数据

对于工作负载中的基础结构资源，请确保同时收集日志和指标。 对于基础结构即服务 (IaaS) 系统，除了捕获与工作负载运行状况相关的指标外，还捕获 OS、应用程序层和诊断日志。 对于平台即服务 (PaaS) 资源，捕获与底层基础结构相关的日志的能力可能会受到限制，但请确保除了捕获与工作负载运行状况相关的指标外，还可以捕获诊断日志。

尽可能多地从云平台收集日志。 可以收集订阅的活动日志和管理平面的诊断日志。

收集策略

避免从每个组件手动检索遥测数据。 将数据移动到一个中心位置，并将其合并到该位置。 对于多区域解决方案，建议先逐个区域收集、合并和存储数据，然后将区域数据聚合到单个中央系统中。

权衡：请注意，使用区域和集中式数据存储会产生成本影响。

要优化带宽的使用，请根据数据的重要性进行优先级排序。 可以批量传输不太紧急的数据。 但是，此数据不得无限期延迟，尤其是包含时间敏感的信息时。

收集服务可以使用两个主要模型来收集检测数据：

  • 拉取模型：主动从应用程序的每个实例的各种日志和其他源中检索数据。

  • 推送模型：被动等待数据从构成应用程序的每个实例的组件发送。

监视代理

可以在请求模型中使用监视代理。 代理在每个应用程序实例的单独进程中在本地运行，定期拉取数据并将信息直接写入应用程序的所有实例共享的公共存储。

显示如何使用监视代理拉取信息并将其写入共享存储的示意图。

注意

监视代理非常适合用于捕获从数据源自然提取的检测数据。 它适用于在单个位置中有限数量的节点上运行的小型应用程序。 示例包括SQL Server动态管理视图中的信息或Azure 服务总线队列的长度。

性能注意事项

复杂且高度可缩放的应用程序可能会生成大量数据。 数据量很容易使单个中心位置的 I/O 带宽不堪重负。 遥测解决方案不能成为瓶颈，并且必须随着系统的扩展而扩展。 理想情况下，解决方案应包含一定程度的冗余，以降低丢失重要监视信息的风险， (如审核或计费数据) （如果系统部分发生故障）。

缓冲检测数据的一种方法是使用队列：

显示如何使用队列来缓冲检测数据的示意图。

在此体系结构中，数据收集服务将数据发布到队列。 消息队列是合适的，因为它提供“至少一次”语义，有助于确保排队数据在发布后不会丢失。 可以使用单独的辅助角色实现存储写入服务。 可以使用 优先级队列模式 来实现此体系结构。

为了实现可伸缩性，可以运行存储写入服务的多个实例。 如果正在监视大量事件或大量数据点，可以使用 Azure 事件中心 将数据调度到其他计算实例进行处理和存储。

合并策略

从应用程序的单个实例收集的数据提供该实例的运行状况和性能的本地化视图。 若要评估系统的整体运行状况，需要从本地视图中合并数据的某些方面。 可以在存储数据后执行此操作，但在某些情况下，可以在收集数据时执行此操作。

显示使用服务合并检测数据的示例的示意图。

通过独立的数据合并服务传递检测数据，此服务可以合并数据，并可充当筛选器和清理进程。 例如，可以合并包含相同关联信息（如活动 ID）的检测数据。 (用户可能会在一个节点上启动业务操作，然后在第一个节点发生故障或由于负载均衡的配置方式而转移到另一个节点。) 此过程还可以检测并删除任何重复的数据。 如果遥测服务使用消息队列将检测数据推送到 storage，则可能发生 (重复。)

存储

选择存储解决方案时，请考虑数据类型、使用方式以及所需的紧急程度。

注意

对非生产环境和生产环境使用单独的存储解决方案，以确保每个环境中的数据易于识别和管理。

存储技术

请考虑多语言持久性方法，其中不同类型的信息存储在最适合每种类型使用方式的技术中。

例如，Azure Blob 存储和 Azure 表存储的访问方式类似。 但是，可以对其执行的操作有所不同，它们保存的数据的粒度也不同。 如果需要运行更多的分析操作或需要对数据使用全文搜索功能，可能更适合使用数据存储，因为它提供的功能已针对特定类型的查询和数据访问进行优化。 例如：

  • 性能计数器数据可以存储在 SQL 数据库中以启用即时分析。

  • 最好将跟踪日志存储在 Azure Monitor 日志或 Azure 数据资源管理器中。

  • 可以将安全信息存储在 HDFS 解决方案中。

可能会出于多个目的而需要同一检测数据。 例如，可以使用性能计数器来提供系统性能随时间推移的历史视图。 此信息也可能与其他使用情况数据结合来生成客户帐单信息。 在这些情况下，相同的数据可能会发送到多个目标，例如发送到文档数据库，该数据库可以是用于保存计费信息的长期存储，也可以发送到用于处理复杂性能分析的多维存储。

请务必启用保护数据免受意外删除的功能，例如资源锁和软删除。

此外，请确保使用基于角色的访问控制来保护对存储的访问，以帮助确保只有需要访问数据的个人才能这样做。

合并服务

可以实现另一个服务，该服务定期从共享存储检索数据，根据数据用途对其进行分区和筛选，然后将其写入到适当的数据存储集。

此图显示了一个数据分区服务，该服务根据数据类型将数据移动到适当的数据存储。

另一种方法是在合并和清理过程中包含此功能，并在检索到数据时直接将它写入这些存储，而不是将它存储在中间共享存储区域。

每一种方法有其优点和缺点。 实现单独的分区服务可减少合并和清理服务的负载，并且可以根据需要重新生成一些分区数据 (具体取决于共享存储) 中保留的数据量。 但是，此方法会消耗额外的资源。 此外，在从每个应用程序实例接收检测数据与将此数据转换成有用信息之间可能出现延迟。

查询注意事项

考虑需要数据的紧急程度。 生成警报的数据必须快速访问，因此应该保留在快速数据存储中，并编制索引或结构化以优化警报系统运行的查询。 在某些情况下，收集服务可能需要在本地格式化和保存数据，以便警报系统的本地实例可以快速发送通知。 同一数据可以发送到前面图表中显示的存储写入服务，如果出于其他目的而需要它，则集中存储。

数据保留注意事项

在某些情况下，处理和传输数据后，可以删除本地存储的原始源数据。 在其他情况下，可能有必要保存原始信息，或者这样做会有用。 例如，你可能希望保留为调试生成的数据在其原始格式中可用，但在解决任何 bug 后迅速将其丢弃。

性能数据通常具有更长的生存期，因此可以使用它来发现性能趋势和进行容量规划。 此数据的合并视图通常在一段有限的时间内保持联机以实现快速访问。 过了这段时间后，可以将其存档或丢弃。

存储能够找出长期趋势的历史数据很有用。 与其完整保存旧数据，不如向下采样数据以减少其分辨率并节省存储成本。 例如，可以合并超过一个月的数据，以形成每小时视图，而不是逐分钟保存性能指标。

针对客户计量和计费收集的数据可能需要无限期保存。 此外，法规要求可能规定需要存档和保存为审核和安全而收集的信息。 此数据也很机密，因此可能需要加密或进行保护，以防止篡改。 切勿记录用户密码或可能用于实施身份欺诈的其他信息。 在存储数据之前，应从数据中清除这些详细信息。

为了确保遵守法律和法规，请尽量减少任何可识别信息的存储。 如果确实需要存储身份信息，请确保在设计解决方案时考虑允许个人请求删除其信息的要求。

分析

从各种数据源收集数据后，对其进行分析以评估系统的整体运行情况。 对于此分析，请清楚地了解：

  • 如何基于已定义的 KPI 和性能指标构建数据。

  • 如何关联在不同指标和日志文件中捕获的数据。 在跟踪事件序列时，这种关联非常重要，有助于诊断问题。

在大多数情况下，体系结构的每个组件的数据都是在本地捕获的，然后与其他组件生成的数据准确组合在一起。

例如，三层应用程序可能具有以下功能：

  • 允许用户连接到网站的表示层。

  • 托管处理业务逻辑的一组微服务的中间层。

  • 存储与操作关联的数据的数据库层。

单个业务操作的使用情况数据可能跨所有三个层。 此信息必须关联在一起，以提供操作的资源和处理使用情况的整体视图。 关联可能涉及在数据库层上的一些数据预处理和筛选。 在中间层，聚合和格式设置是常见任务。

建议

  • 关联应用程序级别和资源级日志。 评估这两个级别的数据，以优化问题的检测和这些问题的故障排除。 可以在单个数据接收器中聚合数据，或利用跨两个级别查询事件的方法。 建议使用统一的解决方案（例如 Azure Log Analytics）来聚合和查询应用程序级别和资源级日志。

  • 为冷分析定义明确的存储保留时间。 建议采用这种做法，以便在特定时间段内启用历史分析。 它还可以帮助你控制存储成本。 实施流程，确保将数据存档到更便宜的存储和聚合数据，以便进行长期趋势分析。

  • 分析长期趋势以预测操作问题。 评估长期数据以形成操作策略，并预测可能发生的运营问题以及时间。 例如，你可能会注意到，平均响应时间会随着时间推移而缓慢增加，并接近最大目标。

有关这些建议的详细指导，请参阅 分析云应用程序的监视数据。

可视化效果

仪表板

可视化数据的最常见方法是使用仪表板，仪表板可以将信息显示为一系列图表或图形，或者以某种其他视觉形式显示。 这些项可以参数化，分析师可以为任何特定情况选择重要参数，如时间段。

使仪表板与 运行状况模型 保持一致，以便它们指示工作负荷或工作负荷组件何时正常、降级或不正常。

要使仪表板系统有效工作，它必须对工作负荷团队有意义。 可视化与工作负载运行状况相关的信息，这些信息也是可操作的。 当工作负荷或组件降级或不正常时，工作负载团队的成员应该能够轻松识别问题在工作负载中的哪个位置，并开始其纠正措施或调查。 相反，包含不可操作或与工作负载运行状况无关的信息会使仪表板变得不必要的复杂和令人沮丧的团队成员试图从可操作数据中识别背景噪音。

你可能拥有面向利益干系人或开发人员的仪表板，这些仪表板被自定义为仅显示他们认为相关的工作负载的相关数据。 确保工作负载团队了解其他团队想要查看和预览仪表板的数据类型，然后再将其共享到检查，以便清楚起见。 为利益干系人提供有关工作负载的仪表板是让他们了解工作负载运行状况的好方法，但如果利益干系人不清楚地了解他们看到的数据，则可能会适得其反。

好的仪表板不只是显示信息。 它还使分析师能够提出有关该信息的临时问题。 某些系统为操作员提供了管理工具用于完成这些任务和浏览底层数据。 相反，根据用于保存信息的存储库，可以直接查询数据或将其导入 Excel 等工具进行进一步分析和报告。

注意

将仪表板访问权限限制为授权人员。 仪表板上的信息可能具有商业敏感性。 还应保护基础数据，以防止用户更改它。

报表

报告用于生成系统的整体视图。 它可能包含历史数据和当前信息。 报告要求划分为两大类：操作报告和安全报告。

操作报告通常包括以下内容：

  • 聚合统计信息，用于了解指定时间范围内整个系统或指定子系统的资源利用率。

  • 识别整个系统或指定子系统在指定时间段内的资源使用趋势。

  • 监视整个系统或指定子系统在指定时间段发生的异常。

  • 确定已部署资源的应用程序效率，并了解资源量及其相关成本是否可以在不不必要地影响性能的情况下减少。

安全报告跟踪客户对系统的使用情况。 其中可能包括：

  • 审核用户操作。 此任务需要记录每个用户完成的单个请求以及日期和时间。 应对数据进行结构化，使管理员能够快速重新构造用户在指定时间段内完成的操作序列。

  • 按用户跟踪资源使用情况。 此任务需要记录用户的每个请求如何访问构成系统的各种资源，以及访问时间。 管理员可以使用此数据按用户生成指定时间段（可能用于计费）的利用率报告。

在许多情况下，批处理进程可以根据定义的计划生成报告。 正常情况下，延迟不是问题。 还应具有可根据需要自发生成报告的批处理过程。 例如，如果将数据存储在关系数据库（如 Azure SQL Database）中，则可以使用 SQL Server Reporting Services 等工具来提取和设置数据的格式，并将其呈现为一组报表。

警报

为了帮助确保系统保持正常、响应和安全，请设置警报，以便操作员能够及时响应它们。 警报可以包含足够的上下文信息，以帮助他们快速开始诊断活动。 警报可用于调用 修正功能，如自动缩放或其他自我修复机制。 警报还可以通过提供对预算和限制的可见性来实现成本感知。

建议

  • 定义一个警报响应流程，以确定负责任的所有者和行动。

  • 为明确定义的范围（资源类型和资源组）配置警报并调整详细程度以最大限度地减少噪音。

  • 使用自动警报解决方案（如 Splunk 或 Azure Monitor），而不是要求人们主动查找问题。

  • 使用警报操作修正过程。 例如，自动创建票证以跟踪问题和解决方案。

  • 跟踪区域中云平台服务的运行状况、有关中断的通信、计划内维护活动和其他运行状况公告。

阈值

当超过阈值时，系统会生成警报，如监视系统检测到的那样。 确保设置的阈值通常提供足够的时间来对工作负载实施必要的更改，以避免降级或中断。 例如，设置自动缩放阈值，以便在任何正在运行的系统变得不堪重负，导致用户体验降级之前启动缩放。 根据你过去在管理基础结构方面的经验分配的阈值，并通过作为测试实践的一部分执行的测试来验证这些阈值。

有关警报用例和其他注意事项的详细指导，请参阅 设计可靠的监视和警报策略。

Azure 便利化

  • Azure Monitor 是一种全面的监视解决方案，用于从云和本地环境收集、分析和响应监视数据。

  • Log Analytics 是 Azure 门户 中的一种工具，可用于针对 Log Analytics 工作区中的数据编辑和运行日志查询。

    如果使用多个工作区，请参阅 Log Analytics 工作区 体系结构指南 ，了解最佳做法。

  • Application Insights 是 Azure Monitor 的扩展。 它提供 APM 功能。

  • Azure Monitor 见解 是适用于特定 Azure 技术的高级分析工具， (VM、应用服务和容器) 。 这些工具是 Azure Monitor 和 Log Analytics 的一部分。

  • 适用于 SAP 解决方案的 Azure Monitor 是在 Azure 上运行的适用于 SAP 环境的 Azure 监视工具。

  • Azure Policy 可帮助你执行组织标准并大规模评估合规性。

  • Azure Monitor 基线警报 (AMBA) 是警报定义的中心存储库，客户和合作伙伴可以使用这些存储库通过采用 Azure Monitor 来改善其可观测性体验。

卓越运营清单

请参阅完整的一组建议。

卓越运营清单