我们与乌克兰的朋友和同事同在。如需支持乌克兰，请架构
另请参阅
Jaeger v2 旨在成为一个多功能、灵活的追踪平台。它可以部署为单个二进制文件，并可配置为在 Jaeger 架构中执行不同的角色。
角色
- collector：接收来自应用程序的追踪数据并将其写入存储后端。
- query：提供 API 和用户界面，用于查询和可视化追踪。
- ingester：从 Kafka 摄取 spans 并将其写入存储后端；在分流收集器-Kafka-摄取器配置下运行时非常有用。
- all-in-one：在单个进程中同时扮演 collector 和 query 角色。
- agent：一个主机代理或 sidecar，与应用程序一起运行，并将追踪数据转发到 collector。虽然 Jaeger 可以配置为扮演此角色，但我们建议改用标准的 OpenTelemetry Collector ，因为您可能还需要它来处理其他类型的遥测数据（指标和日志）。
选择 all-in-one 配置或 collector/query 配置取决于偏好。当使用外部存储后端时，两种配置都可水平扩展，但 collector/query 配置允许分离读写流量并独立扩展它们，同时应用不同的访问和安全策略。
带有内存存储的 all-in-one 配置最适合开发和测试，但不建议用于生产环境，因为数据在重启时会丢失。带有 Badger 后端的 all-in-one 可以用于生产，但仅适用于适中的数据量，因为它限于单个实例且无法水平扩展。
架构选择
可扩展 Jaeger 后端最常见的两种部署选项是直接存储和使用 Kafka 作为缓冲区。
直接存储
在此部署中，collector 从追踪的应用程序接收数据并直接写入存储。存储必须能够处理平均和峰值流量。collector 可以使用内存队列来平滑短期流量高峰，但如果存储无法跟上，持续的流量峰值可能会导致数据丢失。
通过 Kafka
为了防止 collector 和存储之间的数据丢失，Kafka 可以用作中间的持久队列。collector 配置有 Kafka 导出器。需要部署一个额外的组件 ingester 来从 Kafka 读取数据并将其保存到存储中。可以部署多个 ingester 来扩展摄取能力；它们会自动在它们之间划分负载。实际上，ingester 与 collector 非常相似，只是配置了 Kafka 接收器而不是基于 RPC 的接收器。
使用 OpenTelemetry Collector
您无需使用 OpenTelemetry Collector 来操作 Jaeger，因为 Jaeger 是 OpenTelemetry Collector 的一个定制发行版，具有不同的角色。然而，如果您已经使用 OpenTelemetry Collectors 来收集其他类型的遥测数据或用于预处理/丰富追踪数据，它可以放在收集管道中 Jaeger 的前面。OpenTelemetry Collectors 可以作为应用程序 sidecar、主机代理/守护程序或远程服务集群运行。
OpenTelemetry Collector 支持 Jaeger 的远程采样协议，可以直接从配置文件提供静态配置，或者将请求代理到 Jaeger 后端（例如，在使用自适应采样时）。
将 OpenTelemetry Collector 作为 sidecar / 主机代理
优点
- SDK 配置得到简化，因为追踪导出端点和采样配置端点都可以指向本地主机，无需担心远程服务运行的位置。
- Collector 可以通过添加环境信息（如 k8s pod 名称）来丰富数据。
- 数据丰富所需的资源使用可以分布到所有应用程序主机上。
缺点
- 额外的数据编组/解组层。
将 OpenTelemetry Collector 作为远程集群
优点
- 分片能力，例如在使用基于尾部的采样 时。
缺点
- 额外的数据编组/解组层。
Jaeger 二进制文件
Jaeger 二进制文件构建在 OpenTelemetry Collector 框架之上，并包括：
- 官方上游组件，如 OTLP 接收器、批处理和属性处理器等。
- 来自
opentelemetry-collector-contrib的上游组件，如 Kafka 导出器和接收器、尾部采样处理器等。 - Jaeger 自身的组件，如 Jaeger 存储导出器、Jaeger 查询扩展等。
Jaeger 组件
Jaeger 存储扩展 - Jaeger 支持的存储后端的扩展中心。它提供所有其他 Jaeger 组件对 Jaeger 存储实现的访问。
Jaeger 存储导出器 - 将 spans 写入 Jaeger 存储扩展中配置的存储后端。
Jaeger 查询扩展 - 运行查询 API 和 Jaeger UI。
OpenTelemetry 组件
接收器
OTLP - 接收通过 OpenTelemetry 协议 (OTLP) 发送的 spans。
Jaeger - 接收通过 gRPC 或 Thrift 协议传输的 Jaeger 格式追踪。
Kafka - 接收来自 Kafka 的各种格式（OTLP、Jaeger、Zipkin）的 spans。
Zipkin - 接收使用 Zipkin v1 和 v2 协议的 spans。
无操作（No-op） - 用于不需要摄取管道的 Jaeger UI / 查询服务部署。
处理器
批处理器 - 批处理 spans 以提高效率。
尾部采样 - 支持高级的后收集采样。
内存限制器 - 当收集器过载时支持反压。
属性处理器 - 允许通过属性过滤、重写和丰富 spans。可用于删除敏感数据、减少数据量或附加环境信息。
过滤器处理器 - 允许从收集器中删除 spans 和 span 事件 (⚠️ 可能会导致追踪中断)。
导出器
OTLP - 通过 gRPC 以 OTLP 格式发送数据。
OTLP HTTP - 通过 HTTP 以 OTLP 格式发送数据。
Kafka - 以各种格式（OTLP、Jaeger、Zipkin）将数据发送到 Kafka。
Prometheus - 将指标发送到 Prometheus。
调试（Debug） - 用于管道的调试工具。
无操作（No-op） - 用于不需要摄取管道的 Jaeger UI / 查询服务部署。
连接器
Span 指标 - 从 span 数据生成指标。
转发（Forward） - 在收集器中的管道之间重定向遥测数据（例如：span 到指标 / span 到日志）
扩展
健康检查 v2 - 支持健康检查。
zPages - 暴露收集器的内部状态以进行调试。
性能分析器 (pprof) - 启用 Go 的
net/http/pprof端点，通常由开发人员用于收集性能剖析并调查收集器的问题。
