企业官网建设流程全解析

Jaeger 分布式链路追踪：一条 Docker 命令拉起全栈，16686 端口查出每条请求的慢在哪

【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger

微服务调到第四五个，问题就变了味道：用户说"下单偶尔卡住"，你打开 A 服务日志看到请求转发出去了，B 服务日志里对应的记录隔了 800 毫秒才出现，C 服务说它根本没收到慢请求。每个服务都"没问题"，但整条链路就是慢——这就是分布式系统里最折磨人的排查方式，靠 grep 日志拼时间戳。Jaeger（CNCF 毕业的分布式追踪平台，Uber 开源后捐赠给云原生基金会）解决的就是这件事：给每个请求发一个 trace id，所有服务把处理片段（span）上报到它，你在 UI 上就能看到这一次请求在每个服务里各花了多久、错在哪一跳。

没有它时的排查，和有它之后

跨服务追慢请求：以前是三个服务的日志窗口来回切，拿 trace id 手动对齐时间戳，一次排查二十分钟起步；接入 Jaeger 后，在http://localhost:16686按 trace id 或耗时筛一下，一条 trace 的水流图里每个 span 的耗时、状态码全摊开，慢在哪一跳一眼可见。

协议和上报格式的兼容：v2 的 all-in-one 配置（cmd/jaeger/internal/all-in-one.yaml）里同时挂了 OTLP（gRPC 4317 / HTTP 4318）、Jaeger 旧协议（thrift 14268）和 Zipkin（9411）三组接收器。实测下来最省心的一点是：老 SDK 走 14268 的遗留流量、新 SDK 走 OTLP 的流量、甚至 Zipkin 客户端的流量，落进同一个存储，UI 里长得一模一样，不用为每种客户端维护一套查询。

采样成本：全量上报的 span 量级在流量大时扛不住。仓库里docker-compose/tail-sampling/给了一套现成样板：collector 挂tail_sampling处理器，配一条string_attribute策略只保留指定服务的 trace（示例只留tracegen-02和tracegen-04），decision_wait设 5 秒等整条 trace 到齐再做取舍。踩坑提醒：多实例部署时同一 trace 的 span 必须路由到同一实例才能正确决策，所以他们额外起了个带 loadbalancing exporter 的 OTel Collector 转发层，docker-compose/tail-sampling/otel-collector-config-connector.yml里就是干这个的。

能力全景：按你要干的事分

跑起来、存得住

• all-in-one 单容器自带 collector + query + UI + 内存存储，内存后端上限max_traces: 100000，够调试不够生产
• 生产存储四选一，配置文件都是现成的：cmd/jaeger/config-elasticsearch.yaml、config-clickhouse.yaml、config-cassandra.yaml、config-badger.yaml
• 存储版本支持策略写得明明白白（README 里有张表）：ES 支持9.x和维护期内的8.19.x，OpenSearch3.x/2.x，Cassandra5.0.x+ 维护中的4.x，ClickHouse 覆盖当前与前一个 LTS

查得动、看得懂

• UI 提供 Search / Compare / System Architecture / Monitor 四个标签页，支持按 service、operation、tag 过滤，还能勾选多条 trace 对比
• Monitor 标签页把 span 数据聚合成 RED 指标（请求率、错误率、P95 等分位延迟），按服务+操作分组
• 指标后端二选一：Prometheus，或者直接查 ES/OpenSearch 里的 trace 数据省掉一个存储，对应cmd/jaeger/config-spm-prometheus.yaml与config-spm-elasticsearch.yaml一族配置

控得住成本

• 远程采样策略下发：all-in-one 里remote_sampling扩展监听 5778（HTTP）/5779（gRPC），策略文件每秒热加载
• 尾采样：上面提到的 tail-sampling 方案
• 自适应采样：components/processor/adaptivesampling/提供基于目标请求率的动态调节

一条完整走线：从 clone 到看到 trace

git clone https://gitcode.com/GitHub_Trending/ja/jaeger之后，想最快看到东西其实不用碰源码。一条命令拉起 all-in-one：

docker run --rm --name jaeger -p 16686:16686 -p 4317:4317 -p 4318:4318 jaegertracing/jaeger:latest

然后让东西产生 trace。仓库自带tracegen这个压测小工具（cmd/tracegen/），跑docker run jaegertracing/jaeger-tracegen -service abcd -traces 10就能打出几十条带父子关系的 span。大概率会卡的地方在这里：tracegen 默认往localhost发数据，而你在容器里跑它时localhost是容器自己，得把 OTLP 地址指到宿主机或正确的网络别名上，-trace-exporter otlp-http加环境变量OTEL_EXPORTER_OTLP_TRACES_ENDPOINT就能解决。想要更真实的场景，用examples/hotrod/下的 docker-compose 把 HotROD 演示应用和 Jaeger 一起拉起来，浏览器开http://localhost:8080点几下，16686 的 UI 里就有带完整调用链的数据了。

老用户才知道的几个细节

• 端口别记混：ports/ports.go里全有常量化——UI 和查询 API 在 16686，gRPC 查询在 16685，还有 16687 是 MCP server 端点（对接 AI 客户端查 trace 用的，比较新）。排障时先看这个文件，比翻文档快。
• Monitor 标签页不是默认就有的：它依赖 metrics 后端，启动时 Jaeger 会向 UI 声明自己有哪些存储能力，没配 metrics 后端时 Monitor 标签直接不出现，/api/metrics/*接口返回 501 并写明原因。看到"少了个标签"先查jaeger_query.storage下有没有 metrics 键。
• 配置废弃有硬承诺：README 里写了 deprecation 规则——废弃选项至少保留 3 个月或两个小版本（取较晚者），所以升级时对着 release notes 里的废弃声明做迁移计划就行，不会被下个版本突然抽掉。

社区与生态

Uber 发起、CNCF 毕业项目（2019 年 10 月），维护者名单在MAINTAINERS.md，治理规则在GOVERNANCE.md。参与入口是项目的 issue 和 PR，贡献指南见CONTRIBUTING.md；发布节奏跟随 Go 版本支持策略（Go 新版发布后跟进，移除 N-1 支持）。ADOPTERS.md里列了 Uber、Ticketmaster、Grafana Labs 等生产用户，其中 Ticketmaster 公开过每天 1 亿笔交易走 Jaeger 的案例。

想动手的话，最直接的一步是跑通 all-in-one 再打开http://localhost:16686；生产部署细节（各存储后端、K8s、安全）仓库里cmd/jaeger/下的 config 文件和CONTRIBUTING.md指向的文档是最快的入口。

核心关键词：Jaeger、分布式链路追踪、分布式追踪平台、OpenTelemetry、CNCF、链路追踪 UI、trace 存储、尾采样

长尾关键词：分布式追踪系统怎么选、Jaeger 快速部署、链路追踪采样策略、微服务慢请求排查、span 数据聚合 RED 指标、Jaeger 存储后端支持版本、tail sampling 配置

【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger