PLFM_RADAR：平台雷达监控的告警收敛与异常检测实践

PLFM_RADAR这个代号在我内部习惯里读作“Platform Radar”，也就是“平台雷达”。过去两年我一直在折腾这个项目，一开始只是受不了半夜被无意义的告警吵醒，后来慢慢发现：所谓的监控平台，和真正的“雷达”之间，差得不是一星半点。这篇文章就从我做PLFM_RADAR的动机、核心链路、技术选型、踩坑记录一路讲下来，希望能给同样被平台稳定性折腾到秃头的朋友一点参考。

它到底解决什么问题？一句话说透：传统监控告诉你“某个指标超了阈值”，PLFM_RADAR试图回答“平台现在到底处于什么状态、哪里最不对劲、该先找谁”。它不是要取代你的Prometheus或者ELK，而是站在这些数据之上，做一层像雷达一样的“信号识别与分诊层”。如果你手头有超过五十台机器、十几个微服务、三条以上业务链路，而且每周都要因为告警风暴被扣绩效，那这篇东西应该能让你少走我走过的弯路。

1. 没有这三个事故，我不会动手写PLFM_RADAR

做这个项目前，我所在的团队并非没有监控。恰恰相反，指标看板、日志系统、告警规则一应俱全，可一到线上出问题时，系统就像集体失明。事后复盘，我发现“该有的都有”和“该看的都看到”之间隔了一道很深的沟。

1.1 凌晨三点，报警轰炸之后是长久的沉默

第一个让我下定决心的事故发生在凌晨三点。某个老服务的GC时间突刺，触发了我们配置的阈值告警，钉钉群瞬间轰炸了上百条消息。我迷迷糊糊爬起来，第一反应是“是不是又有人发版出问题了”，打开发布平台一查，最近两个小时内根本没有变更。然后我开始逐个看指标，CPU、内存、IO、RT，前后折腾了四十分钟，才定位到是某个数据库连接池耗尽，导致整个链路雪崩。

这四十分钟我一直在想一件事：为什么告警只告诉我“GC时间超了”？为什么没有告诉我“这个GC突刺导致哪些接口开始变慢、哪个连接池快满了、最可疑的调用方是谁”？传统监控是故障发生时给你一堆碎片，而一个合格雷达要做的是直接锁定入侵目标。凌晨三点的崩溃，不在于告警多，而在于信息之间没有形成关联。

1.2 监控列表里全是“绿色”，业务已经在流失了

第二个事故更具讽刺意味。周五下午三点，我们的交易平台响应时间整体抬升，但所有单机指标看过去都是绿的——CPU不到30%，内存正常，磁盘IO平缓，容器健康检查也全过。用基础监控的视角去看，这套系统健康得不能再健康。

但业务方在死命催：用户下单页面已经转圈十几秒了。后来追查发现，真正的瓶颈在数据库一条慢SQL，它把连接池里的连接全部占住，应用线程都卡在等待连接上。而我们的基础监控只看单机资源，根本没把“数据库连接池等待数”“应用线程Blocked数量”这类业务链路指标纳进来。PLFM_RADAR的雏形，就是从那时开始画在纸上的：雷达不能只扫描外部环境，更要扫清楚平台自身的“生理信号”。

1.3 开发说是运维的锅，运维说是开发的锅

第三个事故发生在一次大促压测。压测过程中一个核心接口RT从20ms飙到800ms，开发团队盯着代码日志找半天，说“底层数据库查询全是慢调用”，运维团队看数据库监控，说“是上游接口并发量太大把连接池打满了”，两边在群里来回踢了差不多一小时的皮球。

说白了，两边其实都对，但他们的视角各自锁定在一层。我那时候做了一个决定：不做又一个跨层日志平台，而是做一个能实时把“用户请求链路、服务层指标、基础设施负载”投影到同一个雷达视图上的系统。这个决定，就是PLFM_RADAR的起点。它不是为了替代任何现有工具，而是为了在工具之上长出一层“看懂全局”的能力。

