项目名叫 rea最早源自我的一次临时救火某天凌晨三台服务器的磁盘使用率轮流触顶我一个人在终端里反复切换、逐台排查折腾了大半夜才定位到真正的问题。那种明明每台机器都能登录却看不清整体状态的憋屈让我决定写一个能把资源指标和事件信息汇总到一起的小工具。它就是 Rea一个轻量级的资源事件聚合器。也许你已经拥有一套完整的监控体系或者团队规模大到有专职的运维平台这篇文章对你的参考价值有限但如果你像我一样面对的是十几个实例、几十个服务想要用很少的维护成本把机器状态、服务状态、业务事件放进同一个视图Rea 的设计思路和踩坑记录应该能帮你省不少时间。1. Rea 的起点为什么不能只靠现成方案凑一个出来1.1 当时的真实场景数据分散到让人崩溃接手那批节点时每台机器上都有一套独立的管理脚本日志散落在各自的目录系统指标则被一个简单的循环任务写进了文本文件。表面上一切都能看到实际上要在几分钟内回答现在到底有没有问题、问题在哪一台这件事必须挨个登录执行命令再把屏幕上的输出自己拼起来。我印象最深的是一次容量评估需要统计一周内各服务的最大内存占用。按理说半小时能搞定结果因为数据格式不统一有的输出是 KB有的是 MB有的干脆是百分比我硬是花了一下午清洗数据。从那时起我就意识到缺的不是采集手段而是一个统一的事件入口——让所有机器、服务和业务状态都变成同一类消息后面无论做聚合、告警还是排查都只面对一个模型。1.2 评估现成方案时的三个否决点我也认真考虑过部署一套完整的监控平台毕竟现成方案听起来更省事。但仔细列了需求之后发现三个问题绕不过去。第一部署链路太长。一套完整的监控平台通常要拆成采集端、存储端、告警端、展示端再加上配套的配置管理对我们这种两人兼职维护的小团队来说光是版本升级和存储调优就可能成为新的负担。第二数据模型偏指标化。现成方案擅长处理数字指标比如 CPU、内存、QPS但我们的场景里还有大量事件型数据比如某个服务重启、某个任务重试、某次发布完成。把这些东西硬塞进指标模型里要么丢失上下文要么到处打标签后续查询反而更麻烦。第三告警规则和内部流程对接困难。我们希望告警不止发到一个群还要附带故障时间线、相关节点列表、上次变更记录。现成方案的告警模板可以做但每改一次都要研究它的 DSL成本比我自己写一个简单的触发逻辑要高。所以最终结论是与其去迁就一个重型系统不如做一个贴合自己使用习惯的小工具。Rea 的定位从一开始就很明确——不做大而全的监控平台只做把分散的事件汇总成可操作的信息这一件事。2. Rea 的核心设计一条事件消息走到底2.1 事件模型统一的三层标签结构Rea 最早用的就是指标名数值时间戳这种最小模型但很快发现不够用。比如上报一条磁盘使用率 87%如果不知道是哪台机器、哪个服务、归属于哪条业务链路这条事件基本没有意义。后来我把模型固定成了带三层标签的结构{ host: app-node-01, service: api_server, biz: order, kind: metric, name: disk_used_percent, value: 87, ts: 1710000000, seq: 1024 }host表示物理或虚拟节点service表示进程或服务名biz表示它所属的业务分组。kind字段区分metric、event、alert三个类型seq是本机单调递增的序号用来做去重和排序。你可能觉得这不就是加几个标签吗差别其实在思维方式上。之前是为每种数据写一段处理逻辑现在变成了先决定它是一条什么事件然后所有下游都围绕事件处理。采集端只要按照这个格式上报聚合端就不需要关心数据来自哪个脚本告警端也只需要按标签过滤不用为每种指标单独开发规则。2.2 为什么坚持先落地缓冲、再异步聚合很多人在做类似工具时第一步想到的是引入消息队列让采集端把数据发到队列再由消费者处理。逻辑上没毛病但对我们这种规模来说多维护一个消息队列意味着多一个故障点队列挂了整个采集链路就断了还得处理队列本身的磁盘和吞吐问题。Rea 选择了更笨但更稳的做法采集端先把事件写在本机的结构化文件里聚合端定期来拉取拉取成功后删除或标记偏移量。这样相当于用本地磁盘做了一次缓冲网络抖动、聚合端重启都不会丢数据。聚合端只要能访问所有节点的文件接口就能以一个全局进度把事件汇总起来。这个设计带来两个额外好处天然支持重放。如果某天发现某个时段的聚合结果有问题我只需要关掉删除已拉取事件的逻辑再把所有历史事件重新推演一遍。背压简单。聚合端处理不过来时它自己会变慢采集端不会被打爆也不会因为发送超时报错。相比 TCP 直推模式这种拉取模式天然具备流量控制能力。代价是实时性会差一点从事件产生到聚合端可见通常有一到两秒的延迟。对于资源监控和故障告警这个场景两秒完全可接受。3. 关键实现细节协程、幂等和配置分离3.1 采集端为什么是协程而不是线程Rea 的采集端运行在每个节点上负责读取本机的系统状态、服务健康信息以及接收业务侧主动上报的事件。刚开始我图省事用多线程模型每类采集任务开一个线程。节点少的时候挺正常节点多了之后问题就来了线程占的内存不小而且大量时间花在等系统调用返回上上下文切换开销完全浪费在 IO 等待上。后来我改成了 Python 标准库自带的async/await协程模型采集任务全部在一个事件循环里调度async def collect_once(): tasks [ read_cpu_usage(), read_disk_usage(), read_service_health(), ] results await asyncio.gather(*tasks, return_exceptionsTrue) await append_to_spool(results)这么做的直接收益是单节点的采集端内存从 80MB 降到了不到 20MB更重要的收益是IO 操作变成了挂起等通知再继续当某个采集目标响应慢的时候其他采集任务完全不会被拖累。如果你也在考虑类似方案我的建议是面对大量短时 IO 操作协程的并发效果优于线程但如果你的采集任务里存在明显的 CPU 密集型计算比如复杂的日志解析那需要额外考虑把这类任务丢到线程池里避免阻塞事件循环。3.2 聚合端幂等写入与断点恢复聚合端的核心职责是把散落在各节点的事件统一落盘并做初步汇总。因为采集端的数据是至少一次语义——节点写完本地文件聚合端拉取后可能还没来得及确认就重启了于是同一批事件会被再次拉到——聚合端必须处理重复。Rea 的去重键很简单host service name ts seq。其中seq是每个节点内部单调递增的序号所以同一节点永远不会产生两对完全相同的ts和seq。聚合端拿到一条事件后先查这个键是否已经存在存在就跳过。为了避免查重拖慢速度我在内存里维护了一个最近 10 万条事件的键集合老事件定期按时间窗口清理。断点恢复方面聚合端每处理完一批事件就更新本地的游标文件记录每个节点已经拉取到哪一条。这里有一个容易偷懒的地方有人图省事等到全部处理完才写一次游标结果进程一崩溃恢复后从很旧的位置重新拉下游被重复数据打得很惨。正确的做法是每批处理完立刻同步落盘游标虽然多了一点 IO 开销但换来了最多重复一个批次的可靠边界。3.3 告警规则阈值只是配置触发逻辑才要进代码Rea 的告警模块最初和聚合逻辑耦合在一起每个规则都要写一段代码后来我把规则改成声明式配置只有触发动作留在代码里。一个规则的示例大致是这样的rules: - name: 磁盘高水位 expr: disk_used_percent 85 for: 5m group: infra notify: [default]expr是简单的比较表达式for表示持续多久才触发。之所以坚持只用阈值持续时间这种简单规则是因为复杂规则如连续三次上升且与前二十四小时同环比超过 20%虽然强大但调试成本高容易误报。实际用下来大部分故障都可以用简单的阈值加持续时间覆盖真正需要复杂判断的场景Rea 会选择把原始事件转发到外部分析而不是在聚合端内置一个规则引擎。配置化的另外一个好处是业务同学可以自己提我要在订单量低于某值时收到告警而不用等我们去改代码。触发逻辑一旦固定成模板新增规则和维护规则都变得非常轻。4. 上线后的三个真实事故以及我怎么把它们修好的4.1 跨天窗口的统计缺了一截Rea 上线第二周有人反馈某天的错误率统计比平时少了一截大概少了晚上十点到凌晨两点这段。我一开始怀疑是采集端漏采了检查日志发现数据明明都进来了。后来才发现问题是时间窗口的处理方式聚合端按本地日做天级分桶而事件里面的ts使用的是标准时区的时间戳。当采集端和聚合端不在同一时区或者系统时区配置不一致时靠近日界线的数据会被划分到错误的桶里看起来就像缺了一段。修复方案有两步。第一步所有事件统一以标准时区的时间戳存储展示时再由前端转换成本地时区第二步天级统计不再使用今天零点到明天零点这种固定边界而是用滑动的最近 24 小时窗口。这样即使某个节点的时钟有一点偏移也不至于把整段数据丢掉。这个坑给我最大的教训是时间戳的语义必须在事件模型建立时就定死不要在存储层和展示层用各自的本地时间拼拼接接否则排查问题时会非常痛苦。4.2 重启后出现大量重复事件顺序还乱了还有一次聚合端因为内存占用过高被自动重启。重启过后下游统计面板出现大量重复计数而且部分事件的顺序明显错乱——旧的错误率数据后出现新的反而先到。定位后发现是本地缓冲文件的重放逻辑有问题。聚合端重启时从上一次记录的游标位置继续拉取但拉取回来的事件没有按seq做内存排序直接按文件读取顺序写入了。各节点上报到缓冲文件时本身就是并发的顺序本来就无法保证一旦重放原来已经被消费的记录再次进来而新的记录又混在其中最后就是乱上加乱。修复分三层游标每批落盘把可能重复的数据范围控制在最小聚合写入前按seq排序保证同一个节点的事件永远按序号递增落盘查重键加上seq让重复记录不只靠时间戳判断。经过这次之后我再也不敢把进程崩溃后还能否恢复出正确数据当成默认成立的事情任何有状态的模块都必须明确定义恢复语义。4.3 告警风暴把通知通道打挂告警上线后不久就迎来了第一次大考某次存储节点连续故障一个小时内粘连在磁盘、延迟、错误率上的十几条规则轮番触发通知通道直接被打满了频率限制真正重要的故障反被淹没。现在回看这个问题本质上是没有区分规则触发和用户通知。正确的流程应该是规则触发产生一条告警事件进入一个待通知队列再由通知模块统一去重、合并、限频最后发给用户。Rea 现在的通知策略是三条简单的约束同一个规则在 10 分钟内最多通知 1 次同一个节点上的不同规则在 5 分钟内合并成一条汇总消息如果同时段有多个节点告警只发一条包含节点清单的消息明细留到页面上看。这三条约束消灭了绝大多数重复打扰。从那以后告警从夜里手机被打爆变成了夜里只响一次但每次都能定位到问题范围。5. Rea 现在的运行表现和接下来的想法5.1 一组来自实际运行的参考数字目前 Rea 管理着大约六十个节点每分钟会产生三万条左右的事件很多是业务侧主动上报的操作记录。采集端的常驻内存维持在 60MB 上下聚合端单实例能稳定处理每秒 5000 条事件的峰值从事件到达聚合端到在查询页面上出现p99 延迟不到两秒。存储层使用文件按天分片配合定期合并压缩三十天的历史数据整体体量很小专门维护存储集群的压力完全没有出现。这个数据不算漂亮但对我们来说是够用的。Rea 的目标始终不是处理海量日志而是把资源指标和关键事件整理成一打开就知道有没有问题的视图。如果你也需要处理非常高的吞吐那么把这套事件模型换成更底层的实现完全可行但核心设计——统一事件格式、本地缓冲、幂等写入、配置化告警——是不用改的。5.2 下一步把事件相关性做起来现在的 Rea 更像一个汇总告警工具离我理想中的排查助手还差一步。我接下来的计划是在事件模型之上构建一层相关性分析当某个节点的错误率升高时自动关联同一节点的磁盘事件、网络事件、最近发布记录甚至把同一业务分组下其他节点的状态一并列出来。这件事的底层能力其实已经有了只差一个分析引擎。因为事件全部带了host、service、biz三层标签做初步的链路关联并不需要在存储层做复杂计算只需要在查询时把标签匹配和时序对齐做好。我计划先做一个最小版本在一张展示页上把一次故障的告警事件、相关指标变化、时间线内的所有操作记录放在一起减少排查时切换上下文的时间。我现在的习惯是每个月去翻一遍告警记录看看哪些规则长期没触发、哪些规则触发太频繁然后顺手调整阈值或通知策略。工具在一个团队里真正被接受靠的往往不是功能数量而是它能在你需要的时候刚好给出有用的信息。Rea 还在慢慢往这个方向演进。