OTLP HTTP 接收口
OpenTelemetry Collector 的 OTLP/HTTP 接收端口：应用把 traces、metrics、logs 通过 HTTP POST 发到 4318（默认路径 /v1/traces 等），对应的 gRPC 端口是 4317。浏览器与前端 SDK 只能走 HTTP，因此 4318 常被暴露在更靠外的位置。
基本信息
| 服务 | OpenTelemetry Collector（otlp receiver） |
|---|---|
| 协议 | TCP/HTTP（protobuf 或 JSON） |
| 默认端口 | 4318（gRPC 4317） |
| 默认路径 | /v1/traces、/v1/metrics、/v1/logs |
| 暴露面 | 仅采集网段，公网需网关鉴权 |
典型使用场景
- 后端服务上报链路追踪数据
- 前端与浏览器 SDK 上报遥测
- 日志与指标统一经 OTLP 汇聚
- 灰度对比两套采集配置
- 自建 Collector 时核对两个协议是否都在监听
接收端核对
接收端核对
ss -lntp | grep -E '431[78]'
curl -i http://collector01:4318/v1/traces -H 'Content-Type: application/json' -d '{}'
# Collector 配置:
# protocols:
# http: {endpoint: 0.0.0.0:4318}
# grpc: {endpoint: 0.0.0.0:4317}排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 监听 | ss -lntp | grep -E '431[78]' | 只有 4317：用 HTTP 上报的 SDK 全部失败 |
| 路径 | POST 到 /v1/traces | 返回 404：路径拼错或只开了另一协议 |
| 编码 | Content-Type 与实际编码 | 报不支持的格式：protobuf 与 JSON 混用 |
| 边界 | 公网可达性与鉴权配置 | 公网可写：可注入伪造遥测数据 |
otlp 接收器默认同时开 4317 与 4318；前端与浏览器场景只能用 4318，这让它经常被放到更靠外的位置，因此限流与鉴权要按公网服务的标准来配。
写入口的安全边界
遥测接收端本质是一个写入接口：不加限制时攻击者可以注入大量伪造数据，既污染监控与告警，也能把存储与后端查询打满。生产上应限制来源、设置请求体大小与速率上限，并在网关层做鉴权。
上报端与接收端的协议要一致：gRPC 客户端连 HTTP 端口会一直失败，HTTP 客户端连 gRPC 端口同样不通。排查时先确认 SDK 配置里的协议与端口是否匹配。
把 4318 裸放公网收数据：任何人都能注入伪造遥测，把监控后端当成写入型存储攻击。
接收端与后端存储的容量要匹配：采集量上涨时先看接收端的队列与丢弃计数，再看存储写入速率，否则容易把后端压力误判成网络问题。
在 K8s 里接收端常以 DaemonSet 或 Deployment 暴露，注意 Service 的端口映射与探针配置：探针路径写错时 Pod 反复重启，现象很像接收端崩溃。