📚 课程目录第3章数据采集层设计

3. 数据采集层设计

数据采集层是可观测性平台的第一道关口，它决定了后续存储、检索与告警能否拿到“干净、完整、带上下文”的原始信号。在 Elastic 生态中，采集侧主要有两条技术路线：以 Filebeat、Metricbeat 为代表的 Beats 家族，以及统一代理 Elastic Agent。二者并非简单的“新旧替代”关系，选型要结合采集对象、管理规模与运维能力来判断。

一、Beats 与 Elastic Agent 的选型对比

Beats 是轻量级单用途采集器：Filebeat 负责日志文件，Metricbeat 负责系统与中间件指标，Packetbeat 负责网络流量，Winlogbeat 负责 Windows 事件日志。每个 Beat 独立安装、独立配置、独立升级，进程职责单一，资源占用可预测。Elastic Agent 则是“一个代理 + 多种集成（Integration）”的模型，通过 Fleet 集中下发策略，一个 Agent 进程即可同时采集日志、指标、追踪与安全数据，并内置与 Elasticsearch、Kibana 的策略通道。

选型时可从四个维度判断：采集对象——若只需采集 Nginx 日志，Filebeat 足够；若同时要日志、主机指标、容器指标与集成仪表盘，Agent 更省事。管理规模——几十台主机手工维护 Beats 配置尚可接受，上百台以上则 Fleet 的集中策略下发优势明显。网络与合规——Agent 需要与 Fleet Server 保持策略通信，隔离网络需额外规划；Beats 只需能连到 Elasticsearch 或 Logstash。升级与回滚——Agent 支持策略级升级，Beats 需逐台或借助配置管理工具。

经验法则：采集对象单一、主机数量少、网络受限时优先 Beats；采集对象多样、主机规模大、希望统一策略与开箱仪表盘时优先 Elastic Agent。二者也可共存，例如用 Agent 采集主机与容器，用独立 Filebeat 采集特殊路径日志。

二、模块化采集配置

无论选哪种采集器，配置都应遵循“模块化”原则：把输入、处理、输出三段解耦，按数据源拆分为可独立启停的模块，避免一个巨型配置文件牵一发动全身。

以 Filebeat 采集 Nginx 访问日志为例，模块化配置可拆为 inputs、processors、output 三部分。inputs 定义采集路径与多行合并规则；processors 负责解析、丢弃、补充字段；output 指向 Elasticsearch 或 Logstash。下面是一个可直接参考的示例（参数为教学示例，非实测值）：

filebeat.inputs:
- type: filestream
  id: nginx-access
  enabled: true
  paths:
    - /var/log/nginx/access.log
  fields:
    env: prod
    service: nginx
  fields_under_root: true

processors:
- dissect:
    tokenizer: "%{client_ip} - - [%{timestamp}] \"%{method} %{url} HTTP/%{http_version}\" %{status} %{bytes}"
    field: "message"
    target_prefix: "nginx"
- drop_event.when.equals:
    nginx.status: "304"

output.elasticsearch:
  hosts: ["https://es-prod:9200"]
  index: "nginx-%{[env]}-%{+yyyy.MM.dd}"

模块化的关键点有三：一是用 fields 注入 env、service 等环境与业务标签，让后续检索能按环境和服务过滤；二是用 dissect 或 grok 在采集侧完成结构化，减少入库后的解析开销；三是用 drop_event 过滤无价值事件（如 304 响应），降低存储与传输成本。Elastic Agent 的集成配置同样遵循这一思路，只是把 inputs/processors 封装在集成策略中，通过 Fleet 的变量（如 ${host.name}、自定义 env 变量）实现差异化。

三、多环境部署策略

多环境（开发、测试、生产）部署的核心是“配置同源、参数分离”。推荐做法是：采集配置模板统一维护，环境差异通过变量注入，而不是复制三份配置各自修改。

对 Beats，可用环境变量或配置管理工具（Ansible、SaltStack）在部署时替换 env、Elasticsearch 地址、证书路径等参数。对 Elastic Agent，Fleet 支持按 Agent Policy 划分环境，每个 Policy 绑定不同的集成变量与输出地址，Agent 通过标签（如 env:prod）自动匹配策略。

索引命名要体现环境隔离，例如 logs-nginx.prod-2025.06.01 与 logs-nginx.dev-2025.06.01，配合 Kibana 空间或索引模式实现权限与视图隔离。生产环境还应考虑：采集器资源限制（CPU/内存）、日志轮转与文件句柄、TLS 证书校验、以及采集端到输出端的背压处理。若使用 Logstash 作为缓冲层，可在采集器 output 中配置 bulk_max_size 与重试策略，避免 Elasticsearch 抖动导致数据丢失。

四、常见采集故障排查

采集故障通常表现为“Kibana 里看不到数据”或“数据不完整”。排查应沿着“采集器是否运行 → 文件是否被读取 → 事件是否被处理 → 是否成功写出”这条链路逐段确认。

第一类：采集器未启动或配置错误。用 systemctl status filebeat 或 elastic-agent status 查看进程状态；用 filebeat test config 与 filebeat test output 验证配置与连通性。第二类：文件未被采集。检查 paths 是否匹配、文件权限是否可读、filestream 的 id 是否重复、registry 文件是否记录了错误偏移。第三类：解析失败。若 dissect 的 tokenizer 与实际日志格式不一致，字段会解析为空，可在 processors 后加 on_failure 分支记录原始消息。第四类：输出失败。查看采集器日志中的 connection refused、certificate signed by unknown authority、429 Too Many Requests 等关键字，分别对应网络、证书、限流问题。

排查时建议先看采集器自身日志，再看 Elasticsearch 端索引与集群健康，最后回到数据源确认文件是否在持续写入。若日志中出现 Harvester could not be started，通常是文件权限或路径问题；出现 Failed to publish events，则优先检查输出端连通性与限流。对 Elastic Agent，还要确认 Fleet Server 可达、Agent 策略状态为 Healthy，否则集成配置不会生效。

采集侧最常见的“隐形故障”是 registry 文件损坏或偏移错乱，导致重启后重复采集或漏采。生产环境应定期备份 registry，并在升级前停止采集器，避免文件句柄与偏移状态不一致。

把选型、模块化配置、多环境策略与故障排查串起来看，采集层设计的本质是：用合适的采集器把正确的数据，以可管理、可隔离、可恢复的方式送到后端。选型决定运维复杂度，模块化决定可维护性，多环境策略决定隔离与安全，而排查能力决定故障恢复速度。四者共同构成采集层的工程闭环。