事件 ONCALL 中心建设方法 一站式处理值班 OnCall，智能降噪 北京快猫星云科技有限公司 前言 市面上有众多监控系统，刨去商业软件不说，开源的就有 Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等，还有云厂商提供的监控系统，比如华为云的云 监控、腾 警之后，实际没有后续动作，只是起到 常态化通知的效果，不需要排查，也不需要止损，甚至连个长线的 TODO 都没有。这类告警多了人就疲 了，当重要的告警来临的时候，也容易忽略。这样的规则如果不经过治理，日积月累，就会产生很多无用 的告警。 第二个常见的原因是底层出问题导致所有的上层依赖都告警，越是底层影响越大，比如基础网络如果出问 题，发出几万条告警都是正常的。 第三个原 员，我们应该怎么处理？我的建议是分产品线统计一个指标：“Runbook 预置率”，就是各个产品线有 多少告警规则配置了 Runbook，有多少没有配置，这个比例要统计出来，然后做成红黑榜，让大家去治 理，治理一段时间之后有经验了，知道预置率大概在一个什么范围是合理的，然后就可以要求大家至少达 到预置率下限的值。否则，就一定是有问题的。 Runbook 这个配置原则，是我最为推荐的原则，效果非常明显，其次就是告警分级原则。

业务应用 夜莺介绍：国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 源监控，支持云原生监控，经受了滴滴大规模生产检验 Nightingale 夜莺是新一代国产智能监控平台，既可以解决传统物理机虚拟机的场景，也可以解 决容器的场景。衍生自Open-Falcon和滴滴Odin监控，经受了包括小米、美团、滴滴 在内的数百家企业的生产环境验证，简单可依赖，好用到爆！

22- 08-25 15:48:03 用 Chrome 开发者工具可以看到发的请求参数： 但是，监控数据是周期性上报的，比如每 10 秒上报一次，在 2022-08-25 15:48:03 这个时 刻，未必恰好有监控数据啊，那这个 Table 中的数据是哪里来的？ 实际上，Prometheus 有个启动参数，--query.lookback-delta=2m 来控制这个行为，如果配 置为 具 体时刻（对于排查监控数据采集相关的问题尤为有用），如果在 Graph 视图，返回的数据取 决于 step 参数，查询时传给时序库的 step = 10，返回的图形就是每 10s 一个点，step = 20 就是每 20s 一个点，返回的数据的时间间隔取决于 step 参数而非原始数据的上报间隔。 Range Query 理论上是没法绘制 Graph 的（当然有些时序库可能会做容错处理），因为从原 的（当然有些时序库可能会做容错处理），因为从原 理上说不通。绘图的时候，我们要选择一个时间范围，比如最近一小时，然后传给后端一个 step 参数用于控制分辨率，即数据间隔，比如 step=60，即表示希望每个 series 每分钟返回一 个点，但如果是 Range Query，相当于在某个时刻返回多个点，这就无所适从了。 Prometheus 文档中有一个章节专门介绍函数，各个函数的介绍中，都会写明是用于 instant-