使用 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: ["https://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 自身的运行状态和资源占用，这样才能构建完整的可观测性闭环。
