症状层（现象层）信息观察、系统化统计方法与业界常见统计分析指标

发表于：
字数： 4033 阅读：≈ 9分钟
总结摘要
症状层（现象层）信息观察、系统化统计方法与业界常见统计分析指标

背景 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

四层分析模型
第1层：症状层 (Symptom Layer)
   ├─ 用户感知：响应慢、超时、错误
   ├─ 业务指标：QPS下降、成功率降低
   └─ 核心问题：WHAT（发生了什么）
   
第2层：表现层 (Manifestation Layer)
   ├─ 技术指标：GC耗时、CPU使用率、线程数
   ├─ 资源状态：内存占用、连接数、文件描述符
   └─ 核心问题：WHERE（发生在哪个层面）
   
第3层：原因层 (Cause Layer)
   ├─ 直接原因：内存泄漏、锁竞争、外部依赖慢
   ├─ 触发条件：流量高峰、定时任务、数据累积
   └─ 核心问题：WHY（为什么发生）
   
第4层：根因层 (Root Cause Layer)
   ├─ 代码缺陷：资源未释放、算法效率低
   ├─ 设计缺陷：架构不合理、容量规划不足
   ├─ 流程缺陷：缺乏监控、发布不规范
   └─ 核心问题：HOW（如何从根本上避免）

1. 症状层应该观察哪些信息？

系统化的症状观察应覆盖以下五个维度，每个维度回答一个子问题：

1.1 症状表现特征（呈现出什么异常？）

类别观察要点数据来源示例
用户感知响应变慢、请求超时、错误提示、功能不可用用户反馈、前端监控、APM* 端到端追踪
业务指标QPS**/TPS** 下降、成功率/错误率升高、吞吐量下降业务监控平台、网关日志、自定义埋点
技术症状HTTP 状态码（如 5xx 激增）、慢查询日志、连接超时应用日志、APM、中间件指标

APM：Application Performance Monitoring，应用性能监控
QPS：Queries Per Second，每秒查询数；TPS：Transactions Per Second，每秒事务数

关键记录项：

  • 症状首次出现时间及持续时长
  • 严重程度（例：P99 响应时间从 200ms → 500ms）
  • 是否伴随其他症状（如错误率同步上升）

1.2 影响范围特征（影响多大范围？）

范围类型判断特征排查方向示例
全接口所有 API 同时变慢/报错共享资源（连接池、线程池）、GC*、网络分区
单接口仅特定接口异常业务逻辑、SQL、外部调用
全集群所有节点同步出现外部依赖、基础设施（如数据库）、网络
单节点仅个别节点异常流量不均、硬件故障、配置差异
特定用户/租户仅部分用户受影响数据隔离、权限、租户级配置

*GC：Garbage Collection，垃圾回收

1.3 时间模式特征（何时发生？有无规律？）

时间模式典型特征可能原因
持续性恶化指标随时间线性/指数增长资源泄漏（内存、连接）、数据累积
周期性（每日）每日固定时段出现业务高峰、定时任务
周期性（每周）每周特定日期出现周报任务、数据归档
突发性突然出现后持续或恢复流量冲击、变更事件、外部故障
间歇性时好时坏，无固定规律GC、锁竞争、网络波动

关键记录项：

  • 首次发生时间、最近一次发生时间
  • 发生频率（次/天、次/周）
  • 单次持续时间分布（最短/最长/平均）
  • 与重启、发布、扩缩容的时间关联

1.4 变化趋势特征（如何变化？）

趋势类型数学特征典型场景
线性增长( y = a + b \cdot t )稳定速率泄漏（如每秒漏 10 个连接）
指数增长( y = a \cdot e^{b t} )雪崩效应、递归泄漏
阶梯增长突变后稳定配置触达上限、版本变更
波动增长周期性起伏 + 整体上升业务周期性增长 + 累积效应
平稳无明显趋势正常状态

