从零搭建平台监控预警系统：PLFM_RADAR设计实践

PLFM_RADAR 这个名字放在一起大概就能猜到一半意思Platform Radar平台雷达。这是我去年在团队里从零搭起来的一套平台核心指标监控与预警系统外面是张漂亮的看板里面实际上是一条从数据采集、异常判定、告警通知到归因分析的完整链路。当时做它的原因很简单服务从十几个涨到几十个指标散落在各个后台出问题经常是用户先发现、客服转过来团队才知道“哦挂了”。有了 PLFM_RADAR系统就能7×24小时盯着关键指标用基线而不是固定阈值来判断业务是不是异常找到异常后还会自动拉一遍关联指标做归因分析再把结论推到值班群。这篇文章就围绕 PLFM_RADAR 从需求拆解、架构选型、核心实现到落地踩坑的全过程来写适合后端开发、SRE、数据开发尤其是那些没有专职监控团队、想自己搭一套靠谱监控体系的中小团队参考。1. PLFM_RADAR 是怎么来的从“救火”到“雷达”1.1 需求不是规划出来的是被故障逼出来的一开始团队不是没有监控。机器有 CPU、内存、磁盘告警接口有存活检测数据库也有慢查询日志但这些东西彼此孤立各看各的。真正出问题的时候往往是业务指标先掉比如登录量突然腰斩、下单链路超时率飙升而基础设施指标还“岁月静好”。等机器指标开始异常业务其实已经受了很长时间的伤。更痛苦的是排查。一条“用户反馈支付失败”的消息进来我们得先把链路捋一遍查网关、查服务日志、查数据库连接数、查第三方回调前前后后最快也要十几分钟才能定位到根因。这期间用户一直在叠加反馈。所以大家达成了一个共识不能只在“挂了”的时候才收到通知而是需要一双眼睛提前发现“正在变差”并且最好能直接告诉我们是哪一环出了问题。PLFM_RADAR 这个名字就是在需求评审会上定下来的。我们不打算做一个大而全的APM产品而是聚焦在“平台的业务健康和链路健康”上像雷达一样持续扫描核心指标发现偏离就锁定目标、输出告警、附带诊断信息。目标很明确让告警变得“有用”让排障时间从分钟级压缩到秒级。1.2 监控哪些指标才算抓住了平台的命脉很多团队搭监控习惯从基础设施入手看CPU、内存、流量。但结合我们的场景这类指标只能说明“机器还行不行”不能说明“业务还行不行”。我们后来把指标分成五个层次覆盖范围从平台到业务逐层收敛指标层次典型指标说明北极星指标日活、订单量、支付金额一旦掉头不用问肯定有事RED黄金信号请求量、错误率、P99延迟每一类核心接口都要单独覆盖链路里程碑登录成功率、加购成功率、支付回调时长关键链路每一跳都要能看到数据质量指标上报延迟、缺数率、采集覆盖率监控系统自身不能“瞎”容量与依赖指标DB连接池使用率、MQ积压量、外部服务超时率业务异常的常见根因区这个分层解决了一个很实际的问题告警从哪来、按什么优先级看。北极星指标一旦异常就是P0直接拉群RED信号异常是P1通知服务负责人容量和依赖指标异常是潜在的“定时炸弹”在业务还没明显恶化的时候提前处理。这样即使某一天告警特别多值班的人也能先处理最高层级的那个而不是被几十条噪音淹没。1.3 RADAR 五层能力模型为什么它不是普通监控PLFM_RADAR 不叫 PLFM_MONITOR是因为它不止监控。RADAR 这个名字其实对应了五层能力也是设计它时的五个阶段。R Real-time数据实时采集核心指标至少分钟级入库关键接口要10秒级。A Aggregate多维度聚合计算比如按接口、按机房、按版本、按渠道异常能定位到具体维度。D Detection异常检测引擎用动态基线和统计模型判断“今天比平时异常”而不是拿固定阈值硬卡。A Alert告警通知与状态管理做到不重复、不轰炸、可认领、可恢复。R Report复盘报告每次告警自动沉淀现场数据事后可以直接拉出一个故障时间线。传统监控相当于“火灾报警器”烧起来了才响。PLFM_RADAR 更像真正的雷达它持续扫描、持续构建正常态的画像然后告诉我们“偏离了正常多少、最可能是哪里出了问题”。这个定位上的差异决定了后面很多技术选型都不一样。2. PLFM_RADAR 架构设计与技术选型一台4核8G机器能不能跑起来2.1 四层数据链路从采集到通知的完整闭环PLFM_RADAR 整体数据流分成四层每层职责单一依赖关系清晰采集层业务服务的 SDK 把指标数据通过 HTTP 批量上报到 CollectorCollector 负责解析、校验、补时区标签然后写存储。基础设施指标用 Agent 采集走同一条链路。存储层原始指标数据落在 ClickHouse按天分区、按指标名排序。热数据同时写一份到 Redis用于最近一小时的高频查询。告警状态、指纹去重、基线参数都放在 Redis。计算检测层Celery 定时任务每分钟跑一批检测器从 ClickHouse 拉最近若干分钟的数据、取基线参数、算偏离度命中规则就写入告警事件表再触发送通知任务。展示与通知层Grafana 直接查 ClickHouse 做可视化大屏通知走 IM Webhook、邮件、短信三级通道重大告警直接拉群并 对应负责人。这套链路里最容易被忽略的是“链路上的每一边都要有自监控”。数据从采集到写入经历了多个环节任何一个环节断了后面全是瞎的。所以我们在采集层的 SDK 里加了一个心跳指标每分钟上报自己“采了多少条、发了多少条、耗时多少”Collector 也上报接收量和解析失败率。这些指标同样要检测、要告警否则数据链路断了你还在盯着旧数据怀疑业务出了问题。2.2 技术选型背后的取舍为什么不是 Flink不是 ES先说说存储。一开始有人提议用 Elasticsearch因为团队对 ES 相对熟。但我们的核心查询模式是“按指标名时间范围做聚合统计”这正好是 ClickHouse 的强项。ClickHouse 几千万行数据做分钟级聚合基本都在一百毫秒内返回比 ES 快一个数量级而且部署简单单机就能跑。我们总共保存30天原始数据做压缩后也就几个GB一台普通服务器完全扛得住。再说计算引擎。我们评估过 Flink、Kafka Streams 做实时流计算但最终选择了 Celery 定时任务。原因是我们的业务指标对延迟不敏感分钟级检测已经足够没必要为了“实时”背上流计算的运维负担。Celery 的调度模型是每分钟调度器触发一批任务每个任务对应一个指标检测器任务消费的是 ClickHouse 里“上一整分钟”的数据天然窗口化不需要处理乱序问题。当一个检测器执行时间超过调度周期Celery 的 Next-Schedule-Wait 机制会自动跳过避免任务堆积。组件选型为什么是它存储ClickHouse聚合查询极快、压缩比高、部署简单热缓存Redis告警指纹、状态机、短时指标缓存调度计算Celery Redis Broker分钟级任务足够运维成本低可视化Grafana直接对接ClickHouse面板即所得通知IM Webhook 邮件 短信按级别分级避免所有告警同一通道这套方案跑下来一台4核8G的云服务器就能承载我们目前日均几千万条指标数据的处理量我们大概有3000个基础指标、2000个业务维度组合。如果你的指标规模比我们大十倍第一件事应该是加 ClickHouse 的分片而不是换框架。业务体量没到那个程度的时候简单可靠的方案就是最优方案。2.3 实时性与调度频率的平衡关于“实时”要有一个清醒的定义。PLFM_RADAR 不是证券行情系统大多数平台业务指标分钟级就够。我们把指标按敏感度分了三个档10秒级核心接口存活状态、数据库连通性。这些指标一旦挂了影响面很大必须第一时间感知。1分钟级请求量、成功率、延迟、登录量、订单量。用于异常检测的绝大多数指标都在这个档次。5分钟级容量指标、依赖服务指标、数据质量指标。变化相对缓慢频繁检测反而容易抖动误报。调度频率的另一个细节是“时间窗口对齐”。任务每分钟跑一次取的是上一个自然分钟的数据比如 10:00:00 的任务取 09:58:00 到 09:59:00 之间的数据。这样窗口不会因为任务启动时间不稳定而左右漂移且检测结果和 Grafana 面板上看到的分钟线是完全对应的。如果任务执行耗时超过一分钟下个周期自动延后不硬塞并发保证检测结果的时序稳定。3. PLFM_RADAR 核心实现动态阈值、告警去重、归因分析怎么落地3.1 动态阈值算法EWMA 基线 3σ偏离度这是 PLFM_RADAR 最关键的部分也是最容易写砸的地方。一开始我们用的固定阈值请求成功率低于99.5%就告警。上线第一周就被喷成筛子——业务高峰时段偶尔掉到99%但用户侧完全无感半夜低峰时成功率哪怕掉到98%实际影响的用户也只有几百个。固定阈值要么太灵敏、要么太迟钝根本没有一个放之四海皆准的数。后来换成了动态基线方案每个指标在每个时间桶上都有一个自己的“期望值”判断异常不是用绝对数而是看实际值和期望值的偏离程度。基线的构建方式用指数加权移动平均EWMA对历史数据按衰减权重计算公式上等价于“越近的数据影响越大”。再加上同时间桶的周期性对齐——比如今天是周三 10:00我们对比的是过去几周所有周三 10:00 的基线避免工作日和周末混在一起。import time import hashlib from dataclasses import dataclass, field dataclass class EwmaBaseline: 每个(指标,维度,时间桶)对应一个基线对象 alpha: float 0.3 mean: float 0.0 m2: float 0.0 count: int 0 def update(self, value: float) - None: # Welfords online algorithm EWMA 权重 if self.count 0: self.mean value self.m2 0.0 else: self.mean (1 - self.alpha) * self.mean self.alpha * value delta value - self.mean self.m2 (1 - self.alpha) * (self.m2 self.alpha * delta * delta) self.count 1 def zscore(self, value: float) - float: std (self.m2 / self.count) ** 0.5 if std 1e-6: return 0.0 return (value - self.mean) / std有了每条时间桶的基线和方差检测逻辑就变成“实际值相对基线的 Z-Score 大于3并连续出现3个检测周期才触发告警”。参数 alpha 取0.3表示最近一次数据的权重占到30%对趋势变化还算敏感又不容易被单次毛刺带偏。连续3个周期的条件非常关键它过滤掉了大量的瞬时抖动代价是异常发现慢了两三分钟但从业务角度看这两三分钟换来的是告警可信度的大幅提升非常划算。这里要特别提醒刚上线时不要直接拿历史数据当基线。我们最初把这个系统搭好后直接把近30天数据灌进去算基线结果新指标当天就疯狂误报。原因是有几个指标在历史上经历过代码发布、大促、数据库迁移那些极端值全被记进了基线。后来加了规则新指标先学习24小时学习期内不告警只记录24小时后开始进入检测模式。相当于给雷达一个预热期。3.2 告警去重与状态机怎么把告警频次降下来PLFM_RADAR 上线第二天值班群半天内刷了2000多条告警群直接变成刷屏现场。问题不在检测逻辑而在通知逻辑同一个指标连续命中10次就发了10条告警。这还不是最夸张的最夸张的是一个指标异常从 10:05 持续到 10:45每两分钟一条同一件事被通知了20次。告警系统必须具备状态管理能力而不是单纯的“触发就发”。我们为每条告警定义了四种状态PENDINGpending中、FIRING已触发、ACK已确认、RESOLVED已恢复。触发逻辑是这样的检测器命中异常后先去 Redis 查指纹如果指纹不存在写入 PENDING 状态并开始计时等到连续命中3个周期并且持续时间超过60秒则置为 FIRING 并发送通知FIRING 状态下后续周期即使持续命中也不会再发新消息而是每10分钟尝试一次“升级提醒”如果10分钟内没有被人确认当指标恢复正常自动转为 RESOLVED 并发送一条恢复通知。指纹设计也走了弯路。最开始用“指标名时间戳”做去重结果同一异常在下一分钟又冒出来。后来改成时间桶桶大小默认5分钟指纹 SHA1(指标名 维度值 告警类型 时间桶)。只要同一指标同一维度在同一个5分钟桶内命中过就不会重复发通知。这样即使检测器因为任务堆积延迟执行也不会绕过去重。def alert_key(metric, dims, alert_type, ts): bucket int(ts / 300) * 300 # 5分钟桶 raw f{metric}|{dims}|{alert_type}|{bucket} return hashlib.sha1(raw.encode()).hexdigest()这段逻辑写完后同样一次故障从20条通知降到了2条1条触发1条恢复如果加上人工确认可能只剩1条。告警去重不是“体验优化”是“告警系统能不能活下去”的关键。3.3 归因诊断从“指标掉了”到“可能是哪里出了问题”告警变准了只是第一步。按下葫芦浮起瓢告警虽然不刷屏了但值班的人还是要手动查日志才能找到根因。所以 PLFM_RADAR 加了一个“归因诊断”模块它的思路很简单指标异常不是孤立事件肯定伴随着上下游或同域指标的波动我们把这些关联指标的波动情况自动抓出来排序。当检测器发现“下单成功率”异常时归因任务会立刻拉取同一个时间窗口内的关联指标分为三类基础设施类DB连接数、MQ积压量、网关P99、上游依赖类登录接口成功率、用户服务RT、支付回调时长、同域业务类订单创建量、购物车转化率、支付请求量。然后计算每个关联指标在该窗口内的波动率波动率 |当前均值 - 基线均值| / 基线标准差按波动从高到低排序将Top 3作为“疑似根因”随告警一起发出。举一个真实例子某次“支付金额”突然下跌归因结果最前面的不是支付服务本身而是“支付宝回调超时率”和“网关到支付服务的TCP重传率”。值班的人根据这条提示直接联系第三方支付服务商和网络组少走了很多弯路。归因模块不能保证100%准确但能把排障范围缩小一大半这对一线值班来说就是最大的价值。def attribution(metric, bucket_start, bucket_end, related_metrics): results [] for cm in related_metrics: # 从ClickHouse取当前窗口和基线窗口的数据 current_mean query_metric_mean(cm, bucket_start, bucket_end) baseline baseline_store.get_baseline(cm, bucket_start) if baseline and baseline.std 0: ratio (current_mean - baseline.mean) / baseline.std results.append((cm, ratio)) results.sort(keylambda x: abs(x[1]), reverseTrue) return results[:3]这套逻辑一开始只在告警里附Top 3后来发现每个故障的完整归因列表对复盘很有用于是每次检测都把这个结果落到 ClickHouse 的alert_attribution表里事后做复盘时直接查不用再靠人脑回忆“当时哪些指标不对劲了”。4. PLFM_RADAR 落地过程告警疲劳、脏数据、规则治理4.1 告警疲劳比没有告警更可怕这是 PLFM_RADAR 上线半年最大的教训值得单独拿出来说。告警系统有一个悖论发出的告警越多人对告警的敏感度越低而敏感度一旦降下来真正重要的告警反而没人看。所以“告警少而准”比“告警多而全”更重要。我们做三轮治理。第一轮是分级通知P0级北极星指标异常立即拉群并短信电话P1级核心接口异常推送到群并 负责人P2级容量/依赖波动推送到群不。第二轮是夜间聚合凌晨0点到8点的P2级告警不实时推送而是每30分钟汇总一条一个晚上无论发生多少次P2值班群最多收到16条消息。第三轮是“确认后静默”告警被认领后该指标的后续波动归入一条“跟踪中”消息不再重复触发。级别代表场景通知方式预期时间P0订单量腰斩、支付成功率暴跌拉群短信电话1分钟内P1核心接口错误率超基线3σ推群负责人2分钟内P2容量指标升高、依赖超时推群不10分钟内经过这三轮治理值班群从每天几百条消息降到平均每天10条以内其中有价值的告警占比超过80%。一个真正有效的告警系统应该做到“每条消息都值得我打开看一眼”。4.2 数据质量与告警准确性先揪出脏数据再谈异常告警误报的原因不只有算法问题还有数据源问题。PLFM_RADAR 接入了各种业务方上报的数据但业务方代码更新后经常出现“字段含义变了但没通知我们”的情况。某次有个业务把上报成功率从0-100改成了0-1的小数检测器直接把成功率骤降判成P0拉了几十个同事进群结果是一场乌龙。后来我们加了三道防线。第一道在采集端Collector 对每个指标做合法性校验超过取值范围直接丢弃并记录异常第二道在存储端ClickHouse 写入前计算基础统计信息max/min/avg如果已经在产线跑了一段时间的指标突然出现量级完全不同标记为“疑似数据变更”第三道在检测端检测器在计算异常前先检查数据新鲜度如果采集时间戳与当前时间相差超过180秒判定为 stale_data不参与告警。数据质量指标本身也纳入监控。每个指标都会计算“采集覆盖率”即“应该有数据的分钟数”和“实际有数据的分钟数”之比。覆盖率低于99%就产生一条P2告警通知数据负责人。监控系统必须先证明自己看到的景象是真实的它的结论才有意义这个原则怎么强调都不为过。4.3 规则治理告警规则也要有生命周期PLFM_RADAR 上线的头三个月规则数量翻了一倍但每条规则的平均价值在下降。有些规则是“上线时加来应急的”应急结束后没人撤有些是“看起来重要的指标”实际上业务路径早已改造指标名已经不再上报。如果留着一堆僵尸规则系统每天都在为不存在的指标计算“异常”浪费资源不说偶尔还会冒出无法解释的告警。给所有告警规则加上“Owner”和“Next Review”字段Owner 是对指标负责的人Next Review 是下次评审日期默认两周。每两周做一次规则 review近两周内有告警但未产生有效处置的规则标黄从未产生告警的规则标灰由 Owner 确认是否下线带 TODO Action 的规则必须有明确的完成时间否则直接禁用。这套规则治理看起来不性感但它是告警系统长期稳定运行的地基。没有治理的告警规则库三个月后就是一堆没人看得懂的化石。5. PLFM_RADAR 常见问题与排查实录5.1 “告警哑了”指标明显异常却没收到通知这类问题大概率出在三个环节采集、检测、通知。排查顺序建议从后往前。排查环节检查方式常见原因检测任务查 Celery 日志有没有该指标的检测记录调度周期冲突、任务抛异常告警状态查 Redis 中该指标指纹的状态值已处于 FIRING 且超时未恢复通知通道查 Webhook 回调日志群机器人被踢、URL 配置错数据链路查 ClickHouse 该指标最近是否有值业务方停采、字段改版有一次我们排查“登录量下降”未告警查到最后居然是 Celery 的队列里积压了另一个耗时特别长的报表任务把检测任务全堵住了。从那以后我们给检测任务单独建了一个队列和报表任务物理隔离优先级上也加了 worker 的数量上限。所有检测类任务的执行耗时都记录下来平均耗时超过调度周期的80%就要报警这是检测系统的“健康红线”。5.2 “告警狂响”连续误报是谁的锅连续误报最闹心。我们的经验是先把告警的“持续时间”参数拉长比如要求连续3个周期都异常并且每个周期都是同一个方向的偏离全部上升或全部下降才判定为异常。这样单个周期因为网络抖动产生的毛刺就不会引发告警。有一次某接口连续两天半夜误报看了归因数据发现是数据源延迟导致“窗口内数据缺失”检测器把缺失当成了0处理数值从1000骤降到0偏离度直接拉满。后来对窗口内数据缺失率超过40%的检测点直接跳过不做判定缺失率低于40%的用该指标最近5分钟同维度均值补数并且补数后的结果不参与连续周期计数。数据质量兜底之后这类误报基本绝迹。5.3 “基线漂移”版本发布后指标一直误报每个季度的版本发布尤其是核心链路的大改造会让很多指标发生结构性变化。比如我们把登录页面从改版前的一次性调用改成“预登录确认登录”两步登录成功率的数值形态就完全变了。基线还是老数据新数据一来就会误报“异常偏低”。这个问题最好的处理不是在算法上打补丁而是让发布流程和监控系统联动。版本发布当天允许相关指标进入 24 小时“学习模式”学习期内的数据只更新基线、不生成告警。开发者在发布窗口内通过配置面板手动开启发布稳定后再关闭。如果忘了开也没关系归因模块会在Top 3 里给出“最近1小时是否有发布事件”的提示值班的人看到后可以先检查发布记录再排查其他方向。6. PLFM_RADAR 的经验沉淀监控系统怎么才算“好用”PLFM_RADAR 从原型到上线最大的体会不是技术多复杂而是监控系统本质上是一个“信任系统”。人只有在信警报的时候才会响应警报而这个信任是建立在长时间“不误报、不漏报、每次都给出有效信息”的基础上的一旦崩坏就很难重建。如果让我给后来者三条最实在的建议第一条先想清楚什么是你平台最重要的五个指标雷达只盯这五个核心方向就好别一开始就追求覆盖所有指标第二条告警频率宁可少不可多一个可靠但偶尔漏报的系统远好过一个每天刷屏但没人看的系统第三条每个告警消息里都要有现场信息——当前值、基线值、偏离度、Top关联指标让收到消息的人不用再打开电脑就能大概判断是什么方向的问题。后续 PLFM_RADAR 还在迭代的方向是接入时序预测把基线从 EWMA 升级成 Prophet 之类的模型但现在这套它已经帮我们扛过了好几个大型活动的稳定性保障成了团队真正离不开的那双眼睛。