日志-告警

随笔7个月前发布
138 0 0

日志规范

服务指标

日志-告警

1.事前预防(预防降低故障几率)

• 监控预警
• 日常健康度巡检
• 稳定性checklist
• 研发规范
• 容量规划
• 压测
• 回滚措施
• 容错设计
• 依赖治理
• 慢sql 治理
• 故障演练
• 应急预案

2.事中处理(处理应对,止损恢复)

• 监控告警
• 重启
• 回滚
• 快速扩容
• 熔断降级
• 服务流控
• 服务补偿
• 问题快速定位
• 信息同步

3.事后复盘(复盘优化)

• 故障案例复盘
• 损失统计
• 系统优化
• Checklist 完善

规范日志目的

为了达到发生error异常告警后,开发立马能介入并且快速定位问题。目前监控主要是针对error日志,其实后面将会根据情况,对关键接口的接口请求、耗时等等都做监控。

目前存在的问题

  1. 日志打印的不是太规范,导致error太多,真正有效的信息也被淹没了
  2. 没有及时关注异常
  3. 日志不够细腻,打印的太泛

改造后的要求

遇到ERROR告警必须解决,找到原因,排期上线

统一好工具等

  1. 全局异常拦截类对日志的打印
    @ControllerAdvice的类,对于业务异常,只打印warn级别,其他的使用自带的拦截器,需要自己排查一下项目这个全局异常拦截的打印情况

  2. 异常类(BusinessException等)
    使用统一的异常拦截类

  3. http的公共工具类,都需要支持打印返回值,方便排查

  4. 使用LocalDate, 使用javax.validation-api对接口参数进行校验

1.如何打好日志

INFO

  1. 核心的配置加载,变化等都需要打印:如kafka是否启动加载xxx是否成功定时任务是否启动等等
  2. 处理核心、重要任务时候流程中,比如在开始计算每个任务的开始信息等等。会参与计算,以及比较核心的信息都可以打出来。
  3. 核心、重要业务的增,删,改在修改后都必须打印日志
  4. 对于核心、重要业务在开始走流程的时候,都建议打印入参,以及开始标志,结束后打印出参,以及结束标志。耗时的话根据业务情况增加

WARN

  1. 对于程序出现异常,但是并不需要人工介入,依靠代码容错机制等即可恢复的就可考虑打印warn,例如:配置文件未配置,但是有默认值
  2. 对于业务异常,但是是属于正常业务的范围内,也仅需要打warn,同时根据业务情况可以考虑不打印。
    例如:

    • 调用参数异常
    • 一些异常数据,但是这些异常数据是老的数据并不影响主流程
  3. 对于业务并无影响,或者就算报错了,也没关系,不影响其他的,可以考虑仅打印warn

ERROR

  1. 对于rpc,http等形式调用其他服务,都需要考虑try-catch异常,打印包括入参, 出参返回结果等错误信息。
    改造后需要考虑catch住异常和抛出去的区别,如果不知道有什么影响可以先catch住,打印错误信息后,再次抛出
  2. 对于业务,出现程序无法处理,需要人工介入才能恢复的问题,也是需要打印error日志,将详细的参数信息打印好

告警处理

  1. 细分错误种类
  • 对于已知错误阈值可调高(例如调用不稳定的下游超时),配置好熔断
  • 对于未知错误要做到灵敏,有错误就解决
  1. 告警分组,灵敏、非核心的告警尽量只知会系统相关的人,出现大量的错误,严重的错误,告知范围扩大到全组,方便所有人跟进

监控

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

日志-告警

这些指标也需要设置对应的告警,大于、小于多少的阈值,各种环比的阈值等等

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...