📚 课程目录第3章 Beats采集层架构与部署规划

3. Beats采集层架构与部署规划

Beats 是 Elastic 官方提供的一组轻量级数据采集器，运行在被观测主机或边缘节点上，负责把日志、指标、可用性探测和审计事件推送到 Elasticsearch 或 Logstash。它并不是一个单一程序，而是共享同一套底层框架（libbeat）的采集器家族。理解每个 Beat 的职责边界，是设计采集层拓扑和做资源规划的前提。

四类 Beat 的功能定位

Filebeat 面向日志与文本文件。它通过 prospector（新版称 input）发现文件，用 harvester 逐行读取，并借助 registry 文件记录每个文件的读取偏移量，从而在重启后实现断点续传。Filebeat 支持多行合并、JSON 解码、字段裁剪和条件过滤，是日志采集的主力。

Metricbeat 面向周期性指标。它由 module 与 metricset 组成：module 对应一类系统或服务（如 system、nginx、mysql），metricset 对应一组具体指标（如 cpu、memory、filesystem）。Metricbeat 按 period 周期拉取或读取指标，适合主机资源、中间件和云服务的监控。

Heartbeat 面向可用性探测。它通过 ICMP、TCP 或 HTTP 对目标发起主动探测，输出 up/down 状态、响应时间和状态码，用于合成监控（Synthetic Monitoring）和外部服务可用性判断。

Auditbeat 面向安全审计。它包含 auditd 模块（采集 Linux 系统调用审计事件）和 file_integrity 模块（监控文件哈希与属性变化），用于主机入侵检测和合规审计。

采集器配置的核心结构

所有 Beat 共享一套配置文件骨架，通常位于 /etc/<beat>/<beat>.yml。关键配置块包括：inputs（或旧版 filebeat.inputs）、modules、processors、output、queue 和 logging。以 Filebeat 采集 Nginx 日志为例：

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

processors:
  - add_host_metadata: ~
  - drop_fields:
      fields: ["agent.ephemeral_id", "ecs.version"]

output.elasticsearch:
  hosts: ["https://es-node1:9200"]
  username: "beats_writer"
  password: "${ES_PWD}"
  index: "filebeat-%{[agent.version]}-%{+yyyy.MM.dd}"

queue.mem:
  events: 4096
  flush.min_events: 512
  flush.timeout: 5s

这里 filestream 是 Filebeat 7.16 之后推荐的输入类型，替代了旧的 log 输入。fields_under_root: true 让自定义字段直接位于事件顶层，便于后续在 Kibana 中过滤。queue.mem 控制内存队列容量，当输出端短暂不可用时，队列起到缓冲作用。

模块启用与指标采集

Metricbeat 的模块机制大幅简化了配置。启用 Nginx 模块只需执行：

metricbeat modules enable nginx
metricbeat modules list

随后编辑 modules.d/nginx.yml，指定 period 和 hosts：

- module: nginx
  metricsets: ["stubstatus"]
  period: 10s
  hosts: ["http://127.0.0.1:80"]
  server_status_path: "nginx_status"

Heartbeat 的配置则围绕 monitor 展开，每个 monitor 定义一种探测类型和目标：

heartbeat.monitors:
- type: http
  id: api-health
  name: "API Health Check"
  urls: ["https://api.example.com/health"]
  schedule: "@every 30s"
  timeout: 5s
  check.response.status: [200]

Auditbeat 的 file_integrity 模块适合监控关键目录：

- module: file_integrity
  paths:
    - /etc
    - /usr/bin
    - /usr/sbin
  scan_at_start: true
  scan_rate_per_sec: 50 MiB

部署拓扑与资源规划

采集层部署有两种典型模式：集中式与分布式。集中式在少量跳板机上统一采集远端日志（通过 NFS 或 syslog 汇聚），适合中小规模；分布式在每台业务主机上部署对应 Beat，扩展性好但需管理更多 agent。实际生产中常采用混合模式：Filebeat 随应用容器以 sidecar 或 DaemonSet 方式部署，Metricbeat 以 DaemonSet 覆盖所有节点，Heartbeat 集中部署在少数探测节点，Auditbeat 仅部署在需要合规审计的关键主机。

资源规划需要关注三个维度：CPU、内存和磁盘 I/O。Filebeat 的 CPU 开销主要来自多行合并和 JSON 解析，若日志量大且开启复杂 processor，单实例可能占用 0.5 核以上。Metricbeat 的开销与 period 成反比，10s 周期比 60s 周期约多消耗 3~5 倍 CPU。Heartbeat 的 ICMP 探测需要 root 权限或 cap_net_raw 能力，容器化部署时需显式声明。Auditbeat 的 auditd 模块在高频系统调用场景下可能产生大量事件，建议先用 auditctl 规则收敛范围。

在 Kubernetes 中，建议为每个 Beat 设置 resources.requests 和 resources.limits，例如 Filebeat 请求 100m CPU / 100Mi 内存，限制 500m CPU / 300Mi 内存，避免采集器与业务容器争抢资源。

采集器选型对照

采集器	数据类型	采集方式	典型模块/输入	资源敏感点
Filebeat	日志、文本	被动读取文件	filestream、log	多行合并、JSON 解析
Metricbeat	指标	周期拉取/读取	system、nginx、mysql	period 频率、metricset 数量
Heartbeat	可用性状态	主动探测	icmp、tcp、http	探测频率、目标数量
Auditbeat	审计事件	内核审计/文件扫描	auditd、file_integrity	系统调用频率、扫描速率

选型的基本原则是：日志用 Filebeat，指标用 Metricbeat，外部可用性用 Heartbeat，安全审计用 Auditbeat。四者可以共存于同一主机，但需注意端口、registry 文件和日志目录的隔离。部署前建议先用 ./filebeat test config 和 ./metricbeat test output 验证配置与连通性，再通过 systemctl start 启动服务，最后在 Kibana 的 Discover 中确认数据是否按预期索引写入。