3. 生产系统性能与成本基线建立

在Azure生产系统中，性能优化与成本治理之所以经常陷入“凭感觉调优”的困境，根本原因在于缺少一条可量化、可对比、可追溯的基线。基线不是一次性的快照，而是一组随时间滚动更新的参照系：它告诉你“正常”长什么样，从而让任何偏离都能被快速识别为异常或优化机会。本节围绕三类数据源——Azure Monitor Metrics、Log Analytics与Application Insights——说明如何采集性能计数器与依赖调用数据，定义SLO/SLI，并最终把性能指标与成本指标关联成一条可运营的基线。

三类数据源的分工与采集对象

Azure Monitor Metrics是平台级指标，天然适合采集基础设施与PaaS资源的数值型时序数据，例如虚拟机的CPU百分比、可用内存字节数、磁盘IOPS、网络进出流量，以及App Service的Http5xx计数、SQL Database的DTU/CPU百分比、Storage的Transactions与SuccessE2ELatency。它的优势是采集开销低、保留期长、支持近实时告警，缺点是维度有限、无法承载自定义业务语义。

Log Analytics面向日志与结构化事件，适合采集Metrics覆盖不到的细节：请求级日志、异常堆栈、依赖调用的目标地址与耗时、自定义事件、以及通过KQL聚合出的派生指标。它承担“下钻定位”的角色——当Metrics显示某时段延迟升高时，Log Analytics能回答“是哪个依赖、哪个实例、哪类请求导致的”。

Application Insights则聚焦应用层可观测性，自动采集请求速率、响应时间、失败率、依赖调用（SQL、HTTP、Redis、Service Bus等）的持续时间与成功率，并支持分布式追踪。它把一次用户请求在多个服务间的调用链串起来，是定义SLI最直接的数据来源。

SLI与SLO的定义方法

SLI是“测量什么”，SLO是“目标是多少”。定义SLI时必须明确四要素：测量对象、测量窗口、计算方式、数据来源。以订单服务为例，一个可落地的SLI定义是：在过去5分钟窗口内，Application Insights中requests表里success == true的请求数除以总请求数，得到可用性SLI；延迟SLI则取同一窗口内duration的P95值。SLO可设为可用性≥99.9%、P95延迟≤800ms。这两个数值是示例目标，实际应根据业务容忍度设定。

需要注意，SLI必须与用户体验对齐。CPU使用率不是SLI，它只是资源指标；用户感知的是请求成功与否、快慢如何。因此SLI应优先从Application Insights的请求与依赖数据中提取，Metrics和Log Analytics作为补充与下钻手段。

依赖调用数据的采集与解读

依赖调用是生产系统延迟与故障的主要来源。Application Insights会自动记录每次依赖调用的name（目标）、type（SQL/HTTP/Redis等）、duration、success与resultCode。通过KQL可以快速聚合出依赖健康视图：

dependencies
| where timestamp > ago(1h)
| summarize
    Calls = count(),
    FailRate = round(100.0 * countif(success == false) / count(), 2),
    P95 = percentile(duration, 95)
  by target, type
| order by P95 desc

这段查询输出每个依赖目标在过去1小时内的调用次数、失败率与P95耗时。若某个SQL依赖的P95从基线的120ms升至600ms，而失败率仍为0，说明是性能退化而非可用性故障，应优先检查数据库DTU、索引或查询计划，而不是扩容应用层。

性能与成本关联基线的建立

关联基线的核心思路是：把同一时间窗口内的性能指标与成本指标放在同一张表里，观察“每单位性能所对应的成本”。具体做法是：从Metrics取资源级成本相关指标（如DTU消耗、vCore使用、存储容量），从Application Insights取请求量与延迟，按小时对齐后计算派生指标，例如“每万次请求的DTU消耗”“每毫秒P95延迟对应的计算成本”。

一个可参考的基线记录表结构如下（字段为示例，可按实际调整）：

表中12:00时段请求量上升、P95延迟接近SLO上限、每万请求DTU从约8升至10.8，成本同步上升。这说明该时段存在“规模不经济”——请求增长带来的成本增速快于请求增速。此时应检查是否存在低效查询、缓存命中率下降或连接池争用，而不是简单扩容。

从基线到行动

基线建立后，日常运营只需关注三类信号：一是SLI跌破SLO，触发告警并下钻Log Analytics定位根因；二是性能正常但每万请求成本持续上升，说明存在效率退化，应排查查询、缓存与序列化开销；三是性能与成本同时异常，通常指向流量突增或依赖故障，需结合依赖调用数据判断是扩容还是修复。基线不是静态文档，而应随版本发布、流量结构变化和定价调整滚动更新，通常建议每月复核一次SLO目标与成本关联指标。