唯品会Microscope——大规模分布式系统的跟踪、监控、告警

唯品会Microscope——大规模分布式系统的跟踪、监控、告警平台 - 马宏的世界 - 博客频道 - CSDN.NET
http://blog.csdn.net/alex19881006/article/details/24381109

最近的工作是在唯品会做监控平台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还有一个开源项目叫做Ostrich，用于定义监控指标（count, gauge, histogram, timer）。简单来说，我们想知道用户的在线数量，想知道系统的线程数量，。。。

任何一切想要量化的Metrics，都需要被记录下来。

不过同样的问题是，这个项目也是Scala写的，不过好详细是Java的开源世界中已经有了一个很著名的Metrics软件包。eBay的CAL系统就集成了这个软件包，用于获取监控指标。

除了metrics,对于开发人员来说，异常信息也是他们特别关注的，因此异常的堆栈调用链也需要收入到监控数据来源项。

从Twitter的可视化平台展示的一些demo来看，GC logs也被Twitter的开发人员作为数据来源的一项，存储到后端，进而使得开发人员能够看到 GC的详细信息。

我们认为，从大的方向上面说，数据来源可以总结为：

1、请求调用链
2、系统、业务 metrics（CPU, IO, memory，disk, http, servlet, db, cache, jvm...）
3、异常堆栈
4、GC log

数据有了，下一步就是怎么把客户端的数据传输到服务器端，进行分析、存储、展示了。

客户端数据的存储方案1：日志存储

Log4j现在推出了一个Log4j 2的版本，最大的变化就是用disruptor 的ring buffer做异步处理，异步写日志。从性能测试来看，在吞吐量和延迟方面都有很大提升，这个应该是淘宝的方案，淘宝应该是用disruptor实现了一个类似这样的日志组件。

客户端数据的存储方案2：内存存储

eBay和点评的都是用Java并发库中的LBQ来做存储的，队列做存储的好处很明显，就是读写很方便，性能也高。但是当客户端产生的数据量快速上升时，队列的容量就存在问题。

我们目前的方案是：基于disruptor做一个内存队列。当然，这仅仅是当前的方案，如果将来队列无法支持，那么log4j2 将是我们的备选方案。

存储之后，就是开启独立的线程异步发送到后端，走TCP。

目前flume作为分布式日志的收集框架，在唯品会已经大规模的使用，有专门的团队在维护flume。在将来我们可能考虑让flume来传输监控数据。

数据走到后端处理流程之前，要用消息中间件，比如Kafka/MetaQ做一个缓冲。

Kafka作为消息中间件，为后面的数据处理提供了很好地缓冲区，服务器端也可以非常从容的采用Poll模式来处理数据。

后端的数据处理，我们采用的是SEDA架构，多阶段事件驱动架构，用disruptor做线程之间的数据交换。将整个处理流程抽象为：验证、分析、告警、存储。

目前Storm作为分布式流式处理框架，在公司内部已经得到很好地应用，后期我们会把整个计算逻辑放在storm上面进行。

验证，主要是对一些不符合规范的数据进行过滤，已达到我们能够处理的标准。
分析：主要是对调用链进行统计，分析调用来源，调用依赖
告警：对可能存在问题的调用链，通过告警引擎发送给订阅的开发人员、运维人员
存储：将数据全量存储到TSDB(Hbase)。

Hbase作为一个天然的分布式存储平台，为我们解决了很多问题，Open TSDB则是在Hbase的基础上设计了一套适合存储监控数据的schema。我们将OpenTSdb的设计理念融入到我们的存储平台，使得它能够全量存储所有的监控数据。

查询UI。

查询UI，我们参考Twitter 的可视化平台，将整个页面划分为五个区域。
Home 区域：展示每个域的宏观信息，状态
Viz 区域：metrics报表，dashboard
Alert 区域： 告警平台
Exception 区域：异常的堆栈信息
Trace 区域：分布式调用链路

目前，Microscope已经完成了初步的框架和轮廓开发，还没有经历过海量数据的冲击，很多问题还需要在实践中进行检验，我们会持续完善，并最终开源。将它打造成名副其实的大规模分布式系统的跟踪、监控、告警平台。