1.5 环境上下文（当时发生了什么？）

  • 变更事件：近期发布、配置变更、扩缩容、基础设施变更（如宿主机迁移）
  • 流量特征：总流量变化、峰值流量、流量来源分布（如某地区突增）
  • 依赖状态：下游服务健康状态、数据库/缓存负载、消息队列积压
  • 资源环境：容器/主机 CPU/内存/磁盘/网络水位

2. 如何系统化统计这些现象信息？

系统化统计的目标是将零散的观察转化为可量化、可对比、可追溯的数据。分为三个步骤：

2.1 建立症状记录规范

为每个症状创建一条记录，至少包含：

  • 时间戳（精确到秒级）
  • 症状类型（预定义枚举：响应慢/超时/错误/不可用等）
  • 关联实体（接口名/节点名/用户ID等）
  • 量化数值（如响应时间、错误率）
  • 环境快照（变更ID、流量水位等）

2.2 量化描述方法

对每个症状，从以下维度计算统计量：

量化维度统计量示例说明
频率频数、发生率（如某错误码在总请求中的占比）症状出现的次数或比例
严重程度均值、中位数、分位数（P50/P90/P99）如响应时间分布
持续时间min、max、avg、标准差单次症状持续的时长
累积效应趋势斜率、增长倍数（如内存从 2GB→4GB）评估恶化速度

2.3 统计描述方法

（1）频数分布分析

统计各症状或错误码出现的次数及频率，绘制帕累托图（Pareto Chart），优先解决累计占比达 80% 的高频症状。

（2）集中趋势与离散程度

数据类型推荐统计量适用场景举例
近似正态分布均值 ± 标准差CPU 使用率、内存使用率
偏态分布（常见）中位数 + 四分位数（P25, P75）响应时间、GC 耗时
分类数据频数、百分比、众数错误类型分布

（3）趋势分析

  • 时间序列分解：将指标拆解为趋势项 + 周期项 + 残差（可用移动平均或 STL 算法）
  • 环比/同比：与前一分钟/小时/天对比，或与去年同期对比
  • 移动平均：平滑短期波动（如取 5 分钟滑动平均），凸显长期趋势

（4）相关性初步判断

在症状层阶段，无需进行严格的相关分析，但可通过图形叠加快速识别关联：

  • 将响应时间曲线与 GC 耗时曲线在同一时间轴叠加
  • 将错误率曲线与流量曲线叠加
  • 观察指标同步变化的时间点

3. 业界常见统计分析信息（指标与方法）

在症状层，业界通常会关注以下统计分析信息，用于快速评估服务健康状况和异常特征。

3.1 核心业务与服务质量指标

指标类别常见统计量说明
吞吐量QPS、TPS、每秒请求字节数服务处理能力的总量
延迟P50、P90、P95、P99、P999百分位数比均值更能反映尾部延迟
错误率错误请求占比（如 5xx 比例）、失败率通常按 HTTP 状态码或业务错误码分别统计
可用性9 的个数（99.9%、99.99%）通常基于错误率与延迟阈值计算
饱和度资源使用率（CPU/内存/连接数等）表示服务接近瓶颈的程度

上述四个维度（延迟、流量、错误、饱和度）即 Google SRE 书中的 四个黄金指标（Four Golden Signals）。

3.2 应用性能统计指标

指标常见统计量适用场景
GC 相关GC 频率（次/分钟）、GC 耗时（P99）、GC 暂停时间分布Java 服务内存问题
线程池活跃线程数、队列长度、拒绝任务数线程池配置不当、死锁
连接池活跃连接数、等待获取连接耗时数据库/Redis 连接瓶颈
慢查询慢查询数量、慢查询耗时分布（P99）SQL 性能问题

3.3 时间序列异常检测统计量

方法统计量/输出说明
静态阈值阈值（如 CPU > 80%）简单但无法适应周期性
动态阈值（3σ）均值 ± 3×标准差假设正态分布，实际中常先用 Box-Cox 变换
移动平均 + 波动带滑动均值 ± 2×滑动标准差适应缓慢变化，常用于监控系统（如 Prometheus 的 holt_winters）
同比环比当前值 / 上一周期值 - 1快速发现突发变化（如流量突增 200%）

