用 docker compose 集成全链路追踪的关键是理清依赖、配置对齐与数据流向：选准组件版本（如 skywalking 8.8.0+ 搭 es 7.12.1）、用 depends_on+healthcheck 控制启动顺序、通过环境变量注入配置、确保 trace id 贯穿调用链（http header 或 grpc metadata 透传）、日志统一 json 格式输出 trace_id，并通过 ui、api 和日志三步验证闭环。
用 Docker Compose 集成全链路分布式追踪系统，关键不是堆命令，而是理清服务依赖、配置对齐和数据流向。只要组件选得准、启动顺序控得住、Trace ID 贯得通，一次编排就能跑通整个调用链。
选对追踪系统与配套存储版本
不同追踪工具对后端存储有强版本约束，踩错一个 tag 就连不上：
- SkyWalking 8.8.0+ 推荐搭配 elasticsearch:7.12.1，不支持 ES 8.x；storage 配置必须设为
SW_STORAGE=elasticsearch7 - Pinpoint 依赖 HBase 2.2.6，官方未提供现成镜像，需基于 openjdk:8 构建，或使用社区验证的
pinpointdocker/pinpoint-hbase:2.2.6 - Jaeger All-in-One 模式虽简单，但生产建议拆分为
jaeger-collector、jaeger-query和jaeger-agent，后端用 Cassandra 或 Elasticsearch（ES 7.x 同样适用）
用 docker-compose.yml 编排服务依赖与网络
Docker Compose 的核心价值是自动处理启动顺序和内部通信。OAP 不能在 ES 还没就绪时就去连，UI 也不能在 OAP 没响应时加载数据：
- 用
depends_on+healthcheck确保前置服务真正可用，例如给 ES 加健康检查：
healthcheck:
test: ["CMD-SHELL", "curl -f http://localhost:9200/_cat/health?h=status 2>/dev/null | grep -q 'green'"]
interval: 30s
timeout: 10s
retries: 5 - 所有服务默认在同一 bridge 网络，容器名可直接作 host 使用：OAP 中配置
SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200，无需写 IP - 挂载配置文件时优先用环境变量覆盖，比如 OAP 的
application.yml中关键项通过environment注入，便于多环境切换
让 Trace ID 真正贯穿整个调用链
容器跑起来了，不代表追踪就生效。Trace ID 必须从入口服务开始注入，并在每个跨服务调用中透传：
- 应用接入 Agent 时，确保开启上下文传播：SkyWalking Java Agent 默认支持 HTTP header 中的
sw8字段；Jaeger SDK 默认使用uber-trace-id - 网关或前端服务需在发起下游请求时携带该 header，gRPC 场景则需在 metadata 中注入
- 日志中同步打印
trace_id字段，格式建议统一为 JSON，例如：
{"level":"INFO","service":"order-service","trace_id":"a1b2c3d4e5","message":"create order ok"}
这样后续接入 ELK 或 Loki 才能按 trace_id 聚合全链路日志
验证与可观测性闭环
部署完成不等于追踪可用，要建立快速验证路径：
- 访问 UI（如 SkyWalking 的
http://localhost:8080或 Jaeger 的http://localhost:16686），确认服务列表已发现、拓扑图可生成 - 发起一次真实请求（如调用订单接口），在 UI 的 Search 页面输入 trace ID 或服务名，查看完整调用链是否包含全部环节、耗时是否合理
- 进容器执行
curl -s http://oap:12800/v3/services，确认 OAP API 返回非空 JSON，说明收集器正常接收数据 - 检查各服务容器日志，搜索
trace或span关键字，确认 Agent 已加载且无连接拒绝报错
