Apollo-11：轻量级任务调度监控与告警系统实践拆解

Apollo-11 是我过去几周在团队内部推进的一个终端级监控与告警系统的项目代号。刚看到这个名字时你可能第一反应是登月，实际上我们就是希望它足够稳、足够可控，所以才借了这个代号。它解决的核心问题很明确：当我们把一套分布式的任务调度系统跑起来之后，发现传统监控工具要么太重、要么粒度不够，团队临时需要一个能自定义任务编排、实时采集指标、按规则自动告警的轻量终端控制面板。于是 Apollo-11 就诞生了。它不复杂，但设计上很讲究，适合正在做中小型中间件、内部工具系统或者对实时监控有定制需求的团队参考。

这个项目从需求梳理到完成第一版可用的 Demo，大概用了两周的空闲时间，期间踩了不少坑，也推翻过一次架构。我不想把它包装成一副什么都设计好了的样子，事实上它的很多取舍都是在真实故障和使用反馈里逼出来的。今天这篇内容，我会把它从思路到落地再到上线后的 bug 排查记录完整拆开，尽量给到可复现的方案和过程。文章里涉及的具体代码用伪代码和真实语言片段混写，核心逻辑保持一致。

1. 项目初衷与整体设计思路

1.1 为什么选择“Apollo-11”这个名字

取名这件事可以很随意，但在我们团队内部却花了不少时间讨论。最初的名字是“watchdog-monitor”，后来同事说太无聊，换成了“lotus”，又觉得和品牌空壳没有关联。最后我拍板叫 Apollo-11，原因很简单：我们做的是一个需要像登月一样“每一步都必须可观测、可回滚、可预期”的调度监控系统。任务调度、失败重试、数据上报，每一条链路都不能有黑盒。

实际上这个名字最终也影响了我们的设计风格。Apollo-11 不是一个普通的 Elastic Stack 或者 Prometheus + Grafana 的组合，它是一套我们自己的轻量方案。我们明确限定了它的边界：不采集主机层面的所有指标，只围绕调度任务做生命周期追踪；不上埋点 SDK，只用消息总线上报事件；不接复杂权限系统，只做简单角色区分。名字本身像是一个定心丸，提醒整个项目要保持可控的复杂度，不要野心过大。

1.2 架构选型：三个核心服务的取舍

一开始我们参考的是某个开源任务调度系统的监控插件，但那个方案依赖一个重量级消息队列，团队里没有人专职维护它。后来我们重新评估，把需求压缩成了三块：任务状态流转的管理、实时指标的计算与存储、告警规则的判定与推送。针对这三块，我们分别做了选型。

任务状态流转我们直接用 Go 写了一个轻量的事件总线，本质上就是带订阅分发的内存通道，并配一个简单的持久化文件做故障恢复。这里没有选择 Kafka 或者 NATS，不是它们不好，而是因为我们的任务量级每天只有几十万条事件，单机内存足够扛得住，Kafka 反而会引入分区、副本这些运维负担。实时指标计算我们用 Redis 的 Hash 和 Sorted Set 做时间窗口聚合，一开始没想用时序数据库，因为不想再部署一个独立的服务，而且我们需要的指标维度很固定，用 Redis 做秒级窗口完全够用。告警判定我们用了一个单独的可执行程序，每十秒拉取一次 Redis 聚合结果，再和预先配置的规则做比对，命中之后走钉钉机器人和邮件通知。

这套架构在运维上非常省心，总共三个进程：调度主进程、事件总线进程、告警判定进程，没有额外的集群依赖。对一个小团队来说，能少维护一个中间件，就已经值回票价了。后面我会详细说每个模块的实现细节，包括为什么选择这种结构而不是更复杂的容器化部署。

1.3 目录结构与模块边界

Apollo-11 的代码仓库结构也因架构选型变得很清晰。根目录下面主要分为 apollo-core（事件总线核心）、apollo-agent（采集侧逻辑）、apollo-alert（告警规则引擎）、apollo-ctl（命令行交互工具）。这个拆分是实打实从使用场景里长出来的，不是预先设计得很完美然后照着写代码。

