大家好, 欢迎大家来参加这次公开课.
今天和大家一起探讨”通过Datafuse理解全链路跟踪”、”OpenTracing让监控一个分布式调用过程简单化”.
这个主题中, 提到了”Datafuse”、”全链路跟踪”、”OpenTracing”、”分布式调用” 等等名词, 首先想和大家交流一下, 大家对这些名词了解多少?
因为今天的分享是对这几块领域进行探讨, 大家可以先谈谈各自的理解, 可以在会议里进行打字说一说.
…… 大概2分钟的聊天.
今天的公开课, 希望能达到这样的目的, 1、了解链路跟踪实现的原理. 2、Rust社区关于链路跟踪有哪些开源库可以使用. 3、在学习datafuse项目时提供一种从链路跟踪角度入手项目的思路.
首先我来简单的介绍一下自己.
我叫苏林, 是一名从事于互联网研发的程序员, 也是一名技术爱好者, 在互联网行业有十余年, 先后效力于电商、SaaS领域, 对底层系统级开发比较感兴趣, 也才促使我学习和探索Rust语言.
今天的分享按以下3部分来进行.
1、介绍Datafuse以及为什么需要链路跟踪
2、什么是OpenTracing
首先我们先简单的了解一下什么是Datafuse.
…..
…..
一堆介绍完了以后, 抛出一个问题, 这样一个大型开源的分布式项目, 请求在各服务之间流转, 调用链错综复杂，一旦出现了问题、异常以及性能瓶颈时，很难追查定位，这个时候就需要全链路追踪来帮忙了。全链路追踪系统能追踪并记录请求在系统中的调用顺序，调用时间等一系列关键信息，从而帮助我们定位异常服务和发现性能瓶颈。
以一次简单的请求来直观的理解一下
假设用户发来一次http请求, 我们进行追踪, 返回的结果大概是右图的样子, 它是以时间线为层级的一个关系, 每一个色块就是一个操作的耗时, 不同的耗时之间，不同的操作之间它是存在一个调用的关系, 最终就会长成这个样子, 可以从图中发现 请求的执行 包括 读写Redis, 或者说是读写一个数据库, 有了这样的一个结果, 对我们分析问题就比较有帮助.
接下来, 通过Datafuse直观的带领大家感受下全链路跟踪的图形化界面.
目前datafuse的tracing，这一块目前还存在一些问题。一个是 query 的 tracing 集成到 jaeger 的话，目前似乎还取不到数据的；还有的是 store 的 tracing 目前做的链路不是很全面，所以能看到的信息有限。
目前跟踪不到从 query 到 store 的全链路的。只是简单给大家看一下, 在这里我也号召大家试着帮datafuse改进 tracing 能力, 今天这门公开课不是终点, 而是一个新的开始.
其实Datafuse全链路跟踪的实现, 是通过 tokio-rs/tracing 来实现的, 在Rust社区中还有…….
Dapper 跟踪模型
Dapper的核心功能是对每一次RPC的接收和发送设置跟踪标识和其他监控信息(比如耗时等), 并且把这些信息和请求RequestX关联起来. 同时跟踪模型不仅仅局限于特定的RPC框架, 还能跟踪其他行为, 比如SMTP会话, Mysql 操作等等.
Dapper 数据抽象
Dapper在RPC收发过程中生成Span, 并把所有Span挂载到特定的Trace Tree上, 这一步可以是异步的.
刚才提供, 我们主要关注于它的性能, 来看一下三个库的性能对比, 这是去年Rust Conf大会, PingCAP的研发小伙伴提供的一个性能对比分析图, 也正是由于前两个库的性能不满足他们的要求, 他们才开发了自己的Minitrace.
