用 ERROR 日志做告警：低成本高 ROI 的兜底监控实践

作为服务的研发、运维人员，你会给服务配置哪些告警规则？

机器性能相关的？

很多人首先想到机器的 CPU、内存、磁盘、网络、IO 相关的指标，虽然在现代微服务架构下，这些指标的重要性下降了，但是这些指标确实比较容易配置，能够给你安全感。但这不是我今天要聊的。

服务的SLI指标？

如果对 Google SRE 稍微有点了解，大概率会听过 Google 四个黄金指标、RED 这样的方法论，必然不会遗漏 SLI 指标，这也不是我今天要聊的。

我想提醒大家的是：

服务的ERROR日志数量！

很多人遗漏了这个监控告警，原因可能是：

• 日志告警工具缺失
• 日志不规范不好做告警配置
• 已经有了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 日志作为兜底，非常关键。

因为通常来讲，只要代码逻辑遇到问题，一定会打印 ERROR 日志，所以一般问题都可以通过这一条告警规则命中。

赶紧回去搞起来吧。相信我，它一定会帮你发现各种可以优化的点。