种机制告诉系统：“我已知晓 告警，现在我开始处理了，你不要升级了”。典型的认领功能一般是做在页面上的，告警后打开告警事件 管理中心，选中相关告警一键认领，也可以通过上行短信或即时通讯工具中的上行回调机制来完成。 升级机制会给值班人员很大的压力，毕竟谁也不想稍不留神就把电话打到老板那里，所以一般只有严重的 告警才会启用升级机制，警告或者通知性质的告警都不用启用升级机制。当然，这个规范怎么定，各个团 关的人，这个 时候就可以在故障下面添加评论，其他人就可以及时看到。等到止损之后，大家还要根据故障时间线复 盘，产出一系列跟进项，这个时候就需要这个故障管理模块具备跟进项管理的功能，或者至少能够跟任务 管理系统良好打通。 有了这样一个故障协同的机制之后，故障被处理掉的概率就大幅提升了，后续再配合一些运营统计手段， 统计各个团队的平均故障止损时间，建立红黑榜，大家就会有更高的热情来处理故障。当然，人的热情再 当然，人的热情再 高，也不如机器来得快，如果有些告警能够直接关联自动化处理逻辑，无疑可以大大增加事件闭环率。 告警自动处理 很多监控系统都可以配置 Webhook，当告警触发之后自动回调某个 HTTP 接口，来串联一些自动化的 逻辑，让告警事件无人值守自动处理。比如某个机房的某个服务挂掉了，Webhook 的逻辑是自动调用切 流的接口，把服务流量切走，这样来达到止损的目的。

lb资源 • es资源 • 分布式⽂文件 • 进程监控 业务层 • qps/tps • 耗时分布 • 饱和度 • 吞吐量量 • 依赖响应 • 缓存命中率 • 调⽤用链 • SLA • ⽇日志 播放质量量 • 点播/直播 • 播放卡顿 • 平均⾸首帧 • 播放失败率 • 弹幕加载 • cdn质量量 客户端质量量 • ⽤用户端⽹网络质量量 0.3 * requests:holt_winters_rate1h offset 7d 告警规则: 预测业务A请求量量异常 异常响应 todo • 异常事件关联关系挖掘 • 全联路路模块调⽤用分析 • 瓶颈分析 针对历史事件 针对当前事件 • 异常检查(动态阈值) • 异常定位(根因分析) • 快速⽌止损 针对未来事件 • 故障预测 • 容量量预测 • 趋势预测

15:48:03 这 2 分钟之间的数据，然后返回最新的那个。 查询类型 上例中的 mem_available_percent{app="clickhouse"} 称为查询表达式，不同的表达式，会返 回不同的内容，返回的内容总共有 4 种格式，分别是：Instant vector（瞬时向量）、Range vector（范围向量）、Scalar（标量）、String（字符串）。返回瞬时向量的查询表达式，我们