日志-告警

日志规范

服务指标

image.png

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日志，将详细的参数信息打印好

告警处理

细分错误种类

对于已知错误阈值可调高（例如调用不稳定的下游超时），配置好熔断
对于未知错误要做到灵敏，有错误就解决

告警分组，灵敏、非核心的告警尽量只知会系统相关的人，出现大量的错误，严重的错误，告知范围扩大到全组，方便所有人跟进

监控

监控大屏的搭建，对于一些核心指标必须有（多个维度的：业务指标、基础组件、性能指标等等），例如：