4. Receiver 配置基础:OTLP Receiver、Prometheus Receiver、Host Metrics Receiver 的配置与适用场景
Receiver 是 OpenTelemetry Collector 数据管道的入口,负责接收来自各类数据源的遥测信号。不同的 Receiver 决定了数据采集的协议、格式和适用场景,直接影响 SLI 口径数据的覆盖范围与采集质量。本章聚焦三种最核心的 Receiver:OTLP Receiver、Prometheus Receiver 和 Host Metrics Receiver,从配置语法、参数含义到适用场景进行系统讲解。
4.1 OTLP Receiver:统一协议入口
OTLP Receiver 是 OpenTelemetry 的原生协议接收器,支持 gRPC 和 HTTP 两种传输方式,能够接收来自任何 OTLP 兼容客户端(如 SDK、其他 Collector、Instrumentation Library)的 traces、metrics 和 logs。它是构建统一可观测性数据面的核心组件。
4.1.1 配置示例与参数解析
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
max_recv_msg_size_mib: 4
max_concurrent_streams: 100
tls:
cert_file: /etc/ssl/certs/collector.crt
key_file: /etc/ssl/private/collector.key
http:
endpoint: 0.0.0.0:4318
cors:
allowed_origins:
- "https://app.example.com"
allowed_headers:
- "content-type"
max_recv_msg_size_mib: 2
| 参数 | 默认值 | 说明 | 对 SLI 采集的影响 |
|---|---|---|---|
endpoint |
0.0.0.0:4317 (gRPC)0.0.0.0:4318 (HTTP) |
监听地址与端口 | 端口冲突或防火墙未放行将导致数据丢失,直接影响 SLI 数据完整性 |
max_recv_msg_size_mib |
4 (gRPC) / 2 (HTTP) | 单条消息最大接收尺寸(MiB) | 过小会导致大尺寸指标批次被截断或拒绝,造成 SLI 数据缺失 |
max_concurrent_streams |
100 | gRPC 最大并发流数 | 高并发场景下若设置过小,客户端连接将被限流,影响采集时效性 |
tls |
无 | TLS 证书与密钥配置 | 生产环境必须启用,否则数据明文传输存在安全风险 |
cors |
无 | HTTP 跨域配置 | 浏览器端采集器(如 Web SDK)需要正确配置,否则跨域请求被拦截 |
最佳实践:在 SLI 口径数据采集场景中,建议将
max_recv_msg_size_mib 设置为 8-16 MiB,以容纳包含大量时间序列的指标批次。同时启用 gRPC 的 keepalive 参数,防止长连接因空闲被中间件断开。
4.1.2 适用场景
- 多语言应用接入:Java、Go、Python、Node.js 等 SDK 原生支持 OTLP,适合异构微服务架构的统一数据采集。
- Collector 级联部署:作为上游 Collector 的出口协议,将数据转发至中心 Collector 或后端。
- 高精度 SLI 数据:OTLP 支持 Delta 时间戳和 Explicit Histogram,适合需要精确延迟分布和计数器的 SLI 场景。
4.2 Prometheus Receiver:拉模式指标采集
Prometheus Receiver 采用经典的拉(Pull)模式,定期从配置的目标端点抓取 Prometheus 格式的指标数据。它兼容 Prometheus 生态的 Exporter 和直接暴露 /metrics 端点的应用,是采集基础设施和中间件指标的首选方式。
4.2.1 配置示例与参数解析
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'kubernetes-pods'
scrape_interval: 30s
scrape_timeout: 10s
metrics_path: /metrics
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app]
regex: my-service
action: keep
- job_name: 'node-exporter'
scrape_interval: 15s
static_configs:
- targets: ['localhost:9100']
labels:
env: production
| 参数 | 默认值 | 说明 | 对 SLI 采集的影响 |
|---|---|---|---|
scrape_interval |
60s | 抓取周期 | 间隔过长会导致 SLI 数据粒度变粗,无法捕捉短时抖动;过短则增加目标负载 |
scrape_timeout |
10s | 单次抓取超时时间 | 超时设置应小于 scrape_interval,否则累积超时导致数据空洞 |
metrics_path |
/metrics |
指标暴露路径 | 自定义路径需与目标应用一致,否则抓取失败 |
kubernetes_sd_configs |
无 | Kubernetes 服务发现配置 | 动态环境必须配置,否则新 Pod 无法自动纳入采集范围 |
relabel_configs |
无 | 标签重写规则 | 用于过滤和丰富指标标签,直接影响 SLI 口径的维度准确性 |
注意:Prometheus Receiver 在 Collector 中属于有状态组件。当 Collector 重启或扩缩容时,抓取状态会丢失,可能导致指标重复或遗漏。对于 SLI 口径数据,建议配合
batch Processor 和幂等性 Exporter 使用,以降低数据不一致风险。
4.2.2 适用场景
- 基础设施监控:Node Exporter、Kubelet、cAdvisor 等系统级指标采集。
- 中间件与数据库:Redis Exporter、MySQL Exporter、Nginx Exporter 等。
- Kubernetes 环境:利用服务发现自动抓取 Pod 和 Service 的指标,适合容器化 SLI 数据采集。
- 已有 Prometheus 生态:无需改造应用,直接复用现有 Exporter 和告警规则。
4.3 Host Metrics Receiver:主机级零配置采集
Host Metrics Receiver 是 Collector 内置的主机指标采集器,无需外部依赖即可从操作系统获取 CPU、内存、磁盘、网络等基础指标。它适用于快速搭建主机级 SLI 监控,特别适合边缘节点和轻量级部署场景。
4.3.1 配置示例与参数解析
receivers:
hostmetrics:
collection_interval: 60s
scrapers:
cpu:
metrics:
system.cpu.utilization:
enabled: true
memory:
metrics:
system.memory.usage:
enabled: true
disk:
metrics:
system.disk.io:
enabled: true
network:
metrics:
system.network.io:
enabled: true
load:
metrics:
system.cpu.load_average.1m:
enabled: true
filesystem:
metrics:
system.filesystem.usage:
enabled: true
paging:
enabled: false
processes:
enabled: false
| Scraper | 默认启用 | 采集指标示例 | SLI 相关性 |
|---|---|---|---|
cpu |
是 | system.cpu.utilization, system.cpu.time |
高:CPU 饱和直接影响请求延迟和错误率 |
memory |
是 | system.memory.usage, system.memory.utilization |
高:内存不足导致 OOM 和请求失败 |
disk |
是 | system.disk.io, system.disk.operations |
中:磁盘 I/O 瓶颈影响数据密集型服务 |
network |
是 | system.network.io, system.network.errors |
中:网络错误可能导致连接超时 |
load |
是 | system.cpu.load_average.1m |
高:负载趋势反映系统整体压力 |
filesystem |
是 | system.filesystem.usage |
中:磁盘满导致写入失败 |
paging |
否 | system.paging.usage |
低:仅在内存压力分析时启用 |
processes |
否 | system.processes.count |
低:进程数异常可能暗示故障 |
关键配置建议:
collection_interval建议设置为 30-60s,与 SLI 的评估窗口(如 1 分钟、5 分钟)对齐。- 按需启用 scraper,避免采集无用指标增加 Collector 内存开销。
- 在容器环境中,Host Metrics Receiver 采集的是宿主机指标,而非容器指标。如需容器级 SLI,应配合
kubeletstatsReceiver 或 Prometheus Receiver 使用。
4.3.2 适用场景
- 裸机/VM 主机监控:快速获取操作系统基础指标,无需安装 Agent 或 Exporter。
- 边缘节点:资源受限环境下的轻量级采集方案。
- 故障排查辅助:作为 SLI 数据降噪的上下文指标,帮助定位根因。
- 快速原型验证:在 Collector 部署初期快速建立主机级可观测性基线。
4.4 三种 Receiver 对比与选型建议
| 维度 | OTLP Receiver | Prometheus Receiver | Host Metrics Receiver |
|---|---|---|---|
| 数据来源 | OTLP 协议客户端 | Prometheus /metrics 端点 | 操作系统内核接口 |
| 采集模式 | 推(Push) | 拉(Pull) | 拉(Pull,内部) |
| 信号类型 | Traces + Metrics + Logs | 仅 Metrics | 仅 Metrics |
| 外部依赖 | 无 | 目标端点需暴露 /metrics | 无 |
| 配置复杂度 | 低 | 中(服务发现、relabel) | 极低 |
| 适用 SLI 类型 | 应用级(延迟、错误率、吞吐量) | 基础设施级(CPU、内存、磁盘) | 主机级(系统资源利用率) |
| 推荐场景 | 微服务、自定义应用 | Kubernetes、中间件、Exporter 生态 | 裸机、VM、边缘节点 |
选型口诀:应用指标用 OTLP,基础设施用 Prometheus,主机基线用 Host Metrics。三者可同时启用,通过 Pipeline 路由至不同 Processor 和 Exporter,实现 SLI 口径数据的全栈覆盖。