高可扩展性

Jaeger 后端旨在没有单点故障，并随着业务需求进行扩展。例如，Uber 的任何给定 Jaeger 安装通常每天处理数十亿个跨度。

对 OpenTracing 和 OpenTelemetry 的原生支持

Jaeger 后端、Web UI 和检测库从一开始就被设计为支持 OpenTracing 标准。

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

从 v1.35 开始，Jaeger 后端可以从 OpenTelemetry SDK 中以其本机 OpenTelemetry 协议 (OTLP)  接收跟踪数据。但是，内部数据表示和 UI 仍然遵循 OpenTracing 规范的模型。

多个存储后端

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

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

现代 Web UI

Jaeger Web UI 是使用 Javascript 使用流行的开源框架（如 React）实现的。在 v1.0 中发布了几个性能改进，以使 UI 能够有效地处理大量数据并显示具有数万个跨度（例如，我们尝试了具有 80,000 个跨度的跟踪）的跟踪。

云原生部署

Jaeger 后端以 Docker 镜像集合的形式分发。二进制文件支持各种配置方法，包括命令行选项、环境变量和多种格式（yaml、toml 等）的配置文件。Kubernetes 运算符  和 Helm 图表  为部署到 Kubernetes 集群提供帮助。

可观察性

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

与 Zipkin 的向后兼容性

虽然我们建议使用 OpenTelemetry 对应用程序进行 instrumentation，但如果您的组织已经使用 Zipkin 库进行了 instrumentation，则无需重写所有代码。Jaeger 通过 HTTP 接受 Zipkin 格式（Thrift、JSON v1/v2 和 Protobuf）的跨度，从而与 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（请求、错误、持续时间）指标的形式可视化聚合的跨度数据，以突出显示具有统计显着请求/错误率或延迟的服务和/或操作，然后利用 Jaeger 的跟踪搜索功能来查明属于这些服务/操作的特定跟踪。

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