干监控运维这些年我一直觉得最讽刺的一件事是平台越大我们对它的“感知”反而越模糊。前段时间团队复盘一次线上事故下单量悄悄跌了快三成愣是没有任何告警直到用户投诉涌进来我们才从日志里翻出真相——上游一个接口不停超时重试把线程池打满了。事后所有人都在问监控系统都在干嘛答案不是没数据而是数据太多太散没有人能拼出完整画面。PLFM_RADAR 就是被这类事故逼出来的项目。PLFM 就是 Platform 的缩写RADAR 不是花哨的包装——雷达的工作循环是“扫描、发现、跟踪、判定”这恰好是平台监控该有的工作方式。这套系统做的事情很简单把基础设施、应用、业务三层信号统一收拢到一个“雷达屏”上用一套统一的算法自动识别异常、分级告警、跟踪恢复让值班的人不用再在五六个看板之间来回切换也能知道平台到底健不健康。这篇文章我会把 PLFM_RADAR 从设计思路到落地细节完整拆解包括怎么定指标、怎么选异常检测算法、怎么让告警不成“狼来了”以及我踩过的坑。不管你是平台运维、后端开发还是数据工程师里面应该都有可以直接抄作业的部分。1. 项目定位为什么平台需要一台“雷达”1.1 雷达模型对平台监控的启示真实雷达的工作流程是这样的发射电磁波持续扫描空域接收回波信号后从大量杂波里滤出目标然后持续跟踪目标的位置和运动轨迹最后综合速度、方向等信息判断这个目标到底是友军还是威胁。拆解下来核心是四个动作扫描、滤波、跟踪、识别。平台监控面临的处境和雷达高度重合。基础设施指标、应用性能指标、业务转化指标这些信号满天飞就像雷达屏幕上密密麻麻的杂波真正的故障往往一开始只是一个小异常不会立刻击穿阈值而一个指标单独看都正常组合起来可能意味着平台正在出大问题。传统监控的“埋点—阈值—告警”是一条线性链它只关心“当前时刻是否超限”完全不关心趋势和上下文。雷达模型比它多出来的关键一环就是“跟踪”持续观察一个指标的变化轨迹判断它是在正常抖动还是已经进入了恶化通道。这也是为什么我把项目命名为 RADAR。设计每一个模块时我都会问自己一句真实雷达在这个环节会怎么处理采集频率应该多密才能不漏掉“目标”用什么方法滤除抖动噪声才不至于天天误报怎么定义“威胁等级”才不会让值班人员在告警轰炸里麻木这些问题的答案最终都沉淀进了架构和算法选型里。1.2 我们要解决的三个核心痛点痛点一指标孤岛。当时团队的工具链是这样的机器资源指标在自建监控系统里接口延迟和错误率在另一个 APM 工具里订单等业务数据散落在报表平台。三个系统各有各的看板各有各的口径。平台出故障时值班同学要先登三个系统人工比对时间线才能勉强拼出事故轮廓。这个过程少则十几分钟多则半小时而线上故障的黄金处置时间往往就在前五分钟。PLFM_RADAR 的第一个目标就是统一收口所有信号进同一个管道用同一套时间轴对齐。痛点二阈值静态。传统的固定阈值告警比如“接口错误率超过 1% 就报警”写起来简单用起来难受。大促期间流量翻倍错误率波动本来就大固定阈值要么频繁误报要么因为阈值调太宽而漏掉真问题。而且不同接口、不同业务的基线差异很大核心支付接口的错误率必须卡在 0.1%而某个内部工具接口即使到 5% 也未必需要惊动值班。静态阈值无法适配这种动态差异就必然走向误报和漏报的两难。痛点三告警疲劳。我见过最夸张的情况一个告警群里一天刷了八百多条通知其中大部分是同一个问题在不同监控规则下的重复触发。值班同学从最开始点开每条通知到后面划掉整个群只用了一个星期。告警疲劳比没有监控更可怕——它会让人在真正需要响应的时候选择性失明。所以 PLFM_RADAR 从设计第一天就把“告警收敛”当成核心需求而不是事后补救的功能。2. 架构设计与方案选型从信号采集到预警闭环2.1 三层数据采集基础设施、应用、业务整个采集层我按信号来源分成三条线每条线独立采集、统一上报基础设施层包括 CPU、内存、磁盘、网络、GC 等资源指标用常见的 agent 采集器就能覆盖。采集频率我设在 15 秒一次理由稍后细说。应用层包括接口 QPS、错误率、延迟分位数这些运行时指标。这里最关键的选型点是埋点方式我没有用侵入式代码埋点而是选择在统一的中间件层做切面采集这样业务代码零改动接入成本低也避免因为埋点遗漏导致监控盲区。业务层包括下单量、支付成功率、核心漏斗转化率等业务指标。这一层的数据往往不在技术监控的视野里需要从业务事件流中聚合出来。实现上通过消息队列实时上报关键业务事件再由聚合任务按分钟粒度计算指标。三条线的数据最终统一进入消息队列做格式标准化和时间对齐之后再写入存储。这里有一个非常重要的细节每类指标都必须带三个属性——指标名、标签集合、时间戳。没有统一标签规范的话后面做多维分析会非常痛苦。比如同样是“下单量”这个指标有的系统叫 order_count有的叫 order_num不统一口径聚合出来的结果就是灾难。2.2 存储与计算选型时序数据库加流批混合指标数据的特点是持续写入、按时间维度查询、很少更新。这种负载天生适合时序数据库。我选型时对比过几种方案最终选择了对高基数场景支持更好的时序库配合保留策略做分级降精度存储最近 7 天保留原始精度30 天降采样到分钟级更久的历史只保留小时级聚合。这样既保证近期排障能查到细节又控制住了存储成本。计算层我采用的是流批混合。实时链路负责异常检测和告警判定用流处理框架消费消息队列里的指标事件通过滑动窗口实时计算各项统计量。批处理链路负责生成趋势基线、周期性特征等需要历史数据的模型每天定时跑一次把结果同步给实时检测模块使用。选型背后有个考量纯流式计算写起来灵活但对于同比、环比这类需要“拿今天和上周同日比较”的逻辑流式状态管理会变得很重。把基线计算放到批处理实时模块只做比较判断架构清晰很多。这算是我踩过不少坑之后总结出来的相对省心的分工方式。2.3 告警分级与响应闭环三种链路三种力度告警模块我按照“影响面”和“紧急度”分了三级对应不同的通知渠道和响应方式告警级别触发条件示例通知渠道期望响应时间P0核心链路可用性低于 99% 或错误率持续超限电话加短信加 IM 群5 分钟内P1延迟 P95 超过基线 1.5 倍且持续 10 分钟IM 群加短信15 分钟内P2非核心业务指标出现异常波动IM 群汇总推送当天跟进坚持“响应时间”和“打扰程度”匹配是告警设计里我最想强调的一条原则。如果 P2 也用电话轰炸那这个系统和没有告警系统没有区别。另外每一条告警触发后都要求自动创建一条事件记录包含触发时间、相关指标曲线、关联的标签维度这样值班同学打开告警就能直接看到上下文不用再去翻看板找数据。告警恢复后自动关闭事件并在群里发送恢复通知形成完整的“触发—响应—恢复”闭环。3. 核心环节的实操实现指标、算法、收敛三件事3.1 指标体系怎么定少而准而不是多而全很多团队做监控平台指标越接越多最后看板上一屏放不下真正看起来的没几个。PLFM_RADAR 在指标选择上坚持三个原则一是可行动性一个指标异常时值班人员必须知道该找哪个团队、查哪个服务否则就是噪音二是信号效率优先选能快速反映平台健康状况的指标不能等到用户感知了指标才变化三是分层覆盖基础设施、应用、业务每层选少量核心指标避免重复表达同一个故障信号。分层典型指标采集频率核心关注点基础设施层CPU 使用率、内存用量、磁盘 IO、GC 耗时15 秒资源耗尽和瓶颈应用层QPS、错误率、P50/P95 延迟、线程池活跃度30 秒服务健康与性能劣化业务层下单量、支付成功率、核心漏斗转化率60 秒用户体验与营收影响频率的选择也值得说两句。基础设施指标 15 秒采集是因为资源类指标的异常往往来得很快CPU 打满可能就在几秒之内频率太低会错过峰值。业务指标 60 秒足够因为业务异常通常不会在几秒内消失而且业务指标噪声大频率过高反而会造成误报。不要为了追求“实时”而把所有指标都提到秒级成本和收益不成比例。3.2 异常检测算法固定阈值之外的三板斧固定阈值不是不能用但不应该作为唯一手段。PLFM_RADAR 实际落地了三种动态检测方法分别适配不同类型的指标第一种是滑动窗口加 3 倍标准差适合 CPU 使用率这类相对平稳的指标。做法是维护一个最近 15 分钟的窗口计算均值和标准差当前值超过均值加 3 倍标准差就判定异常。这个方法的优点是简单、可解释缺点是真实监控数据的分布往往是重尾的直接套用标准差会被极端值拉偏。所以我在实现时做了一点改进把标准差换成更稳健的 MAD中位数绝对偏差阈值卡在均值加 3 倍 MAD 上对偶发毛刺的容忍度明显提升。第二种是指数加权移动平均EWMA适合接口延迟这类需要快速捕捉突变的指标。EWMA 的核心思想是给近期数据更高的权重让平滑值更快贴近当前水平再拿实际值和平滑值之间的偏差来判断是否突变。我最初用固定阈值卡延迟绝对值结果大促期间天天误报换成 EWMA 之后它对“延迟突然比近期水平高出一截”这类变化更敏感同时又能自然适配不同时段的基线水平。实际参数上衰减系数我取了 0.33 个标准差的判异范围这个组合在我们的数据上误报和漏报相对均衡。第三种是同比环比加季节性分解适合有明显日周期规律的业务指标比如下单量、活跃用户数。这类指标不处理周期性直接套用前两种方法会有问题凌晨的低谷和晚间高峰的标准差差异巨大同一个阈值根本不成立。我的做法是先按天构建历史基线用过去 7 天同一时刻的中位数作为基准值再计算当前值相对基准值的偏离比例超过设定比例才告警。这种方法还有一个好处天然支持活动效应比如上周同期正好在做促销基线里就包含了促销的拉升不会把正常的活动波动当异常。# 季节性同比检测的简化实现示意 def seasonal_deviate(current_value, ts): # 取过去7天同一时刻的序列 baseline history_lookup(ts, days7, same_minuteTrue) base_med median(baseline) base_mad median([abs(x - base_med) for x in baseline]) # 用偏离倍数来判定而不是绝对阈值 dev_ratio (current_value - base_med) / (base_mad 1e-6) return dev_ratio 5.0 # 超过5倍MAD才判定异常三种方法并不是非此即彼的关系。我的配置经验是每个指标可以同时启用多种检测方法只要任何一种判定异常就触发告警但触发后的告警等级要按更严格的方法来评估。比如季节性偏差方法捕捉到业务指标异常如果同时 EWMA 也触发了说明可能确实是技术故障级别可以上调。3.3 告警收敛与通知路由把“狼来了”变成“狼真的来了”告警收敛是整个系统里最花心思的部分也是被最多团队低估的部分。我在落地过程中主要做了四层收敛。第一层是聚合去重。同一个服务在短时间内多个实例上报相同指标异常系统会自动聚合成一条告警而不是每台机器各发一条。细节在于聚合的 key 怎么设计我用的维度组合是“指标名加服务名加异常类型”实例 IP 只作为详情信息保留不作为聚合维度。第二层是持续时间确认。一次抖动触发的检测结果不直接发告警而是先进入一个观察窗口比如持续 3 个检测周期仍然异常才正式触发。这一层能过滤掉大量瞬时毛刺。代价是告警延迟但对于绝大多数场景晚一两分钟确认远好过大半夜被一条假告警叫醒。第三层是维护窗口。发布变更期间关停或降级告警避免发布动作本身触发告警轰炸。我在接入 CI/CD 流水线时留了一个 webhook发布开始和结束自动切换维护窗口状态。没有这层设计之前每次发版自动发一轮告警值班同学基本都把发布时段的告警直接免疫了真出事反而在群里找不到人。第四层是告警升级机制。一条 P2 告警如果持续超过 30 分钟没有认领自动升级为 P1 并通知到更高级别的响应人P1 超过 15 分钟没有响应自动电话通知。升级机制保证了告警不会因为没人看而悄悄消失同时也没有在第一时间骚扰所有人。4. 常见问题与排查经验实录那些文档里不会写的坑4.1 误报率居高不下怎么把阈值调到“刚刚好”PLFM_RADAR 上线初期误报率一度高得离谱最严重的一天告警群里三分之一的通知是假的。深入排查后发现原因有三类第一类是检测窗口太短指标本身是有业务周期的15 分钟的窗口在流量尖峰时段样本不足统计量不稳定第二类是重尾分布问题用标准差做判异在 CPU 这类指标上还行但在延迟这种长尾指标上很容易被极端值拉偏第三类是小流量指标问题某个低频接口一天只有几百次调用错误率波动天然剧烈偶尔出现一次错误就从 0 跳到 10%。针对这三类原因我分别做了调整窗口长度从固定值改成按指标配置业务指标至少覆盖两个完整周期判异统计量全面换成更稳健的中位数加 MAD小流量指标引入最小样本量限制样本量不足时直接用固定阈值并降低告警级别。另外我在告警触发逻辑里加了一个“多指标关联确认”的可选策略只有当两个及以上相关指标同时异常时才触发最高等级告警。比如下单量异常的同时接口错误率也升高那基本可以确认不是偶发问题。这套组合拳打下来误报率降到了可接受的范围。4.2 数据延迟导致漏报和重复告警时序数据最常见的隐形杀手是数据乱序和回填。我们遇到过这样的情况某个业务模块因为自身问题指标上报延迟了好几分钟批量补数据时检测模块把“过去五分钟的曲线整体拉高”瞬间触发了一串历史告警。值班同学凌晨三点被这些“过去式”告警叫醒体验极差。解决方式是在检测模块里加了一个数据新鲜度检查只有当前时间减去指标时间戳在允许的延迟窗口内才会参与实时检测超过延迟窗口的数据直接进入离线通道不触发告警。延迟窗口的设置需要权衡太短会把一些本来可以提前发现的异常延后太长又会导致补数据触发误报。我们的经验值设置在 3 分钟配合告警停留观察期基本能覆盖绝大多数上报延迟场景。4.3 资源开销与成本控制实时监控的代价实时监控的隐性成本容易被忽略。高频采集加实时计算每个指标每秒都要过一遍检测逻辑指标一多计算开销就往上涨。我在成本控制上做了几件事一是所有指标默认都做降精度存储原始数据只保留最近 7 天超过 7 天的按分钟聚合保存超过 30 天的再聚合成小时级二是检测频率和采集频率解耦不是所有指标都需要每种算法都跑平稳型指标可以用较低的检测频率只有核心链路指标才全算法跑满三是把不必要的标签维度从指标中拆出去高基数标签是时序数据库查询性能的最大杀手一个本来不需要拆分的维度可能会把存储和查询成本放大好几倍。还有一个容易被忽略的点告警消息本身也占成本。短信和电话通道按条计费所以我做了预算控制——每级别的告警每天有数量上限超过上限的同类告警自动合并成日报摘要。这条策略既控制成本也倒逼大家把告警规则写得更精准。5. 一些个人体会作为收尾PLFM_RADAR 从设计到稳定运行前后迭代了好几轮最大的变化不在技术实现上而在团队的使用习惯上。早期大家还是习惯性地去翻各个系统看板不太信任这个“雷达屏”随着误报率降下来告警上下文越带越全值班交接从“我去看下 APM”变成了“雷达上已经开始追了”这套系统才算真正活了。如果让我给准备做类似平台监控的团队一句建议那就是先定指标再谈算法。异常检测模型再花哨指标选错了全是白搭。另外一定要在项目早期就把“告警收敛”提上日程它决定的是整个监控系统的可信度可信度没了再准的算法也拦不住值班同学把告警群消息划走。最后再分享一个小技巧给每条告警规则写一个“预期行为说明”。比如这条规则在什么场景下会触发、触发后应该找哪个团队、大概是什么原因。这些说明会跟着告警事件一起推送给值班人极大缩短排障时间。坚持半年之后沉淀下来这套说明基本就是团队最接地气的故障处置手册。
干监控运维这些年我一直觉得最讽刺的一件事是平台越大我们对它的“感知”反而越模糊。前段时间团队复盘一次线上事故下单量悄悄跌了快三成愣是没有任何告警直到用户投诉涌进来我们才从日志里翻出真相——上游一个接口不停超时重试把线程池打满了。事后所有人都在问监控系统都在干嘛答案不是没数据而是数据太多太散没有人能拼出完整画面。PLFM_RADAR 就是被这类事故逼出来的项目。PLFM 就是 Platform 的缩写RADAR 不是花哨的包装——雷达的工作循环是“扫描、发现、跟踪、判定”这恰好是平台监控该有的工作方式。这套系统做的事情很简单把基础设施、应用、业务三层信号统一收拢到一个“雷达屏”上用一套统一的算法自动识别异常、分级告警、跟踪恢复让值班的人不用再在五六个看板之间来回切换也能知道平台到底健不健康。这篇文章我会把 PLFM_RADAR 从设计思路到落地细节完整拆解包括怎么定指标、怎么选异常检测算法、怎么让告警不成“狼来了”以及我踩过的坑。不管你是平台运维、后端开发还是数据工程师里面应该都有可以直接抄作业的部分。1. 项目定位为什么平台需要一台“雷达”1.1 雷达模型对平台监控的启示真实雷达的工作流程是这样的发射电磁波持续扫描空域接收回波信号后从大量杂波里滤出目标然后持续跟踪目标的位置和运动轨迹最后综合速度、方向等信息判断这个目标到底是友军还是威胁。拆解下来核心是四个动作扫描、滤波、跟踪、识别。平台监控面临的处境和雷达高度重合。基础设施指标、应用性能指标、业务转化指标这些信号满天飞就像雷达屏幕上密密麻麻的杂波真正的故障往往一开始只是一个小异常不会立刻击穿阈值而一个指标单独看都正常组合起来可能意味着平台正在出大问题。传统监控的“埋点—阈值—告警”是一条线性链它只关心“当前时刻是否超限”完全不关心趋势和上下文。雷达模型比它多出来的关键一环就是“跟踪”持续观察一个指标的变化轨迹判断它是在正常抖动还是已经进入了恶化通道。这也是为什么我把项目命名为 RADAR。设计每一个模块时我都会问自己一句真实雷达在这个环节会怎么处理采集频率应该多密才能不漏掉“目标”用什么方法滤除抖动噪声才不至于天天误报怎么定义“威胁等级”才不会让值班人员在告警轰炸里麻木这些问题的答案最终都沉淀进了架构和算法选型里。1.2 我们要解决的三个核心痛点痛点一指标孤岛。当时团队的工具链是这样的机器资源指标在自建监控系统里接口延迟和错误率在另一个 APM 工具里订单等业务数据散落在报表平台。三个系统各有各的看板各有各的口径。平台出故障时值班同学要先登三个系统人工比对时间线才能勉强拼出事故轮廓。这个过程少则十几分钟多则半小时而线上故障的黄金处置时间往往就在前五分钟。PLFM_RADAR 的第一个目标就是统一收口所有信号进同一个管道用同一套时间轴对齐。痛点二阈值静态。传统的固定阈值告警比如“接口错误率超过 1% 就报警”写起来简单用起来难受。大促期间流量翻倍错误率波动本来就大固定阈值要么频繁误报要么因为阈值调太宽而漏掉真问题。而且不同接口、不同业务的基线差异很大核心支付接口的错误率必须卡在 0.1%而某个内部工具接口即使到 5% 也未必需要惊动值班。静态阈值无法适配这种动态差异就必然走向误报和漏报的两难。痛点三告警疲劳。我见过最夸张的情况一个告警群里一天刷了八百多条通知其中大部分是同一个问题在不同监控规则下的重复触发。值班同学从最开始点开每条通知到后面划掉整个群只用了一个星期。告警疲劳比没有监控更可怕——它会让人在真正需要响应的时候选择性失明。所以 PLFM_RADAR 从设计第一天就把“告警收敛”当成核心需求而不是事后补救的功能。2. 架构设计与方案选型从信号采集到预警闭环2.1 三层数据采集基础设施、应用、业务整个采集层我按信号来源分成三条线每条线独立采集、统一上报基础设施层包括 CPU、内存、磁盘、网络、GC 等资源指标用常见的 agent 采集器就能覆盖。采集频率我设在 15 秒一次理由稍后细说。应用层包括接口 QPS、错误率、延迟分位数这些运行时指标。这里最关键的选型点是埋点方式我没有用侵入式代码埋点而是选择在统一的中间件层做切面采集这样业务代码零改动接入成本低也避免因为埋点遗漏导致监控盲区。业务层包括下单量、支付成功率、核心漏斗转化率等业务指标。这一层的数据往往不在技术监控的视野里需要从业务事件流中聚合出来。实现上通过消息队列实时上报关键业务事件再由聚合任务按分钟粒度计算指标。三条线的数据最终统一进入消息队列做格式标准化和时间对齐之后再写入存储。这里有一个非常重要的细节每类指标都必须带三个属性——指标名、标签集合、时间戳。没有统一标签规范的话后面做多维分析会非常痛苦。比如同样是“下单量”这个指标有的系统叫 order_count有的叫 order_num不统一口径聚合出来的结果就是灾难。2.2 存储与计算选型时序数据库加流批混合指标数据的特点是持续写入、按时间维度查询、很少更新。这种负载天生适合时序数据库。我选型时对比过几种方案最终选择了对高基数场景支持更好的时序库配合保留策略做分级降精度存储最近 7 天保留原始精度30 天降采样到分钟级更久的历史只保留小时级聚合。这样既保证近期排障能查到细节又控制住了存储成本。计算层我采用的是流批混合。实时链路负责异常检测和告警判定用流处理框架消费消息队列里的指标事件通过滑动窗口实时计算各项统计量。批处理链路负责生成趋势基线、周期性特征等需要历史数据的模型每天定时跑一次把结果同步给实时检测模块使用。选型背后有个考量纯流式计算写起来灵活但对于同比、环比这类需要“拿今天和上周同日比较”的逻辑流式状态管理会变得很重。把基线计算放到批处理实时模块只做比较判断架构清晰很多。这算是我踩过不少坑之后总结出来的相对省心的分工方式。2.3 告警分级与响应闭环三种链路三种力度告警模块我按照“影响面”和“紧急度”分了三级对应不同的通知渠道和响应方式告警级别触发条件示例通知渠道期望响应时间P0核心链路可用性低于 99% 或错误率持续超限电话加短信加 IM 群5 分钟内P1延迟 P95 超过基线 1.5 倍且持续 10 分钟IM 群加短信15 分钟内P2非核心业务指标出现异常波动IM 群汇总推送当天跟进坚持“响应时间”和“打扰程度”匹配是告警设计里我最想强调的一条原则。如果 P2 也用电话轰炸那这个系统和没有告警系统没有区别。另外每一条告警触发后都要求自动创建一条事件记录包含触发时间、相关指标曲线、关联的标签维度这样值班同学打开告警就能直接看到上下文不用再去翻看板找数据。告警恢复后自动关闭事件并在群里发送恢复通知形成完整的“触发—响应—恢复”闭环。3. 核心环节的实操实现指标、算法、收敛三件事3.1 指标体系怎么定少而准而不是多而全很多团队做监控平台指标越接越多最后看板上一屏放不下真正看起来的没几个。PLFM_RADAR 在指标选择上坚持三个原则一是可行动性一个指标异常时值班人员必须知道该找哪个团队、查哪个服务否则就是噪音二是信号效率优先选能快速反映平台健康状况的指标不能等到用户感知了指标才变化三是分层覆盖基础设施、应用、业务每层选少量核心指标避免重复表达同一个故障信号。分层典型指标采集频率核心关注点基础设施层CPU 使用率、内存用量、磁盘 IO、GC 耗时15 秒资源耗尽和瓶颈应用层QPS、错误率、P50/P95 延迟、线程池活跃度30 秒服务健康与性能劣化业务层下单量、支付成功率、核心漏斗转化率60 秒用户体验与营收影响频率的选择也值得说两句。基础设施指标 15 秒采集是因为资源类指标的异常往往来得很快CPU 打满可能就在几秒之内频率太低会错过峰值。业务指标 60 秒足够因为业务异常通常不会在几秒内消失而且业务指标噪声大频率过高反而会造成误报。不要为了追求“实时”而把所有指标都提到秒级成本和收益不成比例。3.2 异常检测算法固定阈值之外的三板斧固定阈值不是不能用但不应该作为唯一手段。PLFM_RADAR 实际落地了三种动态检测方法分别适配不同类型的指标第一种是滑动窗口加 3 倍标准差适合 CPU 使用率这类相对平稳的指标。做法是维护一个最近 15 分钟的窗口计算均值和标准差当前值超过均值加 3 倍标准差就判定异常。这个方法的优点是简单、可解释缺点是真实监控数据的分布往往是重尾的直接套用标准差会被极端值拉偏。所以我在实现时做了一点改进把标准差换成更稳健的 MAD中位数绝对偏差阈值卡在均值加 3 倍 MAD 上对偶发毛刺的容忍度明显提升。第二种是指数加权移动平均EWMA适合接口延迟这类需要快速捕捉突变的指标。EWMA 的核心思想是给近期数据更高的权重让平滑值更快贴近当前水平再拿实际值和平滑值之间的偏差来判断是否突变。我最初用固定阈值卡延迟绝对值结果大促期间天天误报换成 EWMA 之后它对“延迟突然比近期水平高出一截”这类变化更敏感同时又能自然适配不同时段的基线水平。实际参数上衰减系数我取了 0.33 个标准差的判异范围这个组合在我们的数据上误报和漏报相对均衡。第三种是同比环比加季节性分解适合有明显日周期规律的业务指标比如下单量、活跃用户数。这类指标不处理周期性直接套用前两种方法会有问题凌晨的低谷和晚间高峰的标准差差异巨大同一个阈值根本不成立。我的做法是先按天构建历史基线用过去 7 天同一时刻的中位数作为基准值再计算当前值相对基准值的偏离比例超过设定比例才告警。这种方法还有一个好处天然支持活动效应比如上周同期正好在做促销基线里就包含了促销的拉升不会把正常的活动波动当异常。# 季节性同比检测的简化实现示意 def seasonal_deviate(current_value, ts): # 取过去7天同一时刻的序列 baseline history_lookup(ts, days7, same_minuteTrue) base_med median(baseline) base_mad median([abs(x - base_med) for x in baseline]) # 用偏离倍数来判定而不是绝对阈值 dev_ratio (current_value - base_med) / (base_mad 1e-6) return dev_ratio 5.0 # 超过5倍MAD才判定异常三种方法并不是非此即彼的关系。我的配置经验是每个指标可以同时启用多种检测方法只要任何一种判定异常就触发告警但触发后的告警等级要按更严格的方法来评估。比如季节性偏差方法捕捉到业务指标异常如果同时 EWMA 也触发了说明可能确实是技术故障级别可以上调。3.3 告警收敛与通知路由把“狼来了”变成“狼真的来了”告警收敛是整个系统里最花心思的部分也是被最多团队低估的部分。我在落地过程中主要做了四层收敛。第一层是聚合去重。同一个服务在短时间内多个实例上报相同指标异常系统会自动聚合成一条告警而不是每台机器各发一条。细节在于聚合的 key 怎么设计我用的维度组合是“指标名加服务名加异常类型”实例 IP 只作为详情信息保留不作为聚合维度。第二层是持续时间确认。一次抖动触发的检测结果不直接发告警而是先进入一个观察窗口比如持续 3 个检测周期仍然异常才正式触发。这一层能过滤掉大量瞬时毛刺。代价是告警延迟但对于绝大多数场景晚一两分钟确认远好过大半夜被一条假告警叫醒。第三层是维护窗口。发布变更期间关停或降级告警避免发布动作本身触发告警轰炸。我在接入 CI/CD 流水线时留了一个 webhook发布开始和结束自动切换维护窗口状态。没有这层设计之前每次发版自动发一轮告警值班同学基本都把发布时段的告警直接免疫了真出事反而在群里找不到人。第四层是告警升级机制。一条 P2 告警如果持续超过 30 分钟没有认领自动升级为 P1 并通知到更高级别的响应人P1 超过 15 分钟没有响应自动电话通知。升级机制保证了告警不会因为没人看而悄悄消失同时也没有在第一时间骚扰所有人。4. 常见问题与排查经验实录那些文档里不会写的坑4.1 误报率居高不下怎么把阈值调到“刚刚好”PLFM_RADAR 上线初期误报率一度高得离谱最严重的一天告警群里三分之一的通知是假的。深入排查后发现原因有三类第一类是检测窗口太短指标本身是有业务周期的15 分钟的窗口在流量尖峰时段样本不足统计量不稳定第二类是重尾分布问题用标准差做判异在 CPU 这类指标上还行但在延迟这种长尾指标上很容易被极端值拉偏第三类是小流量指标问题某个低频接口一天只有几百次调用错误率波动天然剧烈偶尔出现一次错误就从 0 跳到 10%。针对这三类原因我分别做了调整窗口长度从固定值改成按指标配置业务指标至少覆盖两个完整周期判异统计量全面换成更稳健的中位数加 MAD小流量指标引入最小样本量限制样本量不足时直接用固定阈值并降低告警级别。另外我在告警触发逻辑里加了一个“多指标关联确认”的可选策略只有当两个及以上相关指标同时异常时才触发最高等级告警。比如下单量异常的同时接口错误率也升高那基本可以确认不是偶发问题。这套组合拳打下来误报率降到了可接受的范围。4.2 数据延迟导致漏报和重复告警时序数据最常见的隐形杀手是数据乱序和回填。我们遇到过这样的情况某个业务模块因为自身问题指标上报延迟了好几分钟批量补数据时检测模块把“过去五分钟的曲线整体拉高”瞬间触发了一串历史告警。值班同学凌晨三点被这些“过去式”告警叫醒体验极差。解决方式是在检测模块里加了一个数据新鲜度检查只有当前时间减去指标时间戳在允许的延迟窗口内才会参与实时检测超过延迟窗口的数据直接进入离线通道不触发告警。延迟窗口的设置需要权衡太短会把一些本来可以提前发现的异常延后太长又会导致补数据触发误报。我们的经验值设置在 3 分钟配合告警停留观察期基本能覆盖绝大多数上报延迟场景。4.3 资源开销与成本控制实时监控的代价实时监控的隐性成本容易被忽略。高频采集加实时计算每个指标每秒都要过一遍检测逻辑指标一多计算开销就往上涨。我在成本控制上做了几件事一是所有指标默认都做降精度存储原始数据只保留最近 7 天超过 7 天的按分钟聚合保存超过 30 天的再聚合成小时级二是检测频率和采集频率解耦不是所有指标都需要每种算法都跑平稳型指标可以用较低的检测频率只有核心链路指标才全算法跑满三是把不必要的标签维度从指标中拆出去高基数标签是时序数据库查询性能的最大杀手一个本来不需要拆分的维度可能会把存储和查询成本放大好几倍。还有一个容易被忽略的点告警消息本身也占成本。短信和电话通道按条计费所以我做了预算控制——每级别的告警每天有数量上限超过上限的同类告警自动合并成日报摘要。这条策略既控制成本也倒逼大家把告警规则写得更精准。5. 一些个人体会作为收尾PLFM_RADAR 从设计到稳定运行前后迭代了好几轮最大的变化不在技术实现上而在团队的使用习惯上。早期大家还是习惯性地去翻各个系统看板不太信任这个“雷达屏”随着误报率降下来告警上下文越带越全值班交接从“我去看下 APM”变成了“雷达上已经开始追了”这套系统才算真正活了。如果让我给准备做类似平台监控的团队一句建议那就是先定指标再谈算法。异常检测模型再花哨指标选错了全是白搭。另外一定要在项目早期就把“告警收敛”提上日程它决定的是整个监控系统的可信度可信度没了再准的算法也拦不住值班同学把告警群消息划走。最后再分享一个小技巧给每条告警规则写一个“预期行为说明”。比如这条规则在什么场景下会触发、触发后应该找哪个团队、大概是什么原因。这些说明会跟着告警事件一起推送给值班人极大缩短排障时间。坚持半年之后沉淀下来这套说明基本就是团队最接地气的故障处置手册。