• apollo-core 是整个项目的心脏，负责事件接收、去重、顺序保证和状态快照。
• apollo-agent 需要嵌入到改造成本最小的位置，所以我们没有做一个独立收集代理，而是直接以 SDK 的形式注入到任务执行器的回调里。这样任何语言只要实现了上报接口，就能接入 Apollo-11。
• apollo-alert 是独立程序，通过订阅 Redis 频道拿到实时变化，同时读取静态规则文件，判定后推送。
• apollo-ctl 是给工程师手工查询用的终端命令，后续也跑在 Web 面板后面。

模块边界一旦清晰，很多冲突就提前消解掉了。比如说谁负责重试、谁负责去重这类问题，定义清楚之后开发的时候完全没有互相等对方的情况。

2. 核心模块拆分与关键技术细节

2.1 任务编排引擎的设计

任务编排不是一个新词，但真正落地时会发现难点都在状态设计上。任务的全生命周期在我这里拆成了 pending、running、success、failed、timeout、manual_blocked 六种状态。每一种状态之间的迁移路径必须保证唯一性，简单说就是我可以允许一个任务从 running 变成 failed，但不允许从 failed 再变成 success，除非是人工强制修正。这个规则保证了上报阶段乱序到达时不会污染状态机。

实现方式说穿了也很基础，就是用事件总线里带一个协程安全的状态映射表。收到一个新事件时，先查当前状态是否允许迁移，允许才走后续逻辑，不允许就直接丢弃并记录一条 warning。这里有一个重要的技巧：每个事件都必须携带一个递增序列号，而不是单纯依靠时间戳。序列号是幂等判断的基础，如果同一个任务 ID 带着相同序列号的事件重复出现，我们直接忽略，这样即使 agent 端因为网络抖动重发了消息，也不会导致状态被重复计算。

你可能会问为什么不用现成的状态机库，比如 go-statechart？原因在于我们的迁移规则简单，而且六种状态里大多数是线性流转，用库反而要额外学一套 DSL。直接写映射表，一个二维 map 就能搞定，团队里任何一个人维护起来都没什么心智负担。

2.2 实时事件总线与推送通道

事件总线是整个系统里最容易出性能瓶颈的地方。我们最开始用一个全局的 Go channel 来传递所有事件，结果运行到第三天就出现消费者积压，因为告警程序和本地日志持久化都挂在同一个 channel 上。后来我改成了按任务 ID 分片，也就是每个任务有自己独立的事件队列，消费者可以并发处理不同任务的事件，而对于同一个任务的事件则严格串行。这样既解决了并发安全问题，又不会让某一个大任务的事件阻塞其他任务。

分片队列实现在 Go 里非常自然，用一个 map 维护 taskID 到 chan 的映射，结合 sync.Map 保证并发读写安全。新任务进来时创建 channel，任务结束并确定所有事件都被消费完就删除 channel，这样就避免了 channel 泄漏。还有一个细节是关于 Backpressure 的处理，当某个任务的 channel 满时，我们不是简单的丢弃事件，而是交给一个 holding area 暂存，并触发一个限制信号，让 agent 端放慢上报速度。这种策略比丢数据或者粗暴阻塞要平滑很多。

推送通道我们最终选了 WebSocket 而不是 Server-Sent Events，原因有两个：一是告警和任务状态更新需要支持双向确认，WebSocket 方便 client 回传 ack；二是内部工具控制台的在线连接数量很少，WebSocket 的连接成本完全可以忽略。我们给 WebSocket 设计了一个简单心跳和重连机制，十秒一次 ping，连续三次没 pong 就主动断开，让客户端走重连逻辑。

2.3 指标采集与存储层

指标采集最初的任务是想知道每个任务的平均耗时、失败率、队列积压数。这三个指标不需要精确到每个请求，只要能在分钟级看到趋势就好，所以我们就采用时间窗口聚合。窗口定为十秒一个桶，每个桶里用 Redis 的 Hash 保存 sum、count、max、min 四个字段。这样一个实时计算逻辑只需要几十行代码，完全没有引入复杂流计算框架的必要。

