从夜莺5.1版本开始，摒弃了之前数据PUSH型的告警规则，完全使用PromQL来触发告警，相比之前确实灵活了很多，不过学习成本会略高一丢丢，权衡之下，我们认为这是值得的。下面用几条简单的PromQL来入门一下PromQL的用法，至于更多使用知识，请参考Prometheus官网

    需求1：客户端失联告警

    1. target_up == 0

    target_up是夜莺自动生成的一个监控指标，用于监控采集客户端是否存活，如果采集客户端在持续上报监控数据，target_up的值就是1，如果采集客户端不再上报监控数据了，这个指标的值就变成0了，所以，PromQL如上配置，即可在监控客户端失联的时候告警，为了防止网络抖动的情况，或临时restart进程，告警规则里，持续时长一般配置为60秒，给出一定的容错周期。

    监控数据和监控客户端是如何关联的呢？就看监控数据中的ident标签，或host标签，如果有这俩标签中的一个，系统就认为这个监控数据是跟某个监控客户端相关的，就认为在这一时刻，监控客户端是活着的。

    需求2：对整机的CPU空闲率告警

    CPU空闲率的指标是cpu_usage_idle，我们直接用promql查询这个指标，可以看到，有很多Label，比如：cpu="cpu0"说明这个监控指标标识的是0号cpu的数据，我们要处理整机的CPU空闲率，应该用这个Label：cpu="cpu-total"

    1. cpu_usage_idle{cpu="cpu-total"} < 25

    上面的promql只是指定了cpu="cpu-total"这一个标签，没有指定是哪个机器，那就表示对所有机器生效，任何一台机器的CPU空闲率小于25就告警。

    简单的PromQL一般就是指定metric，然后在{}中指定筛选标签，和之前夜莺的告警配置规则是一个道理，但是PromQL远不止可以做这些，还可以做很多更复杂的表达式计算，更多知识请参考：Prometheus官网

    下面是一条Prometheus的告警规则，对照这条规则，咱们看一下是怎么对应到夜莺的功能的。

    1. groups:
    2. - name: example         # 报警规则组的名字
    3.   rules:
    4.   - alert: InstanceDown # 检测job的状态，持续1分钟metrices不能访问会发给altermanager进行报警
    5.     expr: up == 0
    6.     for: 1m             # 持续时间，表示持续一分钟获取不到信息，则触发报警
    7.     labels:
    8.       severity: danger  # 自定义标签
    9.     annotations:
    10.       summary: "Instance {{ $labels.instance }} down"     # 自定义摘要 
    11.       description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than
    • groups.name，报警规则组的名称，有点像是夜莺里的业务组的概念
    • alert，表示告警规则名称，和夜莺里的规则名称类似
    • expr，是一条promql表达式，和夜莺的告警规则里的promql对应
    • for，对应夜莺告警规则里的持续时长
    • labels，对应夜莺告警规则里的附加标签
    • annotations，夜莺没有这个概念，夜莺在处理发送内容时，会有统一的几个模板来生成告警内容
    • evaluation_interval，这个是在Prometheus的global段的配置，表示规则执行频率，对应夜莺规则里的执行频率

    当然，夜莺的告警规则还有一些其他配置，比如：

    • 规则备注：未来发送告警消息的时候，会把备注信息带上
    • 告警级别：默认分了3个级别，夜莺把告警级别做成一个单独的字段了，如果是Prometheus生态的话，做成标签即可
    • 生效集群：夜莺可以接入多个Prometheus、VictoriaMetrics、M3DB集群，所以，告警规则具体是生效到哪个集群，需要有个配置指定
    • 预案链接：每一条触发的告警，都应该对应一个预案，这是最佳实践，所以告警规则里可以指定预案链接，发送告警消息的时候也可以带上
    • 生效配置：控制该条告警规则是否生效，如果生效，具体是在哪些时间点生效
    • 通知媒介：配置告警发送的时候是发邮件、还是发钉钉、发企业微信等
    • 告警接收组：配置告警通知的时候，通知哪些人，配置成组相当比较好管理，比如某人离职，只要从组里移除即可，不需要修改每条告警规则
    • 启用恢复通知：一般告警的时候会发一条通知，恢复的时候也可以发一条通知，如果只想收告警，不想收恢复，可以在这里关闭
    • 重复发送频率：即通道静默时间，告警发出之后，如果一直没有恢复，过xx时间之后，会重复通知
    • 回调地址：可以配置多个webhook地址，告警之后，会依次调用，POST方式，把告警事件内容序列化为JSON，放到POST Body中，webhook对应的逻辑就可以从中解析出告警事件，做一些自动化处理逻辑