Jaeger 分布式链路追踪一条 Docker 命令拉起全栈16686 端口查出每条请求的慢在哪【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger微服务调到第四五个问题就变了味道用户说下单偶尔卡住你打开 A 服务日志看到请求转发出去了B 服务日志里对应的记录隔了 800 毫秒才出现C 服务说它根本没收到慢请求。每个服务都没问题但整条链路就是慢——这就是分布式系统里最折磨人的排查方式靠 grep 日志拼时间戳。JaegerCNCF 毕业的分布式追踪平台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里同时挂了 OTLPgRPC 4317 / HTTP 4318、Jaeger 旧协议thrift 14268和 Zipkin9411三组接收器。实测下来最省心的一点是老 SDK 走 14268 的遗留流量、新 SDK 走 OTLP 的流量、甚至 Zipkin 客户端的流量落进同一个存储UI 里长得一模一样不用为每种客户端维护一套查询。采样成本全量上报的 span 量级在流量大时扛不住。仓库里docker-compose/tail-sampling/给了一套现成样板collector 挂tail_sampling处理器配一条string_attribute策略只保留指定服务的 trace示例只留tracegen-02和tracegen-04decision_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.xOpenSearch3.x/2.xCassandra5.0.x 维护中的4.xClickHouse 覆盖当前与前一个 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扩展监听 5778HTTP/5779gRPC策略文件每秒热加载尾采样上面提到的 tail-sampling 方案自适应采样components/processor/adaptivesampling/提供基于目标请求率的动态调节一条完整走线从 clone 到看到 tracegit clone https://gitcode.com/GitHub_Trending/ja/jaeger之后想最快看到东西其实不用碰源码。一条命令拉起 all-in-onedocker 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 在 16686gRPC 查询在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jaeger 分布式链路追踪一条 Docker 命令拉起全栈16686 端口查出每条请求的慢在哪【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger微服务调到第四五个问题就变了味道用户说下单偶尔卡住你打开 A 服务日志看到请求转发出去了B 服务日志里对应的记录隔了 800 毫秒才出现C 服务说它根本没收到慢请求。每个服务都没问题但整条链路就是慢——这就是分布式系统里最折磨人的排查方式靠 grep 日志拼时间戳。JaegerCNCF 毕业的分布式追踪平台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里同时挂了 OTLPgRPC 4317 / HTTP 4318、Jaeger 旧协议thrift 14268和 Zipkin9411三组接收器。实测下来最省心的一点是老 SDK 走 14268 的遗留流量、新 SDK 走 OTLP 的流量、甚至 Zipkin 客户端的流量落进同一个存储UI 里长得一模一样不用为每种客户端维护一套查询。采样成本全量上报的 span 量级在流量大时扛不住。仓库里docker-compose/tail-sampling/给了一套现成样板collector 挂tail_sampling处理器配一条string_attribute策略只保留指定服务的 trace示例只留tracegen-02和tracegen-04decision_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.xOpenSearch3.x/2.xCassandra5.0.x 维护中的4.xClickHouse 覆盖当前与前一个 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扩展监听 5778HTTP/5779gRPC策略文件每秒热加载尾采样上面提到的 tail-sampling 方案自适应采样components/processor/adaptivesampling/提供基于目标请求率的动态调节一条完整走线从 clone 到看到 tracegit clone https://gitcode.com/GitHub_Trending/ja/jaeger之后想最快看到东西其实不用碰源码。一条命令拉起 all-in-onedocker 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 在 16686gRPC 查询在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
