日志规范
服务指标
1.事前预防(预防降低故障几率)
• 监控预警
• 日常健康度巡检
• 稳定性checklist
• 研发规范
• 容量规划
• 压测
• 回滚措施
• 容错设计
• 依赖治理
• 慢sql 治理
• 故障演练
• 应急预案
2.事中处理(处理应对,止损恢复)
• 监控告警
• 重启
• 回滚
• 快速扩容
• 熔断降级
• 服务流控
• 服务补偿
• 问题快速定位
• 信息同步
3.事后复盘(复盘优化)
• 故障案例复盘
• 损失统计
• 系统优化
• Checklist 完善
规范日志目的
为了达到发生error异常告警后,开发立马能介入并且快速定位问题。目前监控主要是针对error日志,其实后面将会根据情况,对关键接口的接口请求、耗时等等都做监控。
目前存在的问题
- 日志打印的不是太规范,导致error太多,真正有效的信息也被淹没了
- 没有及时关注异常
- 日志不够细腻,打印的太泛
改造后的要求
遇到ERROR告警必须解决,找到原因,排期上线
统一好工具等
-
全局异常拦截类对日志的打印
@ControllerAdvice的类,对于业务异常,只打印warn级别,其他的使用自带的拦截器,需要自己排查一下项目这个全局异常拦截的打印情况 -
异常类(BusinessException等)
使用统一的异常拦截类 -
http的公共工具类,都需要支持打印返回值,方便排查
-
使用LocalDate, 使用
javax.validation-api
对接口参数进行校验
1.如何打好日志
INFO
- 核心的配置加载,变化等都需要打印:如
kafka是否启动
,加载xxx是否成功
,定时任务是否启动
等等 - 处理
核心、重要
任务时候流程中,比如在开始计算每个任务的开始信息等等。会参与计算,以及比较核心的信息都可以打出来。 -
核心、重要
业务的增,删,改在修改后都必须打印日志 - 对于
核心、重要
业务在开始走流程的时候,都建议打印入参,以及开始标志,结束后打印出参,以及结束标志。耗时的话根据业务情况增加
WARN
- 对于程序出现异常,但是并不需要人工介入,依靠代码容错机制等即可恢复的就可考虑打印warn,例如:配置文件未配置,但是有默认值
- 对于业务异常,但是是属于正常业务的范围内,也仅需要打warn,同时根据业务情况可以考虑不打印。
例如:- 调用参数异常
- 一些异常数据,但是这些异常数据是老的数据并不影响主流程
- 对于业务并无影响,或者就算报错了,也没关系,不影响其他的,可以考虑仅打印warn
ERROR
- 对于rpc,http等形式调用其他服务,都需要考虑try-catch异常,打印包括入参, 出参,返回结果等错误信息。
改造后需要考虑catch住异常和抛出去的区别,如果不知道有什么影响可以先catch住,打印错误信息后,再次抛出 - 对于业务,出现程序无法处理,需要人工介入才能恢复的问题,也是需要打印error日志,将详细的参数信息打印好
告警处理
- 细分错误种类
- 对于已知错误阈值可调高(例如调用不稳定的下游超时),配置好熔断
- 对于未知错误要做到灵敏,有错误就解决
- 告警分组,灵敏、非核心的告警尽量只知会系统相关的人,出现大量的错误,严重的错误,告知范围扩大到全组,方便所有人跟进
监控
监控大屏的搭建,对于一些核心指标必须有(多个维度的:业务指标、基础组件、性能指标等等),例如:
这些指标也需要设置对应的告警,大于、小于多少的阈值,各种环比的阈值等等
© 版权声明
文章版权归作者所有,未经允许请勿转载。
相关文章
暂无评论...