一、监控体系概述：为什么需要持续监控、监控的黄金信号、监控与可观测性的区别

大家好，我是你们的老朋友。今天咱们聊聊监控体系的开篇——为什么你的系统离不开持续监控，以及那些被无数大厂验证过的黄金信号到底是什么。嗯，这部分内容我讲了很多次，但每次都有新感悟。

1.1 为什么需要持续监控？——别等用户骂上门才醒

先问大家一个问题：你的系统真的健康吗？

很多团队觉得“服务能跑就行”，结果呢？用户投诉了才发现数据库连接池满了，老板拍桌子了才知道缓存雪崩了。我经历过一次刻骨铭心的教训：某次大促，监控只配了CPU和内存，结果流量突增时，线程池耗尽导致接口超时，整整15分钟没人发现。等我们反应过来，用户已经骂了上千条。

持续监控不是锦上添花，是保命符。它的核心价值有三点：

• 提前发现隐患：比如内存泄漏，监控能让你在OOM前就收到告警
• 快速定位根因：出问题时，监控数据就是你的“黑匣子”
• 量化服务质量：没有数据，你怎么跟老板说“系统变好了”？

1.2 监控的黄金信号——Google SRE 的四大法宝

说到监控指标，绕不开 Google SRE 提出的四大黄金信号。说白了，这四样东西能覆盖90%的故障场景。我建议你把它刻在脑子里。

黄金信号	定义	我踩过的坑
延迟（Latency）	请求从发出到收到响应的时间	只看平均延迟会骗人，P99才是真相
流量（Traffic）	系统承受的请求量（QPS、RPS、带宽）	流量突增时，别忘了看来源分布
错误（Errors）	请求失败的比率（HTTP 5xx、业务错误码）	隐式错误最可怕——返回200但数据是错的
饱和度（Saturation）	资源被用掉的程度（CPU、内存、磁盘、连接数）	饱和度到100%才告警？晚了！

延迟：别被平均值骗了

为什么我强调P99？举个例子：某接口平均延迟50ms，看起来不错吧？但P99可能是2秒。这意味着1%的用户在忍受卡顿。我在项目中遇到过，某次优化只盯着平均值，结果P99飙到5秒都没发现，用户反馈“系统好慢”才去查。嗯，从那以后我告警阈值全改成P99了。

流量：不只是看数字

流量监控不只是看QPS高低。你得知道流量从哪来、到哪去。有一次我发现QPS突然翻倍，以为是好事，结果一查是爬虫在刷接口。所以，流量监控要配合来源分析，不然你连被攻击了都不知道。

错误：小心“假成功”

HTTP 200不代表一切正常。我记得有个支付服务，接口永远返回200，但业务状态码是“余额不足”。这种隐式错误最坑人——监控没告警，用户却投诉了。所以，错误监控一定要深入到业务层面。

饱和度：留有余地

饱和度到100%才告警？那叫事后诸葛亮。我建议阈值设在70%-80%。比如CPU到80%就预警，留出时间扩容。我曾经因为磁盘使用率到95%才处理，结果半夜IO hang了，整个集群雪崩。教训啊。

1.3 监控与可观测性的区别——别把“看仪表盘”当成“懂系统”

很多人把监控和可观测性混为一谈。其实它们有本质区别。我打个比方：

• 监控：你知道车的水温表、油表、速度表。出问题时，你看到“水温过高”。
• 可观测性：你不仅能看表，还能打开引擎盖，查冷却液、风扇、传感器。你能问“为什么水温过高？”

说白了，监控是“已知的未知”——你提前定义了要关注什么指标。可观测性是“未知的未知”——你可以在出问题时，通过数据探索根因。

维度	监控	可观测性
目标	发现已知问题	探索未知问题
数据来源	预定义的指标（Metrics）	指标+日志+链路追踪（三大支柱）
典型工具	Prometheus + Grafana	Datadog、SkyWalking、ELK
使用场景	“CPU高了，告警！”	“为什么这个请求慢了？查一下链路”

为什么可观测性更高级？

你想想看，监控只能告诉你“出事了”，但可观测性能告诉你“哪里出事了、为什么出事”。举个例子：

• 监控：延迟P99升高了，告警！
• 可观测性：通过链路追踪发现，是数据库查询慢，进一步看日志，发现是某个SQL没走索引。

我建议团队先做好监控，再逐步建设可观测性。别一上来就搞全链路追踪，成本高、收益低。先把四大黄金信号配好，再考虑日志和链路。

1.4 总结——从“被动救火”到“主动预防”

好了，这一章的核心就这些。我总结一下：

• 持续监控是系统稳定性的基石，别等用户骂了才行动
• 四大黄金信号（延迟、流量、错误、饱和度）是监控的必修课，每个都要配好阈值
• 监控和可观测性不是一回事，先做好监控，再追求可观测性

下一章，我会带你实战搭建一套监控体系。嗯，到时候我会分享一些我亲手踩过的坑，保证让你少走弯路。