2. 定边界：PLFM_RADAR不是监控平台，而是平台的“雷达”

很多同事第一次听说PLFM_RADAR，都会下意识问一句：这不就是告警系统吗？花半天时间建个规则、接上钉钉机器人，不就完事了？我承认，外形上确实有点像，但定位完全不同。雷达和监控系统的区别，在于它处理的是“回波信号”，而不是原始波形。监控把所有指标摆在你面前，雷达则直接告诉你：有一个亮点在东北方向，正在靠近。

2.1 和现有监控体系的分工：我采数据，你管存储

业界成熟的监控方案其实已经把数据采集和存储做得非常扎实，Prometheus加Grafana的组合，或者ELK做日志聚合，都已经很顺手。我没有蠢到重新造一套采集和存储。PLFM_RADAR的定位，是把见成熟监控体系当成传感器——它们负责采集原始信号，我负责把原始信号加工成“态势判断”。

这里有一个很重要的设计原则：PLFM_RADAR几乎不自己拉取指标，而是通过对接现有的Prometheus接口、日志系统Webhook、链路追踪服务的Span数据，来获取统一格式的“信号样本”。这样做的好处显而易见：接入一个新的业务服务，不需要改对方代码，只要它本身有监控指标，雷达就能自动感知。

2.2 雷达视图：从指标到“信号”的抽象

PLFM_RADAR最核心的抽象，是“信号”。原始指标只是一串时间序列数值，信号则是经过加工后的态势判断。举个例子：磁盘使用率82%这只是一个指标；但如果结合“磁盘每分钟增量2%”和“该盘承载日志目录”，就能生成一个“磁盘容量将在九小时后耗尽”的信号。

我在代码里把信号定义得非常简单：一个Signal对象只有四个字段，信号名称、严重级别、置信度、以及一个指向相关指标们的证据链。信号不做复杂的归属判断，它只负责说明“我发现了一个可疑的回波”，至于要不要拉响警报，交给下游的决策引擎。这套抽象跑了一年后我回头看，当初坚持“信号和告警分离”实在太正确了。如果信号直接映射成告警，平台就会被噪音淹没；把二者分开，才可能做降噪和收敛。

2.3 目标用户“一目一屏”的诉求

我当时和运维、研发负责人聊需求，大家提得最多的一句话是：不要给我看几百张图，我只想在早上花二十秒知道平台是否健康。这句话直接决定了PLFM_RADAR的前端交互形态——主界面就是一张模拟雷达屏幕的态势总览图，中央是核心业务模块，外围是基础设施层，异常信号会以聚焦亮点和辅助线的方式出现在对应方位。

这听起来很玄，但落地时逻辑非常简单。我们把整个平台拆成几个固定的业务域（比如交易、账户、营销、消息），每个业务域绑定一组核心指标，然后周期性计算一个“健康分”。雷达图上显示的不是具体的指标曲线，而是这个业务域的健康分和对应异常信号的分布。你一眼扫过去，就知道今天该先盯交易链路还是消息队列。这种设计，做出来以后开发团队一句话把我点醒了：“终于不用自己脑补关联了。”

3. 核心链路拆解：采集、信号识别、告警分诊

从架构上看，PLFM_RADAR是一条非常典型的数据管道：采集模块负责把外部信号拉进系统，识别模块负责判断信号到底是不是异常，分诊模块负责把最终结论送到正确的人手里。它不复杂，但每一环节都有不少值得说道的门道。

3.1 采集这层，最关键的不是全，而是“够用就好”

我见过很多想做统一监控的项目，第一步就想把全公司机器的所有指标一网打尽，结果采集端先把自己搞崩了。PLFM_RADAR的采集策略很克制：每个业务域默认只采集二十个核心指标，全平台初期总共一百二十个指标。指标不在多，在于能够覆盖“资源瓶颈、链路质量、业务健康”三个维度。

