你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关收集性能数据的建议
适用于此 Azure 架构良好的框架性能效率清单建议：
| PE：04 | 收集性能数据。 工作负荷组件和流应提供自动、连续且有意义的指标和日志。 在工作负荷的不同级别收集数据，例如应用程序、平台、数据和操作系统级别。 |
|---|
收集性能数据是指收集指标和日志的过程，这些内容提供有关工作负载性能的信息。 此数据包括称为指标的数字值。 指标描述特定时间点的系统状态。 它还包括包含组织到记录中的不同类型的数据的日志。
通过收集性能数据，可以监视和分析工作负载的性能。 可以使用此信息来识别性能瓶颈、排查问题、优化资源分配，并做出数据驱动的决策，从而提高工作负载的整体性能效率。
如果没有数据驱动的见解，你可能不知道潜在的性能问题或优化机会。 潜在结果包括响应时间变慢、吞吐量降低、资源使用率增加，并最终获得不理想的用户体验。 此外，缺少性能数据使得难以及时诊断和排查问题，从而延长停机时间并降低工作效率。
定义
| 术语 | 定义 |
|---|---|
| 活动日志 | 跟踪资源管理操作的日志，例如删除资源。 |
| 应用程序日志 | 跟踪有关应用程序事件、错误和其他活动的信息的日志，例如登录和数据库连接失败。 |
| 应用程序性能监视 （APM） 工具 | 用于监视和报告应用程序性能的工具。 |
| 代码检测 | 从应用程序代码的角度直接或间接捕获性能指标。 捕获的指标包括流指标、资源使用以及特定于语言或运行时的指标。 |
| 分布式跟踪 | 跨分布式工作负荷组件收集和关联指标。 |
| 指标接收器 | 指标的存储目标，用于关联时序数据进行分析。 |
| 平台日志 | 诊断和审核数据，其中包括资源日志、活动日志和审核日志。 |
| 平台指标 | 记录特定时间工作负荷性能的数值。 |
| 资源日志 | 系统生成的数据。 它提供有关系统状态的信息。 |
| Rx/Tx 错误 | 接收错误数，并在网络接口上传输错误。 |
| 结构化日志记录 | 定义有意义的格式来记录消息，通常为键值对。 |
关键设计策略
性能优化要求数据根据工作负荷的性能目标度量工作负荷的当前性能或流。 你需要收集适当的数据量和多样性，以根据性能目标衡量代码的性能和基础结构。 确保工作负荷中的每个组件和流都自动生成连续且有意义的指标和日志。 需要从各种级别（如应用程序、平台、存储和操作系统）源此数据。 综合性能数据收集允许全面了解性能，从而精确识别效率低下和改进途径。
集中收集性能数据
集中放置性能指标和日志是指从各种源收集性能指标和日志，并将其存储在一个中心位置的过程。 创建中央指标接收器和中央日志接收器。 通过这样集中放置，可以跨不同系统和组件轻松访问、分析和监视性能指标和日志。 通过集中指标和日志，可以深入了解工作负荷的性能。 选择可聚合和存储工作负荷性能指标和日志的合适平台或工具。
权衡：了解收集指标和日志的成本。 通常，收集的指标和日志越多，成本就越高。
分段性能数据
将性能数据分段涉及到根据来源、用途或环境对指标和日志进行整理和分类。 例如，应将生产数据与非生产数据分开，或区分性能目标和业务指标。 将数据分段有助于优化特定环境、简化故障排除，并限制性能监视中的不准确性。 通过保持不同数据类型之间的明确区别，可以更有效地捕获、分析和响应相关指标，并更好地将工作负荷运行状况与工作负荷目标保持一致。 若要细分性能数据，请考虑以下建议：
使生产数据和非生产数据保持独立。 通过按环境分隔数据，可以确保每个环境的集中监视和优化。 在生产环境中，可以更好地识别和解决直接影响用户和业务运营的性能问题。 在非生产环境中，在部署到生产环境之前，数据分离有助于在测试阶段进行有效的故障排除和微调。
在每个环境中使用一组数据。 不要对性能目标使用一组数据，不要对与性能目标相关的警报使用另一组数据。 使用不同的数据集会导致不准确的警报，从而破坏性能监视的有效性。
单独的性能目标和业务指标。 运营和开发团队使用性能目标来监视工作负荷运行状况并满足业务目标。 业务指标与业务目标或客户报告相关。 在单独的数据流中捕获业务指标，即使数据直接重叠也是如此。 通过分离，你可以灵活地捕获正确的数据并独立分析数据。
定义保留策略
保留策略决定应将性能数据保留多长时间。 建立这些策略有助于高效管理存储，并确保仅可访问分析必需的数据。 这类策略可提高性能并满足合规性标准。 应为日志和指标数据配置保留策略，以便在所有环境中启用有效的故障排除和监视。 例如，日志和指标可能需要在生产环境中保留的时间比测试环境中更长的时间。 保留期应符合组织的要求和合规性法规。 决定保留数据以用于分析和审核目的的时间。 存档不需要立即分析的数据。
收集应用程序性能数据
收集应用程序数据涉及监视和分析应用程序的性能指标，例如吞吐量、延迟和完成时间，主要通过检测代码收集。 应用程序性能数据提供有关应用程序的运行状况和性能的宝贵见解。 通过监视和分析性能数据，可以识别和排查问题、优化应用程序性能，并为应用程序做出明智的决策。
检测代码
检测是指将代码片段嵌入或将工具集成到应用程序代码的过程。 检测的目的是在应用程序运行时捕获性能数据。 必须收集突出显示应用程序关键操作的指标。 专注于吞吐量、延迟和完成时间等指标。 区分与业务相关的操作和不相关的操作非常重要。 对于与业务运营相关的数据，请确保其元数据采用允许不同的跟踪和存储的方式进行结构化。 代码检测的主要原因是收集有关应用程序如何处理其工作负荷的数据。 它提供了以下优点：
识别性能瓶颈： 通过跟踪 CPU 使用率和内存使用等指标，可以识别瓶颈并相应地优化代码。
评估负载下的系统行为： 可以查看应用程序在不同工作负荷和压力方案中的表现。 此数据可帮助你确定与可伸缩性、并发性和资源使用相关的问题。
跟踪应用程序运行状况和可用性： 由于关键绩效指标是实时监视的，因此可以获取有关影响应用程序性能和可用性的潜在问题的警报。
改善用户体验： 可以深入了解用户如何与应用程序交互。 使用此信息优化用户体验并识别改进领域。
规划容量和分配资源： 检测收集的性能数据可以提供对应用程序资源要求的宝贵见解。 此信息可以告知你有关规划容量和分配资源的决策。
检测用于性能监视的代码时，请考虑以下策略：
使用 APM 工具：APM 工具可以收集和分析性能数据，包括指标、跟踪和日志。 APM 工具提供代码级检测、事务跟踪和性能分析等功能。
使用日志记录和跟踪框架：日志记录和跟踪框架是开发人员集成到其应用程序中的工具或库，有助于日志记录和跟踪。 这些框架提供用于生成日志、跟踪请求的函数，有时甚至会格式化或传输生成的数据。 通过将日志记录和跟踪框架合并到代码库，开发人员可以在运行时捕获相关数据。 数据可以包含有关运行路径、I/O 和性能的信息。
自定义检测：开发人员可以添加自定义代码来收集其应用程序和工作负荷特有的性能指标。 自定义检测可以测量运行时、跟踪资源使用情况或捕获特定事件。 仅当平台指标不足时，才编写自定义代码检测。 在某些情况下，平台资源可以度量应用程序的聚合甚至精细透视。 权衡一个问题，即是使用自定义代码来重复该工作，而使用自定义代码来权衡过度的代码权衡还是依赖于平台功能。
捕获事务时间。 捕获事务时间与衡量关键技术功能作为性能监视的一部分的端到端时间有关。 应用程序级指标应包括端到端事务时间。 这些事务时间应涵盖关键技术功能，例如数据库查询、外部 API 调用的响应时间和处理步骤的失败率。
使用遥测标准。 请考虑使用围绕遥测标准构建的 APM 工具检测库和工具，例如 OpenTelemetry。
启用分布式跟踪
分布式跟踪是一种用于跟踪和监视请求流经分布式系统的技术。 它允许在请求跨多个服务和组件传输时跟踪请求的路径，从而提供对工作负荷性能和效率的宝贵见解。 分布式跟踪对于性能效率非常重要，因为它有助于识别分布式系统中的瓶颈、延迟问题和优化区域。 可以通过可视化请求流来确定延迟或效率低下的位置，并采取适当的措施来提高性能。 按照以下步骤启用分布式跟踪：
首先检测应用程序和服务以生成跟踪数据。 使用支持分布式跟踪的库或框架，例如 OpenTelemetry。
确保跟踪信息跨服务边界传播。 通常，应为每个请求传递唯一的跟踪 ID 和其他上下文信息。
设置集中式跟踪收集系统。 此系统收集和存储应用程序和服务生成的跟踪数据。
使用收集的跟踪数据可视化请求的端到端流，并分析分布式系统的性能特征。
收集应用程序日志
检测代码时，主要输出之一应该是应用程序日志。 日志记录可帮助你了解应用程序如何在各种环境中运行。 应用程序日志记录生成应用程序事件的条件。 在所有应用程序环境中收集应用程序日志。 应用程序中的相应日志条目应该为它们各自的事务捕获一个相关 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 存储 Analytics 允许为 blob 存储、表存储和队列存储等Azure 存储服务收集性能数据。 可以为存储帐户启用日志记录和指标，以监视关键绩效指标，例如读取/写入操作数、吞吐量和延迟。
收集操作系统性能数据：Azure 诊断扩展使你可以从虚拟机（VM）收集详细的性能数据，包括 CPU、内存、磁盘 I/O 和网络流量。 可以将此数据发送到 Azure Monitor 或其他存储服务进行分析和警报。
验证和分析性能数据：在 Azure Monitor 中，可以使用 Azure Monitor 日志从应用程序和系统收集、分析和可视化日志数据。 可以将 Azure Monitor 日志配置为从应用程序引入日志，包括应用程序级日志和基础结构日志。 通过聚合日志，可以跨查询事件并深入了解应用程序的性能。 有关详细信息，请参阅 Azure Monitor 日志成本计算和选项 以及 Azure Monitor 的定价。
在 Azure Monitor 中，可以定义警报规则，以基于预定义条件监视特定的性能指标和触发警报。 例如，可以创建警报规则，以便在 CPU 使用率超过特定阈值或响应时间超出指定限制时通知你。 配置警报规则以将通知发送到所需的收件人。
创建警报规则时，可以定义确定何时应触发警报的条件。 可以设置阈值、聚合方法、时间窗口和评估频率。 根据性能监视要求定义条件。 除了发送通知之外，还可以指定触发警报时要执行的操作。 操作可能包括发送电子邮件、调用 Webhook 或运行 Azure 函数。 选择相应的操作以响应特定警报方案。
示例
相关链接
性能效率清单
请参阅完整的建议集。