4. Source参数配置(上):数据源类型与连接基础

Source 是 Collector 管道的入口,决定了数据从何处、以何种方式进入处理流水线。本章聚焦 Source 层的核心参数:数据源类型、连接参数、认证方式、超时与重试策略。正确配置这些参数,是管道稳定运行的前提。

4.1 数据源类型概览

Collector 支持四种主流数据源类型,每种类型对应不同的采集场景和配置范式:

类型 典型场景 数据格式 采集模式
API REST/gRPC 接口、云服务 SDK JSON / Protobuf 轮询 / Webhook 回调
DB MySQL、PostgreSQL、MongoDB 行 / 文档 / 时序 SQL 查询 / CDC 流
File 日志文件、CSV、Parquet 文本 / 二进制 Tail / 全量扫描
Stream Kafka、RabbitMQ、Pulsar 消息 / 事件 订阅 / 消费组
选型建议: 优先使用 Stream 类型处理实时事件;API 类型适合有状态查询;DB 类型适合批量 ETL;File 类型适合遗留系统日志采集。
数据源类型与采集模式关系图 数据源类型与采集模式关系 Collector Source API DB File Stream 轮询 / Webhook SQL / CDC Tail / 全量扫描 订阅 / 消费组 每种数据源类型对应不同的采集模式,Source 参数需按类型差异化配置 API 和 DB 适合有状态查询,File 和 Stream 适合无状态持续采集

4.2 连接参数配置

连接参数是 Source 与外部系统建立通信的基础。不同数据源类型的连接参数差异显著,以下列出核心字段:

4.2.1 API 类型连接参数

  • endpoint:API 基础 URL,例如 https://api.example.com/v2
  • method:HTTP 方法,支持 GET / POST / PUT
  • headers:自定义请求头,如 Content-Type、User-Agent
  • query_params:查询参数键值对
  • proxy:代理服务器地址(可选)

4.2.2 DB 类型连接参数

  • connection_string:JDBC/ODBC 连接串,例如 jdbc:mysql://host:3306/db
  • host / port / database:主机、端口、数据库名
  • ssl_mode:SSL 模式(disable / prefer / require / verify-ca / verify-full)
  • pool_size:连接池大小,默认 5

4.2.3 File 类型连接参数

  • path:文件路径或通配符,如 /var/log/app/*.log
  • encoding:文件编码,默认 UTF-8
  • file_format:格式(text / csv / json / parquet)
  • delimiter:分隔符(CSV 专用)

4.2.4 Stream 类型连接参数

  • bootstrap_servers:Kafka 集群地址列表
  • topic / queue:主题或队列名称
  • group_id:消费者组 ID
  • auto_offset_reset:偏移重置策略(earliest / latest / none)
最佳实践: 连接参数应通过环境变量或密钥管理服务注入,避免硬编码在配置文件中。对于 DB 和 Stream 类型,建议启用连接池和心跳检测。

4.3 认证方式

认证方式决定了 Source 如何安全地访问数据源。Collector 支持以下认证机制:

认证方式 适用数据源 配置示例 安全等级
Basic Auth API username:password Base64 编码 低(需配合 HTTPS)
API X-: <key> 中
OAuth2 API client_id + client_secret + endpoint 高
Username/Password DB user=admin password=**** 中(建议 SSL)
SSL/TLS 双向认证 DB / Stream cert.pem + key.pem + ca.pem 高
SASL/SCRAM Stream (Kafka) sasl.mechanism=SCRAM-SHA-256 高
文件 File / API _file=/path/to/ 中
安全警告: 禁止在配置文件中明文存储密码或密钥。推荐使用 Vault、AWS Secrets Manager 或 Kubernetes Secrets 进行密钥管理。OAuth2 的 refresh_ 应定期轮换。

4.4 超时与重试策略

超时和重试是保障 Source 健壮性的关键参数。配置不当会导致管道阻塞或数据丢失。

4.4.1 超时参数

参数名 默认值 说明 调优建议
connect_timeout 10s 建立 TCP 连接的超时时间 内网 5s,公网 15s
read_timeout 30s 等待数据响应的超时时间 API 按 P99 响应时间 × 2
write_timeout 30s 发送请求的超时时间 大文件上传需适当增加
idle_timeout 60s 连接空闲超时(仅 Stream/DB) 小于 LB 的空闲超时

4.4.2 重试策略

重试策略采用指数退避 + 抖动算法,避免重试风暴:

# 重试策略配置示例
retry:
  max_attempts: 3
  initial_interval: 1s
  multiplier: 2.0
  max_interval: 30s
  jitter: 0.1
  retryable_codes: [429, 500, 502, 503, 504]
  • max_attempts:最大重试次数,默认 3,建议不超过 5
  • initial_interval:首次重试等待时间,默认 1s
  • multiplier:退避倍数,默认 2.0
  • max_interval:最大等待时间,默认 30s
  • jitter:随机抖动因子(0~1),防止惊群效应
  • retryable_codes:可重试的 HTTP 状态码或错误码
重试避坑: 4xx 错误(除 429 外)通常不应重试;幂等性 API 可安全重试,非幂等操作需谨慎。对于 DB 连接,重试前应检查连接有效性。
超时与重试策略流程图 超时与重试策略执行流程 发起 Source 请求 超时检查 成功 → 返回数据 失败 / 超时 重试次数 < max_attempts? 指数退避 + 抖动 放弃 → 记录错误 超时触发重试,重试采用指数退避 + 抖动,避免重试风暴

4.5 参数配置综合示例

以下是一个完整的 API 类型 Source 配置示例,涵盖连接、认证、超时和重试:

source:
  type: api
  name: "prometheus-metrics-source"
  endpoint: "https://prometheus.example.com/api/v1/query"
  method: GET
  headers:
    Content-Type: application/json
    Accept: application/json
  auth:
    type: oauth2
    client_id: "${CLIENT_ID}"
    client_secret: "${CLIENT_SECRET}"
    _url: "https://auth.example.com/oauth/"
    scopes: ["metrics:read"]
  timeout:
    connect_timeout: 10s
    read_timeout: 30s
    write_timeout: 15s
  retry:
    max_attempts: 3
    initial_interval: 1s
    multiplier: 2.0
    max_interval: 30s
    jitter: 0.1
    retryable_codes: [429, 500, 502, 503, 504]
关键检查清单:
  • 确认 endpoint 可达且返回预期格式
  • 验证认证凭据未过期且权限最小化
  • 超时时间应大于数据源 P99 响应时间
  • 重试次数不宜过多,避免下游压力
  • 生产环境启用连接池和心跳检测