这里有一个关键的计算模式可以分享。当需要计算“当前这一分钟内任务的平均耗时”时，不会直接在多个 Hash 上做跨窗口计算，而是在写入时同步维护一个一分钟的滚动窗口队列。队列里存的不是原始值，而是一个小结构体，累加器和计数器。这样在查询的时候直接拿累加器除以计数器就行，时间复杂度是 O(1)。代价就是可能需要多占几百 KB 内存，但对于我们的量级来说完全可以忽略。

除了这些业务指标，我们还采集了 agent 侧的“心跳迟到率”。简单说就是每个任务执行器应该在启动和结束时各上报一条心跳，如果心跳时间和调度时间差超过某个阈值，就判定为迟到。这个指标非常关键，它经常比业务指标更早暴露网络或者执行环境的问题。

2.4 告警面板与规则引擎

告警面板最初被设计成一个独立网页，但后来发现最频繁使用它的居然是运维值班同事，他们更希望在终端里就能看到异常状态。所以我们同时保留了一个轻量 TUI 界面和 Web 版。Web 版完全走 WebSocket 推送，同一份状态数据直接转发；TUI 版则直接订阅 Redis 频道。两种界面共用一套告警规则，没有各自为政。

规则引擎本身用的是 JSON 配置文件，每条规则包含任务名前缀、统计窗口、触发阈值、持续时间、通知目标五个字段。这样一个看起来非常简单的设计，实际上解决了我们团队里“只会写 SQL 不会写 Ruby”的同事能自主配告警的问题。告警表达式的解析我们写了一个很小的语法解析器，支持大于、小于、百分比变化这类比较运算，完成一个基础版本不过三百行代码。

比较大的坑是告警风暴。因为我们设定了每个任务失败都会触发一次告警，某次上游程序 bug 导致三百多个任务几乎同时失败，结果钉钉机器人刷屏刷了十分钟。后来加了聚合窗口，相同前缀任务在一分钟内的失败告警只推一条，并把失败数量带到消息里。

3. 从零到一：实操实现与关键代码

3.1 准备环境与初始化依赖

以下是我们在项目最开始进行的依赖初始化操作。如果你也想复刻这个项目，会用到 Go 1.20 以上版本、Redis 6.2，以及一个支持 WebSocket 的任意前端框架。我们后端统一用 Go，前端控制台用 Vue3，主要是团队成员更熟悉这套组合。

# 初始化 Go 模块 go mod init apollo-11 # 安装必要的依赖 go get github.com/go-redis/redis/v9 go get github.com/gorilla/websocket go get github.com/spf13/cobra # 如果还需要做 TUI 界面 go get github.com/charmbracelet/bubbletea

项目启动之后，第一件事不是写代码，而是把 Redis 的键命名规范定下来。我们用apollo:task:{taskID}:events存事件流，用apollo:metric:{taskName}:window存每个时间窗口的聚合值，用apollo:alert:rule存告警规则哈希。提前定规范能避免后续联调时因为 key 混乱导致的互相覆盖，这个成本相当低但收益非常高。

3.2 事件总线的核心代码

事件总线的代码是整个项目最值得复盘的部分。先看事件定义和总线接口：

