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

有关收集性能数据的建议

  • 项目

适用于此 Azure Well-Architected 框架性能效率清单建议：

PE：04 收集性能数据。 工作负载组件和流应提供自动、连续且有意义的指标和日志。 收集工作负载不同级别的数据，例如应用程序、平台、数据和操作系统级别。

收集性能数据是收集指标和日志的过程，这些指标和日志提供有关工作负荷性能的信息。 此数据包括数值，称为 指标。 指标描述系统在特定时间点的状态。 它还包括包含组织成记录的不同类型的数据的日志。

通过收集性能数据，可以监视和分析工作负荷的性能。 可以使用此信息来识别性能瓶颈、解决问题、优化资源分配，以及做出数据驱动的决策，以提高工作负载的整体性能效率。

如果没有数据驱动的见解，你可能不知道潜在的性能问题或优化机会。 潜在结果包括响应时间变慢、吞吐量降低、资源使用率增加，最终用户体验欠佳。 此外，由于缺少性能数据，因此难以及时诊断和排查问题，从而导致停机时间延长并降低工作效率。

定义

术语 定义
活动日志 跟踪资源管理操作的日志，例如删除资源。
应用程序日志 跟踪有关应用程序事件、错误和其他活动的信息的日志，例如使用登录和数据库连接失败。
(APM) 工具监视应用程序性能 用于监视和报告应用程序性能的工具。
代码检测 从应用程序代码的角度直接或间接捕获性能指标。 捕获的指标包括特定于语言或运行时的流指标、资源使用情况和指标。
分布式跟踪 跨分布式工作负载组件收集和关联指标。
指标接收器 指标的存储目标，用于关联时序数据进行分析。
平台日志 诊断和审核数据，包括资源日志、活动日志和审核日志。
平台指标 记录特定时间工作负荷性能的数值。
资源日志 系统生成的数据。 它提供有关系统状态的信息。
Rx/Tx 错误 网络接口上的接收错误和传输错误数。
结构化日志记录 定义有意义的格式来记录消息，通常作为键值对。

关键设计策略

性能优化要求数据根据工作负荷或流的性能目标来衡量工作负荷或流的当前性能。 需要收集适当数量和多样性的数据，以根据 性能目标衡量代码和基础结构的性能。 确保工作负荷中的每个组件和流自动生成连续且有意义的指标和日志。 需要从应用程序、平台、存储和操作系统等不同级别获取此数据。 通过全面的性能数据收集，可以全面了解性能，从而准确识别低效和改进途径。

集中性能数据

集中性能指标和日志是从各种源收集性能指标和日志并将其存储在中心位置的过程。 创建中央指标接收器和中央日志接收器。 这种集中化允许跨不同系统和组件轻松访问、分析和监视性能指标和日志。 通过集中指标和日志，可以了解工作负载的性能。 选择可聚合和存储工作负载性能指标和日志的合适平台或工具。

权衡：了解收集指标和日志的成本。 通常，收集的指标和日志越多，成本就越高。

分段性能数据

对性能数据进行分段涉及根据指标和日志的来源、用途或环境对指标和日志进行组织和分类。 例如，应将生产数据与非生产数据分开，或区分性能目标和业务指标。 分段数据有助于优化特定环境，促进故障排除，并限制性能监视中的不准确之处。 通过明确区分不同的数据类型，可以更高效地捕获、分析和响应相关指标，并更好地使工作负载运行状况与工作负载目标保持一致。 若要对性能数据进行分段，请考虑以下建议：

  • 将生产数据和非生产数据分开。 通过按环境分隔数据，可以确保对每个环境进行重点监视和优化。 在生产环境中，可以更好地识别和解决直接影响用户和业务运营的性能问题。 在非生产环境中，在部署到生产环境之前，数据分离有助于在测试阶段进行有效的故障排除和微调。

  • 在每个环境中使用一组数据。 不要将一组数据用于性能目标，将另一组数据用于与性能目标相关的警报。 使用不同的数据集会导致不准确的警报，从而损害性能监视的有效性。

  • 单独的性能目标和业务指标。 运营和开发团队使用性能目标来监视工作负载运行状况并满足业务目标。 业务指标与业务目标或客户报告相关。 在单独的数据流中捕获业务指标，即使数据直接重叠也是如此。 通过分离，可以灵活地捕获正确的数据并独立分析数据。

定义保留策略

保留策略规定性能数据应保留多长时间。 建立这些策略有助于有效地管理存储，并确保只有必要的数据可供分析。 此类策略支持更好的性能并满足合规性标准。 应为日志和指标数据配置保留策略，以便在所有环境中实现有效的故障排除和监视。 例如，日志和指标可能需要在生产环境中保留比在测试环境中保留更长的时间。 保留期应符合组织的要求和合规性法规。 决定将数据保留多长时间用于分析和审核。 存档不需要立即分析的数据。

