高可伸缩性

Jaeger 后端旨在实现无单点故障，并能够随着业务需求进行扩展。例如，Uber 的 Jaeger 安装通常每天处理数十亿个 Span。

云原生

Jaeger 后端以容器镜像或原始二进制文件的形式分发，支持多种平台。可以通过 YAML 配置文件自定义二进制文件的行为。Kubernetes 集群的部署由Kubernetes operator  和 Helm chart  提供辅助。

OpenTelemetry

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

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

Jaeger 可以接收标准OpenTelemetry 协议 (OTLP) 的追踪数据。然而，内部数据表示和用户界面仍然遵循 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 后端。