新手问题 分布式跟踪系统——产品对比

cdh0805010118 · 2018年06月27日 · 388 次阅读

分布式跟踪系统设计目标

  1. 低侵入性
  2. 灵活的应用策略;(可以 [最好随时] 决定所收集数据的范围和粒度)
  3. 时效性;从 agent 采样,到 collect、storage 和 display 尽可能快
  4. 决策支持;
  5. 可视化是王道;(丰富的数据报表)
  6. 低消耗;在 web 请求链路中,对请求的响应影响尽可能小
  7. 延展性;随着业务量暴增,分布式跟踪系统的高可用、和高性能表现依然好

分布式跟踪系统标准——OpenTracing

为了规范业界的分布式跟踪系统产品的统一范式,CNCF(大名鼎鼎的 Cloud Native Computing Foundation) 设计了 trace 标准,目前 uber、apple 等知名公司完全遵循该标准设计 trace 系统。

各大厂商 trace 系统对比

分布式跟踪系统各类产品,根据设计目标和标准形成综合对比:

产品名称 厂商 开源 OpenTracing 标准 侵入性 应用策略 时效性 决策支持 可视化 低消耗 延展性
jaeger uber 开源 完全支持 部分侵入 策略灵活 时效性高, UDP 协议传输数据 (在 Uber 任意给定的一个 Jaeger 安装可以很容易地每天处理几十亿 spans) 决策支持较好,并且底层支持 metrics 指标 报表不丰富,UI 比较简单 消耗低 jaeger 比较复杂,使用框架较多,比如:rpc 框架采用 thrift 协议,不支持 pb 协议之类。后端存储比较复杂。但经过 uber 大规模使用,延展性好
zipkin twitter 开源 部分支持 侵入性强 策略灵活 时效性好 决策一般 (功能单一,监控维度和监控信息不够丰富。没有告警功能) 丰富的数据报表 系统开销小 延展性好
CAT 大众点评 吴其敏 开源 - 侵入性强 策略灵活 时效性较好,rpc 框架采用 tcp 传输数据 决策好 报表丰富,满足各种需求 消耗较低 , 国内很多大厂都在使用 -
Appdash sourcegraph 开源 部分支持 侵入性较弱 采样率支持 (粒度:不能根据流量采样,只能依赖于请求数量);没有 trace 开关 时效性高 决策支持低 可视化太弱,无报表分析 消耗方面。不支持大规模部署, 因为 appdash 主要依赖于 memory,虽然可以持久化到磁盘,以及内存存储支持 hash 存储、带有效期的 map 存储、以及不加限制的内存存储,前者存储量过小、后者单机内存存储无法满足 延展性差
MTrace 美团 不开源 - - - -
CallGraph 京东 不开源 -
Watchman sina 微博 不开源 -
EagleEye 淘宝 不开源 -
skywalking 华为 吴晟 开源 完全支持 侵入性很低 策略灵活 时效性较好 由于调用链路的更细化, 但是作者在性能和追踪细粒度之间保持了比较好的平衡。决策好 丰富的数据报表 消耗较低 延展性非常好,水平理论上无限扩展

综合来说,

1. jaeger对于go开发者来说,可能比较合适一些,但是入手比较困难。它的rpc框架采用thrift协议,现在主流grpc并不支持。后端丰富存储,社区正在积极适配
2. appdash对于go开发者想搭建一个小型的trace比较合适,不适合大规模使用
3. zipkin项目,github很活跃,star数量很多,属于java系。很多大厂使用
4. CAT项目也属于java系, github不活跃,已不太更新了。不过很多大厂使用,平安、大众点评、携程...
5. skywalking项目, 也属于java系。目前已成为Apache下的项目了,github活跃,作者也非常活跃,当当、华为正在使用。
6. appdash项目,go语言开发,因为可视化过于简单、且完全内存存储,不太适合大规模项目使用。

所以选择的话,可以从skywalking、cat、jaeger和zipkin中选择。

参考资料

当当 11·11:高可用移动入口与搜索新架构实践

分布式调用跟踪系统调研笔记

京东分布式服务跟踪系统-CallGraph

全链路监控(一):方案概述与比较

各大厂分布式链路跟踪系统架构对比

skywalking

更多原创文章干货分享,请关注公众号
  • 加微信实战群请加微信(注明:实战群):gocnio
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册