Filebeat生产部署需确保配置文件权限为root:root且chmod 600/644，registry目录可写、paths用绝对路径并验证通配符展开，output调试先禁用TLS与认证。
Filebeat 能直接跑在生产服务器上，不依赖 Java、内存压得低、重启后不丢日志——只要配置文件权限对、路径写准、registry 位置可写，基本不会起不来。
filebeat.yml 权限和所有者必须是 root:root 且不能有 group/other 写权限
Filebeat 启动时会校验 filebeat.yml 的权限，如果设成 777 或 664，会直接报错退出：
Exiting: error loading config file: config file ("filebeat.yml") can only be writable by the owner but the permissions are "-rwxrwxrwx"必须执行：
sudo chown root:root /etc/filebeat/filebeat.yml-
sudo chmod 644 /etc/filebeat/filebeat.yml（或更严一点用600） - 如果用了
modules.d/下的模块配置（比如nginx.yml），同样要检查并修复权限
paths 配置里通配符不生效？先确认文件是否存在且可读
常见现象：明明写了 - /var/log/*.log，但 filebeat -e -c filebeat.yml 启动后没采集到任何日志。
原因往往不是语法错，而是：
-
/var/log/下根本没有以.log结尾的文件（比如实际是messages、secure，无后缀） - Filebeat 进程用户（默认是
root，但若改过user配置）对目标目录无读取权限 - 路径用了相对路径（如
logs/app.log），而当前工作目录不是配置文件所在目录，导致解析失败
建议始终用绝对路径，并用 sudo -u root ls -l /var/log/*.log 手动验证通配是否能展开。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
采集不到轮转后的日志？检查 registry 文件是否可写
Filebeat 依靠 /var/lib/filebeat/registry（默认路径）记录每个文件的 inode 和 offset。如果该路径不可写，每次重启都会从头读——看起来像“重复采集”，其实是“根本没存偏移”。
典型表现：
- 日志文件刚被
logrotate切走，新文件生成后 Filebeat 没识别为同一来源，又从第一行开始读 -
filebeat logs里频繁出现Harvester started for file，但 offset 始终是 0
解决方法：
- 确认
/var/lib/filebeat/目录存在且属主为root：sudo mkdir -p /var/lib/filebeat && sudo chown root:root /var/lib/filebeat - 启动前加
--path.data /var/lib/filebeat显式指定（避免某些离线包解压后路径错位） - 不要手动删
registry文件——除非你明确要重采全部日志
output.elasticsearch 连不上？先绕过 TLS 和认证快速验证链路
线上环境常因证书、用户名密码、网络策略卡住。调试阶段建议临时降级验证：
- 把
output.elasticsearch.hosts改成本地 ES 实例：["http://127.0.0.1:9200"] - 注释掉
username、password、ssl.*等字段 - 用
curl -XGET http://127.0.0.1:9200/_cat/indices?v确认 ES 真的在听请求
一旦基础通路跑通，再逐项加回安全配置。很多连不上问题，其实出在 ES 侧没开自动建索引（尤其阿里云 ES），而不是 Filebeat 配错了。
最易忽略的是 registry 目录权限和 paths 通配符的实际展开结果——这两处一错，Filebeat 就像没装一样安静，既不报错也不传数据。
