1. PSI 指标基础：压力-状态-指示器
PSI（Pressure-State-Indicator）是一套源自环境科学、后被引入系统性能监控领域的结构化度量框架。在系统监控语境下，PSI 将复杂的系统健康度拆解为三个可观测、可量化的层次：压力（Pressure）、状态（State） 和 指示器（Indicator）。这种分层模型让运维人员能够从“原因→现状→信号”的因果链中快速定位性能瓶颈。
1.1 三层模型定义
| 层次 | 英文 | 定义 | 监控示例 |
|---|---|---|---|
| 压力 | Pressure | 施加给系统的外部或内部负载强度，是性能退化的根本驱动力 | CPU 运行队列长度、磁盘 I/O 并发数、网络入向带宽利用率 |
| 状态 | State | 系统在当前压力下的瞬时健康快照，反映资源是否过载 | CPU 使用率、内存占用率、磁盘平均等待时间 |
| 指示器 | Indicator | 由压力与状态共同作用产生的可告警信号，通常带有阈值边界 | CPU 软锁检测、OOM Killer 触发次数、磁盘 I/O 超时比例 |
关键区分：压力是“输入”，状态是“当前值”，指示器是“是否越界”。三者构成一条完整的因果监控链，缺一不可。
1.2 PSI 在系统性能监控中的核心作用
PSI 框架在系统性能监控中承担以下四项核心职能：
- 因果解耦 — 将“负载高”与“系统慢”拆开分析，避免将压力直接等同于故障。
- 早期预警 — 压力层的变化通常早于状态层恶化，为告警阈值设定提供前置窗口。
- 根因定位 — 通过三层数据联动，快速区分是“请求洪峰”（压力）还是“资源泄漏”（状态）导致异常。
- 阈值校准 — 指示器阈值不再依赖经验拍脑袋，而是基于压力-状态的统计关系动态设定。
实践案例：某电商大促期间，CPU 使用率（状态）仅 65%，但运行队列长度（压力）已达 12。若只监控状态层，系统会被判定为“健康”；而 PSI 框架会立即触发压力告警，提前 3 分钟扩容，避免后续的请求堆积雪崩。
1.3 PSI 三层关系图
1.4 典型 PSI 指标映射表
以下表格列出 Linux 系统中最常见的 PSI 三层指标映射关系，帮助你在实际监控中快速对号入座：
| 资源域 | 压力指标 (P) | 状态指标 (S) | 指示器 (I) |
|---|---|---|---|
| CPU | runqueue_depth / load_avg_1m | cpu_util_percent / steal_pct | cpu_pressure_avg10 > 1.0 |
| 内存 | page_fault_rate / swap_io_rate | mem_util_percent / oom_score | memory_pressure_avg10 > 0.5 |
| 磁盘 I/O | avgqu-sz / await | iowait_pct / svctm | io_pressure_avg10 > 0.8 |
| 网络 | backlog_len / retrans_rate | bandwidth_util / drop_rate | tcp_retrans_seg > 阈值 |
常见误区：不要将压力指标直接当作告警指示器。例如 runqueue_depth 长期偏高但 CPU 使用率未饱和时，应优先排查调度器或锁竞争，而非直接触发 CPU 告警。PSI 框架要求你始终从三层联动视角做判断。
1.5 PSI 与现有监控体系的融合位置
PSI 并非替代现有监控工具（如 Prometheus、Zabbix、Datadog），而是为它们提供一套更严谨的指标分层逻辑。在架构上，PSI 通常嵌入在以下位置：
- 采集层 — 通过 /proc/pressure/ 接口或 eBPF 程序获取原始压力数据。
- 聚合层 — 将压力、状态、指示器分别存入不同的时间序列标签。
- 告警层 — 指示器阈值不再写死，而是基于压力-状态的历史分布自动计算基线。
1.6 本章小结
PSI 指标基础是整门课程的基石。你需要记住三个核心要点：
- 压力 ≠ 故障 — 压力是负载输入，状态是系统响应，指示器才是告警信号。
- 三层必须联动 — 单独看任何一层都会导致误告警或漏告警。
- 阈值设定前置窗口 — 压力层的变化比状态层早 30–120 秒，这是动态阈值校准的关键时间窗。