在linux上部署opentelemetry的核心是部署并配置otelcol（opentelemetry collector），而非仅安装sdk；sdk仅生成数据，otelcol负责接收、处理、批处理、重试、采样及导出，缺它则遥测数据无法统一采集与可靠传输。
直接结论：在Linux上部署OpenTelemetry，核心不是“安装SDK”，而是部署并配置otelcol（OpenTelemetry Collector），再让应用通过OTLP协议把Traces/Metrics/Logs推给它。 光装Python或Java的SDK包，不配Collector，数据根本出不去，也谈不上“统一”。
为什么必须用otelcol而不是只装SDK
SDK（如opentelemetry-python）只负责生成和初步格式化遥测数据；它不接收、不转发、不批处理、不重试、不加采样策略——这些全靠otelcol完成。生产环境里，没有otelcol做中转，SDK直连后端（比如Jaeger或Prometheus）会迅速暴露以下问题：
- 应用重启导致连接中断，Trace丢失
- 网络抖动时无重试机制，指标断层
- 多个服务共用一个Exporter地址，缺乏负载分发能力
- 无法统一添加资源属性（如
service.name、env=prod）
所以Linux部署第一步，永远是拉起一个稳定运行的otelcol进程。
在Linux上快速启动otelcol的两种可靠方式
推荐优先使用静态二进制方式，避免Docker依赖和权限问题：
- 下载最新版：
curl -O https://www.php.cn/link/4ae895de21512e5ab771ee7e3194a09b/releases/download/v0.106.0/otelcol_0.106.0_linux_amd64.tar.gz（注意核对GitHub Releases上的最新版本号） - 解压并验证：
tar -xzf otelcol_*.tar.gz && ./otelcol --version - 准备最小配置
config.yaml：
receivers:
otlp:
protocols:
grpc:
http:
exporters:
logging:
loglevel: debug
service:
pipelines:
traces:
receivers: [otlp]
exporters: [logging]
- 启动：
./otelcol --config config.yaml，看到Starting otelcol...即成功
如果已用Docker且信任宿主机网络，也可用：docker run -p 4317:4317 -p 4318:4318 -v $(pwd)/config.yaml:/etc/otelcol/config.yaml otel/opentelemetry-collector。但注意：Docker默认禁用gRPC反射，若需调试，得加--enable-host-ports或改用host.docker.internal地址。
应用端怎么连上本地otelcol
不同语言写法差异大，但共性是都得设对OTEL_EXPORTER_OTLP_ENDPOINT和OTEL_RESOURCE_ATTRIBUTES：
- Python应用（用
opentelemetry-instrument启动）：OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 OTEL_RESOURCE_ATTRIBUTES=service.name=my-api opentelemetry-instrument --traces-exporter otlp_http python app.py - Java应用（用Agent）：
java -javaagent:/path/to/opentelemetry-javaagent.jar -Dotel.exporter.otlp.endpoint=http://localhost:4318 -Dotel.resource.attributes=service.name=my-api -jar app.jar - 关键点：gRPC默认走
4317，HTTP/JSON默认走4318；务必和config.yaml中otlpreceiver开启的协议端口一致 - 别漏
service.name——它是所有可观测平台做聚合、筛选、告警的锚点，没它，数据进来就是“匿名流浪汉”
容易被忽略的三个硬伤点
很多人在otelcol跑起来、应用也上报了之后，仍看不到数据，卡在以下环节：
-
config.yaml里没声明tracespipeline，或pipeline名拼错（比如写成trace而非traces），otelcol会静默跳过该段配置 - 应用和
otelcol不在同一网络命名空间（例如应用在Docker容器里，localhost指向容器自身，而非宿主机）；此时必须用宿主机IP（如172.17.0.1）或host.docker.internal - 防火墙拦了
4317/4318端口，尤其是CentOS/RHEL默认启用firewalld：sudo firewall-cmd --add-port=4317/tcp --permanent && sudo firewall-cmd --reload
真正难的从来不是“怎么装”，而是确认信号从应用发出、经Collector加工、最终抵达后端的每一段链路是否畅通——尤其当你的后端是Prometheus+Grafana或SigNoz这类需要额外配置接收器的系统时，Collector只是中间一环，不能把它当成终点。
