线上崩了，谁先知道？

先问一句线上出问题的时候是你们先发现还是用户先发现如果答案是后者这篇就是写给你的。一、我们曾经面对的窘境业务越做越大监控却各搞各的。没有统一标准没有统一平台一个团队N套监控结果就是告警要么不来要么半夜乱炸阈值全靠人拍脑袋流量一波动就误报人工配置繁琐维护成本居高不下没有监控标准想起来就加想不起来就裸奔。用户都投诉到客服了技术才反应过来发现滞后响应更滞后。我们给自己定了一条线出现问题30分钟内必须解决要做到这一点靠零散的监控远远不够。我们需要一套面向业务场景、能分钟级感知异常的智能监控与告警体系。于是有了「星盾」。二、星盾是什么一句话说清面向业务场景的智能监控报警系统。对业务全链路做分钟级监控 即时告警覆盖前端页面、服务端功能前端用「lego」采集用户行为数据服务端用 Prometheus 和 ks 看接口与性能目标只有一个异常早发现、早响应、早定位、早解决核心逻辑只有十个字监控 → 告警 → 响应 → 定位 → 解决形成闭环。三、凭什么能「分钟级」架构与能力撑腰整体架构从数据采集到展示运营星盾采用清晰的四层架构数据采集 → 数据处理 → 监控告警 → 展示运营各司其职统一收口。配置有多简单三步搞定一句话先告诉系统「要盯哪块业务」监控项再配个「能看趋势的图」看板最后定「啥情况算异常、通知谁」报警项。配完就自动跑有问题就分钟级提醒。PS开启「AI通用分析」后前两步配完即可第三步可跳过。下面分别说明每一步要做什么、怎么配。第一步创建监控项如图所示把「看什么」说清楚——要监控哪个业务场景、看哪些指标、怎么算这部分数据。1. 先把数据收全覆盖前端、服务端等多端数据在同一平台内统一配置与告警。数据源典型用途lego前端/客户端页面曝光、按钮点击、关键行为PV/UV、曝光、点击等Prometheus服务端指标QPS、延迟、错误率等接口、服务、中间件可用性与性能服务端 ks业务服务端自定义指标/上报与 Prometheus 互补2. 用户行为指标规模、转化、占比先把「用户行为」本身看清楚有多少人来UV、做了多少次行为PV、其中有多少转化占比。维度含义典型用法PV次数按次数统计看规模与总量接口调用次数、页面曝光次数、点击次数UV人数按人数/设备去重看覆盖与体验面多少用户受影响、多少人完成某行为单指标当前监控项自身的统计值可以是 PV 或 UV看某一行为的绝对值首页曝光 PV、某接口 QPS占比指标本监控项 ÷ 关联监控项得到占比看比例与转化区域曝光占比、成功率流量波动时更稳减少误报做转化率类报警如区域曝光 PV / 页面曝光 UV时分子分母会分别用到 PV、UV两种都要支持占比指标需要在配置时关联一个已有监控项作为分母系统自动计算占比并报警。3. 精确到终端/页面/模块基础条件 条件匹配 分组筛选基础条件先圈出「哪一类事件、哪一块页面/模块」如商品曝光、App 首页_推荐对应埋点中的事件类型 模块/页面是最粗的一层场景圈选。条件匹配在基础条件上再做精细过滤如 sectionId108、firsttab精选、终端类型等实现同一模块下不同 tab、不同区域、不同终端分别监控。分组筛选字段指定按哪一维度分组如渠道、终端方便在看板和告警里对比不同终端/页面/模块并按具体实体下钻。第二步添加看板如图所示为监控项配置可视化看板用于查看该监控项的数据趋势。看板主要有两个作用配置报警阈值时参考实际值创建报警项、设定手动阈值时需先在看板查看该监控项的历史曲线与量级再根据实际数据设定避免阈值过松或过紧。日常出问题时帮助定位线上出现问题后可查看看板看趋势、发生时间等辅助判断异常时段与影响范围便于定位问题。第三步创建报警项如图所示在监控项与看板的基础上定义「什么情况下算异常、如何通知到人」把观测能力转化为可执行的告警策略实现「监控 — 告警 — 响应」闭环。配置项含义 / 用途关联监控项告警绑定到具体监控项曝光率、接口 QPS 等报警条件按维度过滤只对符合条件的数据做统计与触发如 t值[终端类型]统计周期(秒)按多少秒聚合再判断如 60 秒减少瞬时抖动触发条件最大值/最小值/平均值/求和、连续发生、环比变化率等适配不同场景分组条件告警触发时按某维度展示如按 t值便于定位告警方式企微通知、语音报警等重要告警多通道触达触发条件怎么用常见几种连续发生连续 N 个周期才告警减少误报、统计周期内最大/最小值、环比变化率发现相对基线的突然变差。而触发条件里最核心的是阈值——什么算异常、多少才报两种配置方式告别「拍脑袋」阈值配置方式说明手动配置自己设阈值单指标对单一指标如首页曝光 PV、某接口 QPS直接设阈值超过或低于即告警适合量级、绝对值类监控。转化率用组合指标如区域曝光 PV / 页面曝光 UV算转化率再报警流量高峰、低谷波动再大也能更稳地判断是不是真异常减少误报。自动对比AI基于历史数据自动学习业务规律对异常波动做智能识别 实时告警。该设多少阈值、什么时候报系统自己学人工配置和维护成本都降下来。四、手动阈值的两个坑我们用 AI 填上了前面说到可以通过手动配置或 AI 自动对比来设阈值。如果只靠手动设阈值很容易踩两个坑报警配置滞后阈值要参考看板历史曲线与量级往往得先收集一周左右数据才能配出合适阈值。无法应对流量持续变化业务调整后数值持续升高或下降并稳定在新范围若不及时改阈值就会误报或该报不报。举例大促期间某核心转化率从平时的 5% 提升到 8% 并稳定下来。若阈值仍按 5% 设「低于 4% 报警」大促后回落到 6% 本属正常却可能被误报反之若按 8% 设平时 5% 时又可能该报不报。人工改阈值总存在时间差。为此我们接入了AI 通用分析能力。接下来用大白话讲清楚系统怎么知道「出问题了」并发出告警。判定为异常之后还要明确一点往哪边偏才需要告警有的指标我们只关心「掉下去了」如转化率、曝光量有的只关心「飙上去了」如错误率、延迟。星盾支持按业务诉求配置指标方向避免双向波动都报、噪音过多。一句话总结星盾先用历史数据算出「正常范围」再拿当前数据和它比只有偏离够大、持续够久才判定为异常并根据严重程度给出正常 / 警告 / 严重从而减少误报、又能及时发现问题。真实例子报警长什么样App 搜索结果页短暂进不去时从图中可以清晰看出 17:10–17:18 左右出现问题并触发告警方便快速定位与恢复。五、监控从哪来创建与补充机制配好了报警还要问一句监控数据从哪来历史功能怎么补、新需求怎么跟上下面就是我们的补充机制。1.历史功能补充先覆盖哪些已有场景按公司链路等级优先覆盖核心链路APP 首页、商品发布、浏览、下单支付等访问量PV/UV topN页面、曝光 topN功能模块2.新增功能补充新需求怎么跟上需求阶段评估是否需增加监控开发或上线后及时补充按周统计新上线业务需求通知 QA 负责人评估本周是否有需补充的监控报警这样历史场景不遗漏、新需求能跟上监控和业务一起迭代。六、上线之后数字会说话1.APP平台内部50 条报警已接入App 核心场景 100% 覆盖自 2025 年 4 月底上线至今累计发现线上问题 20 个运营配置问题 5 个内部 bug 3 个外部 bug 7 个业务规则调整 1 个业务正常波动 4 个避免 2 次三级事故2.其他业务方过期页面累计发现 2 个线上投放问题分钟级感知 自动下架有效阻止持续曝光魔方专题构建失败成功预警并推动处理 10 余起故障保障运营活动稳定上线用户还没发现我们先知道了该下架的下架该修的被修。这就是「星盾」要达成的效果。写在最后线上质量监控从来都不是一个团队中某个职能的事而是整个业务维度的事关注用户真实业务感受。星盾要做的就是把这件「业务维度」的事用统一平台、统一标准、分钟级感知串起来让各职能都能在同一套体系里看问题、响应问题、定位问题。如果你也经历过「线上崩了用户先知道」的尴尬不妨试试