OpenTelemetry 入门和部署
内容提要
OpenTelemetry（OTel）是CNCF托管的开源项目，提供与供应商无关的统一API、SDK和工具集，用于采集和关联指标、链路、日志三类遥测数据。其核心组件包括标准化传输协议OTLP、多语言SDK以及负责数据处理转发的Collector。文章通过Docker Compose部署Jaeger、Prometheus、Elasticsearch和OTel Collector，并使用curl上报测试数据验证，同时介绍了Elasticsearch Data Stream的索引机制。
延伸解读
OTel Collector 的管道设计：解耦采集与后端
文章中的 otel-collector 配置清晰展示了 receivers、processors、exporters 三段式管道。应用只需将 OTLP 数据发到 Collector，后续转发到 Jaeger、Prometheus 或 Elasticsearch 均由配置决定。这种解耦意味着更换后端时，应用代码无需改动，只需调整 Collector 配置。对于多团队共用一套采集入口的场景，这种设计能显著降低维护成本。
Jaeger 与 Collector 的端口冲突及规避
Jaeger v2 自身也监听 4317/4318 作为 OTLP 接收端口，与 OpenTelemetry Collector 默认端口相同。若在同一主机部署，必须修改其中一方的端口。文章指出，修改 Jaeger 端口会导致其自监控指标采集报错，虽然可用环境变量禁用自监控，但不建议这么做。因此更稳妥的做法是调整 Collector 的端口，或让 Jaeger 仅作为存储后端，不直接接收应用数据。
Elasticsearch Data Stream 的隐藏约定与踩坑
文章特别提醒，Elasticsearch Exporter 默认使用 Data Stream，索引名必须以 logs-、metrics- 或 traces- 开头，否则会报 index_not_found_exception。即使自定义为 logs-${service.name}，也会匹配内置模板 logs，自动转为 .ds- 前缀并添加日期后缀。若要使用普通索引，需显式设置 elasticsearch.mapping::mode = none。这些约定在官方文档中并不显眼，容易在集成时耗费大量排查时间。
极简部署的适用边界与生产化提醒
文章明确说明，示例中的 Docker Compose 配置为了便于演示，省略了安全、性能等方面的优化，例如 Elasticsearch 关闭了安全认证、Prometheus 未配置持久化调优、Collector 未启用 TLS 等。这套架构适合本地验证和功能测试，但直接用于生产环境存在风险。正式使用时，需要根据实际负载、安全要求和团队规范，对配置进行适配性改造。
Q&A
OpenTelemetry 是什么？它主要解决什么问题？
OpenTelemetry（OTel）是 CNCF 托管的开源项目，提供与供应商无关的统一 API、SDK 和工具集，用于采集和关联指标、链路、日志三类遥测数据。它主要解决在异构微服务环境中，以统一、标准化的方式采集和关联运行数据的难题。
OpenTelemetry 的核心组件有哪些？各自的作用是什么？
核心组件包括：OTLP 协议，定义遥测数据的标准化编码、传输和传递机制；多语言 SDK，为 Java、Go、Python 等提供官方实现，方便应用集成采集数据；OpenTelemetry Collector，独立运行的代理服务，负责接收、处理和转发 OTLP 格式的数据到后端平台。
如何用 Docker Compose 部署一套基本的 OpenTelemetry 服务？
使用 Docker Compose 部署四个服务：Jaeger（trace 后端）、Prometheus（指标存储）、Elasticsearch（日志存储）和 OTel Collector（数据处理转发）。需要创建 compose.yml 以及 conf/jaeger.yml、conf/prometheus.yml、conf/otelcol-config.yml 配置文件，并提前创建 es_data 和 prom_data 数据目录，然后执行 docker compose up -d 启动。
如何向 OpenTelemetry Collector 上报测试数据并验证？
使用 curl 向 Collector 的 HTTP 端口 4318 发送数据：上报 trace 用 /v1/traces，上报 metric 用 /v1/metrics，上报日志用 /v1/logs。验证方式：trace 在 Jaeger UI（http://127.0.0.1:16686）查看，metric 在 Prometheus UI（http://127.0.0.1:9090）搜索指标名，日志在 Elasticsearch 中查看索引和数据。
Elasticsearch Data Stream 是什么？使用它时有哪些注意事项？
Data Stream 是 Elasticsearch 7.9 引入的用于优化时序数据（如 Logs、Traces、Metrics）存储的机制，适合只追加不更新的场景。使用时索引名必须以 logs-、metrics- 或 traces- 为前缀，否则会报 index_not_found_exception。若要自定义非 Data Stream 索引名，需显式关闭 Data Stream，设置 elasticsearch.mapping::mode = none。
OpenTelemetry Collector 的配置文件中，数据接收、处理和转发是如何定义的？
配置文件分为 receivers、processors、exporters 和 service 四部分。receivers 定义 OTLP 接收端口（4317 gRPC、4318 HTTP）；processors 包括 batch 批处理和 transform 转换（如设置日志索引名）；exporters 将数据转发到 Jaeger、Prometheus 和 Elasticsearch；service 中按 traces、metrics、logs 分别定义管道，组合对应的接收器、处理器和导出器。
