共计 2692 个字符，预计需要花费 7 分钟才能阅读完成。
在大型网站零碎设计中，随着分布式架构，特地是微服务架构的风行，咱们将零碎解耦成更小的单元，通过一直的增加新的、小的模块或者重用曾经有的模块来构建简单的零碎。随着模块的一直增多，一次申请可能会波及到十几个甚至几十个服务的协同解决，那么如何精确疾速的定位到线上故障和性能瓶颈，便成为咱们不得不面对的辣手问题。
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 的上报接入点批改为
【https://collector.erda.cloud/…】
例如：
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 的高牢靠部署计划》