type Event struct { TaskID string `json:"taskID"` Sequence int64 `json:"sequence"` Status string `json:"status"` Ts int64 `json:"ts"` Extra map[string]interface{} `json:"extra,omitempty"` } type Bus struct { mu sync.RWMutex queues map[string]chan *Event stateMap map[string]string // taskID -> current status seqMap map[string]int64 // taskID -> last sequence }

事件上报接口最关键的是幂等和顺序校验：

func (b *Bus) Publish(ctx context.Context, evt *Event) error { b.mu.RLock() lastSeq, exists := b.seqMap[evt.TaskID] b.mu.RUnlock() if exists && evt.Sequence <= lastSeq { // 重复事件，直接忽略 return nil } // 状态迁移校验 if !validTransition(b.stateMap[evt.TaskID], evt.Status) { log.Warnf("invalid transition: %s -> %s", b.stateMap[evt.TaskID], evt.Status) return nil } ch := b.getOrCreateQueue(evt.TaskID) select { case ch <- evt: b.updateState(evt) return nil default: // 队列满了，进入 holding area 并触发背压 b.hold(evt) return ErrBackpressure } }

这里有个细节值得说一下：我们在触发背压时，是先把事件放入一个临时结构，然后通知调用方“请放慢上报”。调用方收到 ErrBackpressure 后会做指数退避重试。这样整个系统在负载高的时候不是崩溃，而是平滑降级。实际跑下来效果很符合预期，最严重时只是事件延迟了 200ms 左右，没有丢失一条。

3.3 时间窗口聚合的参数设置与计算

聚合窗口参数直接决定了监控数据的实时粒度。我们经过反复测试最后选了十秒窗口，因为如果窗口太短，比如一秒，Redis 读写压力会明显变大，而且很多任务耗时本来就大于一秒，看不出趋势；如果窗口太长，比如一分钟，告警的反馈速度又太慢。十秒正好能覆盖绝大多数短任务，而且对长任务也能快速反映堆积迹象。

聚合的核心代码是每一条任务结束事件都会调用一个 UpdateMetric 函数：

func UpdateMetric(rdb *redis.Client, taskName string, costMs int64, ts time.Time) error { windowKey := fmt.Sprintf("apollo:metric:%s:window", taskName) hourKey := fmt.Sprintf("apollo:metric:%s:hour", taskName) pipe := rdb.TxPipeline() // 当前十秒窗口的统计 pipe.Incr(rdb.HKey(windowKey, "count").Context, windowKey, "count") // 这里用 Lua 脚本保证原子性 // 维护一个一分钟滚动 window，记录总耗时和总次数 _, err := pipe.Exec() return err }

如果不用 Lua 脚本来保证读写原子性，很容易出现并发下少计数的情况。我们是把五分钟滚动窗口维护在一个独立的 Sorted Set 里，每个窗口结束时间作为 score，value 是小 JSON 字符串，里面包含 count 和 totalCost。查询当前五分钟均值时，只需要取出 score 介于 start 和 end 的所有 member 做累加。这种方法写起来很简单，但不适合超大流量场景，因为每次查询都要遍历窗口内所有 member。按我们的精度要求完全没有问题。

3.4 告警规则配置与通知推送实现

告警规则的配置我们采用了一个人可读的文本格式，而不直接写 JSON。这样做的首要原因是避免逗号括号错误导致整个配置解析失败。我们定义了一套极简语法：

RULE task_prefix: "batch_" WINDOW: 5m THRESHOLD: failed_rate > 0.05 DURATION: 2m NOTIFY: dingtalk, email

解析后的规则会编译成内部的规则表达式树。判定时，程序每隔十秒拉取一次聚合指标，然后执行表达式树。如果连续多个周期都命中，并且到达 DURATION 设定的持续时间，就触发通知。引入 DURATION 是为了防止毛刺导致误报，只要某一次指标恢复正常，连续计数就会清零。

通知推送我们封装了统一的 Notifier 接口，目前实现了 DingTalkNotifier 和 EmailNotifier。丁丁这块的推送逻辑很简单，就是构造一个带标题和文本的 JSON 发到机器人地址。但要注意做好频率控制，否则一个状态频繁切换会被重复提醒。发送之前我们先用 Redis 的 SetNX 加一把两分钟的锁，同一个告警 ID 在两分钟内只发一次，这样能有效防抖。

4. 上线两周后：踩坑实录与排查手册

4.1 内存持续上涨但没有内存泄漏

上线第一周最让人困惑的是事件总线进程的 RSS 内存从 250MB 慢慢涨到了接近 800MB。我们用 Go 的 pprof 看 heap profile，发现大量对象被挂在holding area里。查根因发现，是 agent 上报任务的频率设计有缺陷。正常情况下任务事件应该迅速消费掉，但进入 holding area 的场景是因为 channel 满之后触发背压，而 agent 端指数退避重试的时间上限是十秒。可一旦任务执行器因为批处理启动慢，事件就会在数十秒内持续积压，holding area 一直没有机会清理。

解决办法是给 holding area 增加一个上限容量，超过之后不再无限暂存，而是丢弃事件并记录一条 drop 日志，同时立即触发一个高风险告警。任何系统都不该用无限内存换数据完整性，明确降级边界比假装不丢数据更靠谱。

4.2 WebSocket 连接被中间层截断

前端控制台差不多每过 45 秒就掉一次线。排查发现是控制台到服务端之间隔着一层 HTTP 反向代理，代理默认空闲超时时间是 60 秒，我们的心跳间隔虽然只有十秒，但代理只在数据传输时刷新超时，WebSocket 的 ping 帧被代理当成了控制帧没有透传，导致假死连接被断开。

最终处理是我们在业务层设置了一个强制心跳消息，而不是依赖协议层的 ping/pong。也就是说在 WebSocket 的 JSON 消息里，每十五秒发送一条{"type":"heartbeat"}，代理层看到是一个真正的数据传输，就会刷新超时计时。改完之后连续开了一整天，没有再发生掉线。

4.3 时间窗口聚合的数据毛刺问题

告警面板在某些任务上出现过 polling 频率极高的现象，排查发现是时间窗口聚合的数据偶尔会多算一次或漏算一次。原因出在 Redis 的键过期设置上，我们给十秒窗口设置了 60 秒过期，理论上足够，但实际上有的任务执行跨过了窗口边界，结束事件被归到了下一个窗口，而下一个窗口的计数在上一个窗口过期前还没有累积到足够样本，导致平均值计算被拉偏。

修正方式是改用固定时间片，也就是时间戳按十秒对齐后再写入，而不是事件到达的时刻。听起来差别不大，但在高峰并发时能显著减少跨窗口的事件错位。经过修正后，毛刺问题基本消失。

4.4 快速排查速查表

我把上线后遇到的几类典型问题整理成了排查表格，这对于没有专职运维的团队非常实用：

5. 一些经验总结和可扩展的方向

5.1 事后验证有效的设计决策

项目迭代到现在，我复盘了最初几个关键设计决策，发现有两项是收益最大的。第一个是“先定义状态迁移矩阵，再写业务逻辑”。虽然这句听起来像软件工程教科书，但落地时确实让很多潜在的乱序问题在编码阶段就被规避了。第二个是“监控系统本身也必须可监控”。我们可以通过 Apollo-11 的告警去监控其他生产任务，但 Apollo-11 自身如果出问题，只能靠日志。于是程序中专门埋了心跳指标，每五分钟上报一次自身状态，这样至少不会出现监控先挂了而不自知的情况。

从反面来看，让我再选一次的话，会在第一天就把告警聚合频率限制做进去。这个功能是上线后最紧急的补丁，如果前置设计，能省下不少半夜处理刷屏的精力。

5.2 后续可以继续扩展的方向

Apollo-11 当前的定位是轻量级任务监控面板，如果后续有更多团队接入，第一优先考虑增加多租户隔离。每套监控数据按照团队维度隔离，避免不同项目之间的任务名互相冲突。第二是支持更多通知渠道，比如企业微信和短信服务，这会涉及更复杂的频率控制和模板管理。第三是把告警规则从静态文件改成动态配置界面，配合权限控制流动起来。

不过这些扩展会带来系统复杂度上升，所以后续推进时我会额外谨慎，尽量保持它作为轻量系统的核心定位不变。

最后分享一个小技巧：在给监控系统设计告警规则时，不要一开始就追求“全而细”，先挑最常发生的三种故障场景配置规则，跑通之后再逐步加。你自己写出来的告警规则如果还没有真正触发过，它大概率是不好用的。我们就是靠这条经验，避免了很多无效告警规则带来的噪音。