Filebeat vs Logstash：轻量搬运工与重型管道怎么选
Filebeat 和 Logstash 深度对比——定位（搬运 vs 加工）、资源占用（10MB 级 vs 数百 MB 堆）、背压机制、组合架构（Filebeat→Logstash→ES）适用场景与许可证注意点，并从观测云视角说明为什么大多数团队可以用 DataKit 一站替代。
Filebeat 与 Logstash 是 Elastic Stack 中分工不同的两个数据组件：Filebeat 是部署在每台机器上的轻量日志搬运工（shipper），只做采集、轻解析和转发；Logstash 是集中式的重型数据处理管道（pipeline），做复杂的解析、富化和多路输出——两者的经典组合是"边缘用 Filebeat 收集，中心用 Logstash 加工"，但这种两层架构正在被更简洁的方案取代。
核心要点速览
- 一句话选型：只需要"把文件日志可靠送到某个地方"用 Filebeat；需要复杂 grok 解析、字段富化、多输出路由才用 Logstash。
- 资源差距悬殊：Filebeat 常驻内存十几 MB，Logstash JVM 堆默认 1GB——边缘节点别放 Logstash。
- 观测云用户的答案更简单：DataKit 一个采集器同时覆盖两者的高频场景，自带 Pipeline 解析，无需维护两层组件。
两者定位的本质区别是什么？
| 维度 | Filebeat | Logstash |
|---|---|---|
| 角色 | 边缘搬运工 | 中心加工管道 |
| 语言/运行时 | Go，单二进制 | Java/JRuby，JVM |
| 常驻内存 | ~10–40MB | ~1GB+（JVM 堆） |
| 解析能力 | 基础（JSON decode、多行合并、dissect） | 强大（grok、mutate、date、geoip、ruby 脚本……） |
| 输入源 | 文件、容器、syslog、TCP/UDP、HTTP 等 | 极广（beats、消息队列、数据库 JDBC、HTTP……） |
| 输出目标 | ES、Logstash、Kafka、Redis、文件 | ES、消息队列、HTTP、邮件……几乎任意 |
| 断点续传 | registry 文件记录 offset | 取决于 input 插件（部分无持久化） |
| 背压 | 内置：下游慢则减速采集 | 内部队列（内存/持久化）缓冲 |
Filebeat 的优势与边界是什么？
优势：极低的资源占用让它可以部署在每一台边缘节点甚至 IoT 设备；registry 机制保证重启不丢不重；modules（nginx、MySQL、Kafka……）提供开箱即用的解析和 ES Ingest 管道。
边界：复杂解析（多层嵌套 grok、字段计算、外部数据富化）不是它的强项；输出目标列表有限（没有任意 HTTP/Webhook 的灵活输出——这正是需要对接非 Elastic 平台时的痛点）。
Logstash 的优势与代价是什么？
优势：filter 生态是业界最丰富的日志加工工具箱——grok 模式库、KV 拆分、日期规范化、GeoIP、DNS 反解、Ruby 自由脚本；input/output 插件两百多个，几乎能连接任何系统。持久化队列（PQ）让它能承受下游抖动。
代价：JVM 的内存与调优成本；配置复杂度高；吞吐调优需要理解 pipeline worker、batch size、队列水位等概念。
经典的 Filebeat → Logstash 组合何时成立？
当且仅当：边缘节点资源紧张（放不下 Logstash）+ 中心需要复杂加工（Filebeat 做不了）+ 下游是 Elastic 生态。组合时用 Lumberjack/Beats 协议对接，Filebeat 自带背压会反向控制采集速度，天然防雪崩。
反过来说，以下情况组合就是过度设计：解析需求简单（Filebeat 单干即可）；或团队根本不在 Elastic 生态（两层组件都要为 ES 的输出格式服务）。
许可证与发行版注意
7.13 之后二者都是 Elastic License + SSPL 双授权（非 OSI 认可的开源协议），云厂商封装受限；OpenSearch 生态有对应的 fork。商用前确认你的用法是否落入限制范围。
观测云视角：为什么多数团队可以跳过这两层
观测云的数据采集由 DataKit 完成，一个组件覆盖 Filebeat 和 Logstash 的高频职责：
| 需求 | Elastic 方案 | 观测云方案 |
|---|---|---|
| 文件采集+断点续传 | Filebeat filestream + registry | DataKit 磁盘文件采集，内置续采 |
| 容器日志 | Filebeat autodiscover | DataKit 容器日志采集 |
| 复杂解析 | Logstash grok/filter | DataKit Pipeline（grok/函数脚本） |
| 多行合并 | Filebeat multiline | DataKit multiline / Pipeline |
| 背压与缓冲 | Filebeat 背压 + Logstash PQ | DataKit 内置缓存与失败重试 |
| 送达观测云 | 需 ES/自定义输出 | 原生上报，含指标/链路/日志统一打标 |
也就是说：Filebeat 与 Logstash 的组合解决的问题，在观测云体系里是"装一个 DataKit + 写一段 Pipeline"。选型 Elastic 组件的合理场景是：你已经有 ES 集群并计划长期使用 Kibana。
常见问题（FAQ）
Q：Filebeat 不经过 Logstash 直连 Elasticsearch 可以吗？ 可以，而且是官方推荐的简单架构；只有需要复杂加工或输出到 ES 以外的系统时才插入 Logstash。
Q：Filebeat 和 Logstash 之间用什么协议？ Lumberjack（Beats 协议），Logstash 端用 beats input（端口 5044 是惯例）；支持 TLS 和压缩。
Q：有没有比 Logstash 更轻的中心加工方案？ Elastic 自家的 ES Ingest Node 可以承接大部分 grok/enrich；开源世界里 Vector（Rust）是高性能替代；观测云用户则用 DataKit 分布式采集 + 云端 Pipeline。
Q：从 Filebeat/Logstash 迁移到观测云 DataKit 难吗？ 采集侧配置是一一对应的（输入源、路径、多行规则），解析规则从 grok 平移到 Pipeline 语法；已有的 grok pattern 大部分可直接复用。
系列阅读
- 上一篇：《Rsyslog 集中化日志实战》
- 下一篇：《Fluentd vs Fluent Bit 对比》
- 相关：《Filebeat 详解》 · 《Logstash 详解》 · 《日志采集器七款横评》 · 《返回索引》
