OpenTelemetry 收集器管道设计器

解决什么问题

OpenTelemetry Collector 的 pipeline 配置很容易踩坑：receiver、processor、exporter 三段里拼错一个组件名或参数，collector 启动就报错；更麻烦的是配置语法没错，但采样策略没生效、字段没清洗，这类问题往往到线上才发现，排查成本很高。这个技能帮工程师在动手写 YAML 之前把管道结构梳理清楚，给出能直接落地的配置骨架。

核心能力

• 组件覆盖：receiver 支持 otlp、prometheus、filelog；processor 支持 batch、attributes、tail_sampling；exporter 支持 otlphttp、jaeger、elasticsearch。
• 典型流程：先确认数据从哪进（OTLP 推送还是 Prometheus 抓取），中间要不要批量聚合或打标签，最终落到哪个后端，再按这个顺序把管道拼出来。
• 设计取舍：tail_sampling 适合在高流量下按规则取舍数据，attributes 用来补字段或改字段，batch 控制发送粒度——三者如何组合，取决于你更在意传输成本还是可观测性细节。

适用边界与注意点

• 运行环境要求 Go；collector 本身通常以容器方式部署，上游镜像发布在 ghcr.io/open-telemetry/opentelemetry-collector-releases。
• 组件能力以 OpenTelemetry 官方文档为准，遇到版本差异要去 collector 文档 核对。
• 它是设计配置的助手，不是配置管理工具：跑起来之后的部署、扩缩容和自身监控仍要自己搭。
• 上游镜像通过 sigstore/cosign 签名，拉镜像前先校验签名更稳妥。