1. 监控体系总览：为什么需要监控？监控的黄金信号

大家好，我是这次课程的主讲。在调度系统这个领域摸爬滚打了十几年，踩过的坑比走过的路还多。今天咱们聊聊监控体系总览——说白了，就是回答两个问题：为什么要监控？以及到底该监控什么？

我记得刚入行那会儿，有个老前辈跟我说过一句话，我一直记到现在：「没有监控的系统，就像闭着眼睛开车。」你想想看，调度系统是业务的中枢神经，一旦出问题，影响面往往是全站的。所以，监控不是可选项，而是基础设施。

1.1 为什么需要监控？

先说说最根本的问题。很多人觉得监控就是「出问题了报警」，其实远不止这些。我个人习惯把监控的价值分成四个层次：

• 发现故障——系统挂了你能第一时间知道，而不是等用户投诉
• 定位根因——出问题后能快速缩小范围，知道是哪里出了岔子
• 容量规划——通过趋势数据预判资源瓶颈，提前扩容
• SLA 保障——量化服务质量，给业务方一个交代

我在项目中遇到过不止一次，因为监控缺失导致故障从几分钟拖到几小时。有一次调度集群的某个节点内存泄漏，因为没有设置内存使用率的告警，直到整个集群 OOM 才被发现。嗯，那次事故之后，我连夜把全量节点的资源监控补上了。

1.2 监控的黄金信号（The Four Golden Signals）

好，既然要监控，那到底该监控哪些指标？Google 的 SRE 团队总结了一套方法论，叫做「黄金信号」。一共四个维度：延迟、流量、错误、饱和度。我这些年做过的调度系统，无论规模大小，这套框架基本都能覆盖。

下面我逐个拆解，每个信号我都会结合调度系统的场景来讲。

1.2.1 延迟（Latency）

延迟，就是请求从发出到收到响应的时间。在调度系统里，这个指标尤其敏感。比如一个任务提交到调度器，到它真正被分配到 worker 执行，中间经历了多少毫秒？

我建议把延迟拆成两部分来看：

• 服务端延迟——调度器处理请求本身的时间
• 网络延迟——请求在网络传输中的耗时

为什么要拆？因为有一次我们线上发现调度延迟飙升，一开始以为是调度器性能问题，查了半天发现是某个机房的交换机出了问题。如果不拆开看，很容易被表象误导。

1.2.2 流量（Traffic）

流量，就是系统承载的请求量。对于调度系统来说，流量指标包括：

• 每秒提交的任务数（TPS）
• 同时运行的任务数（并发数）
• 队列中的等待任务数

流量监控的意义在于：它能告诉你系统当前的压力有多大。我记得有一次大促期间，流量突然暴涨到平时的 10 倍，如果没有流量监控，我们根本不知道调度器已经快扛不住了。

这里有个小技巧：流量指标最好跟历史数据做对比。比如设置一个告警规则——「当前流量超过上周同期的 200%」，这样能提前发现异常流量。

1.2.3 错误（Errors）

错误，就是请求失败的比率。但「错误」的定义需要仔细斟酌。我把它分成两类：

错误类型	说明	调度系统示例
显式错误	HTTP 5xx、超时、异常抛出	任务提交返回 503、worker 连接超时
隐式错误	返回成功但结果不对	任务被调度到错误的节点、数据丢失但无报错

显式错误好抓，隐式错误才是真正的坑。我曾经遇到过一个 case：调度器返回了 200，但任务实际上没有被执行，因为 worker 注册信息过期了。这种错误，光靠 HTTP 状态码是抓不到的，必须结合业务层面的校验。

1.2.4 饱和度（Saturation）

饱和度，就是系统资源被用到了什么程度。调度系统里常见的饱和度指标：

• CPU 使用率
• 内存使用率
• 磁盘 I/O 等待时间
• 网络带宽占用
• 线程池/连接池的活跃度

饱和度监控的核心价值在于预测。当资源使用率达到 70% 的时候，你就该开始关注了，而不是等到 100% 才报警。因为系统在接近饱和时，性能会急剧下降——这叫「拐点效应」。

我个人习惯给每个资源设两个阈值：

• 警告阈值（70%）——需要关注，准备扩容
• 严重阈值（90%）——立即处理，否则马上出问题

1.3 黄金信号在调度系统中的落地

说了这么多理论，咱们看看实际怎么用。下面这张图是我自己总结的调度系统黄金信号框架，你可以对照着搭建自己的监控体系。

1.4 一个真实的案例

最后分享一个我亲身经历的案例，帮你理解这四个信号是怎么协同工作的。

有一次，我们的调度系统在高峰期突然变慢。从延迟指标看，P99 从 200ms 飙升到了 5s。但流量指标显示 TPS 并没有明显变化。这说明问题不在请求量上，而是系统内部出了状况。

接着看错误指标，HTTP 错误率正常，但任务失败率从 0.1% 涨到了 3%。嗯，这里有问题。再查饱和度，发现数据库连接池的使用率达到了 95%。

真相大白了：数据库连接池接近饱和，导致部分任务获取连接超时，任务失败率上升。而成功获取连接的任务也因为排队等待，延迟飙升。

你看，四个信号缺一不可。如果只监控延迟，你只知道「慢了」，但不知道为什么慢。只有四个信号一起看，才能快速定位根因。