收集应用程序性能数据

收集应用程序数据涉及监视和分析应用程序的性能指标，例如吞吐量、延迟和完成时间，这些指标主要通过检测代码收集。 应用程序性能数据提供有关应用程序的运行状况和性能的宝贵见解。 通过监视和分析性能数据，可以识别和排查问题、优化应用程序性能，并为应用程序做出明智的决策。

检测代码

检测是指嵌入代码片段或将工具集成到应用程序代码的过程。 检测的目的是在应用程序运行时捕获性能数据。 收集突出显示应用程序关键操作的指标至关重要。 关注吞吐量、延迟和完成时间等指标。 区分与业务相关的操作和不相关的操作非常重要。 对于与业务运营相关的数据，请确保其元数据的结构方式允许不同的跟踪和存储。 代码检测的主要原因是收集有关应用程序如何处理其工作负载的数据。 它提供以下优势：

  • 识别性能瓶颈： 通过跟踪 CPU 使用率和内存使用率等指标，可以识别瓶颈并相应地优化代码。

  • 评估负载下的系统行为： 可以查看应用程序在不同工作负载和压力情况下的性能。 此数据可帮助你识别与可伸缩性、并发性和资源使用相关的问题。

  • 跟踪应用程序的运行状况和可用性： 由于关键绩效指标是实时监视的，因此可以获取有关影响应用程序性能和可用性的潜在问题的警报。

  • 改善用户体验： 可以深入了解用户如何与应用程序交互。 使用此信息优化用户体验并确定需要改进的领域。

  • 规划容量并分配资源： 检测收集的性能数据可以为应用程序的资源需求提供有价值的见解。 此信息可以告知你有关规划容量和分配资源的决策。

检测代码进行性能监视时，请考虑以下策略：

  • 使用 APM 工具：APM 工具可以收集和分析性能数据，包括指标、跟踪和日志。 APM 工具提供代码级检测、事务跟踪和性能分析等功能。

  • 使用日志记录和跟踪框架：日志记录和跟踪框架是开发人员集成到其应用程序中以促进日志记录和跟踪的工具或库。 这些框架提供用于生成日志、跟踪请求，有时甚至是格式化或传输生成的数据的函数。 通过将日志记录和跟踪框架合并到代码库中，开发人员可以在运行时捕获相关数据。 数据可以包含有关运行路径、I/O 和性能的信息。

  • 自定义检测：开发人员可以添加自定义代码来收集其应用程序和工作负载独有的性能指标。 自定义检测可以测量运行时、跟踪资源使用情况或捕获特定事件。 仅当平台指标不足时，才编写自定义代码检测。 在某些情况下，平台资源可以度量应用程序的聚合甚至精细透视。 权衡是否通过使用自定义代码来重复该工作的问题，以权衡过多的代码权衡或对平台功能的依赖。

  • 捕获事务时间。 捕获事务时间与在性能监视过程中测量关键技术功能的端到端时间有关。 应用程序级指标应包括端到端事务时间。 这些事务时间应涵盖关键技术功能，例如数据库查询、外部 API 调用的响应时间和处理步骤的失败率。

  • 使用遥测标准。 请考虑使用 APM 工具检测库和围绕遥测标准构建的工具，例如 OpenTelemetry。

启用分布式跟踪

分布式跟踪是一种技术，用于跟踪和监视流经分布式系统的请求。 它允许在请求在多个服务和组件之间传输时跟踪请求的路径，从而提供有关工作负荷性能和效率的宝贵见解。 分布式跟踪对于提高性能效率非常重要，因为它有助于识别分布式系统中的瓶颈、延迟问题和优化区域。 可以通过可视化请求流来查明延迟或效率低下发生的位置，并采取适当的措施来提高性能。 按照以下步骤启用分布式跟踪：

  1. 首先检测应用程序和服务以生成跟踪数据。 使用支持分布式跟踪的库或框架，例如 OpenTelemetry。

  2. 确保跟踪信息跨服务边界传播。 通常应为每个请求传递唯一的跟踪 ID 和其他上下文信息。

  3. 设置集中式跟踪收集系统。 此系统收集并存储应用程序和服务生成的跟踪数据。

  4. 使用收集的跟踪数据可视化请求的端到端流，并分析分布式系统的性能特征。

收集应用程序日志

检测代码时，主要输出之一应该是应用程序日志。 日志记录可帮助你了解应用程序如何在各种环境中运行。 应用程序日志记录生成应用程序事件的条件。 跨所有应用程序环境收集应用程序日志。 应用程序中的相应日志条目应该为它们各自的事务捕获一个相关 ID。 相关 ID 应跨关键应用程序流（例如用户登录）关联应用程序日志事件。 使用此关联来评估目标和非功能要求上下文中关键方案的运行状况。

