架构误区系列 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 日志的情况。换一个角度:
运维人员的生产力是有限的,如果报告出来需要处理的问题过多,和没有报告问题是一个效果。
版权声明: 本文为 InfoQ 作者【agnostic】的原创文章。
原文链接:【http://xie.infoq.cn/article/341dbcea140357155e7209144】。文章转载请联系作者。
评论