既然能用 REST 直接写 Elasticsearch，为什么还要装 Logstash？
直连 REST 只能原样写数据，Logstash 提供解析加工、多源采集、缓冲削峰与路由分发能力。数据简单量小可直连，需要清洗与可靠性则应引入中间层。本文对比两种架构。
核心区别：REST 直连只能把"已经整理好的数据"原样写进 ES；Logstash 的价值在写入之前——解析非结构化日志、字段加工与富化、多来源汇聚、缓冲削峰、按条件路由。数据本身规整、量小、来源单一时直连完全可行；日志需要清洗、来源多样或要求不丢数据时，中间层就是必需品。
Logstash 提供的四种能力
1. 解析与加工
原始日志是一行文本，直接写入 ES 只能全文检索。Logstash 用 grok/date/mutate 把文本切成字段、解析时间、转换类型，检索和聚合才有意义。
2. 多源采集
文件、TCP/UDP、消息队列（Kafka、RabbitMQ）、数据库、HTTP——几十种输入插件统一进一条管道，应用不必各自实现上报客户端。
3. 缓冲与削峰
配合队列（或直接对 Kafka 消费），写入洪峰不会直接冲击 ES；ES 短暂不可用时数据在队列里积压而不是丢失。
4. 路由与多输出
按条件把不同日志发到不同索引、不同集群，或同时发一份到对象存储归档。
什么时候可以直连 REST
- 应用本身输出结构化 JSON，无需加工
- 写入量小且平稳，ES 偶发不可用可接受重试或丢失
- 来源单一（就一两个服务），不想多维护一层组件
直连时务必在客户端做批量写入（bulk API）与失败重试，单条一写既慢又脆。
典型取舍
| 场景 | 建议 |
|---|---|
| 原型验证、个人项目 | 直连 REST，架构最简 |
| 多服务文本日志集中分析 | Logstash/采集层做解析 |
| 高峰流量、不允许丢日志 | 队列 + 消费写入 |
| 需富化（GeoIP、字段映射） | 必须有加工层 |
观测云对照
中间层可以不必自己维护。 观测云 DataKit 承担采集与缓冲，Pipeline 承担 grok 解析与加工，写入观测云后按索引与存储策略管理——等价于"Logstash + ES"的能力，但采集端配置即开即用、解析规则在线调试，不需要自己搭管道集群。
常见问题（FAQ）
Q：直连 REST 如何保证不丢数据？
A：客户端本地磁盘队列 + 重试，或者先写 Kafka 再消费写入——后者其实已经把中间层加回来了。
Q：Filebeat 能替代 Logstash 吗？
A：采集+轻加工可以；复杂解析与富化仍需 Logstash 或同等的加工层。
Q：Logstash 性能不够怎么办？
A：横向扩实例、管道批量调大、重活（grok）尽量前置到轻量采集器或用队列削峰。