采集的执行方式我选了定时拉取加事件推送的混合模式。定时拉取主要用于基础资源指标，周期是十五秒；事件推送则用于紧急信号，比如某个服务连续三次健康检查失败，这类信号通过Webhook直接推给雷达，实时性要求更高。这套混合机制跑下来，采集端的资源消耗长期控制在总CPU的百分之二以内，代价是舍弃了秒级监控的精度。对雷达这个场景来说，十五秒的延迟完全可以接受，毕竟我们追求的是态势感知，不是火焰排查。

3.2 信号识别：把异常检测这件事拆成“规则”和“算法”两层

PLFM_RADAR的识别模块，我刻意没有一上来就堆机器学习模型。原因很简单：模型需要标注样本，而我们当时的故障样本远远不够训练出可信的异常检测器。所以我先做了一个轻量规则引擎，把运维经验翻译成可执行的规则，在这个基础上再叠加一层无监督的时序检测算法。

规则引擎的核心是表达式和事件上下文。例如“数据库连接池等待数大于50，且持续五分钟”，翻译成规则就是“pool_wait > 50，duration > 300s”。这类规则对已知故障模式非常有效，但问题在于运维规律无法穷举。于是我们叠加了一个简单的时序漂移检测：对每个核心指标计算滑动窗口内的均值和标准差，如果当前值偏离均值超过三倍标准差，就生成一个“漂移信号”。初版系统上线时，算法层只有这一个检测器，但已经能抓出不少规则引擎看不见的隐患。

提示：不要为了技术炫技而强行上复杂模型。先用规则把已知故障铺好，再用简单算法兜底未知情况，这比一个永远调不好参数的深度学习模型实用得多。

3.3 告警分诊：让告警找到该找的人

PLFM_RADAR和传统告警最大的一点不同，就是告警不是直接发到一个大群里，而是经过一个“分诊”过程。每条信号生成之后，会经过两级判断：第一级是严重度评估，第二级是归属人路由。

严重度评估主要看两个因子：影响范围和持续时间。一个接口错误率超过百分之五，持续三分钟，和持续半小时，严重级别完全不同。归属于人路由则依赖服务目录表，这个表记录了每个微服务的负责人、值班组和关联业务域。告警只会发给当前时间正在当值的那一组人，而不是全部门。这套分诊逻辑上线之后，值班群的消息量直接下降了百分之八十。最关键的是，该收到的故障信息一条都没漏。

4. 具体技术选型与实现细节，照抄也行

聊完链路，说说我具体用了哪些技术组件，以及为什么是它们。这些选型并不一定是最前沿的，但都是被生产环境毒打过之后留下来的。如果你也想照这个思路自建一套雷达，直接抄作业完全没问题。

4.1 指标存储选型：Prometheus做主存，Redis做实时信号缓存

PLFM_RADAR的指标底层依赖Prometheus，但不是直接用它的告警规则，而是把它当成一个时序数据库。识别引擎通过PromQL查询指标数据，并对返回结果做计算。Prometheus的Pull模型数据对齐做得很好，非常适合雷达这种定时扫描场景。

实时信号缓存我放在了Redis里，每个信号以业务域加信号名为Key存储，Value里包含严重级别、置信度、首次发生时间和最后发生时间。为什么不用消息队列来做？因为信号需要被多个下游模块反复读取和合并，Redis这类支持随机读写的KV存储更顺手。比如合并模块发现相同Key的信号在十分钟内反复出现，就直接更新它的最后发生时间，而不是新插入一条。这就天然实现了告警收敛的第一层。

4.2 告警收敛：时间窗口加信号指纹的“双重闸门”

告警收敛是整个PLFM_RADAR里最救命的一块。前期让我们被骂得最惨的，就是同样的故障每隔五分钟刷屏一次。给技术方案加了两道闸门之后，这个问题才算是真正解决。

第一道闸门是时间窗口。识别引擎对某个信号生成告警后，会把这个信号连同它的指纹（业务域、指标名、异常类型拼接的字符串）写进Redis，并设置一个TTL。在TTL之内，如果相同的指纹再次触发，系统只会更新信号状态，不会重新发送告警。第二道闸门是收敛倍数。对于升级型信号，比如“接口错误率从百分之一升到百分之五”，如果五分钟内连续触发三次，自动把告警级别提升一档，并立即通知上一级负责人。

