Filebeat可直接部署于生产服务器，不依赖Java、内存占用低、支持断点续传；关键在于filebeat.yml权限为root:root且chmod 600/644、日志路径用绝对路径并验证通配符展开、registry目录（如/var/lib/filebeat/registry）可写。
Filebeat 能直接跑在生产服务器上，不依赖 Java、内存占用低、重启后不丢日志——关键在于配置文件权限正确、日志路径写准、registry 目录可写。只要这三点落实，基本不会起不来。
用 yum 或 apt 安装最省事，但必须先配好 Elastic 官方源
系统包管理器安装不是简单执行 sudo yum install filebeat 就完事。Elastic 官方包不在 CentOS/RHEL 默认源或 Ubuntu 的 main 源里，漏掉这步会装到旧版甚至报错 “No package filebeat available”。
- CentOS/RHEL：先导入 GPG 密钥并写
/etc/yum.repos.d/elastic.repo，baseurl必须指向8.x（当前稳定大版本），不能写成7.x或留空 - Ubuntu/Debian：用
gpg --dearmor导入密钥，sources.list.d/里的 repo 行必须含signed-by=，否则apt update会跳过该源 - 装完立刻检查版本：
filebeat version，确认输出是8.x开头，避免因源配置失败而装了系统仓库里的陈旧版本（如 CentOS 7 自带的 6.8）
filebeat.yml 权限不对，服务启动直接退出
Filebeat 启动时强制校验配置文件权限。只要 filebeat.yml 的权限是 644 以外的值（比如你顺手 chmod 755 或编辑后 umask 导致变成 664），它就会打印错误并退出：
Exiting: error loading config file: config file ("filebeat.yml") can only be writable by the owner
这不是 warning，是 fatal 错误，systemd 状态会显示 failed。
- 必须执行：
sudo chown root:root /etc/filebeat/filebeat.yml+sudo chmod 644 /etc/filebeat/filebeat.yml（600也行，但644更便于运维查看） - 如果启用了
modules.d/下的模块（例如nginx.yml），同样要chown和chmod，否则模块加载失败且无明确提示 - 别用编辑器“保存时自动改权限”功能——很多 vim/VSCode 插件会悄悄把权限改成
664
日志路径写错或 registry 不可写，现象是“没数据”
配置里写了 paths: ["/var/log/app/*.log"] 却收不到日志，90% 不是语法问题，而是环境没对齐：
-
paths必须用绝对路径，logs/app.log这种相对路径会被忽略，不报错也不采集 - 通配符是否真能匹配？运行
sudo -u root ls -l /var/log/app/*.log，确认 shell 展开后确实有文件；常见坑是日志文件实际叫app.log.1或没.log后缀 -
registry目录默认是/var/lib/filebeat/registry，若该路径不存在或不可写，Filebeat 每次都从头读，offset始终为 0，表现为重复发送旧日志 - 手动创建并授权：
sudo mkdir -p /var/lib/filebeat && sudo chown root:root /var/lib/filebeat
连不上 ES 或 Logstash？先关 TLS 和认证，用 -e 前台跑看真实日志
一上来就配 ssl.certificate_authorities、username/password，很容易卡在证书路径错、CA 不信任、密码输错等细节里，而控制台只显示 Failed to connect 这种泛泛信息。
- 临时注释掉 output 配置里的所有安全相关字段，只留基础地址，例如：
hosts: ["http://10.0.1.5:9200"] - 用
filebeat -e -c /etc/filebeat/filebeat.yml前台运行，观察输出里有没有Harvester started for file（说明文件已识别）和PublishEvents: events sent（说明发出去了） - 如果前台能通但 systemctl start 不行，大概率是 SELinux 或 systemd 的
ProtectSystem限制了访问路径，此时看journalctl -u filebeat -n 50才能看到真实拒绝原因
真正容易被忽略的是 registry 文件的 inode 绑定机制：Filebeat 用 inode 而非文件名识别日志轮转，但如果日志被 cp + truncate 而非 mv，inode 变了，旧 offset 就失效。这种场景下得靠 clean_inactive 和 ignore_older 配合清理状态，而不是反复 chmod。
