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 场景。
OTLP Receiver 数据流架构 OTLP Receiver 数据流架构 Java SDK Go SDK Python SDK 其他 Collector OTLP Receiver gRPC :4317 HTTP :4318 Traces Metrics Logs 统一协议入口 Pipeline Processor Exporter → 后端存储 SLI 口径数据 持久化 说明:OTLP Receiver 作为统一入口,接收多语言 SDK 和上游 Collector 的三种信号,是构建 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 和告警规则。
Prometheus Receiver 拉模式采集流程 Prometheus Receiver 拉模式采集流程 Prometheus Receiver scrape_interval: 30s scrape_timeout: 10s 服务发现 → 目标列表 拉模式调度器 Node Exporter :9100/metrics Redis Exporter :9121/metrics Kubelet :10250/metrics 采集的指标数据 node_cpu_seconds_total redis_connected_clients kubelet_pod_operations → Processor / Exporter 说明:Prometheus Receiver 通过拉模式定期抓取目标端点,适合基础设施和中间件 SLI 指标采集,需合理配置间隔与超时

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,应配合 kubeletstats Receiver 或 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 口径数据的全栈覆盖。