如上的方法，其实就是告警引擎的核心逻辑。告警规则里会要求用户配置promql以及执行频 率，告警引擎就会根据执行频率周期性执行，每次执行的时候就是拿着promql去查询，promql 中带有阈值，即上例中的 <60，所以如果所有机器的内存可用率都很高，比如维持在80~90， 那这个promql是不会返回查询结果的，此时监控系统就认为一切正常。如果返回了结果，比如 上例中返回了3条结果，告警引擎就会认为有异常产生，生成3个告警事件。

，如果某两个级别对应完全一样的处理逻辑，就可以 合并成一个级别。 我的做法是把告警分成 3 个级别。 级别 通知渠道 说明 Critical 电话、短信、即时消息、邮件 影响收入的、影响客户的，必须立刻处理 Warning 短信、即时消息、邮件 无需立刻处理，但是如果不处理，时间久了就会 演化为 Critical 的问题，可以先放入 TODO 列 表，手头上的紧急事务搞定之后就去处理 90%，实际 机器的内存使用率已经 95%，此时就只会发送 Critical 的事件，Info 的就被忽略了。 相关策略配置好之后，就可以收告警了，比如利用钉钉发送，会呈现为一张告警消息卡片： 我们可以直接在钉钉（或飞书、企微等 IM）内部点击跟进，或直接关闭、临时屏蔽，方便地移动办公。 当然，也可以登录 FlashDuty，在 WEB 上查看，需要有个非常直观的页面告诉用户您当前有哪些告