2026/9/5 18:00:21
FEATURED · 精选文章 
如何用Jaeger 5步跑通分布式追踪从零到生产部署的完整路径【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger用户在群里投诉下单变慢了你翻了三小时各服务日志只看到一堆上游超时的半句话。直到你在 Jaeger——CNCF 毕业的分布式追踪平台——里打开那条跨了 7 个服务的调用链9 秒的总耗时里有 8.2 秒卡在一句没走索引的 SQL 上。这就是链路追踪和日志的本质区别日志告诉你谁报了错追踪告诉你时间到底花在哪。Jaeger到底是什么 / 解决什么问题可以把 Jaeger 理解成快递的物流跟踪系统一个请求在微服务之间流转时每一站的时间戳和状态都被记录成span串起来就是一条trace调用链。它由 Uber 开发并捐赠给 CNCF现在基于 OpenTelemetry Collector 构建原生接收OTLP 协议gRPC 4317 / HTTP 4318。和传统日志方案比对比项分散日志Jaeger 分布式追踪定位慢在哪逐服务 grep 后人工拼时间线瀑布图直接看每个 span 耗时跨服务关联依赖 traceId 手工串联自动聚合为一条完整链路服务依赖关系看不出来依赖图直接展示核心能力调用链查询与瀑布图按服务、操作、标签、时间窗过滤逐 span 查看耗时服务性能监控SPM从 trace 数据直接算出 RED 指标请求率、错误率、延迟分位数多种存储后端memory、Badger、Elasticsearch、OpenSearch、Cassandra、ClickHouse灵活采样策略概率采样、自适应采样、尾部采样控制高流量下的数据量从零跑起来最小可用环境准备一台装了 Docker 的机器就够了确认端口空闲16686UI 和查询 API、4317OTLP gRPC、4318OTLP HTTP。启动一键拉起 Jaeger All-in-one一条命令启动包含 UI、Collector、Query、内存存储的 all-in-one 容器docker run --rm --name jaeger \ -p 16686:16686 \ -p 4317:4317 \ -p 4318:4318 \ jaegertracing/jaeger:latest接入应用OTLP 是唯一的入口v2 版本统一走 OTLP。以 Go 应用为例最小接入代码exporter, _ : otlptracegrpc.New(ctx, otlptracegrpc.WithEndpoint(localhost:4317), otlptracegrpc.WithInsecure(), // 本地开发用明文生产记得换 TLS ) otel.SetTracerProvider(sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), // 批量导出减少网络往返 ))Java、Python、Node.js 用各自的 OpenTelemetry SDK配置方式相同把 exporter endpoint 指向localhost:4317gRPC或4318HTTP。不想改业务代码用官方自带的 tracegen 生成模拟流量--network host让它访问宿主机的 4318 端口docker run --rm --network host \ -e OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://localhost:4318/v1/traces \ jaegertracing/jaeger-tracegen:latest \ -trace-exporter otlp-http -traces 100验证先确认数据进来了再看界面# 返回的服务列表里应该出现 tracegen说明数据已入库 curl -s http://localhost:16686/services出现结果即代表整条链路跑通了。浏览器打开http://localhost:16686进入 UI。想要带指标监控的完整演示环境microsim 微服务模拟器 OTel Collector Prometheus Grafana可以直接用仓库里现成的 docker-compose/monitor/cd docker-compose/monitor docker compose up架构图见下图数据流应用 SDK → Collector → Jaeger → 存储UI 同时查 trace 和指标Jaeger 监控环境架构OTel SDK 发出的 trace 经 Collector 分流trace 进 Jaeger 存储聚合出的 RED 指标进 Prometheus最终统一在 UI 呈现看懂你的第一条追踪数据打开http://localhost:16686默认进入查询页。页面分三块顶部是搜索表单service、operation、tags、时间窗、是否只看错误中间是 trace 列表每条显示总耗时、span 数、服务名、时间点进单条后是瀑布图详情。Jaeger UI 的 trace 查询界面上方按服务/操作/标签/时间筛选列表区展示每条 trace 的总时长与 span 数量点击某条进入瀑布图以图中tracegen服务为例几个关键读法总时长Duration这条链路从第一个 span 开始到最后一个 span 结束的墙钟时间比单个 span 耗时更接近用户真实感受单个 span 的耗时占比瀑布图里最长的色块就是关键路径。如果 9 秒的 trace 里某 span 占了 8 秒排查就从它开始operation 名span 的操作名如Get、POST /api/checkout同名 operation 的延迟突变往往就是回归点错误标记带 ✕ 的 span 表示状态码为错误搜索表单里可以勾选只看错误 trace核心能力详解日常监控看什么Monitor 标签页的 RED 三件套v2 内置 SPMService Performance Monitoring功能jaeger-query 直接从 trace 数据算出调用率call rate、错误率error rate、延迟分位数P50/P95/P99在 UI 的 Monitor 标签页以曲线展示。Monitor 标签页展示的 RED 指标请求率、错误率和 P95 延迟按时间分布可按服务/操作下钻三个数字高了分别说明什么P95 延迟上升大部分请求还正常但尾部变慢了——通常是某个下游变慢或 GC 抖动去瀑布图里找变长的 span错误率上升配合只看错误 trace过滤定位是哪个 operation 开始报错请求率与延迟同步跳变大概率是流量峰值打爆了容量进入容量规划场景指标也可以通过 API 直接取方便接入自己的脚本# 查询 tracegen 服务最近 1 小时的 P95 延迟 curl -s http://localhost:16686/api/metrics/latencies?servicetracegenquantile0.95排障时查什么多维过滤 依赖图排障的标准动作是缩小范围先按service 时间窗圈定再加operation和tag如http.status_code500收敛最后打开具体 trace 看瀑布图。UI 的 Services 页还能看到依赖图直观回答谁在调我、我调了谁。容量规划看什么采样策略与存储选型高流量下全量记录既不现实也没必要Jaeger 提供三类采样方案适合场景注意事项概率采样probabilistic开发/低流量全量或固定比例无法保证错误 trace 一条不漏自适应采样adaptive中流量v2 默认方向按服务/operation 动态调概率依赖 trace 反馈尾部采样tail_sampling高流量只留有用的 trace需等待决策窗口如 5s占内存SPM 指标的存储也有两种路线完整演示见 docker-compose/monitor/ 下的多个 compose 文件方案适合场景注意事项Prometheus 后端已有 Prometheus 生态、要接告警多一个组件指标有约 60s 聚合延迟直接查 trace 存储ES/OS已经在用 ES/OS 存 trace不引新组件但查询打到 trace 库ClickHouse 同时存 trace 和指标数据量大、查询并发高需建表支持create_schema: true自动建生产环境怎么配才稳推荐路径先 all-in-one 验证 → 数据量上来后换存储、拆组件 → 接入自身监控告警。阶段一all-in-one 明确数据上限内存存储重启即丢但开发验证够用。关键是显式设上限参考仓库 cmd/jaeger/config.yamljaeger_storage: backends: some_store: memory: max_traces: 100000 # 只保留最近 10 万条 trace超了丢最老的避免内存无界增长阶段二数据量上来后换持久化存储换成 Badger单机时务必设置 TTL否则磁盘会无限增长参考 cmd/jaeger/config-badger.yamlbadger: directories: keys: /data/jaeger/ values: /data/jaeger/ ttl: spans: 48h # 只留 48 小时按排障习惯定老数据靠归档而非无限保留换 Elasticsearch/OpenSearch 时按天滚动索引方便按时间清理完整配置见 cmd/jaeger/config-elasticsearch.yamlelasticsearch: server_urls: [http://localhost:9200] indices: index_prefix: jaeger-main spans: rollover_frequency: day # 每天一个索引清理就是删旧索引 shards: 5 replicas: 1阶段三把 Jaeger 自己也监控起来v2 默认在8888端口以 Prometheus 格式暴露自身指标见config.yaml中 telemetry 段。至少盯这 4 个otelcol_receiver_accepted_spans接收到的 span 数突降说明上游断流otelcol_exporter_sent_spans成功写入存储的 span 数与接收数持续差值变大说明存储端在丢traces_span_metrics_calls_total/traces_span_metrics_errors_totalSPM 算出的调用量与错误量可配业务告警Jaeger 进程的内存与 CPU容器docker stats或 node exporter踩过的坑与诊断路径数据明明发出去了UI 里看不到可能原因采样策略把流量过滤掉了endpoint 指错4317 是 gRPC、4318 是 HTTP混用会连不上服务名和你搜索的不一致。# 1. 先确认后端到底收到了哪些服务 curl -s http://localhost:16686/services # 2. 看 Collector 有没有报错如 schema/索引问题 docker logs --tail 200 jaeger | grep -iE error|fail调整建议临时把采样调成全量验证链路确认应用端OTEL_EXPORTER_OTLP_TRACES_ENDPOINT的协议和端口匹配搜索时用/services返回的原样服务名。查询越来越慢可能原因时间窗开得太宽默认 1h 起步有人直接选全部trace 库索引膨胀没清理单条 trace 的 span 数过多。# ES 后端看索引数量和大小确认滚动索引是否生效、旧索引是否已清 curl -s localhost:9200/_cat/indices/jaeger*?sstore.size:desc调整建议养成先窄时间窗、再放宽的查询习惯给旧索引设保留策略热点查询加 service operation 条件而不是裸查。内存 / 磁盘持续增长可能原因all-in-one 内存存储接近max_traces上限Badger/ES 没设 TTL 或滚动队列积压消费速度 接收速度。# 看容器内存水位 docker stats --no-stream # 对比收发差值sent 明显低于 accepted 说明存储端写入跟不上 curl -s http://localhost:8888/metrics | grep -E otelcol_(receiver_accepted|exporter_sent)_spans调整建议给 memory 后端设小一点max_traces给持久化后端设ttl/ 索引保留天数用tail_sampling或降低概率采样率把入口流量砍下来。从Demo到生产进阶玩法如果你需要只留慢的和错的其他全丢上尾部采样。在 pipeline 里挂tail_samplingprocessor按属性或延迟过滤仓库里有现成示例cmd/jaeger/config-tail-sampling-service-name-policy.yamlprocessors: tail_sampling: decision_wait: 5s # 等 5 秒攒齐一条 trace 再决策 policies: - name: keep-tracegen type: string_attribute string_attribute: { key: service.name, values: [tracegen-00] }如果你需要按业务维度下钻在应用里给 span 加自定义属性如business.tierpremiumUI 搜索表单的 tags 里就能直接按business.tierpremium过滤——这是把追踪从技术视角扩展到业务视角的关键一步。如果你需要回答这次发布动了哪些依赖对比发布前后的 Services 依赖图和 Monitor 页 RED 曲线比翻变更日志快得多。收尾你的行动清单docker run拉起 all-in-onecurl http://localhost:16686/services返回tracegen用 OTLP 把一个真实应用接进来gRPC 4317 或 HTTP 4318在 UI 看到第一条自己的 trace按流量规模选定采样策略概率 / 自适应 / 尾部采样写进配置存储从 memory 换到 Badger 或 ES/ClickHouse并显式设置 TTL / 索引保留把8888端口的自身指标接入 Prometheus至少对 span 接收/写出差值配一条告警从 Demo 到生产不是一次切换而是数据量倒逼的渐进过程先保证链路可见再谈留存和告警。核心关键词Jaeger分布式追踪, 分布式追踪平台, 微服务性能监控, OpenTelemetry OTLP接入, Jaeger生产部署 长尾关键词Jaeger all-in-one一键启动, Jaeger采样策略配置, Jaeger存储后端选择, Jaeger SPM服务性能监控, Jaeger故障诊断排查指南【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何用Jaeger 5步跑通分布式追踪：从零到生产部署的完整路径
如何用Jaeger 5步跑通分布式追踪从零到生产部署的完整路径【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger用户在群里投诉下单变慢了你翻了三小时各服务日志只看到一堆上游超时的半句话。直到你在 Jaeger——CNCF 毕业的分布式追踪平台——里打开那条跨了 7 个服务的调用链9 秒的总耗时里有 8.2 秒卡在一句没走索引的 SQL 上。这就是链路追踪和日志的本质区别日志告诉你谁报了错追踪告诉你时间到底花在哪。Jaeger到底是什么 / 解决什么问题可以把 Jaeger 理解成快递的物流跟踪系统一个请求在微服务之间流转时每一站的时间戳和状态都被记录成span串起来就是一条trace调用链。它由 Uber 开发并捐赠给 CNCF现在基于 OpenTelemetry Collector 构建原生接收OTLP 协议gRPC 4317 / HTTP 4318。和传统日志方案比对比项分散日志Jaeger 分布式追踪定位慢在哪逐服务 grep 后人工拼时间线瀑布图直接看每个 span 耗时跨服务关联依赖 traceId 手工串联自动聚合为一条完整链路服务依赖关系看不出来依赖图直接展示核心能力调用链查询与瀑布图按服务、操作、标签、时间窗过滤逐 span 查看耗时服务性能监控SPM从 trace 数据直接算出 RED 指标请求率、错误率、延迟分位数多种存储后端memory、Badger、Elasticsearch、OpenSearch、Cassandra、ClickHouse灵活采样策略概率采样、自适应采样、尾部采样控制高流量下的数据量从零跑起来最小可用环境准备一台装了 Docker 的机器就够了确认端口空闲16686UI 和查询 API、4317OTLP gRPC、4318OTLP HTTP。启动一键拉起 Jaeger All-in-one一条命令启动包含 UI、Collector、Query、内存存储的 all-in-one 容器docker run --rm --name jaeger \ -p 16686:16686 \ -p 4317:4317 \ -p 4318:4318 \ jaegertracing/jaeger:latest接入应用OTLP 是唯一的入口v2 版本统一走 OTLP。以 Go 应用为例最小接入代码exporter, _ : otlptracegrpc.New(ctx, otlptracegrpc.WithEndpoint(localhost:4317), otlptracegrpc.WithInsecure(), // 本地开发用明文生产记得换 TLS ) otel.SetTracerProvider(sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), // 批量导出减少网络往返 ))Java、Python、Node.js 用各自的 OpenTelemetry SDK配置方式相同把 exporter endpoint 指向localhost:4317gRPC或4318HTTP。不想改业务代码用官方自带的 tracegen 生成模拟流量--network host让它访问宿主机的 4318 端口docker run --rm --network host \ -e OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://localhost:4318/v1/traces \ jaegertracing/jaeger-tracegen:latest \ -trace-exporter otlp-http -traces 100验证先确认数据进来了再看界面# 返回的服务列表里应该出现 tracegen说明数据已入库 curl -s http://localhost:16686/services出现结果即代表整条链路跑通了。浏览器打开http://localhost:16686进入 UI。想要带指标监控的完整演示环境microsim 微服务模拟器 OTel Collector Prometheus Grafana可以直接用仓库里现成的 docker-compose/monitor/cd docker-compose/monitor docker compose up架构图见下图数据流应用 SDK → Collector → Jaeger → 存储UI 同时查 trace 和指标Jaeger 监控环境架构OTel SDK 发出的 trace 经 Collector 分流trace 进 Jaeger 存储聚合出的 RED 指标进 Prometheus最终统一在 UI 呈现看懂你的第一条追踪数据打开http://localhost:16686默认进入查询页。页面分三块顶部是搜索表单service、operation、tags、时间窗、是否只看错误中间是 trace 列表每条显示总耗时、span 数、服务名、时间点进单条后是瀑布图详情。Jaeger UI 的 trace 查询界面上方按服务/操作/标签/时间筛选列表区展示每条 trace 的总时长与 span 数量点击某条进入瀑布图以图中tracegen服务为例几个关键读法总时长Duration这条链路从第一个 span 开始到最后一个 span 结束的墙钟时间比单个 span 耗时更接近用户真实感受单个 span 的耗时占比瀑布图里最长的色块就是关键路径。如果 9 秒的 trace 里某 span 占了 8 秒排查就从它开始operation 名span 的操作名如Get、POST /api/checkout同名 operation 的延迟突变往往就是回归点错误标记带 ✕ 的 span 表示状态码为错误搜索表单里可以勾选只看错误 trace核心能力详解日常监控看什么Monitor 标签页的 RED 三件套v2 内置 SPMService Performance Monitoring功能jaeger-query 直接从 trace 数据算出调用率call rate、错误率error rate、延迟分位数P50/P95/P99在 UI 的 Monitor 标签页以曲线展示。Monitor 标签页展示的 RED 指标请求率、错误率和 P95 延迟按时间分布可按服务/操作下钻三个数字高了分别说明什么P95 延迟上升大部分请求还正常但尾部变慢了——通常是某个下游变慢或 GC 抖动去瀑布图里找变长的 span错误率上升配合只看错误 trace过滤定位是哪个 operation 开始报错请求率与延迟同步跳变大概率是流量峰值打爆了容量进入容量规划场景指标也可以通过 API 直接取方便接入自己的脚本# 查询 tracegen 服务最近 1 小时的 P95 延迟 curl -s http://localhost:16686/api/metrics/latencies?servicetracegenquantile0.95排障时查什么多维过滤 依赖图排障的标准动作是缩小范围先按service 时间窗圈定再加operation和tag如http.status_code500收敛最后打开具体 trace 看瀑布图。UI 的 Services 页还能看到依赖图直观回答谁在调我、我调了谁。容量规划看什么采样策略与存储选型高流量下全量记录既不现实也没必要Jaeger 提供三类采样方案适合场景注意事项概率采样probabilistic开发/低流量全量或固定比例无法保证错误 trace 一条不漏自适应采样adaptive中流量v2 默认方向按服务/operation 动态调概率依赖 trace 反馈尾部采样tail_sampling高流量只留有用的 trace需等待决策窗口如 5s占内存SPM 指标的存储也有两种路线完整演示见 docker-compose/monitor/ 下的多个 compose 文件方案适合场景注意事项Prometheus 后端已有 Prometheus 生态、要接告警多一个组件指标有约 60s 聚合延迟直接查 trace 存储ES/OS已经在用 ES/OS 存 trace不引新组件但查询打到 trace 库ClickHouse 同时存 trace 和指标数据量大、查询并发高需建表支持create_schema: true自动建生产环境怎么配才稳推荐路径先 all-in-one 验证 → 数据量上来后换存储、拆组件 → 接入自身监控告警。阶段一all-in-one 明确数据上限内存存储重启即丢但开发验证够用。关键是显式设上限参考仓库 cmd/jaeger/config.yamljaeger_storage: backends: some_store: memory: max_traces: 100000 # 只保留最近 10 万条 trace超了丢最老的避免内存无界增长阶段二数据量上来后换持久化存储换成 Badger单机时务必设置 TTL否则磁盘会无限增长参考 cmd/jaeger/config-badger.yamlbadger: directories: keys: /data/jaeger/ values: /data/jaeger/ ttl: spans: 48h # 只留 48 小时按排障习惯定老数据靠归档而非无限保留换 Elasticsearch/OpenSearch 时按天滚动索引方便按时间清理完整配置见 cmd/jaeger/config-elasticsearch.yamlelasticsearch: server_urls: [http://localhost:9200] indices: index_prefix: jaeger-main spans: rollover_frequency: day # 每天一个索引清理就是删旧索引 shards: 5 replicas: 1阶段三把 Jaeger 自己也监控起来v2 默认在8888端口以 Prometheus 格式暴露自身指标见config.yaml中 telemetry 段。至少盯这 4 个otelcol_receiver_accepted_spans接收到的 span 数突降说明上游断流otelcol_exporter_sent_spans成功写入存储的 span 数与接收数持续差值变大说明存储端在丢traces_span_metrics_calls_total/traces_span_metrics_errors_totalSPM 算出的调用量与错误量可配业务告警Jaeger 进程的内存与 CPU容器docker stats或 node exporter踩过的坑与诊断路径数据明明发出去了UI 里看不到可能原因采样策略把流量过滤掉了endpoint 指错4317 是 gRPC、4318 是 HTTP混用会连不上服务名和你搜索的不一致。# 1. 先确认后端到底收到了哪些服务 curl -s http://localhost:16686/services # 2. 看 Collector 有没有报错如 schema/索引问题 docker logs --tail 200 jaeger | grep -iE error|fail调整建议临时把采样调成全量验证链路确认应用端OTEL_EXPORTER_OTLP_TRACES_ENDPOINT的协议和端口匹配搜索时用/services返回的原样服务名。查询越来越慢可能原因时间窗开得太宽默认 1h 起步有人直接选全部trace 库索引膨胀没清理单条 trace 的 span 数过多。# ES 后端看索引数量和大小确认滚动索引是否生效、旧索引是否已清 curl -s localhost:9200/_cat/indices/jaeger*?sstore.size:desc调整建议养成先窄时间窗、再放宽的查询习惯给旧索引设保留策略热点查询加 service operation 条件而不是裸查。内存 / 磁盘持续增长可能原因all-in-one 内存存储接近max_traces上限Badger/ES 没设 TTL 或滚动队列积压消费速度 接收速度。# 看容器内存水位 docker stats --no-stream # 对比收发差值sent 明显低于 accepted 说明存储端写入跟不上 curl -s http://localhost:8888/metrics | grep -E otelcol_(receiver_accepted|exporter_sent)_spans调整建议给 memory 后端设小一点max_traces给持久化后端设ttl/ 索引保留天数用tail_sampling或降低概率采样率把入口流量砍下来。从Demo到生产进阶玩法如果你需要只留慢的和错的其他全丢上尾部采样。在 pipeline 里挂tail_samplingprocessor按属性或延迟过滤仓库里有现成示例cmd/jaeger/config-tail-sampling-service-name-policy.yamlprocessors: tail_sampling: decision_wait: 5s # 等 5 秒攒齐一条 trace 再决策 policies: - name: keep-tracegen type: string_attribute string_attribute: { key: service.name, values: [tracegen-00] }如果你需要按业务维度下钻在应用里给 span 加自定义属性如business.tierpremiumUI 搜索表单的 tags 里就能直接按business.tierpremium过滤——这是把追踪从技术视角扩展到业务视角的关键一步。如果你需要回答这次发布动了哪些依赖对比发布前后的 Services 依赖图和 Monitor 页 RED 曲线比翻变更日志快得多。收尾你的行动清单docker run拉起 all-in-onecurl http://localhost:16686/services返回tracegen用 OTLP 把一个真实应用接进来gRPC 4317 或 HTTP 4318在 UI 看到第一条自己的 trace按流量规模选定采样策略概率 / 自适应 / 尾部采样写进配置存储从 memory 换到 Badger 或 ES/ClickHouse并显式设置 TTL / 索引保留把8888端口的自身指标接入 Prometheus至少对 span 接收/写出差值配一条告警从 Demo 到生产不是一次切换而是数据量倒逼的渐进过程先保证链路可见再谈留存和告警。核心关键词Jaeger分布式追踪, 分布式追踪平台, 微服务性能监控, OpenTelemetry OTLP接入, Jaeger生产部署 长尾关键词Jaeger all-in-one一键启动, Jaeger采样策略配置, Jaeger存储后端选择, Jaeger SPM服务性能监控, Jaeger故障诊断排查指南【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