应使用结构化日志记录。 结构化日志记录可加快日志分析和分析速度。 它使日志更易于编制索引、查询和报告，而无需复杂。 在应用程序代码中添加和使用结构化日志记录库。 有时，日志条目可以帮助你关联无法通过其他方式进行关联的数据。

收集资源性能数据

通过收集资源性能数据，可以深入了解工作负载的运行状况和行为。 资源性能数据提供有关资源使用的信息，这是容量规划的关键。 此数据还提供对工作负荷运行状况的见解，并有助于检测问题和进行故障排除。 请考虑以下建议：

  • 收集每个资源的指标和日志。 每个 Azure 服务都有一组特定于资源功能的指标。 这些指标可帮助你了解资源的运行状况和性能。 为每个资源添加 诊断设置 ，以将指标发送到工作负荷团队在生成警报和仪表板时可以访问的位置。 指标数据可用于短期访问。 对于长期访问或从 Azure Monitor 外部的系统进行访问，请将指标数据发送到统一接收器的访问位置。

  • 使用平台工具。 从内置和集成的监视解决方案（例如 Azure Monitor Insights）中收集灵感。 此工具简化了性能操作。 在选择平台并投资自定义工具或报告时，请考虑使用平台工具。

  • 监视网络流量。 监视网络流量是指跟踪和分析跨网络路径移动的数据流和模式。 收集流量分析并监视遍历子网边界的流量。 你的目标是分析和优化网络性能。

收集数据库和存储数据

许多数据库和存储系统都提供自己的监视工具。 这些工具收集特定于这些系统的性能数据。 数据库和存储系统通常生成包含性能相关事件和指示器的日志。 收集数据库数据和存储性能数据，以便确定瓶颈、诊断问题并做出明智的决策，以提高工作负载的整体性能和可靠性。 请考虑收集以下类型的性能数据：

  • 吞吐量：吞吐量度量一段时间内从存储系统读取或写入的数据量。 吞吐量数据指示数据传输功能。

  • 延迟：延迟度量存储操作的持续时间。 延迟数据指示存储系统的响应能力。

  • IOPS (每秒 I/O 操作) ：有关存储系统每秒可以执行的读取操作或写入操作数的数据。 IOPS 数据指示存储系统的吞吐量和响应能力。

  • 容量使用：容量使用是使用的存储容量和可用容量。 容量使用数据可帮助组织规划未来的存储需求。

对于数据库，还应收集特定于数据库的指标：

  • 查询性能：有关数据库查询的执行时间、资源使用情况和效率的数据。 缓慢或低效的数据库查询可能会显著减慢工作负荷。 查找速度缓慢且运行频繁的查询。

  • 事务性能：有关数据库事务性能的数据，例如事务持续时间、并发性和锁争用。

  • 索引性能：有关数据库索引性能的数据，例如索引碎片、使用情况统计信息和查询优化。

  • 资源使用：包括 CPU、内存、磁盘空间、I/O 和网络带宽的数据。

  • 连接指标：跟踪活动、中止和失败连接数的指标。 高故障率可能表示网络问题，也可能指示数据库已达到其最大连接数。

  • 事务速率：数据库每秒运行的事务数。 事务速率的变化可能指示性能问题。

  • 错误率：指示数据库性能的数据。 高错误率可能表示存在性能问题。 收集和分析数据库错误。

(收集操作系统数据（如果适用) ）

(PaaS) 解决方案的平台即服务无需收集操作系统性能数据。 但是，如果工作负荷在虚拟机上运行， (基础结构即服务) ，则需要收集有关操作系统的性能数据。 需要了解操作系统和虚拟机的需求。 经常对操作系统性能计数器进行采样。 例如，可以每分钟对性能计数器采样一次。

至少收集有关以下性能领域的数据。

性能区域 进程或函数
CPU - (用户模式或特权模式的 CPU 使用率)
- CPU 队列长度 (等待 CPU 时间) 的进程数
进程 - 进程线程计数
- 进程句柄计数
内存 - 提交的内存
- 可用内存
- 每秒页数
- 交换空间使用情况
磁盘 - 磁盘读取
- 磁盘写入
- 磁盘吞吐量
- 磁盘空间使用情况
网络 - 网络接口吞吐量
- 网络接口 Rx/Tx 错误

验证和分析数据

