深入理解 Jaeger 分布式追踪平台从快速启动到版本与存储兼容性策略【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger导读本文以 CNCF Jaeger 官方仓库的 README.md 为主线系统讲解这个由 Uber 创建、捐赠给云原生计算基金会CNCF并已毕业成为顶级项目的分布式追踪平台如何用 Docker 在数秒内拉起完整可用的 all-in-one 环境、其 Collector/Query/UI/存储四层架构如何协同工作以及项目在配置弃用、Go 版本与各存储后端Elasticsearch、OpenSearch、Cassandra、ClickHouse上提供的严格兼容性保证。读完本文你将掌握 Jaeger v2 的快速上手方式、默认配置与端口约定并能依据官方支持策略为自己的生产环境选择受支持的存储版本。Jaeger 是什么源自 Uber 的分布式追踪平台Jaeger 是一个开源的端到端分布式追踪系统最初由 Uber Technologies 在内部开发并开源随后捐赠给云原生计算基金会CNCF。2017 年 9 月 CNCF 宣布托管 Jaeger2019 年 10 月 Jaeger 正式毕业成为 CNCF 第 7 个顶级项目。这也意味着它的治理是开放的——任何人都可以参与贡献许多贡献方式甚至不需要写代码。从仓库根目录的 README.md 可以看到Jaeger 的生态不止一个仓库UI仓库中以子模块形式存在对应独立的 jaeger-ui 项目负责 Web 查询界面Data model对应 jaeger-idl 项目定义 trace/span 的数据模型与 IDL 定义官方文档站点与文档源码分别维护在独立的 documentation 仓库中。快速启动秒级拉起完整的追踪系统Jaeger v2 已经发布。在 v2 中整个后端被重写为基于 OpenTelemetry Collector 架构构建一个 all-in-one 二进制即包含了 UI、collector、query 与内置存储官方推荐的秒级体验方式是 Docker# 运行 Jaeger all-in-one包含 UI、collector、query 和内存存储 docker run --rm --name jaeger \ -p 16686:16686 \ -p 4317:4317 \ -p 4318:4318 \ jaegertracing/jaeger:latest # 访问 UIhttp://localhost:16686 # 通过 OTLP 发送 tracegRPC 使用端口 4317HTTP 使用端口 4318其中-p 16686:16686用于浏览器访问 Jaeger UI-p 4317:4317与-p 4318:4318分别对应 OTLP gRPC 与 OTLP HTTP 两个接收端口——这也是 OpenTelemetry SDK 最常用的接入方式。all-in-one 模式背后的实现无配置文件也能跑为什么直接docker run不传任何配置就能工作从源码看这正是 v2 刻意设计的能力。入口 cmd/jaeger/main.go 调用jaegercli.Components()构建全部组件工厂后执行jaegercli.NewCommand(factories)而 cmd/jaeger/internal/command.go 中的checkConfigAndRun会检测命令行中是否存在--config参数若没有就用//go:embed嵌入的默认 all-in-one 配置cmd/jaeger/internal/all-in-one.yaml启动并在日志中提示No --config flags detected, using default All-in-One configuration with memory storage.这份默认配置包含otlp/jaeger/zipkin三个 receiver、batchprocessor、jaeger_storage_exporterexporter以及jaeger_storage、jaeger_query、remote_sampling、healthcheckv2、expvar、zpages等扩展存储后端为内存中的some_storagemax_traces: 100000。Docker 镜像暴露的端口清单cmd/jaeger/Dockerfile 完整列出了镜像对外暴露的端口可据此理解各协议入口端口用途5778远程采样配置 HTTP5779远程采样配置 gRPC4317Collector OTLP gRPC4318Collector OTLP HTTP14268Collector Thrift HTTP14250Collector gRPC9411Collector Zipkin16686Web UI / Query API13132Health Check gRPC13133Health Check HTTP12345仅 debug 镜像Delve 调试器这些默认端口与仓库中的 ports/ports.go 定义保持一致如QueryHTTP 16686、CollectorV2SamplingHTTP 5778、CollectorV2SamplingGRPC 5779、CollectorV2HealthChecks 13133等。架构剖析四层组件的协作流程README 用一张 mermaid 图直观地描述了 v2 的整体架构核心流转如下数据流转分四步埋点采集用户应用内嵌的 OpenTelemetry SDK 通过 HTTP 或 gRPC 将 span 上报给 Jaeger CollectorCollector 处理Collector 完成接收、批处理、采样含远程/自适应采样策略下发通过 gRPC/sampling 反向告知 SDK后将数据写入存储Query 查询Jaeger Query Service 直接读取存储或经由 gRPC 调用存储插件Storage Plugin访问外部存储UI 呈现Jaeger UI 通过 HTTP 调用 Query 的 API如/api/*端点完成检索与可视化。在 v2 中这一架构被落地为 OpenTelemetry Collector 的标准 pipeline。参考 cmd/jaeger/internal/all-in-one.yaml 与完整的 cmd/jaeger/config.yamlservice: extensions: [jaeger_storage, jaeger_query, remote_sampling, healthcheckv2, pprof] pipelines: traces: receivers: [otlp, jaeger, zipkin] processors: [batch, adaptive_sampling] exporters: [jaeger_storage_exporter]组件工厂的注册位于 cmd/jaeger/internal/components.go默认提供otlp、jaeger、zipkin、kafka等 receiverbatch、memorylimiter、tailsampling、attributes、filter、adaptive_sampling等 processor以及debugexporter、otlpexporter、kafkaexporter、prometheusexporter、storageexporter通用写 Jaeger v1 spanstore 的 exporter等 exporter。jaeger_storage为 Query 提供共享存储容器值得单独说明的是jaeger_storage扩展。普通的 OTLP pipeline 中receiver→processor→exporter 各自直接绑定存储后端并不需要额外容器但jaeger-query服务本身不在 pipeline 内它需要访问与其他组件共享的存储后端实现因此该扩展充当了共享存储容器。这一点在 cmd/jaeger/internal/extension/jaegerstorage/README.md 中有明确说明其配置通过 config.go 复用storageconfig.Config并实现confmap.Validator接口做统一校验。在默认配置中它被组织为命名后端backend的形式例如 cmd/jaeger/config.yaml 演示了同时配置some_store与another_store两个内存后端extensions: jaeger_storage: backends: some_store: memory: max_traces: 100000 another_store: memory: max_traces: 100000jaeger_query扩展通过storage.traces/storage.traces_archive字段引用这些命名后端jaeger_storage_exporter则通过trace_storage指定写入目标从而实现在同一进程内 Query、Collector 与存储的灵活解耦。配置兼容性保证弃用政策的硬性约束由于 Jaeger 大量复用 OpenTelemetry Collector 的组件其配置体系继承了 Collector 的 YAML 形态同时还要兼容历史上 Jaeger v1 的 CLI 标志。项目承诺尽力维持各 release 之间的配置兼容性但某些配置项仍可能因可用性改进、新功能或依赖变化而被弃用。为此README 规定了一个清晰的弃用流程CONTRIBUTING.md 中有对应开发者指引被弃用的配置项必须在文档或 release notes 中看到如下标记(deprecated, will be removed after yyyy-mm-dd or in release vX.Y.Z, whichever is later)从包含弃用通知的首个 release 起至少提供3 个月或两次 minor 版本升级以两者中较晚者为准的宽限期之后才可以删除该配置项。举例来说假设 v2.0.0 于 2024-09-01 发布并包含某配置项的弃用通知那么该配置项将保持弃用状态直到 2024-12-01 或 v2.2.0取较晚者之后才允许移除它也可能在弃用状态停留更久。Go 版本兼容性保证Jaeger 会跟踪 Go 官方定义的受支持版本列表。自 Go 1.21 起版本支持的更新策略为新的 Go minor 版本N发布后不久构建与测试步骤随即更新以适配该版本随后移除对 Go 版本N-1的支持N成为最低要求版本。值得注意的是由于所有可被外部 import 的代码都已移入 internal 包Jaeger 无需为了向后兼容旧编译器此前为N-1而保留负担——移除对不受支持 Go 版本的支持不被视为破坏性变更。存储后端版本支持政策生产选型的依据README 明确区分了受政策覆盖的版本与技术上可能仍然兼容的版本并规定只有处于政策覆盖范围内的后端版本Jaeger 才承诺主动进行兼容性修复CI 覆盖并非支持矩阵的定义性依据——CI 可能只测试受支持版本的子集也可能以尽力而为的方式保留旧版本但旧版本出现在 CI 中不代表它受支持。同时Jaeger 不负责后端产品本身、厂商私有发行版或上游维护窗口之外的版本。各后端的具体政策Elasticsearch遵循 Elastic 官方产品与版本 EOL 政策OpenSearch遵循 OpenSearch 官方发布排期与维护政策实践中即当前 major 版本 上一个仍受维护的 major 版本Cassandra遵循 Apache Cassandra 官方维护的 release line支持目标为当前 major 版本 上一个 major 版本ClickHouse遵循官方稳定版与 LTS 生产指导以 LTS 作为支持线覆盖当前与上一个 LTS两者由 ClickHouse 同时维护至少 12 个月每月发布的 stable 版本可能保持兼容或出现在 CI 中但不在政策覆盖范围内。以 2026-07-06 为时间点README 给出的具体覆盖范围如下后端政策依据政策覆盖的版本不覆盖的版本ElasticsearchElastic EOL 政策9.x8.19.x直至 Elastic 公布的 8.x 维护窗口结束8.18.x及更早OpenSearchOpenSearch 维护政策3.x2.x当前维护线为2.19.x1.x及更早Cassandra当前 major 上一个 major基于 Apache 维护的 release line5.0.x受维护的4.x线当前为4.1.x与4.0.x3.x及更早ClickHouse当前与上一个 ClickHouse LTS26.3 LTS与25.8 LTS每月 stable 版本与更早的 LTS 分支该表是信息性的会随上游政策或 release line 变化而更新。对于没有明确上游生命周期的后端Jaeger 支持当前 stable major 版本 紧邻的前一个 major 版本更早版本仅做尽力而为支持并可能在其阻碍开发、安全修复、依赖升级或 CI 可靠性时被移除。从源码构建与参与贡献本地构建与运行仓库的 CONTRIBUTING.md 给出了从源码构建的完整流程。前提是安装 Go 并配置好GOPATH/PATH若在 macOS 上运行make test等目标还需 GNUsedbrew install gnu-sed。克隆仓库后依次执行# 拉取 jaeger-ui 子模块 git submodule update --init --recursive # 安装所需工具 make install-tools # 运行全部单元测试 make test提交流程要求使用非main的命名分支、所有 commit 必须签名通过 DCO 检查提交前依次执行make fmt、make lint、make test。格式化工具统一使用gofumpt由make install-tools随 golangci-lint 自动安装可在 VSCode 中配置保存时自动格式化go.formatTool: gofumpt, gopls: { formatting.gofumpt: true, }带 UI 的本地运行方式go run ./cmd/jaeger --config ./cmd/jaeger/config.yaml这条命令会以 cmd/jaeger/config.yaml 为配置启动 v2 后端若省略--config则如上文所述自动回退到内嵌的 all-in-one 默认配置内存存储。社区与治理维护者机制成为维护者的规则定义在 GOVERNANCE.md官方维护者名单见 MAINTAINERS.md可通过jaegertracing/jaeger-maintainers在 issue/PR 中 他们路线图发布于官方文档站点联系渠道#jaegerSlack 频道首次需加入 CNCF Slack、jaeger-tracing邮件组、GitHub issues 与 discussions安全第三方安全审计报告独立维护安全机制摘要见官方 issue 讨论采纳者各行业使用 Jaeger 的组织清单见 ADOPTERS.md如需加入可评论对应调查 issue。许可证Jaeger 采用 Apache 2.0 许可版权归 The Jaeger Authors 所有详见 LICENSE。项目的发展离不开 CNCF 的长期支持也感谢 Uber 的初始捐赠以及 1Password、Codecov.io、GitHub 等在软件与基础设施层面的持续贡献。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考