OTLP 的 gRPC 接收口
4317 是 OpenTelemetry Collector 的 OTLP gRPC 接收端口。应用与各类 SDK 通过它上报 traces、metrics 与 logs，Collector 再分发到后端存储。OTLP 是 OpenTelemetry 定义的标准协议，同时提供 gRPC（4317）与 HTTP/protobuf（4318）两种传输方式，前者用二进制帧、开销更小，是集群内上报的常用选择。
基本信息
| 服务 | OTLP receiver（gRPC） |
|---|---|
| 协议 | gRPC over HTTP/2（TCP 4317） |
| 对应 HTTP 口 | 4318（HTTP/protobuf） |
| 用途 | 遥测数据统一采集 |
| 安全等级 | 仅监控网段 |
典型使用场景
- 应用通过 SDK 上报链路追踪数据，构建分布式调用链
- 采集主机与容器指标，替代多套采集器并存的局面
- 日志与指标走同一个入口，简化采集端配置
- 排查数据没上报，先确认接收端口与传输协议是否配对
- 评估是否需要双向证书与来源限制
- 迁移监控栈时清点仍指向旧端点的采集配置
接收侧核查
接收侧核查
grpcurl -plaintext 127.0.0.1:4317 list # 列出 gRPC 服务（需 grpcurl）
curl -s http://127.0.0.1:8888/metrics | grep otelcol_receiver | head -6
ss -lntp | grep -E ':(4317|4318) 'OTLP 端口与传输
| 端口 | 协议 | 场景 |
|---|---|---|
| 4317 | gRPC over HTTP/2 | 本条目，二进制上报，集群内常用 |
| 4318 | HTTP 与 protobuf | REST 风格上报，便于手工调试 |
| 8888 | Collector 自身指标 | 自带 metrics 端点 |
| 传输选择 | 按客户端能力 | 两端协议不匹配时连接成功但没有数据 |
部署提示：Kubernetes 场景常用 DaemonSet 搭配集群内 Service 暴露接收端口，避免直接用 NodePort 暴露到公网；升级 Collector 时留意不同大版本之间组件与配置项命名的调整。
Collector 默认不做鉴权，暴露公网会持续收到垃圾数据，既污染观测结果又消耗存储与带宽。生产环境应加双向证书或经反向代理做鉴权，并把接收端口限制在监控网段。
排查顺序：先确认端口监听与网络可达，再看数据是否进入管道（Collector 自身指标里按接收器统计的条目会增长），最后看导出端是否成功写入后端。多数上报失败其实卡在导出端而不是接收端。
选型提示：集群内上报优先用 gRPC 版本，需要经浏览器或反向代理转发时用 HTTP 版本更省事。两者可以同时开启，按客户端能力各取所需，不必强求统一。