本文介绍了唯品会的Microscope监控平台，旨在实现大规模分布式系统的跟踪、监控和告警。文章讨论了链路监控的实现思路，包括对Google Dapper、Twitter Zipkin等方案的研究，以及如何在Java基础上建立跟踪模块。同时，文章提到了数据来源、存储方案（如Log4j、Disruptor、Hbase）、数据传输（如Flume、Kafka）和后端处理（如Storm、SEDA架构）。最后，作者展望了平台的未来发展和优化。
最近的工作是在唯品会做监控平台Microscope。我们的目标是：大规模分布式系统的跟踪、监控、告警平台。
对于链路监控这块，业界的论文当属Google Dapper这篇，它详细的阐述了如何对请求调用链进行跟踪，提出了理论模型，然后它没有具体的代码实现。Twitter 的Zipkin则是根据这篇论文用Scala语言将其实现，并且开源。
Scala在Twitter大规模的使用，包括Twitter的的RPC框架也都是用Scala实现的，我们这边还是以Java为主，所以我们就考虑在参考Zipkin的基础上，自己实现跟踪模块。
国内的很多互联网公司也是基本上按照Dapper的论文模型来实现链路监控：淘宝的鹰眼，新浪微博的watchman，京东的hydra。一脉相承。
eBay则是用了一套叫做Transaction的概念来实现链路监控，大众点评网的CAT的开发者就来自eBay，所以两者高度相似。
链路监控的核心是：用一个全局的 ID 将分布式请求串接起来，在JVM内部通过ThreadLocal传递，在跨JVM调用的时候，通过中间件（http header, framework）将全局ID传递出去，这样就可以将分布式调用串联起来。
模型有了，剩下的工作就是如何获取数据了。
淘宝有众多的中间件，先天优势，在中间件中埋点就可以了。新浪微博采用的方式比较前卫（个人感觉），用的是字节码增强技术来埋点，类似Btrace的做法。
埋点需要与中间件耦合，字节码需要在运行时重写类文件，本质上其实都需要对现有的代码做修改，只不过角度不一样，我们最终的目标其实都是一样的：对应用程序透明即可。所以两种方案各有千秋，合适就行。
论文中提到过采样的问题，考虑到数据量很大的时候，全量跟踪会导致很大的压力，采样便应用而生。淘宝用的是hash采样，京东用的是固定时间段内固定跟踪数量的采样，Dapper使用的是自适应采样。我们的采样，要不要做，暂时没想好，全量先。
跟踪链路的数据，只是监控平台数据来源的冰山一角。
我们在研究中发现Twitter还有一个开源项目叫做Ostri
对于链路监控这块，业界的论文当属Google Dapper这篇，它详细的阐述了如何对请求调用链进行跟踪，提出了理论模型，然后它没有具体的代码实现。Twitter 的Zipkin则是根据这篇论文用Scala语言将其实现，并且开源。
Scala在Twitter大规模的使用，包括Twitter的的RPC框架也都是用Scala实现的，我们这边还是以Java为主，所以我们就考虑在参考Zipkin的基础上，自己实现跟踪模块。
国内的很多互联网公司也是基本上按照Dapper的论文模型来实现链路监控：淘宝的鹰眼，新浪微博的watchman，京东的hydra。一脉相承。
eBay则是用了一套叫做Transaction的概念来实现链路监控，大众点评网的CAT的开发者就来自eBay，所以两者高度相似。
链路监控的核心是：用一个全局的 ID 将分布式请求串接起来，在JVM内部通过ThreadLocal传递，在跨JVM调用的时候，通过中间件（http header, framework）将全局ID传递出去，这样就可以将分布式调用串联起来。
模型有了，剩下的工作就是如何获取数据了。
淘宝有众多的中间件，先天优势，在中间件中埋点就可以了。新浪微博采用的方式比较前卫（个人感觉），用的是字节码增强技术来埋点，类似Btrace的做法。
埋点需要与中间件耦合，字节码需要在运行时重写类文件，本质上其实都需要对现有的代码做修改，只不过角度不一样，我们最终的目标其实都是一样的：对应用程序透明即可。所以两种方案各有千秋，合适就行。
论文中提到过采样的问题，考虑到数据量很大的时候，全量跟踪会导致很大的压力，采样便应用而生。淘宝用的是hash采样，京东用的是固定时间段内固定跟踪数量的采样，Dapper使用的是自适应采样。我们的采样，要不要做，暂时没想好，全量先。
跟踪链路的数据，只是监控平台数据来源的冰山一角。
我们在研究中发现Twitter还有一个开源项目叫做Ostri
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
