4. 数据采集技术

数据采集是远程监控运维的“入口”。采集方式选错，后续的告警、容量分析、故障定位都会建立在不可靠的数据之上。本节围绕六类常见采集技术展开：主机 Agent、SNMP、IPMI、日志采集、API 拉取与流式采集。理解它们的差异，关键不是记住名词，而是判断三件事：数据源在哪里、数据以什么形态产生、采集对时效性和侵入性的要求有多高。

一、六类采集技术的定位与适用场景

主机 Agent 是部署在被监控主机上的常驻进程，直接读取操作系统内核、进程、文件系统、网络栈等本地信息。它适合采集 CPU 使用率、内存、磁盘 IO、进程状态、端口监听、文件句柄等细粒度指标，也能执行本地脚本做自定义采集。优点是数据维度丰富、采样频率可控、可做本地聚合；代价是需要安装、升级、维护，且对主机有资源占用和权限要求。典型场景是业务服务器、数据库主机的深度指标监控。

SNMP 面向网络设备与支持该协议的服务器、打印机、UPS。它通过 MIB 定义对象，用 OID 寻址，管理站以 GET/GETNEXT/GETBULK 轮询，设备也可通过 Trap 主动上报。SNMP 适合交换机端口流量、错包、设备温度、电源状态等。部署要点是统一 SNMP 版本（v2c 简单但明文，v3 支持认证加密）、规划团体名或用户、控制轮询周期与并发，避免大量 GETBULK 压垮设备管理面。

IPMI 走带外管理通道，通过 BMC 独立于操作系统获取服务器电源、风扇、温度、电压、硬盘背板等硬件健康数据，并支持远程开关机、重启、挂载虚拟介质。它的价值在于“操作系统宕机仍可采集”，适合物理服务器硬件监控和远程带外处置。部署时要规划 BMC 管理网段、独立于业务网络、修改默认口令、限制访问来源，并注意 IPMI 1.5/2.0 与 RMCP+ 的兼容性。

日志采集 处理的是文本事件流，典型工具是 Filebeat、Fluent Bit、rsyslog 等。它关注的是“发生了什么”，适合错误堆栈、访问日志、审计记录、业务埋点。部署要点包括：明确采集路径与轮转策略、处理多行日志（如 Java 异常栈）、设置背压与磁盘缓冲、做字段解析与脱敏。日志量通常远大于指标量，必须评估带宽、存储与索引成本。

API 拉取 适用于云平台、Kubernetes、中间件、SaaS 服务等暴露 HTTP 接口的系统。采集器按固定周期调用 REST/GraphQL 接口，拉取实例列表、健康状态、配额、任务进度等。它无需在被采对象上安装组件，但受接口限流、分页、鉴权令牌有效期影响。部署时要处理令牌刷新、分页遍历、失败重试与退避，并避免在业务高峰集中拉取。

流式采集 指数据源主动推送、采集端持续消费的模式，如 Kafka、MQTT、gRPC Stream、WebSocket、OpenTelemetry 的 OTLP 推送。它延迟低、吞吐高，适合高频指标、链路追踪、实时风控与大规模日志。部署要点是消费组与分区规划、断点续传、消息积压监控、端到端延迟观测，以及采集端自身的水平扩展能力。

二、部署要点与常见误区

部署 Agent 时，重点不是“装上就行”，而是控制资源占用与采集范围。建议为 Agent 设置 CPU 与内存上限，明确采集项白名单，避免全量采集磁盘每个分区、每个进程。升级要支持灰度与回滚，否则一次批量升级可能造成大面积数据中断。对于容器环境，Agent 通常以 DaemonSet 形式运行，需注意宿主机路径挂载与权限。

SNMP 部署最常见的误区是“轮询过密”。一台交换机若被多个管理站以 30 秒周期做全表 GETBULK，管理 CPU 会明显升高，甚至影响转发。合理做法是区分核心指标与次要指标，核心指标 60 秒、次要指标 5 分钟，并对同一设备串行轮询。Trap 接收端要能处理风暴，建议做去重与限速。

IPMI 的关键是网络隔离。BMC 管理口应放在独立管理 VLAN，只允许采集服务器与运维跳板访问，禁止暴露到互联网。采集时优先使用 IPMI 2.0 的 RMCP+ 与加密认证，避免使用默认账号。若服务器支持 Redfish，可优先用 Redfish 替代部分 IPMI 采集，接口更规范、返回 JSON 更易解析。

日志采集要解决“多行”和“背压”两个问题。以 Java 异常为例，一条异常包含多行堆栈，若按行采集会被拆散。Filebeat 可用 multiline 配置按时间戳或异常关键字合并。背压方面，当后端不可用时，采集端应写入本地磁盘缓冲并限速，而不是无限占用内存。示例配置片段如下：

filebeat.inputs:
- type: filestream
  paths: [/var/log/app/*.log]
  parsers:
    - multiline:
        type: pattern
        pattern: '^\d{4}-\d{2}-\d{2}'
        negate: true
        match: after
output.elasticsearch:
  hosts: ["http://10.0.20.11:9200"]
  bulk_max_size: 800
queue.mem:
  events: 4096
  flush.min_events: 512
  flush.timeout: 5s

API 拉取要处理鉴权与分页。以 Kubernetes 为例，采集器通过 ServiceAccount 获取 Token，调用 /api/v1/nodes 与 /apis/metrics.k8s.io/v1beta1/nodes 获取节点与指标。若接口返回 continue 字段，必须循环拉取直到为空。遇到 429 限流应指数退避，避免重试风暴。令牌过期要自动重新读取，而不是等采集失败告警。

流式采集的部署核心是“可恢复”。Kafka 消费要记录 offset，MQTT 要使用 QoS 1 并持久化会话，gRPC Stream 要设计重连与断点。采集端要监控消费延迟（Lag），当 Lag 持续增长说明消费能力不足，需要增加分区或消费者实例。流式链路还要关注端到端延迟，从数据产生到可查询的时间应作为 SLO 指标。

三、选型决策与组合策略

实际生产环境很少只用一种采集方式。典型组合是：业务主机用 Agent 采指标、Filebeat 采日志；网络设备用 SNMP；物理服务器用 IPMI 或 Redfish 采硬件；云资源用 API 拉取；高频事件与 Trace 用流式采集。选型时按以下顺序判断：数据源是否支持标准协议、能否安装组件、时效性要求、网络与安全边界、采集健康度是否可观测。

最后强调一个判断原则：采集方式的选择由数据源和运维目标共同决定，而不是由工具偏好决定。先明确要回答什么问题——是看趋势、查故障、做审计还是做实时风控——再反推需要什么数据、以什么频率、从哪个通道获取。采集链路一旦建立，就要把采集器自身当作生产系统来运维，保证数据“采得到、传得稳、查得快”。