日志查询服务，对日志结构化改造traceId，调用链路拓扑图,非error相关。

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查询生命周期核心事件流。