这里有个细节值得注意：收敛不能把真正的故障升级给吞掉。所以在时间窗口内，如果信号严重级别从“警告”升级到了“严重”，无论是否在窗口内，都必须立刻发送一次通知。雷达既要防止噪音轰炸，也要保证重要信息时延最小。

4.3 通知触达：钉钉、电话、站内信，按级别分通道

通知触达层当初考虑过很多渠道，最后留下三条：站内信用于所有信号的记录归档，钉钉群用于一般告警转发，电话加短信只用于“严重”级别。分级通知的策略是PLFM_RADAR保住口碑的最后一条防线，否则再准的雷达，如果半夜把值班工程师电话打爆，隔天也会被投诉到下线。

电话通知的实现我做了一个简单的外呼任务队列：每次外呼都记录被叫号码、原因、关联信号指纹，并设置五分钟的冷却时间。同一个号码在一个冷却周期内，最多只会收到一次电话，哪怕此时系统里同时爆发了三个严重故障。冷却期过后，如果信号仍未恢复，再触发第二次外呼。这个设计对应了一个很实际的运维心理：一次电话是提醒，三次电话是骚扰，而骚扰会让真正要紧的升级被下意识忽略掉。

5. 上线以后被骂出来的四个坑，每一个都价值一台iPhone

PLFM_RADAR不是一炮走红的那种项目。恰恰相反，v1上线第一个月就被轮流投诉。以下四个坑，是我流了不知道多少汗才填平的。

5.1 第一个坑：规则阈值拍脑袋，误报率高到没人信任

v1的规则阈值基本上是我根据经验拍的。比如“数据库连接池等待数大于50就告警”，结果上线第二天，一个平时就有几百连接等待的业务域直接报警轰炸。为什么？因为“等待数”这个指标本身就不是一个绝对值指标，它的正常基线在不同服务之间差异巨大。有的服务阈值是几十，有的服务日常就有几百。

修正方案是引入了“动态基线”加“偏移量”的概念，不再用绝对值判断异常，而是用“当前值相对历史同期均值的偏离倍数”来判断。比如“数据库连接池等待数超过最近七天同时间段均值的三倍，并且持续时间超过十分钟”，用这种相对规则替代绝对阈值之后，误报率大幅下降。这件事给我的教训非常深：用雷达的人最怕拆弹专家太紧张，把所有影子都当成威胁；雷达的校准，永远比雷达的灵敏度重要。

5.2 第二个坑：时间窗口一刀切，把长尾故障全忽略了

刚开始识别信号时，所有指标窗口我都统一设成五分钟。结果有些慢性的资源泄漏问题，比如内存以每小时百分之一的速度增长，要在十几个小时之后才会触发“五分钟窗口内的漂移”，因为它每个瞬间的数据变化幅度都很小，根本不会被三倍标准差规则捕获。

后来我把窗口机制拆成两套：短窗口面向突发型指标，比如接口错误率、线程池拒绝数，时长五分钟；长窗口面向趋势型指标，比如内存增长、磁盘占用、连接池缓慢泄漏，窗口直接拉到六小时。其实就是把监控的“时间尺度”也当成了一种可配置参数。长窗口的算法用的是线性回归拟合斜率，如果判断出斜率为正且持续放大，就会生成“缓慢恶化信号”。这套双窗口机制，成了PLFM_RADAR后来发现隐患的主力手段。

5.3 第三个坑：告警风暴把值班群变成消息垃圾场

某天晚上一个核心数据库主从切换，从外面看只是几十秒的抖动，但内部因为各种依赖关系，一次性触发了接近两百条告警。PLFM_RADAR虽然做了时间窗口收敛，但那时的收敛是按信号指纹做的，没做“根因聚合”——同一个故障引发的不同表现形态，被当成了完全不同的信号。

