从深夜告警到监控闭环：可观测性系统设计与踩坑复盘

1. 一次深夜告警翻车之后PLFM_RADAR的诞生背景凌晨两点四十值班电话把我叫醒用户反馈核心接口已经连续报错四十多分钟。我下意识打开监控系统发现磁盘告警早在两点零一分就触发了但那条告警被淹没在一堆常年没人理的陈旧规则里没有任何人注意到。这件事最讽刺的地方在于系统不是没有发现问题而是发现问题的能力被分散在了好几个工具里没有一个人能把零散的信号拼成一张完整的图。从那天起我决定给自己维护的平台做一套雷达。项目内部代号 PLFM_RADAR——PLFM 就是 platform 的缩写RADAR 在这里既沿用了雷达这个比喻也代表 Realtime Anomaly Detection And Response 这类实时检测与响应的定位。它不是一个取代现有监控大盘的新平台而是一个把日志、指标、业务事件全部收拢在一起、主动扫描异常、并确保告警被真正处理的信号中枢。如果你手上有十几个到几十个服务、技术栈比较杂、又没有专职的 SRE 团队这篇内容应该会对你的胃口。它不要求你搞多大的基础设施也不用引入什么高深的模型。核心是把监控这件事从头到尾捋顺一次先确定扫描哪些信号再解决采集归一化然后设计检测逻辑最后把告警做成一个能闭环的流程。做完之后你会发现晚上能睡个踏实觉确实是可以靠工程手段实现的事。1.1 那通电话暴露出的三个问题复盘那次翻车问题可以拆成三层。第一是信号分散磁盘告警、接口错误率、用户吐槽分别来自三套系统值班的人不可能同时盯住所有面板。第二是规则老化告警规则里有一大半是早期随便加的固定阈值早就匹配不上真实负载导致告警总量很大但价值很低真正重要的消息反而被噪音淹没。第三是缺少闭环告警发出之后有没有人认领、有没有人跟进处理系统里没有任何记录事后连个回顾的抓手都没有。这三个问题其实非常普遍。很多团队的监控建设都是缺什么补什么长出来的先上主机监控再上链路追踪再上日志平台每套工具单独看都很好但它们之间没有关联。PLFM_RADAR 想解决的首先是这个关联问题。1.2 我对这套系统定下的三条硬原则动手之前我给 PLFM_RADAR 定了三条硬原则后来证明每一条都帮我避开了大坑采集要轻尽量不侵入业务代码。能通过日志、标准指标接口拿到的绝不让业务方为了接入而改代码。检测要可解释。每一条告警都必须能说明为什么触发不能给出一堆模棱两可的模型得分。告警要闭环。从发现、认领、处理到恢复每一步都要有记录事后可回溯。尤其是可解释这条它逼着我所有检测逻辑都显式写出触发条件而不是丢给一个黑盒。后面讲到检测引擎时我会详细说为什么这么坚持。1.3 和 Prometheus、ELK 这类现成方案的关系你可能会问Prometheus 加 Grafana、ELK、Sentry 已经覆盖了指标、日志、异常捕捉为什么还要自己做一层我实际用下来的体会是这些工具各自负责一个维度但告警决策往往需要跨维度信息。比如错误率升高如果伴随CPU 飙高那是资源问题如果伴随下游数据库超时率上升那是依赖问题。单看任何一家的面板都很难得出结论只有把多路信号拉到一起做联合判断才有意义。所以我并不主张用 PLFM_RADAR 替代它们而是把它放在这些工具之上做一个汇聚和决策层。下面的采集通道直接消费各系统的既有输出上层做归一化、检测、告警编排。这种桥接而非替代的思路也决定了整个项目的实现难度不会失控。2. 扫描范围怎么定信号分三层别想做成一坨很多监控项目失败不是因为技术不行而是因为什么都想监控最后看板上一片红红绿绿反而没人看。我的做法是先给信号分类每一类定明确的取舍标准再决定接什么、不接什么。2.1 三层信号模型基础设施、应用、业务我把需要扫描的信号分成三层基础设施层CPU、内存、磁盘、网络、进程存活这类资源指标。特点是比较稳定阈值容易定但通常只反映现象不反映原因。应用层接口错误率、请求延迟、QPS、依赖服务的可用性、队列积压量。这一层和代码直接相关最能暴露系统内部的问题。业务层订单成功率、支付回调延迟、注册转化、搜索无结果率这类和产品指标直接挂钩的信号。这一层业务方感知最强也最容易被传统监控忽略。三层之间是串联关系。基础设施层出问题通常意味着机房或机器层面的事故应用层出问题说明服务健康状态恶化业务层出问题意味着用户已经实际受到影响。PLFM_RADAR 的检测逻辑会尽量把三层串起来。比如业务层的支付成功率下降会自动去拉应用层的支付服务错误率和基础设施层的数据库负载三者一起判断而不是只报一个孤立的数字。2.2 接与不接的判断标准对每一类候选信号我只有一个问题这个信号如果异常我会不会真的采取行动如果答案是会接进来如果是知道了但只能干看着就别让它进告警通道。我踩过最典型的坑是把磁盘剩余空间百分比直接拿来设告警。后来发现某些机器磁盘很满其实是设计如此阈值一旦定错每晚都在刷屏。最后我改成监控磁盘使用率的增长速率只有短时间内快速增长的才告警那些存量很大但一直稳定的机器彻底安静了。这就是取舍的意义监控指标是给变化看的不是给状态看的。下面这张表是我在项目里实际维护的信号清单给你做个参考层级信号示例检测方式告警级别基础设施CPU使用率、磁盘增长速率、内存占用静态阈值 速率变化P2/P3应用层接口错误率、P99延迟、队列积压量动态基线 关联检测P1/P2业务层支付成功率、注册转化、核心接口可用性环比变化 关联检测P1这套清单不是一次定完的后面上线两三个月反复调过好几轮。初版尽量少接宁可漏一点也要保证每一条告警都是可信的等跑顺了再逐步加信号反而更快。2.3 按服务维度切还是按接口维度切接哪些信号定了之后还有一个细节信号的聚合维度。比如接口错误率到底按单个接口算还是按整个服务算我的建议是两层都要但优先级不同。值班场景里按服务聚合的告警更适合第一时间处理因为信号强、噪音少按接口聚合的告警适合事后定位因为它能告诉你问题出在哪个入口。所以检测规则里我的默认做法是先按服务维度检测并触发告警告警详情里再附上 TOP 异常接口列表由系统自动生成。这样既能避免告警风暴又不丢定位信息。3. 采集归一化所有数据先变成同一种语言信号范围定了接下来就是最难也最无趣的部分把不同类型的输出采集回来转成统一的格式。这一部分大概占了整个项目一半左右的代码量但它是后续检测能做下去的地基。3.1 采集通道的选择我没有发明新的采集协议而是优先复用现有输出。四个主要通道日志文件服务往 stdout 或磁盘日志写的内容由采集器 tail 并解析。适合吞吐量大、需要事后检索的文本型数据。指标接口只要服务暴露了 Prometheus 格式的 /metrics 端点就直接抓取。这是指标类信号最省力的来源。消息队列业务事件订单、支付、注册等往往已经发到了 Kafka 或 RabbitMQ直接消费一份副本既不打扰业务又能拿到结构化事件。Webhook 回调第三方平台的交付通知比如短信发送回执、支付回调通过 HTTP 接口推给收集服务。选择通道的核心考量是最小侵入。比如日志采集我优先走标准输出而不是改代码加日志指标抓取优先用现成的 /metrics 端点而不是让每个服务单独上报。这样业务方的接入成本低推广起来阻力小很多。3.2 统一事件模型所有来源的数据到了收集服务内部必须先转成一个统一事件模型。我用的是类似这样的结构Go 代码示意type RadarEvent struct { ID string json:id ObservedAt int64 json:observed_at // 雷达观测时间 EventAt int64 json:event_at // 事件原始发生时间 Source string json:source // 来源通道 Service string json:service // 服务名 MetricName string json:metric_name // 信号名 Value float64 json:value // 数值 Tags map[string]string json:tags // 标签实例、接口、环境等 Level int json:level // debug/info/warn/error Raw string json:raw // 原始内容用于排查 }这里特别提一下 ObservedAt 和 EventAt 两个字段。前者是雷达收到数据的时间后者是事件实际发生的时间。日志场景里两者常常相差几分钟甚至更久如果不区分后面做时间相关的统计就会出偏差。这个细节我在上线后被狠狠坑过一次后面专门有章节复盘。归一化的核心是宽进严出进来的时候尽量保留原始信息只是在格式上做转换不要为了整齐好看把排查时有用的原始字段丢掉。统一事件模型带来的最大收益是检测引擎只需要写一套逻辑不用为每种数据源各搞一套。3.3 采样与去重策略日志和指标的数据量很容易膨胀如果不加控制存储成本会吃掉整个项目的价值。我用的策略分三层业务事件全量保留。订单、支付这类事件量级有限却有高价值一条都不能丢。指标数据按固定周期采样默认 15 秒一个点归档时降到 1 分钟或 5 分钟一个点。调试日志只保留 warn 级别以上以及每条错误日志的最近几行上下文debug 级别默认丢弃。去重方面我按 服务名 信号名 标签哈希 做窗口去重窗口默认 5 分钟。同一服务同一指标在短时间内反复触发相同状态时只保留第一条作为触发事件后面的作为状态刷新。这个设计后面也直接简化了告警聚合逻辑。4. 检测引擎规则、基线、关联按这个顺序来检测引擎是整个系统的核心。我在设计时故意没有一上来就上机器学习模型而是按静态规则 → 动态基线 → 跨信号关联三层递进。原因很简单规则最可解释基线能适应负载变化关联能减少单一信号误报。等这三层跑稳了再考虑要不要加更聪明的算法。4.1 第一层静态规则静态规则是最简单的也是兜底的。比如 CPU 使用率超过 90% 持续 5 分钟、磁盘每分钟增长超过某个阈值、核心接口返回 5xx 数量连续两分钟大于 0。这类规则的优点是逻辑透明出了问题一眼能看懂。缺点是阈值需要人肉维护业务高峰期和低谷期适用值不同很容易老化。我把静态规则定位成最后一道防线。动态基线负责适应正常波动静态规则负责抓住绝对异常。两者不是替代关系而是互补关系。配置上用 YAML 管理例如rules: - id: cpu_high metric: cpu_usage condition: value 90 duration: 5m level: P2 action: page - id: disk_growth_fast metric: disk_usage_delta_per_min condition: value 20 duration: 10m level: P3 action: notify4.2 第二层动态基线动态基线解决的核心问题是什么算正常。拿接口 P99 延迟来说白天高并发时 200ms 是常态凌晨低峰时 80ms 就可能已经是异常。固定阈值永远选不对所以要用滑动窗口内的历史数据自学习一个基线。我用的是指数加权移动平均加标准差的方式给近期数据更高权重算出一个期望值和波动范围当前值偏离期望值超过三倍标准差就判定异常。公式不复杂EWMA(t) α * value(t) (1 - α) * EWMA(t-1) std(t) α * |value(t) - EWMA(t)| (1 - α) * std(t-1) upper(t) EWMA(t) k * std(t)α 取 0.3 左右k 取 3既能平滑短期毛刺又能捕捉持续恶化。这里的难点在于不能对时间周期敏感的信号用同一个窗口。我的做法是给信号打上周期标签按天周期的窗口取过去 7 天同时间段按周周期的窗口取过去 28 天同星期同时间段。只有按周期对齐基线才有意义。这一层的价值在压测场景体现得很明显。临时压测会把延迟指标打得很高静态规则会误报。但压测同时把 QPS 拉高而 QPS 高的时候延迟基线本身就高动态基线能自动识别这个延迟在当前 QPS 下并不离谱误报率低很多。这是固定阈值无论怎么调参都做不到的。4.3 第三层跨信号关联单信号检测再怎么调还是会有误报。真正提升告警质量的是关联检测。我的实现思路比较朴素给每个服务维护一张依赖关系图节点是服务边代表调用关系。当某条信号异常时自动去查上下游的信号状态把两者的异常关系一起带进告警上下文。举个例子。支付服务延迟飙高单看这条信号只能告诉你它慢了。但如果同时看到数据库服务器的连接数爆满、磁盘 IO 升高就能推断根源在数据库如果数据库健康周围其他调用它的服务也都变慢那根源可能就在支付服务自身。这个判断可以写成规则A 服务异常且 A 的上游依赖全部正常、下游依赖存在同类异常则根源疑似下游。这一层不需要做得很复杂哪怕只是把关联信号作为上下文拼进告警消息里值班的人也能省下大量切换系统的时间。我实测下来加了关联上下文后平均定位时间缩短了三分之一左右。4.4 控制告警疲劳没有已恢复不配叫告警这里单独说一下告警疲劳。一个告警体系如果总是发出没人理的噪音很快就会像狼来了的故事一样丧失公信力。我的控制手段有三个每条告警必须带已恢复通知。不能只告诉你出事还要告诉你没事了形成一个完整周期否则你会被持续刷屏逼到关掉告警。告警必须带可操作建议。触发条件、定位链接、相关上下文一起附上让收到告警的人十秒内能开始干活。相同的告警在恢复前不重复发送只做状态刷新。恢复后再复发才算新告警。这三条配合前面的聚合去重告警量能降一个数量级。做检测逻辑时算法是其次控制住告警噪音才是让系统活下来的关键。5. 告警触达把发现了变成处理了检测到问题只是开始。真正让人头疼的是告警之后那套流程该发给谁、怎么通知、没人处理怎么办、处理完怎么确认。我在这部分花了非常多心思因为经验告诉我大部分监控项目都死在告警发出去就没人管这一步。5.1 告警分级别什么都打电话我把告警分成 P1、P2、P3 三级对应不同触达方式P1核心业务不可用或已有大规模用户投诉。电话 IM 双通道要求立即响应。P2服务健康明显恶化但暂未影响用户或者已有降级方案兜底。IM 通知15 分钟内认领。P3潜在风险或资源趋势类问题。IM 通知当天处理即可。分级的依据不是技术严重程度而是用户是否已经受影响。这条标准很朴素但执行起来非常有效。很多团队把某个接口延迟升高直接设成 P1结果半夜被叫醒一看只是个做数据批处理的内部接口在跑重任务价值极低。按用户影响分级后告警含金量明显提升。5.2 聚合与去重告警风暴的终结手段告警风暴的根源是同一故障被多个监控维度同时捕捉。我的聚合策略分两步先按服务 信号类型在时间窗口内合并形成事件再按服务 故障根因假设合并成告警组。也就是说支付服务延迟高、错误率高、依赖超时率高这三条信号即使分别触发也会被归到同一个告警组里值班的人只需要处理一次。去重窗口设置为恢复之前不重复。同时每条告警会附带当前故障的持续时长每 30 分钟刷新一次状态但只刷新、不新发。这样值班群不会炸屏事后复盘也有一条清晰的时间线。5.3 值班闭环认领、处理、恢复、复盘PLFM_RADAR 里我加了一个非常简单的值班闭环告警进入待认领状态 → 值班人点击认领 → 系统记录认领人和时间 → 处理完标记恢复系统同步触发恢复通知 → 次日生成值班小结统计每条告警从触发到恢复的时长。这套机制不需要复杂的工单系统一个状态字段就能跑起来但带来的改变是巨大的。从那以后再也没有发生过告警发了但没人管的情况而且每月复盘时有数据可谈哪类告警占比高、哪类恢复慢一眼就能看出整个系统最薄弱的环节在哪。6. 上线后的三次翻车时间戳、存储和雷达自身的失明最后说说上线后实际踩过的三个大坑。每个都是文档里不会写、测试环境很难重现、生产环境一碰就出事的典型问题。我把排查过程和最终方案完整写下来希望你能少走这些弯路。6.1 时间戳偏差差点让我误判了整轮故障上线第二周雷达频繁报核心接口延迟飙升但每次我去看业务系统指标明明正常。反复排查后发现问题出在日志解析环节客户端打印日志用的是本机时间而几台业务机虽然接了 NTP但时间同步延迟不一样有的快三秒有的慢十几秒。采集器拿到日志后又用当前时间去打点于是同一事件的观测时间和发生时间被混在一起做基线对齐时窗口错位就产生了幻觉告警。修复方式就是我前面提到的双时间戳设计EventAt 取日志内容里记录的事件发生时间ObservedAt 取采集器接收时间。所有检测和统计一律以 EventAt 为准ObservedAt 只用来算采集时延这个健康指标。同时把所有采集端的 NTP 配置核了一遍收窄偏差到两秒以内。这个坑的直接教训是做时间序列系统时间字段的语义必须在一开始就定义清楚否则后面每个依赖时间的模块都会跟着错。6.2 存储从每天几个G涨到每天几百G另一个问题更现实存储成本。初版我把所有日志和指标全量入库想着数据越多越能事后分析。结果上线一个月单日存储从几个 G 涨到几百 G把预算直接打穿。后来做了三层收缩第一层指标按周期降采样热数据保留 15 秒粒度七天之后折叠到 1 分钟粒度第二层日志只保留 warn 以上和错误上下文第三层业务事件按重要性分层核心事件永久保留普通事件保留三十天。存储规划其实可以提前估算。我的经验公式是日新增存储约等于原始日志量乘以解析后的有效字段占比再乘以压缩率大概在原始量的 0.03 到 0.1 之间指标另算。如果这个值超过你预算日存储上限的一半就说明采集或保留策略需要收紧。不要迷信热存储分级存储才是长期运行的常态。6.3 雷达自己也会失明最有意思的一次故障是雷达自身挂了两个小时而我全然不知。原因很简单采集服务所在的主机磁盘满了大量事件写不进去但进程还没退出看端口和进程状态都正常监控面板上一片绿。直到用户再一次打电话来我才意识到监控系统的核心故障居然没有一条主动告警。这次之后我做了一个强制要求雷达自身的关键健康指标必须走一条独立的、和主链路物理隔离的检查通道。具体来说一个外部探针每 60 秒探测采集服务的存活、队列积压量、写入延迟和磁盘水位任何一项异常直接走最原始的短信接口通知。同时给所有输入通道加了积压监控如果消费 Kafka 的位点落后超过阈值立即告警。因为采集跟不上了往往比某个指标异常更致命。6.4 这些教训最终沉淀成了什么三次翻车最终沉淀成项目里的几个默认配置所有事件必须区分观测时间和发生时间存储策略上线前就要按预算倒推雷达自身必须有独立心跳。这些不是功能需求而是做监控系统的人必须刻在脑子里的红线。我现在把这三条写进了项目的交接文档里每个接手的人第一课就是背这三条。PLFM_RADAR 从诞生到现在版本号已经换了好几轮。最初是为了让自己别再半夜被用户叫醒后来逐渐变成了团队日常依赖的基础设施。它让我体会最深的一点是监控这件事技术占比其实不高真正难的是把发现问题、通知到人、处理闭环这条链路想清楚并且有定力做到不贪多、不做过剩功能。如果你也正准备搭一套类似的东西希望这份复盘能帮你省掉几个月的弯路。