总体思路与架构原则

• Filebeat 本身不提供集群模式，高可用通过“多实例冗余 + 目标端集群/负载均衡 + 至少一次语义保障”来实现。
• 在每台业务主机上运行独立的 Filebeat 实例，将日志同时发给下游的 Elasticsearch 集群或经 Logstash/负载均衡转发，避免单点。
• 利用 注册表 registry 记录读取位点，配合 ACK/确认机制与 ILM 策略，降低重启或切换时的重复与丢失风险。

部署与配置步骤

• 安装与版本统一
  • 在所有需要采集的 CentOS 主机安装相同版本的 Filebeat（示例使用 YUM）：
    • sudo yum install filebeat -y
• 配置采集输入
  • 编辑 /etc/filebeat/filebeat.yml，为需要保障高可用的路径设置输入（示例为系统日志）：
    • filebeat.inputs:
      • type: log enabled: true paths:
        • /var/log/*.log
• 配置高可用输出
  • 直连 Elasticsearch 集群（内置轮询与故障转移）：
    • output.elasticsearch:
      • hosts: [“es-node1:9200”, “es-node2:9200”, “es-node3:9200”]
      • index: “filebeat-%{[agent.version]}-%{+yyyy.MM.dd}”

      • 如启用安全认证

      • username: “elastic”
      • password: “your_password”
  • 或经 Logstash 集群（集中处理/缓冲后再入 ES）：
    • output.logstash:
      • hosts: [“logstash1:5044”, “logstash2:5044”]
  • 如需统一接入与故障转移，可在前面加 HAProxy/Nginx 作为 TCP/HTTP 负载均衡：
    • output.elasticsearch:
      • hosts: [“haproxy-node:9200”]
• 启用模板与 ILM
  • 建议启用 ILM（Index Lifecycle Management）与内置模板，减少手工索引管理：
    • setup.template.name: “filebeat”
    • setup.template.pattern: “filebeat-*”
    • setup.ilm.enabled: true
• 启动与自启
  • sudo systemctl enable filebeat --now
  • 检查状态：sudo systemctl status filebeat；日志：tail -f /var/log/filebeat/filebeat。

保障至少一次与状态一致性

• 注册表与恢复
  • 配置 registry.path（默认 /var/lib/filebeat/registry），确保重启/切换时可从断点续传；可按需设置清理策略（如 clean_inactive: 72h）以控制状态体积。
• 确认机制与版本选择
  • 使用 Logstash 时，建议开启 ACK 并合理设置 pipeline.workers 与 bulk_max_size，在吞吐与可靠性间平衡；直连 Elasticsearch 的场景依赖 ES 的确认与重试策略。
• 索引与生命周期
  • 采用 ILM 将数据滚动到 hot/warm/cold/delete 阶段，结合副本分片提升可用性；索引命名建议包含 agent.version 与日期，便于多版本共存与回滚。

验证与运维监控

• 连通性与数据验证
  • 查看 Filebeat 日志无报错；在 Kibana 建立 filebeat-* 索引模式并确认有数据写入；必要时在 Logstash 端开启 stdout { codec => rubydebug } 做临时排障。
• 监控与告警
  • 监控 Filebeat 自身指标（处理速率、队列、错误数）与 ES/Logstash 的健康与延迟；可结合 Prometheus + Grafana 或 Elastic Stack 自带监控进行可视化与阈值告警。

常见误区与建议

• 误区：试图将 Filebeat 做成“集群”。正确理解是每台主机一个实例，靠下游集群/负载均衡实现高可用。
• 建议：
  • 避免多实例争抢同一日志文件的同一 inode（可能导致重复或漏读）；若必须多实例，按文件或路径严格划分采集范围。
  • 为 registry 与配置做定期备份；变更前先在测试环境验证。
  • 在容器/云原生场景，优先使用 Kubernetes DaemonSet 在每个节点运行一个 Filebeat 实例，统一接入与治理。