架构误区系列 18：error、warn 不分

本期的架构误区说一个看似非常低级的问题：日志的告警级别问题。

有系统就有日志，有日志就有告警。作为开发同学，往往会比较“重视”日志，把很多的错误都定义为 error 级别，都有逐笔的告警。

其实，对于这个日志级别和告警的问题，我们需要问自己几个问题：

• 这个日志的出现，说明系统在这个时刻遇到问题了么？

• 这个日志需要有后续的处理措施么？

• 这个问题是一个逐笔需要处理的问题吗？还是一个数量超过阈值的问题，或者一个比例的问题。

如果这三个回答是 yes，那才真正需要打印 error 级别的日志，需要告警。

如果不是，大概率是一个 warn，同时需要配置一个 by 错误码数量或者比例的监控，更甚者就是定义一个正常的业务处理流程。

这个概念如果理解起来有一定的难度，那么我们就用例子了解决问题：

例 1：权限异常

很多系统在操作的时候都需要鉴权，如果用户没有操作某个功能的权限，就会弹出权限不足的异常。

对于这类的异常，就不需要 error 级别的告警，这是一个正常的系统交互。如果有必要，可以定义一个 warn 级别的日志，然后每日或者每时统计一下出现权限问题的数量和比例是否正常，可以间接的发现交互设计上的不合理点即可。

例 2：余额不足

在进行转账提现等资金操作时，我们都需要扣减用户的余额。一般情况下我们会先检查，在扣减。但是如果用户有多笔并发的操作，还是有可能在扣减的时候出现余额不足。

对于这类的问题，完全不需要打印 error 日志和告警。甚至，warn 日志都些多余。这就是一个正常的业务逻辑，回到页面上给用户 show 一下就可以了。

例 3：幂等提交导致 DB 唯一键冲突

用户前端重复提交，或者网络抖动，用户对于一个订单创建或者推进了两次。

这种场景也不需要触发 error 日志和告警。这种就应该将前置处理的结果再次返回就可以了，甚至不需要用户感知是提交成功还是幂等成功。

例 4：可重试的任务偶发的执行失败

这种情况，大部分的开发会倾向于打一个 error。但是如果我们的重试机制设计的非常可靠，大概率等到运维去处理的时候，已重试成功了。这种，其实我认为也只需要一个 warn，或者设计成超过一定的充实此处，再触发 error。

例 5：调用下游失败

这个和例 4 非常类似，如果有重试机制，只需要一个 warn，超过一定重试次数还不成功再打印一个 error。

例 6：费用收取失败

这个是一个业务异常的 case，即使告警出来，运维同学也无法处理。这种问题需要定义业务的操作流程 SOP，在系统日志上，可以是一个 warn，也可以只是一个 info。

总之，对于日志级别的设计，需要控制打印 error 日志的情况。换一个角度：

运维人员的生产力是有限的，如果报告出来需要处理的问题过多，和没有报告问题是一个效果。