1. 一次凌晨告警风暴之后我决定动手写一套PLFM_RADAR先说一下这件事的起因。那天凌晨三点平台支付成功率突然往下掉值班群瞬间被告警机器人刷屏五六个人从被窝里爬起来一边看日志一边看监控大盘折腾了快四十分钟才定位到是缓存集群里一个节点发生了内存溢出导致热点数据回源时批量穿透。事后复盘的时候大家翻到几个小时之前的日志才意外发现那个节点在出问题之前GC暂停时间就已经异常拉长错误率也在缓慢抬头只是当时没有任何人注意。这就是我决定动手写PLFM_RADAR的直接导火索。PLFM_RADAR这个名字拆开看就是Platform Radar平台雷达。它不是什么新概念本质是一套围绕平台运行时状态做主动探测、信号采集、异常识别和分级告警的轻量级监控预警系统。但和传统监控方案不同的地方在于传统监控更多是出了故障才报警而雷达的思路是在故障成形之前尽量把异常信号从噪声里挑出来。简单说PLFM_RADAR想解决的问题就三个把散落在日志、指标、链路里的信号碎屑统一收拢别等问题爆发了才拼凑全貌用探测和基线学习的方式建立正常态的参照系让系统自己判断什么算异常把告警做得克制、准确、分级触达别动不动就制造告警风暴。这套系统适合谁如果你维护的业务平台有一定规模每周都会遇到几次看起来不太对劲但又不确定是不是故障的时刻或者说你已经被告警群搞到麻木那这套思路就比较适合你。做PLFM_RADAR不要求多牛的算法背景核心是把工程习惯理顺把数据管道搭通把告警规则打磨细这里面每一步我都可以展开讲。2. 雷达的隐喻PLFM_RADAR的探测原理与整体设计思路雷达这个东西基本原理大家都听过发射电磁波接收到反射回波根据回波的时间、方向、强度判断目标位置和性质。PLFM_RADAR的设计逻辑其实完全照搬了这一套只是把电磁波换成了各式各样的探测请求和采集器把海面上的船换成了业务平台里的异常信号。2.1 发射波主动探测与被动采集的搭配对应到平台监控里主动探测就是系统主动发出去的数据包。最常见的实现包括按时段发起的HTTP健康检查、数据库连接检测、中间件存活探测等。它的好处是信号干净、频率可控、结果直观能拿到当前时刻系统还能不能正常响应的直接结论。而被动采集恰好补足主动探测看不到的东西。比如一条请求返回了200但实际业务逻辑报错主动探测看状态码根本发现不了必须靠采集业务日志里的错误码才能感知。再比如内存缓慢泄漏、GC频率上升这类问题主动探测是探不出来的只能通过持续收集运行时指标从曲线趋势上发现异常。PLFM_RADAR在架构上把这两类信号拆成了三个采集通道主动探测通道负责任务探活和关键接口采样日志采集通道负责全量或半量抓取平台运行日志并做结构化萃取指标采集通道负责收集中间件、数据库、应用进程的运行时指标。三条通道的数据最终会汇聚到同一个信号管道里统一打上标签再交给检测引擎处理。为什么强调同一管道因为很多异常不是单点触发的而是跨通道串联的。比如数据库连接池被打满日志里表现为大量获取连接超时指标里表现为活跃连接数逼近上限主动探测表现为部分接口响应时间暴涨。如果三条通道各看各的每个单项可能都不足以触发告警阈值但要是放在同一个信号模型里交叉比对异常程度就非常明显。2.2 回波处理信号格式的归一化设计雷达接收到的回波是电磁波平台采集到的信号则是日志文本、指标数值、探活结果形态差异非常大。所以PLFM_RADAR信号管道落地的第一步就是归一化。我给每条采集信号定了三个核心字段时间戳统一用UTC毫秒值避免时区差异把信号排序打乱目标标识也就是这条信号描述的是哪个服务、哪个实例、哪个接口信号量值数值型指标直接保存测量值文本型日志则先萃取成结构化字段。举一个日志萃取的例子。原始日志可能是这样一段2025-01-12 03:24:11.289 WARN http-nio-8080-exec-42 Failed to obtain connection from pool, timeout 5000ms, active48, max50萃取之后进入信号管道的格式是这样{ ts: 1736666651289, target: pay-service, channel: log, signal_type: db_connection_timeout, value: 1, attrs: { active: 48, max: 50, uri: /api/v1/pay } }这种归一化设计的价值等到做关联分析和动态基线的时候就会体现出来因为所有检测规则都只需要面向一套数据结构不需要每加一种日志格式就重写一遍解析逻辑。3. 信号采集层落地三类探测通道的实现细节设计思路说完了接下来是落地时最花精力的部分。我按照实际开发顺序一条一条讲三类通道的工程细节和取舍。3.1 主动探测通道轻量探针与探活任务编排主动探测我用的是一套独立的探针服务用Python写的部署在独立的机器上不要和业务服务混在一起否则探针本身反而会干扰被探测服务的运行。探针的核心逻辑其实不复杂定时任务调用目标接口记录响应状态、耗时、状态码然后上报到信号管道。下面这段是简化后的核心代码import asyncio import httpx from signal_router import report async def probe_health_check(service, url, timeout3.0): start asyncio.get_event_loop().time() try: async with httpx.AsyncClient(timeouttimeout) as client: resp await client.get(url) latency_ms (asyncio.get_event_loop().time() - start) * 1000 report({ ts: int(asyncio.get_event_loop().time() * 1000), target: service, channel: probe, signal_type: http_health, value: 0 if resp.status_code 200 else 1, attrs: { latency_ms: round(latency_ms, 2), status_code: resp.status_code } }) except Exception as exc: report({ ts: int(asyncio.get_event_loop().time() * 1000), target: service, channel: probe, signal_type: http_health, value: 1, attrs: {error: str(exc)} })探活频率的设定我在踩坑部分会专门说这里只提醒一点不要把探活频率统统设成一样的。核心链路接口可以30秒一次周边非关键服务5分钟一次就够否则高峰期探活请求本身就会变成一种攻击流量。3.2 日志采集通道全量采集到结构化萃取的取舍日志通道我一开始是想把全量日志都采集上来后来发现成本扛不住。解释一下到了晚间高峰期几个核心服务的日志加起来每秒有几万条全部写入信号管道再解析既要占带宽还耗CPU最后我改成了分级策略。具体的做法是关键服务的WARN级别以上日志全量采集核心接口的异常日志全量采集但正常访问日志降采样到10%非关键服务只采集ERROR级别日志。采集端我用的方案是Filebeat加一个轻量过滤脚本Filebeat负责把日志读出来过滤脚本按上面说的策略做初步筛选再做结构化萃取。这个过程里有几个容易忽略的细节值得说一下。一个是日志时间戳必须重排。分布式环境下各机器存在时钟偏差如果直接用本地时间排序后产生的日志可能排到前头导致检测引擎判断订单错乱。我的做法是采集端强制读取日志里的业务时间字段转成UTC格式后再作为信号时间戳。另一个是多行日志合并问题。像Java应用打印的堆栈异常一条异常往往横跨多行如果按行切分就会把一套堆栈拆成好几条信号检测引擎看到一堆无意义的碎片。处理办法是给Filebeat配了多行匹配规则以WARN或ERROR开头的行为起点直到下一个日志头出现之前都归为同一条日志事件。3.3 指标采集通道覆盖关键水位与业务曲线指标通道主要解决的是日志里看不到的异常。举几个典型场景连接池快要耗尽、内存持续增长、消息队列积压量缓慢上升这些在日志里未必有明显报错但指标曲线的趋势能反映出来。我用的指标源有两个中间件指标比如Redis的memory碎片率、MySQL的连接数和慢查询数、Kafka的consumer lag通过各中间件自带的监控接口采集应用运行时指标比如JVM堆内存、GC暂停时长、线程池活跃线程数通过JMX或者Micrometer暴露的端点采集。比采集更重要的是给指标定义水位标签。我做了一个简单的分类表把信号量值映射成三档水位方便检测引擎快速区分信号强弱信号类型正常区间关注区间危险区间连接池使用率0-60%60%-85%85%消息积压量0-10001000-1000010000GC暂停时间0-50ms50ms-200ms200ms接口耗时P990-200ms200ms-500ms500ms这套分类表不是拍脑袋定的而是根据历史故障复盘逐步修正出来的。比如连接池使用率那条最早我把危险阈值设在90%结果有一次在78%的时候连接池就已经出现获取超时原因是长连接被占用只剩下不足两成的空闲连接给突发请求。后来把关注区间下调到60%危险区间下调到85%。4. 异常识别引擎把回波翻译成有东西在靠近信号管道里积累的数据多了接下来就要解决最关键的问题怎么判断哪条信号是真正的异常哪条只是正常的业务波动。这一步我吃了不少亏最开始用固定阈值结果白天夜里被打脸轮着来后来才逐步迭代成分层检测策略。4.1 固定阈值为什么会被业务曲线打脸固定阈值看起来最简单设一个上限超了就告警。但它有一个致命缺陷业务曲线不是平的而是有明显的时间周期性。举个例子平台每日下单量高峰期在上午十点和晚间八点凌晨三点则是低谷。接口响应时间P99在高峰期跑到400ms是正常的但在凌晨低谷期跑到400ms就很可疑。如果用固定400ms作为阈值那高峰期会出现大量误报值班同学看到告警多了就开始麻木最后真正出故障时反而没人第一时间响应。我见过一个更极端的例子某服务平时每分钟处理500个请求固定线程池阈值设的1000。结果某天业务拉了波活动流量翻了三倍每分钟请求量涨到1500线程池被打满响应时间暴涨。固定阈值在流量爬坡阶段一直没触发等到触发时系统已经不可用了。这说明固定阈值的问题不只是误报还有漏报它缺少相对自身正常水平的比较视角。4.2 动态基线学习用历史分位数定义正常后来我把检测从固定阈值改成了动态基线。核心思路是对每一个目标标识维护一个滑动时间窗口的历史信号值用分位数算法估计当前时段的正常范围再叠加一个宽容系数动态生成上下边界。具体实现上我用Redis的Sorted Set保存最近24小时每个目标标识的指标采样每五分钟算一次基线。计算公式简化如下import numpy as np def calc_baseline(history_values): p50 np.percentile(history_values, 50) p95 np.percentile(history_values, 95) p99 np.percentile(history_values, 99) upper_bound p95 max(2 * (p95 - p50), 0.15 * p95) return { lower: p50 - max(2 * (p50 - min(history_values)), 0.2 * p50), upper: upper_bound, severity_high: p99 * 1.5 }这个公式的意思很直白以P95为基础往上加一段抖动容忍带容忍带的宽度取P95与P50之间差距的两倍和P95的15%两者中的较大值。这样做的好处是如果业务曲线本身很平稳P95和P50离得近容忍带就窄系统对微小异常更敏感如果业务曲线本身抖动很大容忍带自动变宽避免把正常抖动当成故障。4.3 置信度评分多通道印证单通道降权动态基线解决了范围的问题但没有解决可信度的问题。一条信号超了基线真的一定是故障吗不一定。有可能只是数据上报抖动或者某次流量正常脉冲。我给PLFM_RADAR加了一个置信度评分机制。每条异常信号进来先不打分检测引擎会等待一个短暂的观察窗口默认60秒在这个窗口内看同一条目标标识有没有其他通道的信号同时异常。评分规则很简单单通道单点超限置信度30%只记录不触达双通道同时超限置信度60%进入告警候选队列三通道同时超限或单通道连续三次采样超限置信度90%立即触发告警如果检测到关联目标比如数据库连接池异常时调用链下游的服务每关联到一个目标追加10%置信度上限100%。这套机制上线后收到的直观效果是凌晨因为低峰期小抖动触发的伪告警从每天十几条降到了几乎为零而真正的问题反而能提前十几分钟暴露因为检测引擎开始把看起来还没崩但趋势已经很不对劲的信号纳入了高置信度范围。5. 告警触达与降噪别让雷达变成狼来了异常识别做得再准最后如果没有一套靠谱的告警触达机制前面的功夫也等于白费。这一章专门讲告警链路里那些看起来小但实际决定体验的设计细节。5.1 告警分级与触达路由PLFM_RADAR把告警分成了四个级别对应不同的触达方式级别定义触达方式期望响应时间P0核心服务不可用资损风险电话群内所有人5分钟P1核心功能受影响但服务未宕群内值班人15分钟P2非核心功能异常影响可控工单群内通知2小时P3潜在风险信号暂不影响业务汇总进日报24小时内确认P0级别的电话告警一开始我用的单一号码后来发现值班人可能在洗澡或者坐地铁电话没人接就变成漏报。我的改进方案是配置了三层转呼策略第一人选连续拨三次未接后自动转呼第二个人第二个人超时未接再转第三个人同时兜底在值班群内发起。这个策略上线后P0告警的5分钟内确认率从刚上线时的67%提升到了98%。5.2 告警聚合与抑制同一个根因只报一次告警风暴是怎么产生的很多情况下不是系统真的出了几十个独立故障而是一个根因引发了连锁反应。比如Redis节点挂了可能导致依赖它的三十个接口全部超时如果每个接口都生成一条告警值班群瞬间被刷爆。我的做法是加了双层降噪机制。第一层是聚合所有告警在进入触达路由之前先按照根因指纹做一次分组。根因指纹由告警的目标层级、异常类型、起始时间三个维度哈希生成同一指纹只保留第一条告警作为代表后续相同告警全部折叠只更新代表告警的发生次数和最后观测时间。第二层是抑制如果一条P0级告警已经触发那么它的下游依赖所产生的P1、P2级告警在P0解除之前全部静默。举例来说数据库连接池打满触发P0告警后所有因拿不到连接而超时的接口告警都会被抑制值班人员的手机就不会被连续轰炸。等到P0告警恢复后这些被抑制的告警进入迟到的归档队列只用于复盘不再实时触达。5.3 值班雷达屏把复杂状态浓缩成一眼能看懂的画面雷达到最后是要给人看的PLFM_RADAR也给值班同学配了一个简化版雷达屏。页面不放复杂的图表只放几个大数字当前活跃异常数、高置信度信号数、未确认的P0/P1告警数、最近一次探测全通过的时间。背景色用雷达色环的逻辑从正常到危急依次是绿、黄、橙、红。有人可能觉得这东西太简单了但值班场景里凌晨三点被叫起来的那几分钟人的脑子是懵的一个简洁、明确、能直接告诉你现在该干什么的界面比一张堆满折线的监控大盘有用得多。雷达屏的每个数字都要求做成了可点击的下钻页点开就能看到触发告警的信号明细和关联目标方便值班同学快速定位。6. 落地踩坑与调优关于PLFM_RADAR的几个血泪经验最后这部分我要把上线几个月以来踩过的坑和调整过的细节集中梳理一下。这些坑在官方文档里基本找不到答案都是我拿线上事故换来的教训。6.1 探针频率太勤会晃太懒会瞎前面我提过探针频率要分档这里详细说说为什么。最初我把所有服务的主动探测频率都设成10秒一次结果遇到一个电商平台的促销活动流量高峰期探针请求和真实用户请求争抢连接池反而把服务响应时间拉高了探针测出来的结果完全失真。这就像一台真正的雷达如果发射功率太强反而会干扰目标自身的信号。调优后的做法是核心支付链路的接口用30秒探测间隔采用一个探针多路径复用的方式把五个核心接口的探测请求合并到同一次HTTP连接上边缘服务降低到5分钟一次数据库和中间件探活则统一走管理通道不经过业务接口。这样既保证了对核心链路异常的灵敏度又不会给业务造成额外压力。6.2 时钟偏移信号错位的隐蔽杀手这个坑如果不是踩过一次我根本不会注意到。PLFM_RADAR做关联分析时需要把不同通道的信号按时间窗对齐如果采集探针所在的机器和被探测的服务机器之间存在几秒的时钟偏移信号时间戳就会错位。偏得不多时看不出来但一旦进行跨通道置信度比对就可能出现日志通道已经检出错误指标通道由于时间戳更早而没进入同一时间窗的漏判。解决措施有三层所有信号在抵达信号管道时统一以采集端解析出的业务时间字段为准而不是以采集机器本地时间为准所有信号管道节点强制开启NTP同步并保留时钟偏移量作为信号的一个副作用字段最后做跨通道比对时时间窗口从固定60秒加宽到区间前5秒到区间后10秒的弹性窗口容忍一定程度的时钟偏差。6.3 告警逃生通道监控系统自己出问题了怎么办这是我最后想重点提醒的一个工程习惯。PLFM_RADAR自身也是一套线上系统它也会被部署在服务器上也会占资源也可能出BUG。如果雷达本身性能耗尽或者主动探测的调度器卡死了它可能会把大量信号堆积在管道里然后突然一股脑释放造成史无前例的告警洪水。我给PLFM_RADAR加了一个自我保护开关检测引擎维护一个信号积压队列当队列长度超过阈值时自动触发降级模式。降级期间只保留P0级告警的路由触达权限其余告警全部落盘不推送同时主动探测频率自动降低到原来的四分之一先保证雷达自身不成为故障源。这个开关一开始我觉得过度设计结果还真派上过用场——有一次信号管道依赖的消息队列发生抖动积压告警在降级模式下被拦截值班同学只收到了一条P0通知其余噪音全被闷在了系统里。总结一下我做PLFM_RADAR这几个月最大的体会做一套好用的平台警视系统关键不在于用了多复杂的技术而在于把信号收集、异常判断、告警触达这条链路里的每一个细节都打磨到位。如果你也想搭一套类似的雷达我的建议是别一上来就追求大而全先把三类通道跑通再慢慢加检测规则每加一条规则都要问自己一句这条规则在本周的业务曲线上会让我产生多少次误判想清楚这个问题你的雷达才算是真的能打仗。
)
