用于监视工作负荷性能的体系结构策略

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

如果没有性能数据，基础问题和优化机会将不受忽视，从而导致用户体验下降。

本文介绍实现多层性能度量的设计策略，这些度量可捕获延迟、吞吐量和资源行为，以建立基线并确定工作负荷的性能下降。

本文的关键策略基于可观测性的基础操作实践，如 OE：07 体系结构策略中所述，用于设计监视系统。 在《监控设计指南》中提供了关于实施监控实践的指导。 建议先查看这些资源。 本指南中的建议范围限定为性能。 有关可靠性的信息，请参阅 RE：10 体系结构策略，用于设计可靠的监视和警报策略。

定义

使用基于百分位的指标

使用百分位（p50、p95、p99）度量性能指标（例如延迟、响应时间或加载时间），而不是平均值。 平均值可能具有误导性。 如果大多数请求速度较快，但一些请求速度非常慢，则平均值将隐藏不良体验。

百分位数表明尾部行为，这对于理解用户体验非常重要。 p50 表示典型性能，p95 显示大多数用户在负载下的体验，p99 捕获最差的性能或离群值。

使用监视工具收集性能数据，并将其表示为定义时间窗口的百分点。 将这些用作监视、警报和性能分析的基线。

定义性能改进边界

定义明确的性能边界，以便确切地了解度量中包含的内容。 分解整个系统的延迟，而不是将其视为单个数字。 例如，将时间归因于边缘服务、网关、计算和依赖项的每个层，以查看实际发生延迟的位置。

将控制的内容与不控制的内容分开：代码、服务、基础结构和直接依赖项与外部因素（如客户端条件、DNS 解析、ISP 延迟或设备约束）。 这种区别可防止错误行为，并使优化侧重于可以进行更改的领域，同时仍反映完整的端到端用户体验。

评估性能问题何时以及在哪些情况下影响用户体验。 通过设计补偿这种降级，或通过系统可控制部分的改进来缓解这种下降。

按环境和用途细分信号

分段性能数据，以便每个信号反映清晰的上下文。 根据环境和目的进行区分，以避免混淆处理不同或服务于不同决策的信号。

使生产和非生产数据保持独立。 生产数据反映实际用户的影响，应推动监视和警报。 非生产数据可用于测试和优化，但将其与生产偏差结果混合，并隐藏实际问题。

将性能指标与业务指标分开。 性能指标跟踪系统行为和工作负荷运行状况，而业务指标跟踪结果。 即使它们重叠，也会将它们保留在不同的流中，以便可以单独分析和使用每个流。

创建范围限定且可操作的性能报警

警报的目标是在用户可见或业务影响之前提前检测性能下降。 在两个级别生成警报：端到端用户体验和核心内部事务，这些事务表示负载下的关键系统路径。

在每个环境中，针对目标和警报使用单个一致的数据集。 如果警报基于与性能目标不同的数据，则它们变得不可靠且难以信任。

创建可操作且明确绑定到性能结果的警报。 每个警报都应指示存在持续违规的阈值、潜在影响和所涉及的组件，以便清楚地了解调查的位置以及受影响的内容。 从标准、已知的阈值开始，然后根据观察到的系统行为和工作负荷特征随着时间的推移对其进行优化。

考虑基于运行状况模型来设置性能警报。 使用运行状况模型来表示具有多个性能信号的性能关键资源，而不是针对各个指标发出警报。 针对运行状况状态转换发出警报，以便将复合性能问题呈现为单个可操作的警报，而不是大量阈值超限警报。 Azure Monitor运行状况模型支持此模式，其中包含跨依赖项的实体级警报和分层传播。

如果无法对外部依赖项发出直接警报，请使用间接信号（如依赖项调用持续时间、错误率或超时行为）来近似于其对系统性能的影响。

监视弹性

测量系统如何响应需求变化和缩放事件。

跟踪冷启动和初始化延迟，以了解启动开销如何影响响应能力，尤其是在横向扩展事件期间。 监视横向扩展和横向扩展行为，以评估系统适应负载变化的速度，以及缩放操作是否符合需求。

跟踪一段时间内的性能

跟踪性能如何随着设计和外部因素的变化而发展。

建立表示预期系统性能的基线，然后将当前行为与它们进行比较以检测偏移，包括回归和改进。

使用运行状况模型来表示性能基线，并清楚地量化性能关键型资源的健康、降级和不正常状态。 Azure Monitor 运行状况模型支持静态阈值和随时间调整的动态基线，从而实现偏移检测自动化。

将性能更改连接到操作事件，例如部署、配置更新和缩放操作。 使用这些事件对时间线进行批注，使行为中的转变具有明确的上下文，并且可以追溯到可能的原因。

将此持续可见性用作工程决策的反馈循环。 将性能洞察注入到规划和优先化中，并将其视为常规工作的输入，而不仅仅是事件响应。

