所有文章 引言 在构建带分布式追踪的应用时，通常会依赖 DataDog 这类平台来做可观测性。但在开发阶段，这些因素确实会拖慢你的节奏。管理 API key、触发速率限制、发送测试 trace 产生的费用，这些都会带来不必要的摩擦。测试追踪代码不该这么费劲。 好在有更好的办法。本文将展示如何用 Docker Compose 运行 OpenTelemetry Collector，快速搭建一个轻量的本地环境，再配一个极简的 Go 应用来发布 trace，供我们可视化查看。这套环境让你无需依赖 DataDog 之类的外部服务，就能测试和验证追踪逻辑——快速、省钱、省事。 一条 trace 表示一个请求在系统中流转的完整路径——从最初的入口点，到沿途经过的所有服务和组件。它让你从高层视角看清这个请求是如何被处理的，帮助你理解跨服务的性能瓶颈、失败和依赖关系。 在一条 trace 内部，每一个单独的操作都被记录为一个 span。span 记录某个具体工作单元的细节，比如一次函数执行、一次数据库查询或一次外部 API 调用。span 包含时间信息、元数据以及父子关系，用以展示 trace 内部的工作结构。trace 和 span 结合在一起，让你清晰、结构化地看到应用在底层到底在做什么。 在开发阶段使用云厂商的 API 会带来不少痛点： OpenTelemetry（OTel）提供了更灵活的方案。作为开放标准，它让你完全掌控 trace 的采集、处理和导出方式。通过在本地运行 OTel Collector，你可以模拟 trace 管道、调试埋点——全程不用离开自己的开发机。 在进入代码之前，先把本地环境准备好。你只需要 Docker、Go 运行时，以及对 OpenTelemetry 工作原理的基本了解。 你可以查阅文档来下载/安装上述资源： 我们将用一个 Docker Compose 文件来运行 OTel Collector。这套配置会包含一份自定义配置，使其能以 DataDog 兼容的格式接收 trace。这非常适合在不调用外部 API 的情况下做测试。等它跑起来之后，我们再写一个小 Go 应用来生成一些 trace 并发送到本地 collector。 你可以先创建一个自己喜欢的新项目目录。 mkdir <NAME_OF_YOUR_PROJECT> cd <NAME_OF_YOUR_PROJECT> 本地 OTel 配置 在新的项目目录中，加入下面这个用于 OTel 配置的 docker compose 文件。

otel-compose.yaml

services: otel-collector: image: grafana/otel-lgtm:latest ports:

• "8126:8126"
• "4317:4317"
• "4318:4318"
• "3005:3000" # Optional port for health check or UI if needed configs:
• source: otelcol-config.yaml target: /otel-lgtm/otelcol-config.yaml configs: otelcol-config.yaml: content: | receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 prometheus/collector: config: scrape_configs:
• job_name: 'opentelemetry-collector' static_configs:
• targets: ['localhost:8888'] datadog: endpoint: 0.0.0.0:8126 processors: batch: exporters: otlphttp/metrics: endpoint: http://localhost:9090/api/v1/otlp tls: insecure: true otlphttp/traces: endpoint: http://localhost:4418 tls: insecure: true otlphttp/logs: endpoint: http://localhost:3100/otlp tls: insecure: true debug/metrics: verbosity: detailed debug/traces: verbosity: detailed debug/logs: verbosity: detailed service: pipelines: traces: receivers: [otlp, datadog] processors: [batch] exporters: [otlphttp/traces] #exporters: [otlphttp/traces,debug/traces] metrics: receivers: [otlp,prometheus/collector, datadog] processors: [batch] exporters: [otlphttp/metrics] #exporters: [otlphttp/metrics,debug/metrics] logs: receivers: [otlp] processors: [batch] exporters: [otlphttp/logs] #exporters: [otlphttp/logs,debug/logs] OTel 配置文件拆解 我们来简单拆解一下上面的 docker-compose 文件。在 services 块中，我们有 otel-collector，它使用 grafana/otel-lgtm 镜像，暴露常用的遥测端口： 它还从 configs 部分挂载了自定义配置。见下文。 services: otel-collector: image: grafana/otel-lgtm:latest ports:
• "8126:8126"
• "4317:4317"
• "4318:4318"
• "3005:3000" # Optional port for health check or UI if needed configs:
• source: otelcol-config.yaml target: /otel-lgtm/otelcol-config.yaml configs 部分负责定义遥测数据如何被接收、导出和聚合。 receivers 子部分负责接收传入的遥测数据。 receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 prometheus/collector: config: scrape_configs:
• job_name: 'opentelemetry-collector' static_configs:
• targets: ['localhost:8888'] datadog: endpoint: 0.0.0.0:8126 batch 子部分负责在发送前对遥测数据做批处理。batch 部分留空意味着该处理器将使用默认配置运行。 processors: batch: exporters 子部分负责把遥测数据发送到存储后端。 exporters: otlphttp/metrics: endpoint: http://localhost:9090/api/v1/otlp tls: insecure: true otlphttp/traces: endpoint: http://localhost:4418 tls: insecure: true otlphttp/logs: endpoint: http://localhost:3100/otlp tls: insecure: true debug/metrics: verbosity: detailed debug/traces: verbosity: detailed debug/logs: verbosity: detailed service 子部分通过 pipeline 把所有环节串起来。 service: pipelines: traces: receivers: [otlp, datadog] processors: [batch] exporters: [otlphttp/traces] #exporters: [otlphttp/traces,debug/traces] metrics: receivers: [otlp,prometheus/collector, datadog]

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）