PLFM_RADAR 这个名字是我自己起的全称是 Platform Radar翻译过来就是平台雷达。做它的初衷特别朴素——大概半年前我们平台一次线上故障从发生到被用户发现再到最终定位花了将近四十分钟。四十分钟里CPU、内存、磁盘这些基础设施监控全都没有任何反应因为服务根本没挂只是某个核心链路的订单数据在悄悄积压。监控面板上一片绿色业务实际已经半瘫痪。那次之后我一直在琢磨一件事能不能做一个能直接看到业务状态的雷达把这些散落在日志、消息队列、数据库里的信号统一收进来实时判断平台是不是真的健康。基础设施监控解决的是机器活没活着平台雷达要解决的是业务跑没跑得动。两者缺一不可。这就是 PLFM_RADAR 的来源。这篇文章不是要讲一个多复杂的分布式系统而是完整还原我在这个项目里的真实思考数据从哪来、异常怎么判、告警怎么不扰民、上线后踩了哪些坑。如果你所在的团队也经常遇到监控全绿但业务出问题的场景这套思路可以直接拿去参考。1. 先说清楚这套平台雷达到底在监测什么很多人在做监控的时候容易掉进一个误区一上来就堆指标把能采集的全部采一遍最后Dashboard上密密麻麻几百个图真出事的时候反而不知道看哪个。PLFM_RADAR在设计之初就定了一个原则——只监测那些业务出问题一定会变化的信号。1.1 传统监控覆盖不到的三个盲区传统的CPU、内存、磁盘、网络监控本质上是机器健康度监测。它们能告诉你服务器是不是还活着但很难告诉你业务是不是正常运转。我梳理了一下至少有三种典型故障是基础设施监控很难提前发现的积压型故障服务进程活着但消息队列里的数据越堆越多消费端处理不过来。此时CPU可能才30%内存也没爆表面一切正常。成功率跳水某个接口的失败率从0.1%突然涨到15%但总体QPS不高加起来也就几十次失败触发器根本不会响。链路局部阻塞网关层完全正常但下游某个供应商的接口超时了导致出单流程卡住用户侧表现为提交订单转圈。这类问题的共同点是只有从业务数据维度才能观测到。所以PLFM_RADAR的监测对象不是服务器而是平台上的核心交易链路。1.2 三类必须盯紧的业务信号我把平台健康度的信号分成了三大类每类下面再拆具体指标信号大类具体指标解释流量信号请求量、QPS、PV/UV、支付发起量有没有用户在进来、进来多少处理信号成功率、失败率、平均耗时、回调超时率进来的请求有没有被正确处理积压信号队列深度、待处理任务数、数据库堆积量是不是有什么东西在被悄悄积压这三类信号分别回答了三个问题有没有流量进来进来之后是不是被顺利处理了有没有哪个环节在积压只要这三个问题都有明确答案平台的健康度基本就能实时掌握。1.3 这套监测逻辑的适用范围PLFM_RADAR不绑定具体业务它是一套通用的业务雷达逻辑。我拿它适配过电商订单流程、内容审核链路、支付回调场景逻辑基本一致。比如电商场景下流量信号是下单请求量处理信号是订单创建成功率积压信号是支付回调队列深度内容审核场景下流量信号是上传量处理信号是审核完成率积压信号是待审核队列长度。用一句话概括就是任何有输入、有处理、有输出的业务流程都可以套这套雷达逻辑。它能帮你把所有业务环节的水流状态实时可视化。2. 数据采集层我用什么方式把散落的日志和指标收拢起来明确了监测什么之后下一个问题自然就是数据从哪来。这一层是整个PLFM_RADAR的地基地基不稳后面所有检测逻辑都是空中楼阁。2.1 选型原则不引入重量级全家桶开始之前我列了几条约束不能为了做监控专门部署一套完整的微服务全家桶不能要求所有业务线统一改代码接SDK最好是基于现有的日志和接口做轻量改造。所以最终方案是日志采集 主动上报 定时查询三管齐下每一类数据都用最合适的方式收。2.2 日志采集层的具体方案日志是最现成的信号源大部分服务本来就在打印业务日志。PLFM_RADAR的做法是给每一条核心业务日志加上一个结构化字段比如订单进入、订单成功、退款入队、回调收到然后再通过采集器把日志转发到统一的存储里。我用的是Filebeat做文件采集配置上监听各个服务的日志目录解析JSON格式的日志内容然后直接转发到Elasticsearch做索引。一个关键配置是给每条日志打上服务名和Pod标识这样后面查问题的时候可以按服务维度下钻也能快速判断是不是某一台实例出了问题。filebeat.inputs: - type: filestream enabled: true paths: - /data/logs/*.log parsers: - ndjson: target: overwrite_keys: true add_error_key: true output.elasticsearch: hosts: [es01:9200, es02:9200] index: plfm-log-%{yyyy.MM.dd}2.3 指标数据的两种来源日志解决了事件层面的问题但PLFM_RADAR还需要高质量的数值型指标来做异常检测。这一块我用了两种来源业务主动上报核心服务在处理订单、回调等关键节点时用类似prometheus客户端库的方式打点把订单进入量、处理成功量、失败量实时累加。定时拉取对于消息队列深度、数据库积压量这类没法靠打点获取的数据PLFM_RADAR写了一个定时任务每隔30秒调用队列管理API和数据库查询取当前积压数值。主动上报的好处是实时性好能精确到秒级定时拉取的好处是实现简单不侵入业务代码缺点是存在最多30秒的延迟。对于积压类指标来说30秒延迟完全在可接受范围内。2.4 一个容易忽略的坑所有时间戳必须统一时区这一点我在上线第一周就吃过亏。当时采集的服务分散在多个容器上有的容器时区是UTC有的是Asia/Shanghai结果同一时刻的订单数据被标成了不同的小时异常检测算法完全乱了套白天狂报流量骤降晚上狂报流量暴涨。解决方案是在采集端强制统一所有日志和指标在生成的时候就转成UTC时间戳存储展示的时候再转回本地时区。还有一个小细节——容器内的系统时间偶尔会漂移我加了一个定时任务每隔几分钟同步一次容器时间并在采集器里做了时间戳合理性校验如果发现日志时间比当前时间晚了超过5分钟直接标记为异常并告警。3. 异常检测核心从拍脑袋阈值到滑动窗口基线数据收上来之后最核心的问题就是怎么判断当前状态是不是异常PLFM_RADAR在这个问题上的演进过程我觉得很值得分享——它不是一上来就用了多高深的算法而是经历了一个从粗暴到精细的渐进过程。3.1 固定阈值方案为什么不行最初版本用的是最简单的固定阈值规则失败率大于5%就告警请求量低于每分钟1000就告警。上线当天就被现实教育了。白天高峰时段的请求量可能是凌晨的几十倍双十一活动期间的流量是平时的十倍还多。固定的阈值在两个场景下必然翻车一是高峰期稍微波动就触发误报二是低峰期真正的故障因为达不到阈值而漏报。更麻烦的是不同指标的正常区间差得太远根本不存在一个通用阈值可以应付所有情况。3.2 基于时间桶的滑动窗口基线后来我把思路从定死一个值变成了跟历史同期比。核心思想很简单同一个业务指标在相同的时间点上有稳定的周期规律——今天上午10点的流量大概率跟昨天上午10点的流量差不多如果不差不多说明有点异常了。具体实现分三步第一步把时间分桶。一天切成288个五分钟的桶每个桶有一个编号比如00:00-00:05是桶000:05-00:10是桶1以此类推。第二步滑动窗口存历史。每个桶都维护最近14天的历史数据。当新的数据进来它会被归入对应的桶同时最旧的那天数据会被淘汰掉。第三步计算基线和阈值。对每个桶计算历史数据的均值μ和标准差σ当前值x如果满足x μ k * σ就判定为异常。k是一个可调系数默认取3对应大约三西格玛的水平理论上假阳性率在0.3%左右。对于想控制误报的指标可以调大到4甚至5对于宁错杀不放过的关键指标可以调到2。3.3 检测模块的核心代码我写了一个轻量级的检测模块核心逻辑就几十行。这里贴一个简化版本去掉了一些配置和嵌套处理但主体逻辑完整保留import datetime import threading import numpy as np from collections import defaultdict class SlidingWindowDetector: def __init__(self, window_days14, k3.0): self.window_days window_days self.k k self.buckets defaultdict(list) # bucket_id - [history values] self.lock threading.Lock() def _bucket_id(self, ts): 把时间戳映射到5分钟桶编号返回 (日期, 桶序号) dt datetime.datetime.fromtimestamp(ts, tzdatetime.timezone.utc) bucket_no (dt.hour * 60 dt.minute) // 5 return dt.date(), bucket_no def add_sample(self, ts, value): 新数据进来更新对应桶的历史窗口 date_key, bucket_no self._bucket_id(ts) with self.lock: bucket_list self.buckets[bucket_no] bucket_list.append((date_key, value)) # 只保留最近 N 天数据 self.buckets[bucket_no] [ (d, v) for d, v in bucket_list if (date_key - d).days self.window_days ] def check(self, ts, value): 检测当前值是否异常。 如果历史数据不足3天返回 False数据不够不判断。 date_key, bucket_no self._bucket_id(ts) with self.lock: history [v for d, v in self.buckets.get(bucket_no, []) if d ! date_key] if len(history) 30: # 至少需要30个样本 return False mu np.mean(history) sigma np.std(history) if sigma 0: return abs(value - mu) 1e-6 threshold mu self.k * sigma return value threshold, value, mu self.k * sigma有几个细节值得注意。历史数据不足时不判断避免刚上线数据量不够导致乱报当天数据不参与基线计算防止故障日的数据把基线污染掉每个桶独立计算天然适配了业务指标的日周期性。3.4 从单指标异常到组合异常滑动窗口解决了单指标是否异常的问题但有些故障需要多个指标联合判断才准确。比如订单成功量跌了如果请求量也跟着跌可能只是流量太少如果请求量没跌但成功量跌了那就是处理链路有严重问题。我在PLFM_RADAR里加了一层规则引擎支持组合条件判断IF 请求量 基线 AND 成功量 基线*0.5 THEN 判定为处理链路异常这类组合规则大幅降低了误报率而且告警信息里能直接告诉值班同学是哪个环节出了问题定位路径一下子短了很多。4. 告警策略让声音响得恰到好处而不是接连轰炸检测算法再准如果告警发得没节制团队很快就麻木了真正的故障反而会被一堆垃圾告警淹没。PLFM_RADAR在告警策略上花的功夫不比检测算法少。4.1 告警分级是刚需我把告警分成三个级别不同级别用不同的触达通道和响应要求级别触发条件示例触达方式期望响应时间P0支付成功率跌到50%以下、队列积压超过1万电话短信群机器人立即响应P1失败率超过基线3倍、耗时超过基线2倍群机器人邮件10分钟内确认P2成功率缓慢下降、流量偏离基线30%邮件次日看板当天处理分级的意义不在于给告警贴个好看标签而在于让不同重要程度的问题用不同力度的方式打扰不同的人。P0半夜打电话能把人叫起来那P1就别用电话否则值班同学根本分不清哪个是真的紧急。4.2 告警降噪的四个关键机制这里分享PLFM_RADAR实际用下来最有效的四个降噪机制连续确认机制。单次数值超过阈值不告警连续N次每个周期30秒都超过才告警。比如失败率瞬时冲到8%可能只是抖动持续2分钟都在8%以上才是真问题。我把N设成连续4次也就是至少持续两分钟才触发能过滤掉大量瞬时尖峰。同因合并机制。同一个检测规则在15分钟内如果反复触发不再重复发告警只更新原告警的持续时长和当前值。否则一台实例抖动一下可能同时触发五六个通道的告警轰炸。静默期机制。某个告警触发后如果正在处理中允许值班同学手动置为处理中这个规则就进入静默直到处理完毕。避免一边排查一边还在被新告警狂轰乱炸。依赖维度分组。告警不是零散地发而是按故障链路聚合。比如支付回调链路有一项异常时只发一条聚合告警把涉及的服务、指标、波动幅度都列在里面。4.3 告警模板一定要带上可执行信息我见过太多告警长这样警告order_fail_rate异常。收到这种告警值班同学的第一反应不是去查而是骂人——因为这条告警没告诉他问题的严重程度、影响范围、跟历史数据差多少、应该从哪里开始查。PLFM_RADAR的告警模板强制包含以下内容规则名称、级别、触发时间指标当前值和基线值、偏离倍数涉及的服务/模块/机房最近5分钟的趋势上升还是持续高位关联的日志查询链接或命令一条实际的P1告警长这样【PLFM_RADAR P1】支付回调成功率异常 当前值72.3%过去5分钟基线值96.8%偏离1.34倍 影响模块payment-callback-consumer 趋势连续6个采样点低于基线呈持续下降趋势 相关日志grep callback_error /data/logs/payment/*.log | tail -20值班同学拿到这条告警基本不需要再去看Dashboard就能判断问题的大致方向响应速度能快很多。4.4 自愈联动有些异常可以自动处理告警只是第一步PLFM_RADAR还做了一些轻量自愈的尝试。对于少数已经有明确处理方案的异常告警引擎会触发相应的执行动作。比如队列积压超限且消费线程数为0时自动重启消费组并通知值班某个供应商回调连续失败时自动切换备用通道单机处理耗时异常高时自动摘除该实例的负载自愈动作的执行结果会作为告警内容追加到原告警里这样值班同学被叫醒之后看到的不是发生了什么而是系统已经做了什么、现在状态如何。坦白说自愈功能需要非常谨慎我目前只开放了恢复类操作任何可能造成数据丢失的动作——比如清空队列、删表、回滚——一律从严限制宁可人工处理也不能让系统自作主张。5. 上线半年后的真实运行总结与三个值得做的扩展PLFM_RADAR从上线到现在跑了将近半年这一节不讲原理只讲真实数据和踩过的坑以及下一步计划做的几个扩展。5.1 实际检测效果和数据表现半年里PLFM_RADAR一共触发了143次告警其中P0五次P1二十二次P2一百一十六次。仔细复盘了一下143次告警里有11次是误报误报率约7.7%最集中的原因是上游服务发布时短时间抖动触发了组合规则。五次P0全部命中真实故障其中三次是队列积压两次是供应商接口超时都被值班团队在10分钟内处理完毕。和以前最大的对比是再也没有出现过用户比监控先发现问题的情况。哪怕凌晨三四点故障雷达也能在两三分钟内把电话打起来。数据说明这套思路整体是成立的。7.7%的误报率不能说绝对优秀但在可接受范围而且每一次误报复盘后我们都在规则层面做了优化误报率还在往下降。5.2 踩过的坑时间戳、重复计数和发布抖动时间戳问题前面已经提过这里再强调一次——跨时区、跨容器的采集环境里时间戳不一致会让整个滑动窗口算法失效。这是PLFM_RADAR踩过的最深的一个坑也是最容易忽略的一个坑。重复计数的问题出现在主动上报链路里。服务重启后内存中的计数器如果没做持久化会从0开始重新累加导致某个时刻数据突然腰斩。我后来把计数器的快照定期落到Redis里服务启动时先加载快照再继续计数这个问题就解决了。发布会造成数据短暂异常也是常态。每次上线发布请求量会有几十秒的抖动如果检测算法不够聪明就很容易把发布抖动误判成故障告警。PLFM_RADAR加了一个发布窗口配置每次有服务发布时针对该服务的检测规则在发布期间自动静默发布完成后再自动恢复正常检测。别小看这个机制它至少干掉了三成以上的误报。5.3 扩展一按维度下钻定位到具体对象现在的PLFM_RADAR是平台整体维度的能检测出订单成功率下降了但不能直接说出是哪个商品类别、哪个门店、哪个供应商导致的。下一步我计划给指标加上标签维度比如商品品类、门店ID、供应商ID、渠道来源。异常检测从平台级细化到对象级定位问题时能少走很多弯路。5.4 扩展二预测式告警而不是事后告警目前的滑动窗口算法是此时已经异常了才报警本质上是事后告警。雷达的终极形态应该是预测式告警——在异常真正发生之前就发出预警。我打算引入短时时间序列预测模型基于过去几小时的数据预测未来5分钟、10分钟的趋势如果预测值即将越过基线阈值提前发出预警级告警。这样故障的响应时间能从发生后10分钟进一步压缩到发生前几分钟开始准备。5.5 扩展三自动生成故障复盘报告每次P0/P1告警结束后都需要人工写复盘报告效率低且格式不统一。我计划让PLFM_RADAR记录完整的事件时间线什么时候开始偏离基线、什么时候触发告警、告警内容是什么、值班同学做了什么操作、指标什么时候恢复。所有字段打上时间戳事件结束后自动生成一份标准化的时间线报告人只需要补充根因分析。这个扩展做完复盘成本能从半天降到半小时。最后分享一点个人的体会。做PLFM_RADAR这半年我最大的感受是业务监控最难的不是技术而是搞清楚你到底在监测什么。算法和架构都有成熟方案可以借鉴但如果一开始没有把业务链路里最关键的信号梳理清楚后面做得再多也是在噪音里找信号。PLFM_RADAR的价值不在代码多优雅而在于它逼着我们团队把平台健康这件事从凭感觉变成了有依据从被动投诉变成了主动发现。如果你也在做类似的平台监控不妨先别急着写代码花几天时间把你们业务的核心链路画出来找出那几个一出问题业务准受影响的信号点——雷达的雏形往往就是从这张框图开始的。
PLFM_RADAR 这个名字是我自己起的全称是 Platform Radar翻译过来就是平台雷达。做它的初衷特别朴素——大概半年前我们平台一次线上故障从发生到被用户发现再到最终定位花了将近四十分钟。四十分钟里CPU、内存、磁盘这些基础设施监控全都没有任何反应因为服务根本没挂只是某个核心链路的订单数据在悄悄积压。监控面板上一片绿色业务实际已经半瘫痪。那次之后我一直在琢磨一件事能不能做一个能直接看到业务状态的雷达把这些散落在日志、消息队列、数据库里的信号统一收进来实时判断平台是不是真的健康。基础设施监控解决的是机器活没活着平台雷达要解决的是业务跑没跑得动。两者缺一不可。这就是 PLFM_RADAR 的来源。这篇文章不是要讲一个多复杂的分布式系统而是完整还原我在这个项目里的真实思考数据从哪来、异常怎么判、告警怎么不扰民、上线后踩了哪些坑。如果你所在的团队也经常遇到监控全绿但业务出问题的场景这套思路可以直接拿去参考。1. 先说清楚这套平台雷达到底在监测什么很多人在做监控的时候容易掉进一个误区一上来就堆指标把能采集的全部采一遍最后Dashboard上密密麻麻几百个图真出事的时候反而不知道看哪个。PLFM_RADAR在设计之初就定了一个原则——只监测那些业务出问题一定会变化的信号。1.1 传统监控覆盖不到的三个盲区传统的CPU、内存、磁盘、网络监控本质上是机器健康度监测。它们能告诉你服务器是不是还活着但很难告诉你业务是不是正常运转。我梳理了一下至少有三种典型故障是基础设施监控很难提前发现的积压型故障服务进程活着但消息队列里的数据越堆越多消费端处理不过来。此时CPU可能才30%内存也没爆表面一切正常。成功率跳水某个接口的失败率从0.1%突然涨到15%但总体QPS不高加起来也就几十次失败触发器根本不会响。链路局部阻塞网关层完全正常但下游某个供应商的接口超时了导致出单流程卡住用户侧表现为提交订单转圈。这类问题的共同点是只有从业务数据维度才能观测到。所以PLFM_RADAR的监测对象不是服务器而是平台上的核心交易链路。1.2 三类必须盯紧的业务信号我把平台健康度的信号分成了三大类每类下面再拆具体指标信号大类具体指标解释流量信号请求量、QPS、PV/UV、支付发起量有没有用户在进来、进来多少处理信号成功率、失败率、平均耗时、回调超时率进来的请求有没有被正确处理积压信号队列深度、待处理任务数、数据库堆积量是不是有什么东西在被悄悄积压这三类信号分别回答了三个问题有没有流量进来进来之后是不是被顺利处理了有没有哪个环节在积压只要这三个问题都有明确答案平台的健康度基本就能实时掌握。1.3 这套监测逻辑的适用范围PLFM_RADAR不绑定具体业务它是一套通用的业务雷达逻辑。我拿它适配过电商订单流程、内容审核链路、支付回调场景逻辑基本一致。比如电商场景下流量信号是下单请求量处理信号是订单创建成功率积压信号是支付回调队列深度内容审核场景下流量信号是上传量处理信号是审核完成率积压信号是待审核队列长度。用一句话概括就是任何有输入、有处理、有输出的业务流程都可以套这套雷达逻辑。它能帮你把所有业务环节的水流状态实时可视化。2. 数据采集层我用什么方式把散落的日志和指标收拢起来明确了监测什么之后下一个问题自然就是数据从哪来。这一层是整个PLFM_RADAR的地基地基不稳后面所有检测逻辑都是空中楼阁。2.1 选型原则不引入重量级全家桶开始之前我列了几条约束不能为了做监控专门部署一套完整的微服务全家桶不能要求所有业务线统一改代码接SDK最好是基于现有的日志和接口做轻量改造。所以最终方案是日志采集 主动上报 定时查询三管齐下每一类数据都用最合适的方式收。2.2 日志采集层的具体方案日志是最现成的信号源大部分服务本来就在打印业务日志。PLFM_RADAR的做法是给每一条核心业务日志加上一个结构化字段比如订单进入、订单成功、退款入队、回调收到然后再通过采集器把日志转发到统一的存储里。我用的是Filebeat做文件采集配置上监听各个服务的日志目录解析JSON格式的日志内容然后直接转发到Elasticsearch做索引。一个关键配置是给每条日志打上服务名和Pod标识这样后面查问题的时候可以按服务维度下钻也能快速判断是不是某一台实例出了问题。filebeat.inputs: - type: filestream enabled: true paths: - /data/logs/*.log parsers: - ndjson: target: overwrite_keys: true add_error_key: true output.elasticsearch: hosts: [es01:9200, es02:9200] index: plfm-log-%{yyyy.MM.dd}2.3 指标数据的两种来源日志解决了事件层面的问题但PLFM_RADAR还需要高质量的数值型指标来做异常检测。这一块我用了两种来源业务主动上报核心服务在处理订单、回调等关键节点时用类似prometheus客户端库的方式打点把订单进入量、处理成功量、失败量实时累加。定时拉取对于消息队列深度、数据库积压量这类没法靠打点获取的数据PLFM_RADAR写了一个定时任务每隔30秒调用队列管理API和数据库查询取当前积压数值。主动上报的好处是实时性好能精确到秒级定时拉取的好处是实现简单不侵入业务代码缺点是存在最多30秒的延迟。对于积压类指标来说30秒延迟完全在可接受范围内。2.4 一个容易忽略的坑所有时间戳必须统一时区这一点我在上线第一周就吃过亏。当时采集的服务分散在多个容器上有的容器时区是UTC有的是Asia/Shanghai结果同一时刻的订单数据被标成了不同的小时异常检测算法完全乱了套白天狂报流量骤降晚上狂报流量暴涨。解决方案是在采集端强制统一所有日志和指标在生成的时候就转成UTC时间戳存储展示的时候再转回本地时区。还有一个小细节——容器内的系统时间偶尔会漂移我加了一个定时任务每隔几分钟同步一次容器时间并在采集器里做了时间戳合理性校验如果发现日志时间比当前时间晚了超过5分钟直接标记为异常并告警。3. 异常检测核心从拍脑袋阈值到滑动窗口基线数据收上来之后最核心的问题就是怎么判断当前状态是不是异常PLFM_RADAR在这个问题上的演进过程我觉得很值得分享——它不是一上来就用了多高深的算法而是经历了一个从粗暴到精细的渐进过程。3.1 固定阈值方案为什么不行最初版本用的是最简单的固定阈值规则失败率大于5%就告警请求量低于每分钟1000就告警。上线当天就被现实教育了。白天高峰时段的请求量可能是凌晨的几十倍双十一活动期间的流量是平时的十倍还多。固定的阈值在两个场景下必然翻车一是高峰期稍微波动就触发误报二是低峰期真正的故障因为达不到阈值而漏报。更麻烦的是不同指标的正常区间差得太远根本不存在一个通用阈值可以应付所有情况。3.2 基于时间桶的滑动窗口基线后来我把思路从定死一个值变成了跟历史同期比。核心思想很简单同一个业务指标在相同的时间点上有稳定的周期规律——今天上午10点的流量大概率跟昨天上午10点的流量差不多如果不差不多说明有点异常了。具体实现分三步第一步把时间分桶。一天切成288个五分钟的桶每个桶有一个编号比如00:00-00:05是桶000:05-00:10是桶1以此类推。第二步滑动窗口存历史。每个桶都维护最近14天的历史数据。当新的数据进来它会被归入对应的桶同时最旧的那天数据会被淘汰掉。第三步计算基线和阈值。对每个桶计算历史数据的均值μ和标准差σ当前值x如果满足x μ k * σ就判定为异常。k是一个可调系数默认取3对应大约三西格玛的水平理论上假阳性率在0.3%左右。对于想控制误报的指标可以调大到4甚至5对于宁错杀不放过的关键指标可以调到2。3.3 检测模块的核心代码我写了一个轻量级的检测模块核心逻辑就几十行。这里贴一个简化版本去掉了一些配置和嵌套处理但主体逻辑完整保留import datetime import threading import numpy as np from collections import defaultdict class SlidingWindowDetector: def __init__(self, window_days14, k3.0): self.window_days window_days self.k k self.buckets defaultdict(list) # bucket_id - [history values] self.lock threading.Lock() def _bucket_id(self, ts): 把时间戳映射到5分钟桶编号返回 (日期, 桶序号) dt datetime.datetime.fromtimestamp(ts, tzdatetime.timezone.utc) bucket_no (dt.hour * 60 dt.minute) // 5 return dt.date(), bucket_no def add_sample(self, ts, value): 新数据进来更新对应桶的历史窗口 date_key, bucket_no self._bucket_id(ts) with self.lock: bucket_list self.buckets[bucket_no] bucket_list.append((date_key, value)) # 只保留最近 N 天数据 self.buckets[bucket_no] [ (d, v) for d, v in bucket_list if (date_key - d).days self.window_days ] def check(self, ts, value): 检测当前值是否异常。 如果历史数据不足3天返回 False数据不够不判断。 date_key, bucket_no self._bucket_id(ts) with self.lock: history [v for d, v in self.buckets.get(bucket_no, []) if d ! date_key] if len(history) 30: # 至少需要30个样本 return False mu np.mean(history) sigma np.std(history) if sigma 0: return abs(value - mu) 1e-6 threshold mu self.k * sigma return value threshold, value, mu self.k * sigma有几个细节值得注意。历史数据不足时不判断避免刚上线数据量不够导致乱报当天数据不参与基线计算防止故障日的数据把基线污染掉每个桶独立计算天然适配了业务指标的日周期性。3.4 从单指标异常到组合异常滑动窗口解决了单指标是否异常的问题但有些故障需要多个指标联合判断才准确。比如订单成功量跌了如果请求量也跟着跌可能只是流量太少如果请求量没跌但成功量跌了那就是处理链路有严重问题。我在PLFM_RADAR里加了一层规则引擎支持组合条件判断IF 请求量 基线 AND 成功量 基线*0.5 THEN 判定为处理链路异常这类组合规则大幅降低了误报率而且告警信息里能直接告诉值班同学是哪个环节出了问题定位路径一下子短了很多。4. 告警策略让声音响得恰到好处而不是接连轰炸检测算法再准如果告警发得没节制团队很快就麻木了真正的故障反而会被一堆垃圾告警淹没。PLFM_RADAR在告警策略上花的功夫不比检测算法少。4.1 告警分级是刚需我把告警分成三个级别不同级别用不同的触达通道和响应要求级别触发条件示例触达方式期望响应时间P0支付成功率跌到50%以下、队列积压超过1万电话短信群机器人立即响应P1失败率超过基线3倍、耗时超过基线2倍群机器人邮件10分钟内确认P2成功率缓慢下降、流量偏离基线30%邮件次日看板当天处理分级的意义不在于给告警贴个好看标签而在于让不同重要程度的问题用不同力度的方式打扰不同的人。P0半夜打电话能把人叫起来那P1就别用电话否则值班同学根本分不清哪个是真的紧急。4.2 告警降噪的四个关键机制这里分享PLFM_RADAR实际用下来最有效的四个降噪机制连续确认机制。单次数值超过阈值不告警连续N次每个周期30秒都超过才告警。比如失败率瞬时冲到8%可能只是抖动持续2分钟都在8%以上才是真问题。我把N设成连续4次也就是至少持续两分钟才触发能过滤掉大量瞬时尖峰。同因合并机制。同一个检测规则在15分钟内如果反复触发不再重复发告警只更新原告警的持续时长和当前值。否则一台实例抖动一下可能同时触发五六个通道的告警轰炸。静默期机制。某个告警触发后如果正在处理中允许值班同学手动置为处理中这个规则就进入静默直到处理完毕。避免一边排查一边还在被新告警狂轰乱炸。依赖维度分组。告警不是零散地发而是按故障链路聚合。比如支付回调链路有一项异常时只发一条聚合告警把涉及的服务、指标、波动幅度都列在里面。4.3 告警模板一定要带上可执行信息我见过太多告警长这样警告order_fail_rate异常。收到这种告警值班同学的第一反应不是去查而是骂人——因为这条告警没告诉他问题的严重程度、影响范围、跟历史数据差多少、应该从哪里开始查。PLFM_RADAR的告警模板强制包含以下内容规则名称、级别、触发时间指标当前值和基线值、偏离倍数涉及的服务/模块/机房最近5分钟的趋势上升还是持续高位关联的日志查询链接或命令一条实际的P1告警长这样【PLFM_RADAR P1】支付回调成功率异常 当前值72.3%过去5分钟基线值96.8%偏离1.34倍 影响模块payment-callback-consumer 趋势连续6个采样点低于基线呈持续下降趋势 相关日志grep callback_error /data/logs/payment/*.log | tail -20值班同学拿到这条告警基本不需要再去看Dashboard就能判断问题的大致方向响应速度能快很多。4.4 自愈联动有些异常可以自动处理告警只是第一步PLFM_RADAR还做了一些轻量自愈的尝试。对于少数已经有明确处理方案的异常告警引擎会触发相应的执行动作。比如队列积压超限且消费线程数为0时自动重启消费组并通知值班某个供应商回调连续失败时自动切换备用通道单机处理耗时异常高时自动摘除该实例的负载自愈动作的执行结果会作为告警内容追加到原告警里这样值班同学被叫醒之后看到的不是发生了什么而是系统已经做了什么、现在状态如何。坦白说自愈功能需要非常谨慎我目前只开放了恢复类操作任何可能造成数据丢失的动作——比如清空队列、删表、回滚——一律从严限制宁可人工处理也不能让系统自作主张。5. 上线半年后的真实运行总结与三个值得做的扩展PLFM_RADAR从上线到现在跑了将近半年这一节不讲原理只讲真实数据和踩过的坑以及下一步计划做的几个扩展。5.1 实际检测效果和数据表现半年里PLFM_RADAR一共触发了143次告警其中P0五次P1二十二次P2一百一十六次。仔细复盘了一下143次告警里有11次是误报误报率约7.7%最集中的原因是上游服务发布时短时间抖动触发了组合规则。五次P0全部命中真实故障其中三次是队列积压两次是供应商接口超时都被值班团队在10分钟内处理完毕。和以前最大的对比是再也没有出现过用户比监控先发现问题的情况。哪怕凌晨三四点故障雷达也能在两三分钟内把电话打起来。数据说明这套思路整体是成立的。7.7%的误报率不能说绝对优秀但在可接受范围而且每一次误报复盘后我们都在规则层面做了优化误报率还在往下降。5.2 踩过的坑时间戳、重复计数和发布抖动时间戳问题前面已经提过这里再强调一次——跨时区、跨容器的采集环境里时间戳不一致会让整个滑动窗口算法失效。这是PLFM_RADAR踩过的最深的一个坑也是最容易忽略的一个坑。重复计数的问题出现在主动上报链路里。服务重启后内存中的计数器如果没做持久化会从0开始重新累加导致某个时刻数据突然腰斩。我后来把计数器的快照定期落到Redis里服务启动时先加载快照再继续计数这个问题就解决了。发布会造成数据短暂异常也是常态。每次上线发布请求量会有几十秒的抖动如果检测算法不够聪明就很容易把发布抖动误判成故障告警。PLFM_RADAR加了一个发布窗口配置每次有服务发布时针对该服务的检测规则在发布期间自动静默发布完成后再自动恢复正常检测。别小看这个机制它至少干掉了三成以上的误报。5.3 扩展一按维度下钻定位到具体对象现在的PLFM_RADAR是平台整体维度的能检测出订单成功率下降了但不能直接说出是哪个商品类别、哪个门店、哪个供应商导致的。下一步我计划给指标加上标签维度比如商品品类、门店ID、供应商ID、渠道来源。异常检测从平台级细化到对象级定位问题时能少走很多弯路。5.4 扩展二预测式告警而不是事后告警目前的滑动窗口算法是此时已经异常了才报警本质上是事后告警。雷达的终极形态应该是预测式告警——在异常真正发生之前就发出预警。我打算引入短时时间序列预测模型基于过去几小时的数据预测未来5分钟、10分钟的趋势如果预测值即将越过基线阈值提前发出预警级告警。这样故障的响应时间能从发生后10分钟进一步压缩到发生前几分钟开始准备。5.5 扩展三自动生成故障复盘报告每次P0/P1告警结束后都需要人工写复盘报告效率低且格式不统一。我计划让PLFM_RADAR记录完整的事件时间线什么时候开始偏离基线、什么时候触发告警、告警内容是什么、值班同学做了什么操作、指标什么时候恢复。所有字段打上时间戳事件结束后自动生成一份标准化的时间线报告人只需要补充根因分析。这个扩展做完复盘成本能从半天降到半小时。最后分享一点个人的体会。做PLFM_RADAR这半年我最大的感受是业务监控最难的不是技术而是搞清楚你到底在监测什么。算法和架构都有成熟方案可以借鉴但如果一开始没有把业务链路里最关键的信号梳理清楚后面做得再多也是在噪音里找信号。PLFM_RADAR的价值不在代码多优雅而在于它逼着我们团队把平台健康这件事从凭感觉变成了有依据从被动投诉变成了主动发现。如果你也在做类似的平台监控不妨先别急着写代码花几天时间把你们业务的核心链路画出来找出那几个一出问题业务准受影响的信号点——雷达的雏形往往就是从这张框图开始的。
