写点什么

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

作者:agnostic
  • 2023-12-10
    上海
  • 本文字数:1055 字

    阅读完需:约 3 分钟

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


有系统就有日志,有日志就有告警。作为开发同学,往往会比较“重视”日志,把很多的错误都定义为 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 日志的情况。换一个角度:

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


发布于: 刚刚阅读数: 6
用户头像

agnostic

关注

常识、KISS、高可用、合规架构、架构治理 2019-02-14 加入

二十年架构经验,互联网金融专业架构师。Open Group Master Certified Architect

评论

发布
暂无评论
架构误区系列18:error、warn不分_日志级别_agnostic_InfoQ写作社区