高可用之路‑闲聊监控指标的局限

前言

在我和 GPT 探讨了很多天的人生之后他终于说动了我，让我开启迟迟不想动笔的高可用系列。感谢 GPT 们让我从大量繁琐技术文档中解放出来有时间进行真正的思考。不过，写博客对我来说最大的收益是强制自己思考如果连博客本身都被 AI 代劳。那还不如不写，这篇文章文字 AI 含量基本为 0，纯手敲。最多参考了一些 AI 在表达上的建议。

为什么 聊监控指标

作为高可用系列的第一篇。 我原本想写一个宏大的程序大纲，但直接抛框架显得空泛。 先聚焦实际、最容易踩坑的地方——监控指标的解读错误。这几年我在 troubleshooting 中屡次因为误读监控而走入死胡同。认识到监控的局限性是高可用的必修课，因为监控是我们的“眼睛”。

监控指标反映的只是“投影”——使用者痛点①：看不到细粒度分布

监控指标通常展示采集的数据或对采集的数据进行运算。说起来，以最常见的 QPS 为例：

QPS = 请求总数 / 总时间

痛点：请求总数是全局累计。失去了机器维度的分布信息；总时间往往采用固定窗口，掩盖了秒级甚至毫秒级的波动。

这种把「机器 × 时间」二维矩阵压缩成标量的过程，就是一次投影。投影导致的信息丢失，使得我们只能看到“整体趋势”。却难以定位哪台机器在何时出现异常。

时间窗口误差带来的偏差

如果监控程序每 5 s 采样一次但因 GC、负载高等原因实际在第 6 s 才执行。而分母仍使用 5 s，则 QPS 被错误放大。

QPS = 请求总数 / 时间差

使用 Wall Clock 会受 NTP 调整影响，导致跳变；单调时钟虽能避免跳变，却仍无法保证采样任务精确间隔。从而产生不可预知的误差，话说回来，

监控指标无法衡量超出其精度的真实——使用者痛点②：秒级延迟被误判为毫秒级问题

仅记录原始数据也不一定能准确反映程序运行。因为数据本身有精度限制，以 MySQL 主从延迟 Seconds_behind_master 为例，它的粒度只能到秒：

long time_diff = - mi->rli->last_master_timestamp) - mi->clock_diff_with_master);

痛点：两个几乎相同的从库。一个取样基本为 0 秒，另一个半数取样为 1 秒，导致平均延迟相差近 500 ms。怎么说呢，实际主从延迟并没有这么大。这完全是因为指标只能回答「有没有秒级延迟」而不是「有没有毫秒级延迟」。当我们把秒级指标用于毫秒级场景时它会成为误导工具。

时钟偏差累积导致误判

clock_diff_with_master 的精度也是秒，在计算时会四舍五入。若从库时钟比主库慢 0.5 s，却被四舍五入为 1 s。 则即使真实延迟为 0 ms，监控上也会显示约 500 ms 的延迟。

监控指标受限于采集环境——使用者痛点③：容器层面的“假健康”误报

即便拥有无限精度，也难以突破采集环境本身的限制。例如在容器中计算 CPU busy 的方式：

CPU.busy = - cpuacct.usage) / 

痛点：在资源超卖情况下即使物理机 CPU 已经满载，单个容器内部看到的 CPU.busy 最多只能到达约 50%。此时我们可能错误地判断程序仍然健康。老实说，

底层硬件干预不可见

SMM中断会让内核阻塞。却不会体现在 kernel 的 user/system time 上。真实时间可能已过去百毫秒，仅通过内核层面的监控无法感知。只能依赖应用层面的超时报错来发现异常。

监控指标无法无限逼近真实——使用者痛点④：过度观测导致程序性能崩溃

案例：MySQL 使用 与 获取运行信息，这两个命令都会加锁。当监控脚本频繁执行时会严重阻塞业务 SQL，导致 TPS 从千级跌至几百甚至归零；情况下还触发主从切换，

监控程序自身的不可靠性——使用者痛点⑤：数据丢失与计算延迟导致误判趋势

现代微服务架构中。监控数据需要上报至集中式网站，再由多台计算节点进行聚合运算。如果计算节点出现宕机、GC 或阻塞，就会出现以下问题：

• 从数据滞后来看。第30分钟的数据在第31分钟才完成计算，使得第30分钟 QPS 偏低，第31分钟 QPS 偏高。
• 再看数据丢失。节点宕机导致部分采样点缺失，使趋势曲线出现异常波动。
• 整体可信度下降：运维人员难以判断是业务异常还是监控程序故障，引发错误决策。

——把握“投影”背后的局限性才能真正提高可用性

监控指标只是对真实运行状态的一种投影。由于成本与技术限制，它永远无法无限逼近完整事实。需要清晰地认识每个指标到底"测量什么""表达什么"还有"在哪些场景下失效"。只有这样才能避免以下常见误区：

• "看不到问题": 指标粒度过粗或维度压缩导致根因被隐藏。
• "过度反映问题": 指标精度不足或采样窗口不匹配，引起虚假告警。
• "被误导": 把超出指标表达范围的问题当作可靠信号，从而做出错误决策。

后续文章将逐一拆解这些局限性产生的具体问题，并提供实际经验帮助大家在高可用之路上少走弯路。

常见痛点一这方面。定位故障时只能看到整体趋势，看不到是哪台机器何时卡顿 → 导致排查时间翻倍。

常见痛点二这方面。使用秒级延迟指标判断毫秒级性能瓶颈 → 常产生误报或漏报，让 SLA 难以兑现。话说回来，

从常见痛点三来看。容器资源超卖情况下依赖容器内部 CPU 使用率 → 表面健康却埋下隐患，引发突发崩溃。

从常见痛点四来看，频繁查询 MySQL 状态导致业务吞吐骤降 → “观测即干扰”成为真正瓶颈。

从常见痛点五来看，监控网站自身故障引起数据滞后 → 运维误把网站故障当作业务异常处理。