在日志管理领域，Filebeat 因其轻量高效而广受青睐，但许多用户对其功能定位存在一个普遍误解：将其视为日志“归档”工具。实际上，Filebeat 的核心设计专注于实时采集与高效转发。至于日志的长期存储、生命周期管理、冷热数据分层以及最终清理等“重量级”任务，则应由后端存储系统来承担。

那么，实现高效日志归档的正确路径是什么？关键在于清晰的架构分工。本文将深入解析几种主流的日志归档实践方案，帮助您构建清晰、可持续的日志管理体系。

核心原则：明确边界，各司其职

首要原则是明确 Filebeat 的能力边界：它本身不具备长期存储与归档功能。其标准工作流程是将日志实时推送至 Elasticsearch 或 Logstash 等后端系统。真正的归档策略、索引滚动与数据删除，均在后端完成。若需在采集服务器本地保留日志，通常指的是管理 Filebeat 自身的运行日志，此时可借助系统级的 logrotate 工具或 Filebeat 内置的日志轮转功能。

方案一：利用 Elasticsearch ILM 实现全自动管理

这是当前最主流且省心的方案。当日志写入 Elasticsearch 后，可借助其内置的索引生命周期管理（ILM）功能，实现从热数据到冷数据直至删除的全自动化管理。

适用场景：日志直接或经 Logstash 处理后写入 Elasticsearch，并需要基于时间或索引容量进行自动化生命周期管理。

关键实施步骤：

1. 创建 ILM 策略：在 Elasticsearch 中定义策略，规划日志索引的完整生命周期。例如，设置热阶段（hot phase）在达到 50GB 或 7 天后触发滚动，并在 30 天后自动删除。

   PUT _ilm/policy/logstash-policy
   {
     "policy": {
       "phases": {
         "hot": {
           "actions": {
             "rollover": {
               "max_size": "50gb",
               "max_age": "7d"
             }
           }
         },
         "delete": {
           "min_age": "30d",
           "actions": { "delete": {} }
         }
       }
     }
   }

2. 创建索引模板并关联策略：创建一个索引模板，匹配 Filebeat 写入的索引模式（如 filebeat-*），并将上述 ILM 策略与之绑定。

   PUT _template/logstash-template
   {
     "index_patterns": ["filebeat-*"],
     "settings": {
       "number_of_shards": 1,
       "number_of_replicas": 1,
       "index.lifecycle.name": "logstash-policy"
     }
   }

3. 配置 Filebeat 按日期生成索引：在 Filebeat 输出配置中，指定写入 Elasticsearch 的索引名称模式。为配合 ILM，建议写入到一个“写入别名”，并由 ILM 管理实际滚动生成的、按日期命名的索引。

   output.elasticsearch:
     hosts: ["localhost:9200"]
     index: "filebeat-%{[agent.version]}-%{+yyyy.MM.dd}"

4. 自动化运维：完成配置后，ILM 将在后台自动执行索引的滚动、转冷与清理，彻底解放双手，无需再手动管理历史索引。

方案二：通过 Logstash 中转，实现灵活归档

如果日志处理流程需要更复杂的解析、过滤、字段富化或数据分流，Logstash 是理想的中间处理节点。

适用场景：日志需经 Logstash 进行深度处理后再存入 Elasticsearch，或需要分流至其他存储系统（如 HDFS、Amazon S3 等对象存储）进行长期归档。

配置核心：

• Filebeat 输出至 Logstash：配置 Filebeat 将日志发送到 Logstash 的 Beats 输入端口。

  output.logstash:
    hosts: ["localhost:5044"]

• Logstash 下游处理与归档：在 Logstash 管道中，您可以：
  • 使用 Elasticsearch 输出插件，并同样通过索引模板绑定 ILM 策略，实现自动化管理。
  • 使用 S3 输出插件等，将处理后的日志直接写入对象存储，实现低成本长期归档。
  此方案将归档策略的决策与执行置于 Logstash 或更下游的存储层，Filebeat 则持续专注于其核心的数据采集与转发职责。

方案三：本地日志的轮转与保留策略

此部分主要探讨两种需要在本地保留日志的情况：一是被采集的原始业务日志文件，二是 Filebeat 自身的运行日志。

• 业务日志轮转（应用侧控制）：此为最佳实践。应由生成日志的应用程序（如使用 Logback、Log4j2）或操作系统，依据时间或文件大小自动滚动日志文件（例如每日切割或达到 1GB 后新建）。Filebeat 会持续监控日志目录，自动发现并采集新文件，无需在其配置中额外处理轮转。
• Filebeat 运行日志轮转（系统级管理）：对于 Filebeat 在 /var/log/filebeat/ 目录下生成的运行日志，推荐使用 Linux 系统自带的 logrotate 工具进行管理。示例如下：

  /var/log/filebeat/*.log {
      daily
      rotate 7
      compress
      missingok
      notifempty
      create 640 root adm
      postrotate
          kill -USR1 $(cat /var/run/filebeat/filebeat.pid) # 通知Filebeat重新打开日志文件
      endscript
  }

• Filebeat 内置日志轮转（备选方案）：Filebeat 自身也提供了基础的日志轮转配置，可在其配置文件 filebeat.yml 的 logging 部分进行设置。

  logging:
    file:
      path: /var/log/filebeat/filebeat.log
      name: filebeat
      keepfiles: 7
      rotation.period: 24h

重要提示：上述本地轮转方案仅适用于管理 Filebeat 自身的运行日志。对于其采集的业务日志，长期的归档存储仍需依赖后端的 Elasticsearch ILM 或前文所述的应用侧轮转机制。

配置验证与持续运维要点

配置完成后，持续的验证与监控是保障系统稳定运行的关键。

• 配置校验与运行状态监控：
  • 部署前，使用 sudo filebeat test config 命令校验配置文件语法。
  • 通过 sudo systemctl status filebeat 命令查看服务运行状态。
  • 需要排查问题时，使用 sudo journalctl -u filebeat -f 命令实时追踪系统日志。
• 存储与性能优化：
  • 定期执行 df -h，监控采集服务器及 Elasticsearch 集群节点的磁盘使用情况。
  • 根据日志吞吐量及系统资源状况，适当调整 Filebeat 配置中的 bulk_max_size（批量发送大小）、queue.mem.events（内存队列容量）及 max_concurrent_files（并发采集文件数）等参数，以优化内存与 CPU 使用率。

总而言之，高效运用 Filebeat 的秘诀在于清晰界定其角色——它是一位出色的“数据搬运工”，而非“仓库管理员”。将归档存储的职责交付给更专业的后端系统，让每个组件聚焦于其核心优势，方能构建一个高效、稳定且易于维护的日志处理管道。