作为服务的研发、运维人员，你会给服务配置哪些告警规则？
机器性能相关的？
很多人首先想到机器的 CPU、内存、磁盘、网络、IO 相关的指标，虽然在现代微服务架构下，这些指标的重要性下降了，但是这些指标确实比较容易配置，能够给你安全感。但这不是我今天要聊的。
服务的SLI指标？
如果对 Google SRE 稍微有点了解，大概率会听过 Google 四个黄金指标、RED 这样的方法论，必然不会遗漏 SLI 指标，这也不是我今天要聊的。
我想提醒大家的是：
服务的ERROR日志数量！
核心要点
- ERROR 日志数量告警不是替代 SLI，而是覆盖“指标漏报、埋点缺失、业务异常先写日志”的兜底监控。
- 这类告警的前提是日志已经中心化收集，并且至少能稳定解析出
level、module、service等字段。 - ERROR 告警会反向推动研发治理日志级别：真正影响服务运行的异常才应该打 ERROR，普通用户输入错误不应该制造告警噪音。
- 规则可以从“5 分钟内 ERROR 数量大于 0”开始，但生产环境应按服务重要性、错误类型和持续时间逐步细化。
很多人遗漏了这个监控告警，原因可能是：
- 日志告警工具缺失
- 日志不规范不好做告警配置
- 已经有了SLI等重要指标了，觉得够用了
统计服务的ERROR日志数量并做告警，ROI极高，大道至简，我来讲讲原因。
驱动你建立日志中心化收集、ETL、告警链路
指标体系相对容易，Prometheus、VictoriaMetrics 等几乎是每个公司的标配，指标的告警也相对容易，所以大家一般都是有的。在指标领域，有问题的通常不是工具，通常是业务研发只在意 CRUD，对程序稳定性、可观测性等关注较少导致的 SLI 缺失。
日志通常是后于指标体系的，各个公司的建设通常没那么完备。好在 ELK、Loki、VictoriaLogs 等工具的流行度越来越高，用这些开源项目完全可以把日志体系搭建起来。
但是我发现，很多公司有日志收集和查看，但是日志的告警容易缺失。这点请各位看官重视。ElasticSearch 有 ElastAlert2，VictoriaLogs 有 vmalert，如果觉得太过零散不好管理，统一使用 Flashduty 的告警引擎也可以。
https://flashcat.cloud/blog/flashduty-monitors-loki-and-victorialogs/
Flashduty 已经支持了 Prometheus、VictoriaMetrics、ElasticSearch、Loki、ClickHouse、VictoriaLogs、MySQL、Postgres、Oracle 等几乎所有常见数据源。体验地址：https://console.flashcat.cloud
驱动研发梳理日志级别
ERROR日志的告警，通常只需要根据级别过滤，比如告警规则配置（以VictoriaLogs举例）为：
_time: 5m AND _stream:{module="a"} AND level:ERROR | stats count(*) error_total | filter error_total:>0
只要发现 ERROR 级别的日志，就告警。这会让乱打日志级别的情况得到一定的治理。有些研发不太在意日志级别，有时即便是用户参数错误也会打印 ERROR 日志，这给故障排查带来很多噪音。通常来讲：
- 只有确实影响了服务运行的情况才打印 ERROR 日志。个别用户的问题通常只需要打印 Warning。清晰的日志级别，可以大幅减少排障时的噪音干扰。加速故障定位。
- 要求使用
level:ERROR这样的字段过滤，要求日志提前做好 ETL，驱动研发人员采用更结构化的日志格式。目前来看，JSON 格式的日志已经成为可观测性领域的共识。
ERROR 日志告警落地清单
| 环节 | 要做什么 | 目的 |
|---|---|---|
| 日志采集 | 将应用日志集中到 Loki、ElasticSearch、VictoriaLogs 等系统 | 避免只能登录机器查日志 |
| 字段解析 | 解析 level、module、service、trace_id 等字段 |
让告警可以按服务和错误级别过滤 |
| 告警规则 | 对核心服务配置 ERROR 数量或增量规则 | 发现指标体系没有覆盖的异常 |
| 噪音治理 | 对误打 ERROR 的代码做降级或修正 | 减少无效通知，提升告警可信度 |
| 故障联动 | 告警里带上原始日志、查询链接和 trace 信息 | 缩短从告警到定位的路径 |
指标告警的兜底
指标告警很重要，但有时容易漏掉一些问题。使用 ERROR 日志作为兜底，非常关键。
因为通常来讲，只要代码逻辑遇到问题，一定会打印 ERROR 日志，所以一般问题都可以通过这一条告警规则命中。
常见问题
Q1：ERROR 日志数量大于 0 就告警，会不会太吵？
A：第一版规则可以这样做，用来暴露日志级别混乱和异常噪音。进入生产值班后，建议按核心服务、错误类型、持续时间和历史基线逐步收敛，避免把告警通道打爆。
Q2：已经有 SLI 告警，还需要 ERROR 日志告警吗？
A：需要。SLI 更关注用户视角的成功率、延迟和流量，ERROR 日志更贴近代码执行路径。某些问题在 SLI 明显恶化前已经有 ERROR 日志，因此适合做早期信号和兜底信号。
Q3：日志告警最小依赖是什么？
A：至少要有中心化日志系统、稳定的日志级别字段、可按服务过滤的标签或字段，以及能把查询结果转成告警事件的规则引擎。
赶紧回去搞起来吧。相信我，它一定会帮你发现各种可以优化的点。