3.4 服务等级指标

术语全称与解释统计方式
SLIService Level Indicator，服务等级指标具体量化值，如“99% 的请求延迟 < 200ms”中的延迟实际分布
SLOService Level Objective，服务等级目标目标值，如“P99 延迟 ≤ 200ms”
SLAService Level Agreement，服务等级协议通常包含 SLO 及未达标的后果
ApdexApplication Performance Index，应用性能指数将响应时间分为满意、可容忍、失望三类，计算综合得分（0~1）

在症状层分析时，常将当前 SLI 与 SLO 进行对比，若连续多个时间窗口超出 SLO，则触发告警。

3.5 常见的统计图表与分析方法

图表类型用途示例
时序折线图观察趋势、周期性、突变点CPU 使用率 vs 时间
直方图/热力图了解延迟或耗时分布响应时间直方图，观察是否存在长尾
箱线图（Boxplot）对比不同时间段或不同实例的分布比较两个版本的 P99 延迟
火焰图定位 CPU 或内存热点（偏原因层，但症状层可初步观察）哪个函数调用占用最多 CPU
自相关图（ACF）判断时间序列是否具有自相关性（辅助识别周期性）确认错误率是否存在 24 小时周期

4. 总结

症状层的系统化观察与统计是问题排查的基石。本文从观察五个维度（症状表现、影响范围、时间模式、变化趋势、环境上下文）出发，给出了量化记录规范和统计描述方法，并汇总了业界常见的统计分析信息（四个黄金指标、百分位数、Apdex、动态阈值等）。掌握这些方法，能够帮助工程师从“感觉服务有问题”转向“我清楚地知道发生了什么、何时发生、影响多大”，为后续的表现层和原因层分析打下坚实的数据基础。

5. TPS 与 QPS

1. 基本定义

术语全称含义衡量对象
QPSQueries Per Second每秒查询数单一请求/查询操作的速率，通常用于读操作
TPSTransactions Per Second每秒事务数完整业务事务的速率，一个事务可能包含多个操作（请求、数据库写、跨服务调用等）

注意：在纯查询接口且无后续写操作的场景下，QPS 和 TPS 数值上可能相等，但语义不同。很多系统（如 HTTP API）会将每个请求视为一个“事务”，此时 QPS ≈ TPS，但严格区分时仍建议按业务完整性定义。

2. 核心区别

对比维度QPSTPS
操作粒度单次查询或请求一个完整业务事务（可能包含多个请求/操作）
典型场景读接口、搜索、缓存查询、数据库 SELECT下单、支付、转账、注册流程（含写库、消息、缓存更新）
是否包含写操作通常不包含通常包含（至少有一个写操作或状态变更）
依赖范围一般只依赖单个服务或数据源可能跨多个服务、数据库、消息队列
压力测试侧重关注系统处理简单请求的吞吐能力关注系统处理复杂业务链路的吞吐能力

数据库视角的 QPS 与 TPS

在 MySQL 中，<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">QPS</font> 通常指 <font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">Com_select</font> 的每秒次数，<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">TPS</font> 指 <font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">Com_insert + Com_update + Com_delete</font> 的每秒次数（或 <font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">Com_commit</font>）。

3. 总结表（快速记忆）

特征QPSTPS
操作性质读操作为主写操作或读写混合的事务
是否改变系统状态否是
典型接口示例<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">GET /search</font>
，<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">GET /profile</font>		<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">POST /order</font>
，<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">POST /payment</font>
压力测试工具中的常用指标wrk、ab 报告的 QPSJMeter 的 Throughput（若每个 Sampler 代表一个事务）

在实际 Java 服务运维中，建议同时监控两类指标：高 QPS 接口（如商品页、列表页）和高 TPS 接口（如下单、支付），分别设置不同的告警阈值和容量规划目标。

参考资料

一文搞懂高并发性能指标：QPS、TPS、RT、并发数、吞吐量

https://zhuanlan.zhihu.com/p/337708438

知乎·考拉在树上

END