线上崩了，谁先知道？

先问一句：线上出问题的时候，是你们先发现，还是用户先发现？

如果答案是后者，这篇就是写给你的。

业务越做越大，监控却各搞各的。没有统一标准，没有统一平台，一个团队N套监控，结果就是：

发现滞后，响应更滞后。

我们给自己定了一条线：出现问题，30分钟内必须解决！

要做到这一点，靠零散的监控远远不够。我们需要一套面向业务场景、能分钟级感知异常的智能监控与告警体系。

于是有了「星盾」。

面向业务场景的智能监控报警系统。

核心逻辑只有十个字：监控 → 告警 → 响应 → 定位 → 解决，形成闭环。

从数据采集到展示运营，星盾采用清晰的四层架构：

数据采集 → 数据处理 → 监控告警 → 展示运营 ，各司其职，统一收口。

一句话：先告诉系统「要盯哪块业务」（监控项），再配个「能看趋势的图」（看板），最后定「啥情况算异常、通知谁」（报警项）。配完就自动跑，有问题就分钟级提醒。

PS： 开启「AI通用分析」后，前两步配完即可，第三步可跳过。

下面分别说明每一步要做什么、怎么配。

如图所示：

把「看什么」说清楚------要监控哪个业务场景、看哪些指标、怎么算这部分数据。

1. 先把数据收全

覆盖前端、服务端等多端数据，在同一平台内统一配置与告警。

数据源	典型用途
lego	前端/客户端页面曝光、按钮点击、关键行为（PV/UV、曝光、点击等）
Prometheus	服务端指标：QPS、延迟、错误率等，接口、服务、中间件可用性与性能
服务端 k=s	业务服务端自定义指标/上报，与 Prometheus 互补

2. 用户行为指标：规模、转化、占比

先把「用户行为」本身看清楚：有多少人来（UV）、做了多少次行为（PV）、其中有多少转化（占比）。

维度	含义	典型用法
PV（次数）	按次数统计	看规模与总量：接口调用次数、页面曝光次数、点击次数
UV（人数）	按人数/设备去重	看覆盖与体验面：多少用户受影响、多少人完成某行为
单指标	当前监控项自身的统计值（可以是 PV 或 UV）	看某一行为的绝对值：首页曝光 PV、某接口 QPS
占比指标	本监控项 ÷ 关联监控项，得到占比	看比例与转化：区域曝光占比、成功率；流量波动时更稳，减少误报

做转化率类报警（如区域曝光 PV / 页面曝光 UV）时，分子分母会分别用到 PV、UV，两种都要支持；占比指标需要在配置时关联一个已有监控项作为分母，系统自动计算占比并报警。

3. 精确到终端/页面/模块：基础条件 + 条件匹配 + 分组筛选

基础条件： 先圈出「哪一类事件、哪一块页面/模块」（如商品曝光、App 首页_推荐），对应埋点中的事件类型 + 模块/页面，是最粗的一层场景圈选。
条件匹配： 在基础条件上再做精细过滤，如 sectionId=108、firsttab=精选、终端类型等，实现同一模块下不同 tab、不同区域、不同终端分别监控。
分组筛选字段： 指定按哪一维度分组（如渠道、终端），方便在看板和告警里对比不同终端/页面/模块，并按具体实体下钻。

如图所示：

为监控项配置可视化看板，用于查看该监控项的数据趋势。

看板主要有两个作用：

如图所示：

在监控项与看板的基础上，定义「什么情况下算异常、如何通知到人」，把观测能力转化为可执行的告警策略，实现「监控 --- 告警 --- 响应」闭环。

配置项	含义 / 用途
关联监控项	告警绑定到具体监控项（曝光率、接口 QPS 等）
报警条件	按维度过滤，只对符合条件的数据做统计与触发（如 t值[终端类型]）
统计周期(秒)	按多少秒聚合再判断（如 60 秒），减少瞬时抖动
触发条件	最大值/最小值/平均值/求和、连续发生、环比变化率等，适配不同场景
分组条件	告警触发时按某维度展示（如按 t值），便于定位
告警方式	企微通知、语音报警等，重要告警多通道触达

触发条件怎么用？常见几种：连续发生 （连续 N 个周期才告警，减少误报）、统计周期内最大/最小值 、环比变化率（发现相对基线的突然变差）。

而触发条件里最核心的是阈值------什么算异常、多少才报？两种配置方式，告别「拍脑袋」：

阈值配置方式	说明
手动配置（自己设阈值）	单指标：对单一指标（如首页曝光 PV、某接口 QPS）直接设阈值，超过或低于即告警，适合量级、绝对值类监控。转化率：用组合指标（如区域曝光 PV / 页面曝光 UV）算转化率再报警，流量高峰、低谷波动再大，也能更稳地判断是不是真异常，减少误报。
自动对比（AI）	基于历史数据自动学习业务规律，对异常波动做智能识别 + 实时告警。该设多少阈值、什么时候报，系统自己学，人工配置和维护成本都降下来。