1.单次接口串联:
mdc 串联所有业务日志
2.打印日志分类:
按照规范打印uid【鉴权层】,日志层级(入口层,边界io层,内部业务日志)【便于筛选入口日志,找到对应的TraceId】,日志类型(相当于不同的表,pv日志,事件流类型,业务日志1,业务日志规范2)
3.更高维度 业务维度 多次接口串联 :
把日志系统改造成留 生命周期事件流系统,需要业务方打印实体id即entityId,或者 会议id作为生命主题。聚合多次接口的调用. 没有本质上的区别: 操作主体 上边界一入口, 下边界 多依赖方. 对于业务来说, 主体是用户,入口边界是端,出口边界各个服务端. 透传到服务端上那就记录下来, 有时候不同的流程掉同样的接口,需要客户端把流程名/业务id透传到底层的各个系统(接口/业务语义文案的映射转化可能会不全). ( 可能底层系统得到的流程是不全的,但起码能和业务上交流,类似端码和端事件码的功效. 不够顾名思义. ) [其实不合适,因为都是int值,不知道含义,就和直接查看数据库是一样的。] 还是需要一套业务系统。进行文案展现。
鹰眼系统有1的思路,且是链路拓扑。放弃InheritableThreadLocal,封装一个Task,run时复制。而不是create时复制。
悟空系统有三的思路。
把脉系统有2的思路。
阿里云的日志服务将日志完全结构化和key-value化,无schema,支持多条件查询。极大改变了日志的文本性质。已经进化到埋点监控系统了。
日志还是返璞归真比较好,一个uid+入口层筛选出需要的信息,排查对应的问题即可。进一步通过一个 实体id查询生命周期核心事件流。