总体结论
在 Ubuntu 上，Filebeat 通常属于轻量级日志采集器，资源占用相对 Logstash 等 JVM 组件更低。实际占用取决于日志量、输入/处理/输出链路以及系统资源。社区与实测经验显示：
- 轻载场景下，单实例内存常见在约 10–50 MB量级；例如：7.17.24 版本实测约 32.4 MB；早期 6.x 版本也有约 10 MB 的典型占用；另一组 7.x 实例的内存峰值约 11–25 MB。
- 与 Logstash 相比，后者通常需数百 MB起步（有示例约 500 MB），因此在同等日志规模下 Filebeat 对 CPU/内存的压力一般更小。
影响占用的主要因素
- 日志吞吐与事件处理量：事件越多、处理越复杂，CPU 与内存越高。
- 输入类型与数量：使用 filestream（推荐于 7.x+）更高效；大量输入路径或通配符会提升扫描与状态维护成本。
- 处理器与多行解析：大量或复杂的 processors（如 grok、json、multiline）会显著增加 CPU 占用。
- 输出链路与批量策略：直连 Elasticsearch 与经 Kafka/Logstash 的链路差异、批量大小与压缩配置都会影响占用与吞吐。
- 队列与背压：内存队列大小、磁盘队列启用与否、输出阻塞都会改变资源使用曲线。
- 文件状态与注册表：被采集文件数量多、状态频繁更新，会提升内存与 I/O。
快速自检与定位
- 查看进程资源：使用命令如 top/htop 观察 filebeat 进程的 CPU%、MEM%；结合 free -m 检查系统可用内存。
- 检查日志与配置：关注 Filebeat 自身日志（如 -e 输出或日志文件）与配置文件 /etc/filebeat/filebeat.yml，确认是否存在异常报错、过度处理或不必要的模块启用。
- 观察数据面指标：开启或接入 Filebeat 监控，在 Kibana 查看事件速率、处理延迟、输出成功率与队列堆积等指标，定位瓶颈点。
降低资源占用的实用配置建议
- 输入与文件生命周期
- 优先使用 filestream 输入；对不活跃文件设置 close_inactive: 5m；忽略历史文件 ignore_older: 168h，减少无效扫描与状态维护。
- 处理与解析
- 精简或移除不必要的 processors；对多行日志仅在确需时启用 multiline，避免复杂正则带来的高 CPU。
- 队列与并发
- 合理设置内部队列（如 queue.mem.events）与批量参数（如 bulk_max_size），在吞吐与占用间取平衡；必要时启用磁盘队列以缓冲高峰。
- 输出与网络
- 在输出到 Elasticsearch 时启用 compression: true 降低网络流量；根据网络与吞吐调优批量与超时参数。
- 运行与架构
- 禁用不需要的 modules；在大规模或高隔离需求场景，考虑按业务拆分 多实例 部署（如容器化）。