如何使用Filebeat收集应用日志

使用 Filebeat 收集应用日志

一 安装与目录结构

在 Linux 环境下部署 Filebeat，无论是 Debian/Ubuntu 还是 CentOS，过程都相当直接。主流方式有两种：一是通过官方仓库安装 .deb 或 .rpm 包，二是直接下载官方压缩包解压即用。安装完成后，有几个关键目录需要心里有数：核心配置文件通常在 /etc/filebeat/filebeat.yml；数据存储和采集进度记录在 /var/lib/filebeat/；而各种预置的模块则位于 /usr/share/filebeat/modules/。以 CentOS 为例，你可以用 YUM 添加 Elastic 的官方仓库后一键安装；在 Debian 系系统上，安装后同样需要编辑那个关键的配置文件。记住这些路径，后续的配置和运维工作都绕不开它们。

二 最小可用配置与启动

万事开头难？其实不然。上手 Filebeat，从一个最小化的配置开始验证是最稳妥的路径。打开 /etc/filebeat/filebeat.yml，添加一个应用日志输入，这里以 JSON 格式的日志为例，并先输出到控制台看看效果：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/myapp/*.log
  json.keys_under_root: true
  json.overwrite_keys: true

output.console:
  pretty: true

配置好后，启动并验证就简单了。在 Systemd 管理的系统上，执行以下命令：

sudo systemctl enable --now filebeat
sudo systemctl status filebeat
# 观察控制台输出是否出现解析后的 JSON 日志

这里有个关键点值得拎出来说说：将应用日志输出为 JSON 格式，并在采集端启用 json.keys_under_root: true，可以直接把日志内的字段提升到事件的顶层。 这步操作，对于后续的检索和聚合分析来说，能省下不少力气。当然，初次接入时，强烈建议先用 output.console 验证数据解析是否正常，确认无误后再切换到生产环境的输出目的地。

三 输出到 Elasticsearch 与按应用分索引

验证通过后，下一步自然是将日志输送到 Elasticsearch 进行集中存储和分析。更专业的做法是，按不同应用将日志写入不同的索引，便于管理和权限控制。下面是一个同时处理 Nginx 访问日志和 Tomcat 应用日志的配置示例：

filebeat.inputs:
- type: log
  paths:
    - /var/log/nginx/access.log
  json.keys_under_root: true
  json.overwrite_keys: true
  fields:
    index: nginx

- type: log
  paths:
    - /application/tomcat/logs/catalina.out
  fields:
    index: tomcat

output.elasticsearch:
  hosts: ["http://10.0.0.71:9200"]
  indices:
    - index: "elk-nginx-%{+yyyy.MM.dd}"
      when.equals:
        fields.index: "nginx"
    - index: "elk-tomcat-%{+yyyy.MM.dd}"
      when.equals:
        fields.index: "tomcat"

这个配置的逻辑很清晰：首先通过 fields 字段为不同来源的日志打上一个“应用标签”，然后在输出到 Elasticsearch 时，利用 indices 配置项配合条件判断（when.equals），将不同标签的日志分别写入按日期滚动的独立索引。这样一来，日志在源头就被清晰地隔离了。

如果默认的索引模板不符合你的需求，比如需要自定义分片数或副本数，可以关闭索引生命周期管理（ILM）并自行配置模板。例如：

setup.ilm.enabled: false
setup.template.name: “myapp”
setup.template.pattern: “myapp-*”
setup.template.settings.index.number_of_shards: 3
setup.template.settings.index.number_of_replicas: 1

四 多行堆栈与常见采集场景

处理 Ja va 应用日志或异常堆栈时，一个常见的挑战是如何将原本属于同一个事件的多行日志合并。Filebeat 的多行合并功能就是为此而生。下面这个配置示例，可以将以左方括号 [ 开头的行作为一个事件的开始，并将其后续行合并进来：

filebeat.inputs:
- type: log
  paths:
    - /var/log/ja va-app/*.log
  multiline:
    pattern: ‘^\[’
    negate: true
    match: after
    max_lines: 500
    timeout: 5s

除了直接写入 Elasticsearch，Filebeat 还支持多种输出方式，以适应不同的架构场景：

• 输出到 Redis（作为缓冲或供其他消费者如 Logstash 处理）：

output.redis:
  hosts: ["10.0.0.81:6379"]
  key: "nginx_log"
  db: 0

• 输出到 Logstash（进行更复杂的集中解析与加工后再入 ES）：

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

• 仅写入本地文件（用于调试或临时归档）：

output.file:
  path: "/tmp/"
  filename: "app.log"

关于多行合并，有几个参数是关键：pattern 定义了匹配规则，negate 决定是否对匹配结果取反，而 match: after 意味着将匹配行之后的行合并到该事件。别忘了通过 max_lines 和 timeout 来控制单次合并的最大行数和超时时间，避免内存过度消耗或事件迟迟不落盘。

五 生产实践与运维要点

将 Filebeat 投入生产环境，有几个维度的考量必不可少：

运行与可靠性
推荐使用 Systemd 来托管 Filebeat 进程，这能确保服务常驻并在异常退出后自动拉起。当然，根据实际情况，结合 nohup 或容器化部署也是常见选择。另外，务必关注 Registry 文件（默认在 /var/lib/filebeat/），它记录了每个文件的采集进度，是避免重启后数据重复或丢失的关键。

性能与资源
根据实际的日志吞吐量和系统负载，可能需要调整一些参数来优化性能，例如 harvester_buffer_size、bulk_max_size 以及内存队列的大小。开启内置的监控（如 logging.metrics）来观察吞吐量和队列积压情况，是进行性能调优的基础。

安全与合规
当日志需要跨网络传输时，启用 SSL/TLS 加密是基本要求。对于配置文件中的密码等敏感信息，建议使用 Filebeat 的 Keystore 功能来管理。同时，对 Elasticsearch、Redis 等输出目标，实施基于角色的访问控制（RBAC），确保最小权限原则。

观测与可视化
日志进了 Elasticsearch，最终价值要在 Kibana 中体现。记得为按应用创建的索引（如 elk-nginx-*、elk-tomcat-*）创建索引模式，之后就可以使用 KQL 进行高效的检索了，例如快速查找某台主机上的错误：message: “error” AND host.name: “web-01”。最后，一个常被忽略但很重要的建议：同时部署 Metricbeat 来监控 Filebeat 自身的运行状态和资源占用，这样才能构建完整的可观测性闭环。