分布式链路追踪

博客, 技术 / 作者： / 2020年12月6日

sleuth

  • 最近系统优化，公司内部自建了流程引擎，流程引擎节点之间的唤起是通过mq消息的模式，有夸线程导致日志上线文不连贯，一个业务流程不能通过traceId关联起来，尤其最近大量迁移历史功能到流程引擎上，日后肯定会排查问题。
    带着问题，找下解决方案

回顾下什么是sleuth

  1. 大型互联网公司，通常每日的日志量是T或者是P级别，这么大日志中搜索日志怎么办呢？不可能去vi 和 tail 。搜索引擎该出场了，现在日志收集比较主流的是ELK(elastic search + Log stash + kibana)估计还有其他的，原理应该差不多，搜索引擎 + 日志收集 + 可视化界面
  2. 公司运维已经搭建好了ELK，ELK 非常强大，目前公司有几个应用场景
  • 日志收集
  • 异常监控，elk 可以基于日志做异常监控，可以发送邮件和webhook等
  • 图标统计，可以统计接口平均响应时间、接口调用次数、接口并发量等
  1. Spring-Cloud-Sleuth 应用而出，是分布式系统的必然产物，由于分布式系统往往是将业务的纵向的拆分倒不同子系统中，所以一个完整的业务，需要走很多节点。
  • 其实以前已有一套方案，MDC + http header 增加id ，可以将http远程调用链接起来
  1. sleuth 结构分为：traceId + spanId + parentSpan
  2. sleuth demo

spring boot 1.5x mq接入sleuth

  • 看过spring boot 2.0 实现源码后，归根结低，需要保存traceId，spring 2.0 通过切面的方式，在mq推送和消费端来处理，代码看起来相对比较复杂。
  • 目前项目rabbitMq producer 和 consumer 都做了封装，所以在producer 执行push时将traceId保存到message的header中
  • 消息消费时，将header 中的traceId 保存到sleuth上下文中