随着系统的发展，不断优化性能目标。 根据观察到的行为和使用模式调整 SLA、阈值和期望，使目标保持真实，并与实际用户体验保持一致。

收集应用程序性能数据

需要让应用程序的性能指标（例如吞吐量、延迟和完成时间）主要通过检测代码收集。

检测性能最明显的关键执行路径：关键请求流、资源密集型操作，以及外部依赖项或重试的位置。 确保端到端事务可见性，以便测量执行总时间和参与步骤。

捕获三种核心类型的性能信号：

• 聚合性能行为的指标（延迟分布、吞吐量、错误率）
• 用于理解请求路径与系统组件时间分布的跟踪数据
• 用于记录特定步骤或事件的详细执行上下文的日志

在这些信号中使用一致的元数据，以便性能数据可以在系统层和服务之间关联。

避免复制平台已经公开的较低级别的性能信号，除非需要额外的粒度来解释特定于工作负荷的行为或瓶颈。

收集资源性能数据

收集资源级性能数据，以了解基础结构组件在负载下的行为方式，以及它们如何有助于总体工作负荷性能。

每个服务都会公开特定于平台的指标，以反映其运行状况和性能特征。 使用 诊断设置 来导出此数据，以便在超出平台短期保留期后，可以进行警报监测、仪表板显示和长期分析。

收集所有资源的指标和日志。 根据预期范围跟踪计算和存储利用率，以确认预配不足不会引入延迟并降低负载下的性能。 通过查看此数据，可以通过查看 P99 使用情况并将其与资源剩余的余地进行比较来检测过度预配。

将网络流量作为资源性能的一部分进行监视。 分析子网和服务边界之间的流量流，以了解可能影响工作负荷性能的延迟、拥塞和数据传输模式。

收集数据库和存储数据

数据库和存储系统生成专门的性能信号，用于识别瓶颈、验证容量和了解工作负荷行为。 这些信号通常来自内置监视工具和系统生成的日志。

重点介绍关键性能维度：

对于数据库，请将监视扩展到特定于工作负荷的行为：

将这些信号一起使用，区分查询速度缓慢、资源饱和度和结构效率低下的情况。 这样就可以跨存储系统和数据库工作负荷进行有针对性的优化。

收集操作系统性能数据

对于基于基础结构的工作负荷，收集操作系统级指标，以了解计算资源是如何利用的，以及资源约束的发生位置。

定期采样操作系统性能计数器，以便捕获系统在负载下的时间相关行为。

使用这些信号识别操作系统级别的资源饱和度，并区分应用程序级别的低效和基础结构约束。

在必要时生成综合数据

如果系统未一致使用，则很难判断在流量返回时是否表现良好。

若要解决此问题，请使用综合事务，综合事务会通过您的系统发送自动请求。 这些模拟实际使用情况，而不会影响实际用户或数据。 这有助于使系统的各个部分保持活动状态，生成一致的性能指标，并揭示不规则使用可能会隐藏的模式（如日间问题）。

Azure 协助服务

Azure Monitor 提供了一个统一的平台，用于收集、分析和响应整个工作负荷的性能数据。 它将应用程序、基础结构和外部源中的数据聚合到通用数据平台中。

数据收集和存储：使用 Log Analytics 工作区 通过可配置 的保留策略集中性能数据。 创建多个工作区以按环境或合规性要求对数据进行分段。

运行状况建模：Azure Monitor 运行状况模型通过关联指标、日志和跟踪，帮助你定义、衡量并可视化工作负载运行状况，从而在 Azure 资源和组件范围内形成可操作的运行状况状态。

应用程序监视： Application Insights 收集应用程序级遥测数据，包括请求速率、响应时间和异常。 启用 分布式跟踪 ，以跨分布式组件关联性能。

基础结构监视：在所有 Azure 服务上启用 诊断设置 ，以收集平台日志和指标。 使用 Azure 诊断扩展 获取详细的 VM 性能数据。 浏览特定平台的遥测选项。 例如，Kubernetes 群集通过 Prometheus 集成发出丰富的性能遥测数据。

数据库和存储：Azure Monitor 为 Azure SQL 数据库、MySQL、PostgreSQL 和存储服务提供内置监视。 Azure 存储分析跟踪关键绩效指标，例如 Blob、表和队列存储的吞吐量和延迟。

警报和分析：创建具有可自定义阈值、时间窗口和操作（电子邮件、Webhook、Azure Functions）的警报规则。 使用 Azure Monitor 日志交叉查询并关联性能数据。 有关定价详细信息，请参阅 Azure Monitor 定价。

示例

• 基线高可用性区域冗余应用服务 Web 应用程序
• 在 Azure Kubernetes 服务 （AKS） 中监视微服务应用程序
• 监视 Azure 平台登陆区域组件

相关链接

• 平台指标
• 诊断设置
• 审核日志

性能效率清单

请参阅完整的建议集。