高可伸缩性

Jaeger 后端设计上没有单点故障，并能随业务需求进行伸缩。例如，Uber 的 Jaeger 安装实例通常每天处理数十亿 spans。

云原生

Jaeger 后端以容器镜像或原生二进制形式分发，可用于多个平台。二进制的行为可通过 YAML 配置文件定制。部署到 Kubernetes 集群可借助 Kubernetes operator  和 Helm chart 。

OpenTelemetry

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

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

Jaeger 可以接收标准 OpenTelemetry Protocol (OTLP)  中的 trace 数据。然而，其内部数据表示和 UI 仍遵循 OpenTracing 规范的模型。

多种存储后端

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

• 它原生支持流行的开源 NoSQL 数据库作为 trace 存储后端：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 能够有效地处理大量数据并显示包含数万个 spans 的 traces（例如，我们尝试了一个包含 80,000 个 spans 的 trace）。

可观测性

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

拓扑图

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

系统架构图

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

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

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

深层依赖图

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

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

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

服务性能监控 (SPM)

SPM 允许通过计算来自 traces 的聚合指标并将其可视化为时间序列图表，来监控和调查服务性能趋势。它是识别和调查性能问题的强大工具，

更多详情，请参阅服务性能监控 (SPM)。

Zipkin 兼容性

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