概述
Jaeger 主要用于基于微服务的分布式系统的监控和问题定位，包括：
- 分布式上下文传输
- 分布式事务监控
- 根因分析
- 服务依赖性分析
- 辅助性能/延迟优化等
高可用性
在 Jaeger 的架构设计中，所有的后端模块都不会出现单点故障且可以横向扩容。该服务已经在生产环境中得到了稳定性的验证，例如，在 Uber 公司中的 Jaeger 服务每天要处理数十亿个 span 。
原生支持OpenTracing
Jaeger 的后端服务、Web 页面以及客户端Lib库在设计上原生支持了 OpenTracing 的标准，具体来说：
- 通过 span 的概念将 traces 信息表示为有向无环图。
- 支持强类型的 span 标签以及结构化的日志。
- 支持通过 baggage 的方式，来实现通用的分布式上下文传输等。
支持多种后端存储
Jaeger 支持两种流行的开源 NoSQL 数据库作为跟踪数据的后端存储：
- Cassandra 3.4+
- Elasticsearch 5.x/6.x/7.x
此外，Jaeger 还正在实验性用其他数据库来进行数据存储，例如 ScyllaDB、InfluxDB、Amazon DynamoDB、Logz.io。
Jaeger来提供了一种简单的内存存储方式用于快速使用和测试。
现代化的Web UI页面
Jaeger 的 WEB UI 页面是使用一款流行的开源前端框架 React 来实现的。在 v1.0 的版本中，对性能进行了相关的优化，使得用户可以在 UI 页面中高效的处理和展示大量的 trace 数据，例如可以展示包含 80000 个 span 的 trace 数据。
云原生的部署方式
Jaeger 的后端模块是以一组 Docker 镜像的方式进行发布的。其中，它的二进制文件支持各种配置设置方式，包括命令行参数、环境变量以及 yaml 或者 toml 等格式的配置文件。
用户可以使用 K8s Operator, K8s Template 以及 Helm Chart 的方式，轻松的在 K8s 中完成 Jaeger 的部署。
可观测
Jaeger 所有的后端模块都提供了标准了 Prometheus 的监控指标采集接口。同时，Jaeger 的日志输出也都使用了标准的结构化日志打印库 zap 。
后端兼容Zipkin
尽管我们更加推荐使用 Jaeger 客户端库以及 OpenTracing API 来注入应用，从而能够体验到完整的功能支持，但是，如果你的系统目前已经使用了 Zipkin，那么你也不需要写很多代码就可以轻松的切换到 Jaeger 的后端服务。
Jaeger 提供了一套 HTTP 接口可以接收 Zipkin格式（thrift，JSON v1/v2，Protobuf）的 span 数据，从而满足了 Zipkin 的兼容性。想要将 Zipkin 的后端切换到 Jaeger 仅仅需要修改后端访问地址即可。
拓扑图
Jaeger 提供了两种类型的服务拓扑图：系统架构图和深度依赖图。
系统架构图
系统架构图其实是指整个系统架构中所有观察的服务的依赖关系图。该图仅表示服务之间的直接依赖关系，有点儿类似于服务网格中获取到的遥测数据。
例如，对于一个 A-B-C 的图而言，意味着A和B之间有网络流量调用，B和C之前也有网络流量调用。
但是，它无法说明有一些调用链路是完整调用了A-B-C三个服务，也就是说，我们无法断言A服务一定依赖于C服务。
Ps: 上述描述的A, B, C指的都是服务，而不是服务端点（实例）。
系统架构图可以从内存存储中动态构建；也可以在使用分布式存储时，使用Spark或者Flink作业来构建。
深度依赖图（依赖传递图）
对于一个调用链路 A->B->C 而言，表明了服务A对于服务C其实是有着调用依赖的。
我们可以在单个图中，选中一个服务，从而计算并显示出所有调用中经过该服务的链路。通常，这种图并不能完整的表示整个系统的架构，除非某一个服务连接到了系统中所有的服务。例如，一个API网关服务往往可以显示出整个系统的调用链信息。
在深度依赖图中，节点的粒度可以在服务和服务端点（实例）之间更改。对于节点使用服务端点表示时，同一个服务的不同的端点可以显示为单独的节点，例如: A::op1 和 A::op2。
对于深度依赖图而言，目前只能通过 traces 的搜索结果来进行构造。未来，将会增加一个 Flink 作业来通过聚合所有的 trace 信息来计算对应的深度依赖图。
若有收获，就点个赞吧
0 人点赞
