可观测性的三个层次
分布式系统的故障定位比单机复杂得多，因为一次慢查询可能横跨多个组件。完整的观测能力通常由三类数据构成：
- 指标（Metrics）：可聚合的数值，用于趋势与告警，例如 QPS、延迟分位、CPU、磁盘水位；
- 日志（Logs）：离散事件记录，用于定位具体错误，例如选举失败、连接被拒；
- 链路（Traces）：单次请求在各组件间的耗时分解，用于回答「慢在哪一段」。
三者缺一不可。只有指标会知道「变慢了」但不知道原因；只有日志会在海量文本里失去方向。
指标采集与分层
分布式数据库通常按组件暴露监控指标，例如通过标准的指标端点由 Prometheus 之类的系统周期抓取。指标应当分层组织，便于快速缩小范围：
- 业务层：QPS、写入与读取延迟分位、事务成功率、连接数；
- 计算层：SQL 解析耗时、优化器耗时、算子级别的执行耗时与内存占用；
- 存储层：Region 数量、副本同步延迟、Raft 选举次数、存储引擎读写放大；
- 资源层：CPU、内存、磁盘 IO 与容量水位、网络吞吐。
分层的好处是排查有路径可走：业务延迟上升时，先看计算层是否有算子变慢，再确认存储层是否存在副本同步滞后或热点，最后落到资源层找瓶颈。
慢查询是最直接的线索
绝大多数业务侧的「数据库变慢」最终都能归结到具体语句。慢查询日志与分析能力是必备项，关注的不应只是耗时排序，还要看：
- 执行计划是否发生退化（例如原本走索引变成全表扫描）；
- 扫描行数与返回行数的比例是否异常，比例过大通常意味着索引设计有问题；
- 同一条语句在不同时段的耗时差异，用于识别资源竞争而非语句本身的问题；
- 是否出现大事务或长事务，它们是分布式系统中最常见的隐性风险源。
实践建议：把慢查询按「语句模板」聚类，而不是逐条看。真正需要优化的往往只是少数几个模板，却能覆盖大部分耗时。
告警设计：少而准
告警的价值在于被响应。堆满屏幕的告警会迅速让人麻木，因此设计原则是少而准，且每条都可行动。
- 基于症状而非原因告警：例如「核心接口 P99 延迟超阈值」比「某台机器 CPU 高」更值得立即响应；
- 使用持续时间条件抑制抖动：短于若干分钟的瞬时波动不触发；
- 分级处理：致命告警直达值班，容量趋势类进入日报；
- 定期复盘：统计每条告警的实际处理率，长期无效的告警应删除而非保留。
容量与趋势
容量治理属于可观测性的延伸。基于历史指标做趋势外推，可以提前判断磁盘何时到达水位线、连接数何时触及上限、QPS 增长何时需要扩容。相比事后救火，提前规划扩容窗口的成本要低得多。
把观测数据真正用起来，标准只有一个：出问题时能否在几分钟内定位到根因，而不是先花几小时找线索。
| 业务层 | QPS、读写延迟分位、事务成功率、活跃连接数 |
|---|---|
| 计算层 | 解析与优化耗时、算子执行耗时、内存占用、慢查询数量 |
| 存储层 | Region 数量与分布、副本同步延迟、Raft 选举次数、读写放大 |
| 资源层 | CPU、内存、磁盘 IO 与容量水位、网络吞吐 |
| 告警原则 | 基于症状、带持续时间条件、分级响应、定期清理无效告警 |
