可观测体系：指标、告警与容量水位
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 8 · 压测与容量 · 第 45/49 篇 · 🚧 占位待学
上一篇：《影子体系：在生产环境安全地压测》
下一篇：《容量规划与成本：水位的艺术》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 8 · 单元 8.3
一、本文要解决的问题
系统跑起来了，怎么知道它「还剩多少余量」？出事了怎么第一时间「看见」？可观测不是装个监控软件，是设计一套指标体系：看什么指标（RED / USE）、面板怎么组织、告警怎么分级——否则要么看不见故障，要么被警报淹没。
二、知识点清单
- 三大支柱在容量治理中的分工：Metrics（水位与告警）、Logging（根因定位）、Tracing（链路耗时拆解）
- 指标选择法：RED（Rate / Errors / Duration，服务视角）与 USE（Utilization / Saturation / Errors，资源视角）
- Prometheus + Grafana 实操：Micrometer 埋点、应用 / 中间件 / 系统三层面板的组织
- 容量水位看板：QPS 水位（当前 ÷ 压测极限）、RT 趋势、错误率、线程池 / 连接池饱和度
- 告警设计：分级（提醒 / 警告 / 紧急）、收敛（聚合同源）、值班响应；「告警疲劳」的防治
三、动手实验（学习时必须真跑）
- 给示例系统接 Micrometer + Prometheus + Grafana，画「QPS / RT / 错误率 / 线程池 / 连接池」五板斧面板
- 配两级告警规则（RT 超阈值提醒、错误率超阈值紧急），压测时人为触发验证
- 压测同时观察水位面板：记录系统从 30% 到饱和各层指标的变化形态
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。