给日志加上traceid

traceid是什么？

  • 这里所说的traceid是指在服务端收到客户端请求后到服务端返回给客户端结果的过程中给没一条日志添加一个相同的traceid来跟踪请求到返回的整个过程。

为什么要给服务的日志加上traceid?

  • 最近准备给项目里的日志都加上traceid。这样方便服务端网关在收到请求后到返回给客户端之前追踪整个请求的链路。方便排查线上的bug以及统计查询请求的性能瓶颈。
  • 添加一个traceid，对于一个新项目而言并不是什么难事，但是对于一个已经成熟上线的项目而言，还是有很多要注意的地方。
  • 目前我们这个上线的项目采用的微服务的思想:项目里面把功能相对独立的部分单独成进程。方便服务的快速迭代，快速部署和部分更新。实际上这样的拆分作用相当明显，需要功能都不需要停服就可以一做到热更新，大大降低了维护成本，提高了用户的体验。

如何设计traceid?

  • 这里把traceid分成4个部分:
  • 用户相关的uid
  • 消息相关的msgid
  • 递增或唯一的tid
  • 时间相关的时间戳timestamp
  • 用户的uid不用说，方便识别这个业务和那个用户相关。
  • 消息msgid就方便定位业务。
  • tid为了保证traceid的唯一性。
  • 时间戳方便统计请求到返回消耗的时间，同时在每深入一步后可以计算出消耗的时间。

traceid是否可以做到对业务透传？

  • 目前对于线上业务结构，还做不到透传。只能通过在节点间、函数调用间传递参数traceid的方式来使用traceid,这是最简单也是最繁琐的方案了。不过还挺实用，能够解决问题。目前先让各节点支持traceid的链路追踪，后续再进行优化。

总结

  • traceid的添加还在进行中，目前已完成部分节点的链路日志打印。后续会添加链路时间消耗的统计。这里先行记录一下。后续会使用traceid来统计一下各个api的调用耗时。