事件 ONCALL 中心建设方法 一站式处理值班 OnCall，智能降噪 北京快猫星云科技有限公司 前言 市面上有众多监控系统，刨去商业软件不说，开源的就有 Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等，还有云厂商提供的监控系统，比如华为云的云 监控、腾 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 级、协同闭环处理等等。监控系统或多或少都有一些这方面的能力，但是通常都不完备，而这，正是 这种产品存在的价值。这些产品都是以 Duty 命名，核心就是支持告警 OnCall 值班处理的场景。 对于告警事件的后续处理，有哪些问题和需求以及何为最佳实践？我们从思路方法和工具实践两个方面分 别进行探讨，下面先行探讨思路方法，看看要解决这些问题和需求，我们有哪些可能的解法。 思路方法篇 告警事件的后续处理：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 处理等等。看起来需求很多，最核心的痛点有两个：

类型的值表示当前的状态，可大可小、可负可正，比如某个虚机实例挂了，用 0 表示， 如果实例存活，用 1 表示；再比如内存使用率，这个时刻采集是 33.7%，下个周期采集可能就 变成了 25.8%；还有像机器最近 5 分钟的 load、正在运行的进程数量等等，都使用 Gauge 类 型来表示。这种类型的值，我们非常关注当前值。 Counter 类型 Counter 类型是单调递增的值，比如 类型是单调递增的值，比如机器上某块网卡收到的数据包的总量，是从操作系统启动 之后，就持续递增的，对于这种类型的值，我们通常关注的不是当前值是多少，而是关注增量和 变化率。我们在机器上执行 ifconfig 命令： eth0: flags=4163 mtu 1500 inet 10.206.0.16 netmask 255.255.240 errors 0 dropped 0 overruns 0 carrier 0 collisions 0 RX packets 后面的值是 OS 启动以来收到的总的包量，TX packets 后面的值是 OS 启动以来发 出去的总的包量，都是很大的值，我们通常不太关注这个值当前是多少，更关注的是最近 1 分 钟收到/发出多少包，或者每秒收到/发出多少包。 1 2 3 4 5 6

server sdk 注册 获取target 采集数据 吞吐量量 响应时间 错误率 饱和度 熔断 限流 投稿数量量
 订单数据 在线⼈人数
 … ⻩黄⾦金金指标 业务指标 少量量事件 dashboard 报表 告警 统⼀一的告警中⼼心 解决什什么问题? • 告警源头多 • 告警⻛风暴暴, ⼤大量量重复告警 • 发送告警渠道多 • 重要告警没有及时到达 • 优化告警没有数据依据 问题 • 告警标准化 • 告警收敛 • 告警渠道管理理 • 告警升级 • 告警报表 核⼼心功能 API⽹网关 服务树 告警收敛 屏蔽规则 事件管理理 告警渠道 报表系统 ⼯工单系统 鉴权 频控 标准化 时间维度 业务维度 关联关系 rms 告警升级 企业微信 钉钉 邮件 短信 ACK应答 屏蔽 告警等级
 对应处理理⽅方式 ate1h offset 7d 告警规则: 预测业务A请求量量异常 异常响应 todo • 异常事件关联关系挖掘 • 全联路路模块调⽤用分析 • 瓶颈分析 针对历史事件 针对当前事件 • 异常检查(动态阈值) • 异常定位(根因分析) • 快速⽌止损 针对未来事件 • 故障预测 • 容量量预测 • 趋势预测 Thank You! 哔哩哔哩 - ( ゜- ゜)つロ