2. 告警规则基础：概念、触发与通知

告警规则，说白了就是一套 "如果…那么…" 的逻辑。

你告诉系统："如果日志里出现某个异常，那么你就通知我。" 就这么简单。

我刚开始用 ELK 的时候，觉得这玩意儿不就是写几个关键字匹配嘛？ 踩了几次坑才发现——规则写得好不好，直接决定你是半夜被叫醒看假警报，还是安稳睡大觉。

2.1 告警规则到底是什么？

从工程角度看，一条告警规则包含三个核心要素：

• 数据源：你需要监控的数据从哪来？ 通常是 Elasticsearch 的索引查询结果。
• 触发条件：满足什么条件才算异常？ 比如错误数量超过阈值。
• 通知动作：触发后干什么？ 发邮件、钉钉消息、还是调用 API。

你想想看，这三者缺一不可。没有数据源，规则就是个摆设；没有触发条件，系统不知道什么时候该出手；没有通知动作，那告警等于没用。

我记得有一次线上出问题，原因就是规则只配了查询，没配通知。结果日志量飙升，规则疯狂触发，但没人收到通知……嗯，那个教训挺深刻的。

2.2 告警触发条件：把异常翻译成代码

触发条件是告警规则的心脏。你写的条件越精准，误报越少。

常见的触发条件类型，我用一个表格来总结：

条件类型	说明	适用场景
阈值比较	指标值 > 或 < 某个固定数值	CPU 使用率 > 90%，错误率 > 5%
速率/频率	单位时间内事件出现的次数	5 分钟内 500 错误超过 100 次
变化率	当前值与历史均值的偏差比例	流量突然下降 50%
无数据	指定时间内没有新数据到达	心跳检测、定时任务未执行
组合条件	多个条件同时满足或按逻辑组合	高延迟 + 错误率飙升

阈值比较是最容易理解的。比如下面这个例子，用 Elasticsearch 查询语法来写：

// 在 Watcher 或 ElastAlert 中
"query": {
  "bool": {
    "filter": [
      {"term": {"status": "500"}},
      {"range": {"@timestamp": {"gte": "now-5m"}}}
    ]
  }
}

这个查询在匹配所有最近 5 分钟内状态码为 500 的日志。然后再通过一个条件判断，比如 ctx.payload.hits.total > 100，就触发告警。

我曾经吃过这个亏，直接把错误率阈值设成 0，结果上线当天被各种边缘 case 刷屏……后来改成基于历史均值的动态阈值，才消停下来。

2.3 告警通知方式：把信号送到对的人手里

触发条件写好了，下一步就是决定怎么通知你。通知方式选不对，等于白忙活。

我一般把通知方式分成三个等级，你可以参考一下：

1. 即时通知：P0 级别的故障，必须马上知道。适合用电话、短信、钉钉/企业微信机器人。延迟越低越好。
2. 常规通知：需要关注但不紧急。邮件、Slack 频道、Jira 工单。可以用来做日报或周报汇总。
3. 记录归档：不需要人工处理，但留作事后审计。写入单独的 Elasticsearch 索引，或者存到日志文件里。

具体到技术实现，Kibana Alerting 和 ElastAlert 都支持多种通知通道。这里拿钉钉机器人的 Webhook 举个例子：

// 通知动作配置示例
"actions": {
  "dingtalk": {
    "webhook_url": "https://oapi.dingtalk.com/robot/send?access_=xxx",
    "message": {
      "msgtype": "markdown",
      "markdown": {
        "title": "【严重告警】线上错误率过高",
        "text": "当前错误率: {{error_rate}}%\n超过阈值: 5%\n时间窗口: 最近 5 分钟"
      }
    }
  }
}

你想想看，如果每次告警都发邮件，对 P0 级别的事故来说太慢了。我习惯把邮件留给日报，把即时通讯留给紧急事件。

2.4 一条完整规则的肉眼看得到的结构

为了帮你把刚才讲的内容串起来，我画了一张图。它展示的就是一条告警规则从数据输入到通知发出的完整流程。

这张图从数据源出发，经过触发条件判断，最后走到通知动作，最终产生告警事件。每一步都可以灵活配置，但整体结构就是这样。

2.5 写在前面的一些习惯

聊到这里，我想分享几个我个人在写告警规则时养成的习惯：

• 从简单开始：先写单条件规则，跑通了再叠加组合条件。一上来就搞复杂逻辑，排查起来会很痛苦。
• 测试阶段关掉通知：新规则上线前，先运行一段时间只看日志，确认触发条件准确之后再打开通知。
• 给每条规则加描述：规则多了以后，你根本记不清每条是干嘛的。加一句话备注，比如"监控支付接口5分钟内的500错误数"。

嗯，别嫌麻烦。这些习惯能在你维护上百条规则时，救你一命。