高可扩展性
Jaeger 后端的设计目标是无单点故障，并能随业务需求进行扩展。例如，Uber 的 Jaeger 部署通常每天处理数十亿个 span。
云原生
Jaeger 后端以容器镜像或原始二进制文件的形式分发，支持多种平台。二进制文件的行为可以通过 YAML 配置文件进行自定义。部署到 Kubernetes 集群时，可借助 Kubernetes operator 和 Helm chart 进行辅助。
OpenTelemetry
Jaeger 后端和 Web UI 从一开始就被设计为支持 OpenTracing 标准。
- 通过 span 引用将追踪表示为有向无环图（不仅仅是树）
- 支持强类型 span 标签 和 结构化日志
Jaeger 可以接收标准 OpenTelemetry 协议（OTLP）格式的追踪数据。然而，内部数据表示和 UI 仍然遵循 OpenTracing 规范的模型。
多种存储后端
Jaeger 支持越来越多的存储后端：
- 原生支持流行的开源 NoSQL 数据库作为追踪存储后端：Cassandra 4.0+、Elasticsearch 7.x/8.x 和 OpenSearch 1.0+。
- 可通过远程存储 API 扩展其他经过认证的 Jaeger 兼容数据库：ClickHouse。
- 使用 Badger 提供嵌入式数据库支持，以及用于测试环境的简单内存存储。
- 社区正在使用其他数据库进行持续实验；更多信息请参阅此 issue。
采样
为了控制应用程序的开销和存储成本，Jaeger 支持多种采样形式：基于头部的集中远程配置采样（静态或自适应）以及基于尾部的采样。更多信息请参阅采样页面。
现代化 Web UI
Jaeger Web UI 使用 Javascript 以 React 应用的形式实现。v1.0 版本发布了多项性能改进，使 UI 能够高效处理大量数据，并显示包含数万个 span 的追踪（例如，我们尝试过包含 80,000 个 span 的追踪）。
可观测性
所有 Jaeger 后端组件默认暴露 Prometheus 指标。
日志使用结构化日志库 zap 写入标准输出。
拓扑图
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）
SPM 允许通过从追踪数据中计算聚合指标并将其可视化为时间序列图表，来监控和调查服务的性能趋势。它是识别和调查性能问题的强大工具。
更多详情请参阅服务性能监控（SPM）。
Zipkin 兼容性
虽然我们推荐使用 OpenTelemetry 对应用进行插桩，但如果您的组织已经使用 Zipkin 库进行了插桩投入，则无需重写所有代码。Jaeger 通过 HTTP 接受 Zipkin 格式（Thrift、JSON v1/v2 和 Protobuf）的 span，从而提供与 Zipkin 的向后兼容性。从 Zipkin 后端切换只需将 Zipkin 库的流量路由到 Jaeger 后端即可。