性能数据应与性能目标保持一致。 数据需要完全准确地表示工作负载或流性能，因为它与性能目标相关。 例如，Web 服务的响应时间的性能目标为 500 毫秒。 将分析数据作为例行公事，因为频繁的评估可以及早检测和缓解性能问题。

  • 创建警报。 具有可操作的警报是有益的，从而能够及时识别和纠正性能问题。 这些警报应清楚地指示违反的性能阈值、潜在的业务影响以及所涉及的组件。 首先设置常见和建议的警报。 随着时间的推移，你可以根据你的特定需求修改这些条件。 这些警报的主要目标应是预测潜在的性能下降，然后再将其升级为重大问题。 如果无法为外部依赖项设置警报，请考虑设计一种方法来收集间接度量值，例如依赖项调用的持续时间。

  • 设置数据收集限制。 确定并设置所收集的数据量及其保留期的逻辑限制。 遥测有时可能会生成大量数据。 必须专注于仅捕获最重要的绩效指标，或者建立一个高效的系统，以便从性能数据中提取有意义的见解。

Azure 简化

集中、分段和保留性能数据： Azure Monitor 跨多个 Azure 和非 Azure 订阅和租户收集和聚合工作负载的每个层和组件中的数据。 它将数据存储在通用数据平台中，供一组通用工具使用，这些工具可以关联、分析、可视化和/或响应数据。

至少需要一个 Log Analytics 工作区 才能启用 Azure Monitor 日志。 可以将单个工作区用于所有数据收集。 还可以根据对性能数据进行分段的要求创建多个工作区。 它还允许定义 保留策略。

收集应用程序性能数据： Application Insights 是 Azure Monitor 的一项功能，可帮助监视应用程序的性能和可用性。 它通过收集遥测数据（例如请求速率、响应时间和异常详细信息）提供应用程序级见解。 可以为应用程序启用 Application Insights 并将其配置为收集必要的性能数据。 Application Insights 还支持 分布式跟踪。 为所有流配置分布式跟踪。 若要生成端到端事务流，请关联来自不同应用程序组件或层的事件。

性能计数器是监视应用程序性能的强大方法。 Azure 提供各种性能计数器，可用于收集有关 CPU 使用率、内存使用情况、磁盘 I/O、网络流量等的数据。 如果将应用程序配置为发出性能计数器数据，Azure Monitor 会收集并存储数据以供分析。

收集资源性能数据：大多数 Azure 服务生成提供诊断和审核信息的平台日志和指标。 通过启用诊断设置，可以指定要收集和存储的平台日志和指标。 出于关联目的，请为所有受支持的服务启用诊断，然后将日志发送到与应用程序日志相同的目标。

收集数据库和存储性能数据：Azure Monitor 允许收集 Azure 中数据库的性能数据。 可以为Azure SQL数据库、Azure Database for MySQL、Azure Database for PostgreSQL和其他数据库服务启用监视。 Azure Monitor 提供用于监视数据库性能的指标和日志，包括 CPU 使用率、内存使用和查询性能。 若要收到问题的通知，可以根据性能阈值设置警报。

Azure 为数据库提供性能建议，例如 Azure 虚拟机 上的SQL Server。 这些建议可帮助你优化数据库工作负载的性能。 其中包括有关收集性能计数器、捕获等待统计信息和在高峰时段收集性能数据的建议。

Azure 存储分析允许收集 Azure 存储服务（如 Blob 存储、表存储和队列存储）的性能数据。 可以为存储帐户启用日志记录和指标，以监视关键绩效指标，例如读/写操作数、吞吐量和延迟。

收集操作系统性能数据：使用 Azure 诊断 扩展可以从虚拟机 (VM) 收集详细的性能数据，包括 CPU、内存、磁盘 I/O 和网络流量。 可将此数据发送到 Azure Monitor 或其他存储服务进行分析和发出警报。

验证和分析性能数据：在 Azure Monitor 中，可以使用 Azure Monitor 日志从应用程序和系统收集、分析和可视化日志数据。 可以将 Azure Monitor 日志配置为从应用程序引入日志，包括应用程序级日志和基础结构日志。 通过聚合日志，可以交叉查询事件并深入了解应用程序的性能。 有关详细信息，请参阅 Azure Monitor 日志成本计算和选项和Azure Monitor 定价。

在 Azure Monitor 中，可以定义警报规则来监视特定性能指标，并根据预定义的条件触发警报。 例如，可以创建警报规则，以便在 CPU 使用率超过特定阈值或响应时间超过指定限制时通知你。 配置警报规则以向所需收件人发送通知。

创建警报规则时，可以定义确定何时触发警报的条件。 可以设置阈值、聚合方法、时间窗口和评估频率。 根据性能监视要求定义条件。 除了发送通知外，还可以指定触发警报时要执行的操作。 操作可以包括发送电子邮件、调用 Webhook 或运行 Azure 函数。 选择相应的操作以响应特定警报方案。

示例

性能效率清单

请参阅完整的建议集。

性能效率清单