在大型网站系统设计中，随着分布式架构，特别是微服务架构的流行，我们将系统解耦成更小的单元，通过不断的添加新的、小的模块或者重用已经有的模块来构建复杂的系统。随着模块的不断增多，一次请求可能会涉及到十几个甚至几十个服务的协同处理，那么如何准确快速的定位到线上故障和性能瓶颈，便成为我们不得不面对的棘手问题。

Jaeger 是什么

为解决分布式架构中复杂的服务错误定位和性能问题，Google在论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中提出了分布式跟踪系统的设计和构建思路。

Jaeger 是受到 Dapper 的启发，由 Uber 创建的分布式追踪平台，可用于监控和追踪基于微服务模式构建的分布式系统。Jaeger 于 17 年 4 月份开源，9 月进入 CNCF 孵化，2019 年 10 月正式从 CNCF 毕业，一跃成为 CNCF 顶级项目。

Jaeger 的流行得益于背后有大厂和强大的组织支持，同时原生支持 OpenTracing 标准（可以认为是 OpenTracing 协议的参考实现），当前支持多种主流语言（如 Java、.NET、Golang、Python、NodeJS 等），并且社区有大量的 OpenTracing 生态组件可以直接使用。

在架构设计上，Jaeger 使用 gRPC 插件化的设计，可以同时支持多种后端存储，目前支持的数据存储包括：内存、Badger、Cassandra、Elasticsearch、GRPC插件等。在 Jaeger 的新版本中，也实现了流式架构来处理数据分析，不过需要额外引入 Kafka 和 Flink 组件。

但在要实现微服务系统完整的可观测性，我们发现 Jaeger 本身也具有一定的局限性：

• 相比其他的可观测性系统，Jaeger 更专注于链路追踪（Tracing），日志和指标功能支持比较有限。同时因为本身缺少监控和报警机制，Jaeger 往往需要结合其他系统来一起实现，比如 Prometheus、ELK 等。
• Jaeger 作为一个可观察性/监控系统的组成部分，是开发和运维同学定位和发现业务系统问题的重要手段，我们一定要保证监控系统比业务系统活的更久。而 Jaeger 作为一个开源项目，它本身只提供解决方案，并不会提供部署规模的评估方案和服务如何保证高可用的方案，这需要运维同学基于对服务高可用的经验和对业务系统规模的调研的给出具体部署方案。

那么这种情况下我们怎么去降低可观测性平台的复杂性？怎么去提供高可用和高性能的后端服务？

最好的方式是寻找一个能够兼容 Jaeger 的后端系统，提供高可靠、高性能的能力。

当 Jaeger 相遇 Erda

Erda 作为一款云上应用协同开发平台，提供了 SaaS 化可开箱即用的可观测性云服务，免去了自己运维多个监控、日志系统后端的复杂性，同时也提供了完整的微服务观测能力，包括但不限于：

• 服务性能监控，包括接口调用监控、SQL 调用监控、慢事务分析、JVM 监控等
• 分布式链路追踪，调用链路的瀑布图/火焰图等多种分析模式
• 分布式日志查询和分析
• 可视化并且灵活的告警配置，支持告警收敛、降噪
• 自定义仪表盘分析

一般情况下，可以有两种不同的方式来替换 Jaeger 的后端：

• 原生的数据用 Jaeger SDK 产生，查询模式继续使用 Jaeger 的 UI，这样对于应用开发同学来说继续沿用之前的使用模式，但也仅限于 Jaeger 能提供的 Trace 能力
• 原生的数据用 Jaeger SDK 产生，查询使用 Erda 的微服务观测平台

在 Erda 上，目前我们只支持第 2 种方式，原因在于除了 Trace 能力之外，Erda 还可以基于 Jaeger 的数据，自动发现服务调用拓扑，自动分析服务接口的调用性能等。

接下来，我们看一下如何使用 Jaeger SDK 把数据接入 Erda 微服务观测平台。

首先，在管理中心创建一个监控项目（监控项目和研发项目的区别是后者除观测能力之外还包含完整的 DevOps 研发功能）：

接下来在微服务治理平台中找到创建的监控项目，进入后点击【环境设置】 > 【接入配置页面】：

目前 Erda 支持 Jaeger SDK 直连后端的方式，为了区分不同用户上报的追踪数据和鉴权，我们需要根据页面的提示获取【接入点】、【环境ID】和【环境Token】三个变量。

下面以 Java SDK 为例，我们可以使用 Jaeger SpringCloud Starter 或者其他任何兼容 OpenTracing 的 SDK，然后在 Jaeger 的 tags 中添加上面的三个变量标签，并且把 SDK 的上报接入点修改为

例如：

opentracing:
  jaeger:
    service-name: <your_service_name>
    http-sender:
      url: https://collector.erda.cloud/api/jaeger/traces
    log-spans: true
    tags:
      erda.env.id: <your_env_id>
      erda.env.token: <your_token>

Jaeger 和 Erda 功能对比

拓扑分析可以自动计算并生成 Trace 的依赖拓扑，相比 Jaeger 增加了非常多的指标计算，包括 QPS、错误率、平均延迟、状态码分布等：

Erda 可以自动从 Jaeger 的 Trace 数据中计算出服务节点，并生成服务的全局 Top 对比：

Erda 提供服务端视角的 APM 功能，Jaeger 并不具备这样的能力：

Erda 可以对 Trace 数据进行计算分析并且生成大量可自定义配置的告警策略，Jaeger 还暂不支持此功能：

此外，Erda 链路追踪分析能力增强，并支持火焰图模式：

小结

Jaeger 作为 OpenTracing 协议的代表实现，也是 CNCF 的顶级项目和大量云原生框架实现Trace能力的首选。如果你正在使用 Jaeger ，可以很容易的在不修改代码的情况下进行尝试把数据接入到 Erda 进行统计和分析。

另外，Erda 2.0 版本也将于今天正式发布，本次版本中产品整体视觉交互进行全新的改版上线，深度优化产品用户体验；项目级的研发流程全新上线，在单应用的 CI/CD 基础之上，提供了项目级的流水线、制品、环境部署的核心功能，让软件项目产品研发、交付变得更简单优雅～我们在后续的文章中将会对新版本进行详细解读，感兴趣的小伙伴可以持续关注！

参考链接 & 延伸阅读

《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》

《使用SLS Trace实现Jaeger的高可靠部署方案》