结构化异常日志, 如何做好error日志结构化,便于日志监控过滤.

父文章

    稳定性之监控,报警,定位 架构师该做什么. 偏数据分析视角,智能定位. 2/5/15

为什么要结构化?

 结构化后,维度:能够表征业务. 能够定位代码入口,异常点.

1. 入口来源 链路跟踪和mdc结合

2. logger的特定类方法. logger自带属性

3. 自己打印在内容里规划化. 来源

数据分析角度来看稳定性,维度够多,自动化分析. 另外做好维度的边界剥离, 维度是有从属关系的.

分析问题先从大问题再从小维度.

详见

如何结构化

1. 搞一个类封装日志参数

业务信息:

   1. type(type序号,type名+type值), 通过每个接口的注解获取.(直接法: type序号+type名+参数序号+字段属性,aware接口,) 主type,子type

     通过threadLocal获取,需要业务代码解析后设置进来,但侵入业务代码

  2.  通过上下文,前端传入的业务分类如上,端码,

  3. 业务明确的错误码

结构:  端上场景 + web接口类+foreach(异常类名+异常方法+各层异常code)+forEach(异常具体信息)  (端上维度属于上维度, 如果原因不是端上维度,可能就会导致error分散化,导致雪崩场景的error告警,哪哪都告警. 你也不可能把所有下游维度都采集到,或者最底层的维度采集到,例如redis失败,导致调用下游系统error增加,导致自己内部error增加,也是类雪崩场景. 最终还是要采样分析,分析到最终原因. 但是如果系统能够维度刚好在里面,能够