我们与乌克兰的朋友和同事同在。如需在乌克兰需要时提供支持，请架构
另请参阅
术语
Jaeger 在数据模型中表示追踪数据，其灵感来自 OpenTracing 规范 。该数据模型在逻辑上与 OpenTelemetry Traces 非常相似，但存在一些命名差异
| Jaeger | OpenTelemetry | 说明 |
|---|---|---|
| 标签 | 属性 | 两者都支持类型化值，但 Jaeger 不支持嵌套标签。 |
| Span 日志 | Span 事件 | Span 上以结构化形式记录的时间点事件。 |
| Span 引用 | Span 链接 | Jaeger 的 Span 引用具有必需的类型（`child-of` 或 `follows-from`），并且始终指向前驱 Span；OpenTelemetry 的 Span 链接没有类型，但允许属性。 |
| 进程 | 资源 | 描述生成遥测数据的实体的结构。 |
Span
一个 Span 代表一个逻辑工作单元，它具有操作名称、操作开始时间和持续时间。Span 可以嵌套和排序以建模因果关系。
追踪
一个 Trace 代表系统中的数据或执行路径。它可以被视为 Span 的有向无环图。
Baggage
Baggage 是任意用户定义的元数据（键值对），可以附加到分布式上下文并通过追踪 SDK 进行传播。更多信息请参见 W3C Baggage 。
架构
Jaeger 可以部署为一体化二进制文件，其中所有 Jaeger 后端组件都在单个进程中运行，也可以部署为可伸缩的分布式系统。下面讨论了两种主要的部署选项。
直接存储
在此部署中，收集器接收来自被追踪应用程序的数据并将其直接写入存储。存储必须能够处理平均流量和峰值流量。收集器使用内存队列来平滑短期流量峰值，但如果存储无法跟上，持续的流量峰值可能会导致数据丢失。
收集器能够集中向 SDK 提供采样配置，这被称为 远程采样模式。它们还可以启用自动采样配置计算，这被称为 自适应采样。
通过 Kafka
为了防止收集器和存储之间的数据丢失，Kafka 可以用作中间的持久队列。需要部署一个额外的组件 jaeger-ingester 来从 Kafka 读取数据并保存到数据库。可以部署多个 jaeger-ingester 来扩展摄取能力；它们将自动在它们之间分区负载。
使用 OpenTelemetry Collector
您无需使用 OpenTelemetry Collector，因为 jaeger-collector 可以直接从 OpenTelemetry SDK（使用 OTLP 导出器）接收 OpenTelemetry 数据。但是，如果您已经在使用 OpenTelemetry Collector，例如用于收集其他类型的遥测数据或用于预处理/丰富追踪数据，它可以放置在 SDK 和 jaeger-collector 之间。OpenTelemetry Collector 可以作为应用程序 Sidecar、主机代理/守护进程或中央集群运行。
OpenTelemetry Collector 支持 Jaeger 的远程采样协议，可以直接从配置文件提供静态配置，或者将请求代理到 Jaeger 后端（例如，在使用自适应采样时）。
将 OpenTelemetry Collector 作为 sidecar / 主机代理
优点
- SDK 配置得以简化，因为追踪导出端点和采样配置端点都可以指向本地主机，而无需担心这些服务在远程何处运行。
- 收集器可以通过添加环境信息（例如 k8s pod 名称）来提供数据丰富。
- 数据丰富所需的资源使用可以分布到所有应用程序主机上。
缺点
- 额外的数据编组/解组层。
将 OpenTelemetry Collector 作为远程集群
优点
- 分片能力，例如在使用 基于尾部的采样 时。
缺点
- 额外的数据编组/解组层。
组件
本节详细介绍了 Jaeger 的组成部分以及它们之间的关系。其内容按照应用程序中的 Span 与它们交互的顺序进行组织。
追踪 SDK
为了生成追踪数据，应用程序必须使用追踪 SDK 进行插桩，例如 OpenTelemetry SDK 。一个经过插桩的应用程序在接收新请求时创建 Span，并将上下文信息（trace ID、span ID 和 baggage）附加到传出请求。只有 ID 和 baggage 会随请求传播；所有其他剖析数据，如操作名称、时间、标签和日志，都不会传播。相反，它们会在后台异步地进程外导出到 Jaeger 后端。
有多种对应用程序进行插桩的方式
- 手动方式，直接使用追踪 API，
- 依赖已为各种现有开源框架创建的插桩，
- 自动方式，通过字节码操作、猴子补丁（monkey-patching）、eBPF 和类似技术。
插桩通常不应依赖特定的追踪 SDK，而应仅依赖像 OpenTelemetry API 这样的抽象追踪 API。追踪 SDK 实现追踪 API 并负责数据导出。
该插桩设计为在生产环境中始终开启。为了最大程度地减少开销，SDK 采用了各种采样策略。当一个 Trace 被采样时，剖析 Span 数据会被捕获并传输到 Jaeger 后端。当一个 Trace 未被采样时，则根本不收集任何剖析数据，对追踪 API 的调用也会短路，以产生最小的开销。更多信息请参考采样页面。
收集器
jaeger-collector 接收 Trace，将其通过处理管道进行验证和清理/丰富，并将其存储在存储后端。Jaeger 内置支持多种存储后端（参见部署），以及用于实现自定义存储插件的可扩展插件框架。
查询
jaeger-query 是一项服务，它公开API 用于从存储中检索 Trace，并托管一个用于搜索和分析 Trace 的 Web UI。
摄取器
jaeger-ingester 是一项服务，它从 Kafka 读取 Trace 并将其写入存储后端。实际上，它是 Jaeger 收集器的精简版本，仅支持 Kafka 作为输入协议。
