第二个常见的原因是底层出问题导致所有的上层依赖都告警，越是底层影响越大，比如基础网络如果出问 题，发出几万条告警都是正常的。 第三个原因是渠道错配。一些不重要的告警也使用打扰性很高的渠道发出，用户可能会觉得单一渠道不可 靠，想用多个渠道同时发送的方式来保障告警触达率，这也属于告警规则配置不合理的范畴。 第四个原因是预期内的维护动作导致的。比如程序升级变更，如果进程重启时间过长，可能会导致关联的 Runbook 这个配置原则，是我最为推荐的原则，效果非常明显，其次就是告警分级原则。 每个告警都应该合理分级 基本每个监控系统都支持为告警规则配置不同的级别，基本上每个监控系统的用户也都知道应该做分级告 警。但是具体怎么分级，却没有一个行业共识，大家各做各的。这里我也分享一下我的理解，你可以参考 借鉴。 首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不 监控系统会产生原始的告警事件（event），属于同一个告警的多个事件被合并成告警（alert），类似的告 警（比如某个标签相同，或者文本相似度很高）被合并成故障（incident），最终通知用户的是一个个故 障，大幅降低了打扰性。 不同的告警事件，通常有不同的分发逻辑，比如不同时段不同的分发逻辑：白天用短信通知，晚上用电话 通知，比如对象存储的告警要发给存储团队，物理机故障要发给运维团队。这都可以灵活定义。

cdn质量量 客户端质量量 • ⽤用户端⽹网络质量量 • 劫持情况 • 崩溃&卡顿 • 返回码 • 响应时间 • 错误率 服务端监控 ⽤用户端监控 如何推进？ 服务端监控 场景 分析监控场景对应监控⼿手段 类型 metric类型 ⽇日志类型 ⾃自定义类型 ⼿手段 时间序列列数据 ⽇日志处理理流 ⾃自研 ⽤用户端监控 apm ⾃自研 客户端 播放器器 如何推进？ 服务端监控 场景 分析监控场景对应监控⼿手段 类型 metric类型 ⽇日志类型 ⾃自定义类型 ⼿手段 时间序列列数据 ⽇日志处理理流 ⾃自研 ⽤用户端监控 apm ⾃自研 客户端 播放器器 metric⽅方案选型 • 能覆盖⼤大部分监控场景 • 固定⼏几种数据类型 ✦ Counter ✦ Gauge ✦ 等..

项目：https://github.com/didi/nightingale 官网：https://n9e.didiyun.com/ Nightingale 众多企业已上生产，共同打磨夜莺 上图展示部分社区用户，加入夜莺社群，请联系微信：UlricQin Nightingale 众多企业已上生产，共同打磨夜莺 Server01 Server02 Agentd Agentd LoadBalance

的结果： 如果我们认为内存可用率小于60就是有问题的，想找出所有有问题的数据，只要在 promql 中 拼上 < 60 即可： 1 如上的方法，其实就是告警引擎的核心逻辑。告警规则里会要求用户配置promql以及执行频 率，告警引擎就会根据执行频率周期性执行，每次执行的时候就是拿着promql去查询，promql 中带有阈值，即上例中的 <60，所以如果所有机器的内存可用率都很高，比如维持在80~90，