OpenTelemetry Collector 在 Linux 上应以 Gateway 模式容器化部署为采集网关，通过 OTLP 接收应用遥测数据，经 receivers/processors/exporters 配置实现统一处理与转发，并需验证端口、trace 上报及 ZPages 状态确保闭环可观测。
Linux 系统部署 OpenTelemetry Collector 作为采集网关，核心是把它当作统一接收、处理和转发遥测数据（Traces/Metrics/Logs）的中心枢纽，而不是只装 SDK 就完事。它必须运行起来，配置好接收端口和导出器，应用才能把数据可靠地“交”给它。
明确部署目标：Gateway 模式为主
采集网关即 Gateway 模式——在集群或数据中心中部署一个或多个集中式 Collector 实例，所有应用通过 OTLP 协议将数据推送到该网关。这种方式便于统一策略管控，比如采样率、重试逻辑、敏感字段脱敏、TLS 加密、批处理大小等。
- 避免每个应用直连后端（如 Jaeger/Prometheus/Grafana），解耦更彻底
- 网关可横向扩展（如用 Kubernetes Deployment + HPA），应对流量高峰
- 所有认证、限流、路由规则集中在一处配置，运维更可控
推荐部署方式：容器化（Docker Compose 或 Kubernetes）
对大多数 Linux 环境，优先使用容器化部署，省去二进制兼容性与依赖管理问题。官方镜像 otel/opentelemetry-collector:latest 已适配 linux/amd64（Tier 1 支持），稳定可靠。
- Docker Compose 适合测试或中小规模环境：定义
otel-collector服务，暴露4317（gRPC）和4318（HTTP）端口，挂载自定义config.yaml - Kubernetes 生产环境建议用 OpenTelemetry Operator：自动管理 Collector 生命周期，支持 CRD 配置、证书签发（需先装 cert-manager）、健康检查与滚动更新
- 不推荐直接用 rpm/deb 包安装：虽有社区构建版本，但缺乏官方长期维护，升级路径不清晰，配置管理也较原始
关键配置项：接收器、处理器、导出器三件套
网关能力取决于 config.yaml 的编排。一份最小可用网关配置至少包含：
-
receivers：启用
otlp（必开），可选加hostmetrics（采集本机指标）或prometheus（拉取已有 Prometheus target） -
processors：至少配置
batch（提升传输效率）、memory_limiter（防 OOM）、filter（按属性过滤） -
exporters：指向真实后端，如
jaeger（gRPC）、prometheusremotewrite（写入 Prometheus TSDB）、logging（调试用） -
service：把上述组件串联成 pipeline，例如：
traces: receivers: [otlp] processors: [batch] exporters: [jaeger]
验证与可观测性闭环
部署后不能只看容器是否 running，要确认数据真正通路畅通：
- 用
curl -v http://localhost:4318/v1/metrics测试 HTTP 接收端口是否响应（返回 405 表示正常监听） - 启动一个 demo 应用（如 opentelemetry-python 的 quickstart），设置
OTEL_EXPORTER_OTLP_ENDPOINT=http://<gateway-ip>:4318</gateway-ip>，观察 Jaeger UI 是否出现 trace - 访问 Collector 自带 ZPages（默认
:55679/debug/tracez）查看实时 pipeline 状态、队列长度、错误计数 - 若用 Kubernetes，可通过
kubectl logs -l app=opentelemetry-collector查看日志中是否有 “Exporting N spans” 或 “Failed to export” 类提示
