目前的产品架构，分布式系统得到了大范围的应用，使得系统更加灵活，不过同时也给开发、运维人员也带来了很大的难题，如何监控和优化分布式系统的行为。

这里简单介绍下一个小众、简单的 APM 监控工具。

简介 #

分布式追踪的起源源自于 Google 在 2010 年发布的 Dapper (中文版) 论文，一个 Google 内部使用的一个分布式系统跟踪基础设施，其关键提出了 Trace、Span、可视化等核心概念。

后来 Twitter 受到了 Dapper 的启发开源了现在的 Zipkin，包含了存储和可视化 UI 展示；接着，Uber 也在 2015 年开源了 Jaeger 项目，其功能和 Zipkin 类似，这也是目前用的较多的系统，现在已经成为 CNCF 的托管项目。

为了提高不同 Trace 系统的兼容性，曾提出了 OpenTracing 标准，用于提供平台无关、厂商无关的 API，使得开发人员能够方便的添加追踪系统的实现。后续还出现过 OpenCensus 项目，都企图统一分布式追踪，直到 OpenTelemetry 出现整合了以上两个项目，逐渐成为可观测领域的标准，而且还统一了 Metrics、Log 等监控相关内容。

依赖关系 #

如下是一个分布式调用的例子，客户端发起请求，首先到达负载均衡器，接着经过认证服务、计费服务，然后请求资源返回结果。

数据被采集存储后，分布式追踪系统一般会选择使用包含时间轴的时序图来呈现这个 trace。

集成系统 #

Jaeger #

目前使用比较广的是 Jaeger(Uber) 和 Zipkin(Twitter)，这里简单介绍 Jaeger 的使用。

如上所示，Jaeger 的架构分成了如下几个模块：

• Jaeger Client 为不同语言实现了符合 OpenTracing 标准的 SDK，应用程序通过 API 写入数据，然后发送给 Agent 。
• Agent 安装在宿主机上的一个监听 UDP 端口常驻进程，用来接收 span 数据，它会将数据批量发送给 collector。
• Collector 接收 Agent 发送来的数据，然后将数据写入后端存储，被设计成无状态的组件。
• Data Store 后端存储支持将数据写入 Cassandra、Elastic Search。
• Query 接收查询请求，从后端存储系统中检索 trace 并通过 UI 进行展示。

在 2.0 版本之后提供了单个二进制的实现，可以参考 Architecture 中的相关介绍，通过单个文件支持不同角色配置，简单来说，可以通过 jaeger-all-in-one 二进制文件启动，无需其它参数。

AppDash #

这里介绍的 Appdash 是开源的一款用 Go 实现的分布式系统跟踪工具套件，它同样是以 Google 的 dapper 为原型设计和实现的。可以直接从 sourcegraph.com 上下载，在 appdash/cmd 中包含了一个简单的示例，也可以通过如下命令安装。

$ go get -u sourcegraph.com/sourcegraph/appdash/cmd/...

另外，appdash 自带一个服务端的示例，在源码的 examples/cmd/webapp 目录下，在编译执行 webapp 会看到如下结果：

$ webapp
... ... Appdash web UI running on HTTP :8700
[negroni] listening on :8699

这一示例包含了 appdash server、front service、backend service 等组件，直接运行上述编译后的程序，然后通过浏览器打开 http://localhost:8700 连接就可以看到 appdash server 的 UI 界面，一个非常简单的 trace 页面展示。

然后访问 http://localhost:8699/ ，就可以触发了一次 trace，然后在 appdash server UI 可以看到如下界面。

参考 #

• The OpenTracing Semantic Specification OpenTracing 标准的定义，规定了不同语言间需要实现的函数、类型等。