高可伸缩性

Jaeger 后端设计为无单点故障，并能随业务需求扩展。例如，Uber 的任何 Jaeger 安装通常每天处理数十亿个 span。

原生支持 OpenTracing 和 OpenTelemetry

Jaeger 后端、Web UI 和 instrumentation 库从头开始设计，以支持 OpenTracing 标准。

• 通过 span 引用  将 traces 表示为有向无环图（不仅仅是树状图）
• 支持强类型 span *标签* 和 *结构化日志*

自 v1.35 起，Jaeger 后端可以从 OpenTelemetry SDKs 接收其原生 OpenTelemetry 协议 (OTLP)  的跟踪数据。然而，内部数据表示和用户界面仍遵循 OpenTracing 规范的模型。

多种存储后端

Jaeger 可以与越来越多的存储后端一起使用

• 它原生支持流行的开源 NoSQL 数据库作为跟踪存储后端：Cassandra 3.4+、Elasticsearch 7.x/8.x 和 OpenSearch 1.0+。
• 它通过 gRPC API 与其他已认证兼容 Jaeger 的知名数据库集成：ClickHouse 。
• 它支持使用 Badger  的嵌入式数据库和用于测试设置的简单内存存储。
• 目前正在进行社区实验，使用其他数据库；你可以在此议题 中找到更多信息。

现代 Web UI

Jaeger Web UI 使用 React 等流行开源框架通过 Javascript 实现。v1.0 版本中发布了几项性能改进，使 UI 能够高效处理大量数据并显示包含数万个 span 的跟踪（例如，我们尝试了一个包含 80,000 个 span 的跟踪）。

云原生部署

Jaeger 后端作为 Docker 镜像集发布。二进制文件支持多种配置方法，包括命令行选项、环境变量和多种格式（yaml、toml 等）的配置文件。部署到 Kubernetes 集群可借助 Kubernetes Operator  和 Helm chart 。

可观测性

所有 Jaeger 后端组件默认都暴露 Prometheus  指标。日志使用结构化日志库 zap  写入标准输出。

向后兼容 Zipkin

尽管我们建议使用 OpenTelemetry 对应用程序进行插桩，但如果您的组织已经投入使用 Zipkin 库进行插桩，则无需重写所有代码。Jaeger 通过 HTTP 接受 Zipkin 格式（Thrift、JSON v1/v2 和 Protobuf）的 span 来提供与 Zipkin 的向后兼容性。从 Zipkin 后端切换只需将来自 Zipkin 库的流量路由到 Jaeger 后端即可。

拓扑图

Jaeger UI 支持两种类型的服务图：**系统架构图** 和 **深度依赖图**。

系统架构图

这是架构中所有观察到的服务的“经典”服务依赖图。该图仅表示服务之间的一跳依赖关系，类似于从服务网格生成的遥测数据中获得的信息。例如，图 A - B - C 意味着存在一些包含 A 和 B 之间网络调用的跟踪，以及一些包含 B 和 C 之间调用的跟踪。然而，这不代表存在任何包含完整链 A - B - C 的跟踪，即我们不能说 A 依赖于 C。

此图的节点粒度仅为服务，而非服务端点。

系统架构图可以从内存存储即时构建，或者在使用分布式存储时通过 Spark 或 Flink 任务构建。

深度依赖图

也称为“传递依赖图”，其中链 A -> B -> C 意味着 A 对 C 存在传递依赖。单个图需要一个“焦点”服务（以粉色显示），并且只显示通过该服务的路径。通常，这种类型的图不代表系统的完整架构，除非存在一个连接到所有事物的服务（例如 API 网关）并被选作焦点服务。

此图的节点粒度可以在服务和服务端点之间切换。在后一种模式下，同一服务中的不同端点将显示为单独的节点，例如 A::op1 和 A::op2。

目前，传递图只能从搜索结果中的跟踪构建。未来将有一个 Flink 任务通过聚合所有跟踪来计算这些图。

服务性能监控 (SPM)

以 RED（请求数、错误数、持续时间）指标的形式可视化聚合的 span 数据，以突出显示具有统计显著的请求/错误率或延迟的服务和/或操作，然后利用 Jaeger 的跟踪搜索功能精确定位属于这些服务/操作的特定跟踪。

有关更多详细信息，请参阅服务性能监控 (SPM)。