修复方案是给信号增加了“业务域关联树”。每个信号除了自己的业务域，还会带一个上游根因域。当多个信号在同一个时间窗口内出现，并且根因域相同，系统会把它们聚合成一条“故障事件”，标题类似“交易域异常事件：关联数据库主库切换，共收敛九条信号”。值班人员看到的就不再是两百条分散告警，而是一个带证据链的完整事件描述。这件事实实在在地说明：雷达屏幕上的每一个光点都重要，但把光点串成敌机航迹，才具备战术价值。

5.4 第四个坑：接入成本太高，业务方集体观望

v1的时候，要求每个业务方如果要接入PLFM_RADAR，必须改代码上报一套自定义指标。大家嘴上都说好，实际动起来一个都没有。最后我换了一种思路：能通过基础设施层和中间件层采集的指标，绝不让业务方手动埋点，只有少数业务指标才开放自定义上报接口，并且提供了现成的SDK包。

同时我把“接入雷达”和“值班告警对接”解耦了。业务方不接入雷达，也可以用旧有的告警方案；一旦接入，就能获得异常信号推荐和根因收敛的能力。这个策略推出后，两周内接入的服务数量翻了三倍。我那次想明白了一个非常简单的道理：工具再先进，只要让使用的人感觉到有额外负担，它的推广成本就会指数级上升。

6. 复盘之后，我打算在PLFM_RADAR里继续折腾的三件事

项目运行到现在，稳定性目标基本达成，但我并不满足。接下来我更看重的是让雷达从“报信”走向“参谋”，也就是让它在发现问题的同时，给出处置线索和预防建议。

6.1 从定位到排障：用信号链自动给出故障定位建议

现在的PLFM_RADAR能准确告诉你“哪里出了问题”，但还做不到告诉你“为什么出问题”以及“从哪开始查最合适”。我正在尝试把多条关联信号的时间线组合成一组“排障建议”。比如检测到交易域出现“接口超时、连接池等待、下游依赖调用耗时增加”三个信号，系统就可以根据预设链路图谱推断，排障优先级最高的应该是下游依赖，因为它在整条链路时间线上最先出现异常。

这个方向上最大的难点在于链路图谱的维护。完全自动化不现实，所以我采用了“半自动”模式：平台自动从链路追踪数据里生成依赖图，人工定期校准节点关系。短期看需要投入人力，长期看这才是从“告警平台”跃迁到“决策辅助系统”的关键。

6.2 让雷达数据反哺容量规划：从被动救火到提前预警

PLFM_RADAR积累的异常数据本身就是一笔宝贵的资产。我把它和容量管理结合起来：根据历史同期数据和趋势信号，预测各个业务域下个月所需资源的上限和下限。比如每年的营销活动大促前，雷达会根据前一年同期的流量信号和资源消耗，直接给出一份“容量风险清单”。

做这件事最大的价值，是把雷达从故障期间的工具，变成了日常规划的工具。故障不发生当然是最好的；而如果能通过规律性信号提前预判资源瓶颈，在故障发生前就完成扩容，那这个雷达才算真正融入了平台的运行节奏。

6.3 把雷达的“灵敏度”权限下放给业务方：人人可调教自己的信号

最后一点是我个人的执念：PLFM_RADAR的规则配置不应该只握在运维团队手里，应该让业务开发自己调教跟自身服务相关的信号。我准备做一个规则配置面板，让业务方用自然语言描述异常场景，例如“希望在下游依赖超时比例超过百分之二十时收到提醒”，然后由后台翻译成规则模板。

这一步如果走通，PLFM_RADAR就从“我帮你看着平台”变成“平台上的每一个人都在用自己的经验帮雷达做校准”。雷达信号来自各个方向，光靠中央调度室里的几个人，永远不如每个岗位上的哨兵更懂自己负责的那片空域。这也是我坚持开源雷达配置层的初衷。说实话，做完PLFM_RADAR v2之后，我最大的感受是：监控工具好不好用，最终拼的并不只是算法和性能，而是它能不能让人更早地看见问题、更少地承受噪音、更快地找到方向。如果你也在做类似的项目，希望这篇复盘能帮你省掉几个月的弯路。