高可伸缩性

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

原生支持 OpenTracing 和 OpenTelemetry

Jaeger 后端、Web UI 和插桩库从头开始设计，旨在支持 OpenTracing 标准。

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

自 v1.35 版本以来，Jaeger 后端可以接收来自 OpenTelemetry SDK 的原生 OpenTelemetry 协议 (OTLP) 。然而，内部数据表示和 UI 仍然遵循 OpenTracing 规范的模型。

支持多种存储后端

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

• 它原生支持流行的开源 NoSQL 数据库作为 Trace 存储后端：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 的 Trace（例如，我们尝试了一个包含 80,000 个 Span 的 Trace）。

云原生部署

Jaeger 后端被分发为一组 Docker 镜像。二进制文件支持各种配置方法，包括命令行选项、环境变量和多种格式（yaml、toml 等）的配置文件。部署到 Kubernetes 集群可通过Kubernetes operator 和Helm chart 辅助完成。

可观测性

所有 Jaeger 后端组件默认公开 Prometheus  指标。日志使用结构化日志库 zap  写入 stdout。

向后兼容 Zipkin

尽管我们推荐使用 OpenTelemetry 进行应用插桩，如果您的组织已经投入使用 Zipkin 库进行插桩，您不必重写所有这些代码。Jaeger 通过 HTTP 接受 Zipkin 格式（Thrift, JSON v1/v2 和 Protobuf）的 Span，从而提供与 Zipkin 的向后兼容性。从 Zipkin 后端切换只需将来自 Zipkin 库的流量路由到 Jaeger 后端即可。

拓扑图

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

系统架构

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

此图的节点粒度仅限于服务，而非服务终端点。

系统架构图可以从内存存储动态构建，或者在使用分布式存储时通过 Spark 或 Flink 作业构建。

深度依赖图

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

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

目前，传递依赖图只能从搜索结果中的 Trace 构建。将来会有一个 Flink 作业，通过聚合所有 Trace 来计算这些图。

服务性能监控 (SPM)

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

请参阅 服务性能监控 (SPM) 了解更多详细信息。