遇到问题我们可以 **先问是不是，再问怎么解决。**所以我们可以先确认告警是否真的没产生，从数据流程图可以看到，如果有告警产生，在第8步会记录到数据库，我们可以在告警历史列表页看到，所以可以先确认下告警历史列页是否已经有告警记录了，如果有了，那可能你的问题应该是告警没有通知成功，可以看第二个常见问题。

如果告警事件确实没产生，我们可以根据数据流，从前往后收集信息。

第一步

在第一步中，负责告警的模块，会定期同步告警启用状态下的告警规则，然后检查告警规则是否归自己纳管，告警模块如何知道规则是否归自己纳管呢？夜莺的告警规则会配置对哪个数据源进行告警，每个数据源都可以关联一个告警引擎集群，如下图，这样每个告警引擎就会知道自己需要纳管哪个告警规则。

txRAWA

所以我们在第一步我们要确认三个事情

确认告警规则是否是启用的，查看告警规则，生效配置部分来确认

CNAlOo

告警规则是否配置了我们想要告警的数据源，如下图

tO3X6s

数据源是否关联了告警引擎集群，在数据源列表页，点击数据源名称，来确认

rYsRy8

如果第一步有哪一点没对上，那问题就定位了，如果发现没问题，我们继续从第二步收集信息

第二步

确认数据是否通过告警规则中配置的 promql 可以查到异常值，先打开告警规则详情页，复制 promql

xtMHC0

如果是非 promethues 普通模式（v1）的数据源，检查下是否配置了辅助配置

3Y8j3X

然后到即时查询页面，选择对应的数据源，输入上面的 promql 在及时查询查下数据，然后使用 table 视图查询下原始数据（其他数据源同理），确认是否能查到预期的数据，另外需要注意数据是否延迟上报了，如果查不到，可能是数据延迟导致的没触发告警。

Fcvkzm

qcgKUY

如果查不到，说明没有满足产生告警的条件，问题定位。

第三步

如果能查到数据，说明确实出现异常点了，我们继续往下走，根据 告警事件生成流程，我们可以从告警规则的配置以及是否配置了屏蔽规则找线索，先看告警规则配置

PFnLtn

我们分别检查下

我们希望告警的时间是否在生效时间内（4）；
如果是机器相关的告警，是否开始了仅在本业务组生效，且机器是属于告警规则关联的业务组（5）；
出现异常点的持续时长是否满足条件，这个在即时查询可以确认异常点出现的时长（6）；
距离上次发出的告警，是否满足的通知间隔**（如果有恢复事件，间隔会重新开始从0统计）**，可以在告警历史查看上次告警的时间，然后对比下（7）；
是否已经达到最大通知次数（如果有恢复事件，次数会重新开始从0统计），在告警历史列表搜索下告警规则标题，把时间范围拉长到一个月，查看之前产生告警的次数；

如果上面有哪一点没有满足，问题定位。如果都满足条件了。

我们可以确认下是否配置了相关的屏蔽规则，可以到和告警规则相同的业务组下，看下是否配置了告警屏蔽，如果有配置，确认下告警屏蔽中配置的匹配条件，是否和告警事件中的标签匹配，告警事件中的标签由三部分组成，时序数据的标签、告警规则中配置的附加标签、告警规则名称。可以依次和匹配条件做对比，确认是否命中，如果命中，问题定位。

DO1MS8

如果你收集并验证了上面所有的信息，仍然没发现问题，此时很可能夜莺的告警引擎进程没有正常工作，此时可以查看系统配置-告警引擎页面，检查下：

有几个实例在工作，是否有旧的实例忘记升级了
实例是否关联的想要告警的数据源
实例的心跳是否在更新，如果没有更新，说明实例进程挂了，需要重新启动下进程

9nbotV

如果以上都正常，可以登录服务器，查看下实例的日志，将日志级别调整为 DEBUG，过滤关键字 rule_eval + 告警规则 id，例如告警规则 id 为 123，则执行

tail -f *.log|grep "rule_eval"|grep 123

观察每次执行规则判断，是否有错误日志，或者是否能查到数据

这类是查询数据报错了

5m2lsX

这种是没查到数据，即使查询能看到，这里查不到，说明是数据上报有延迟

yxENuZ

如果日志也没有发现异常，可以整理好已经排查的截图，找下相关研发同学

常见问题2：有告警事件了，没有收到通知

此种情况，v7.2.1 以及之后的版本，可以直接查看告警详情页都通知记录按钮，可以看到通知结果，如果是较低的版本，可以参考下面思路排查

这种情况，根据上面的流程图，我们可以收集告警事件通知部分的信息，排查哪里出了问题。

告警通知一共有五种方式，我们逐个看下

方式1：通过接收组+通知媒介，发送给用户
方式2：在告警规则配置回调地址，通过 api 调用发给第三方系统
方式3：在全局回调的地方，配置回调地址，通过 api 调用发给第三方系统
方式4：配置通过脚本，使用脚本配置自定义通知逻辑
方式5：配置订阅规则，通过接收组+通知媒介，发送给用户

方式1 通过接收组+通知媒介，发送给用户

关于通过通知媒介通知给用户的方式，我们需要先确认下，告警规则中是否配置了相关的通知媒介，已经配置了相关接收组

YLEmsx

如果上面两者都有配置，拿钉钉通知举例，可以再挨个检查下，接收组关联的中人，是否有配置钉钉群中的机器人token，如果没有配置，问题定位。如果有配置，就需要登录机器看日志排查，是否调用钉钉通知接口出错了。登录夜莺所在服务器，执行下面命令，查询是否有日志输出，如果有日志输出，根据错误提示，进行响应修改即可

grep “_sender” |more

方式2、3、4

如果告警通知使用的是方式2、3、4，告警规则中的callback、全局 webhook、通知脚本的方式。首先确认下这三方式已经配置了。如果有配置，我们可以登录夜莺部署的服务器，过滤下夜莺的日志文件，找下是否有以下关键字 event_webhook_fail、event_notify、event_callback_fail，如果有，则更加日志提示可以定位问题，按照日志提问修复问题即可。

如果没有搜到相关日志，再查找下 INFO 日志中的如下关键字

全局回调，查看 webhook 关键字

规则回调，查看 callback 关键字

通知脚本，查看 script 关键字

根据日志，可以看到通知结果的详情