既然能用 REST 直接写 Elasticsearch，为什么还要装 Logstash？
REST 客户端或 ingest pipeline 也可加工数据；Logstash 提供独立的多源采集、加工、缓冲与路由。应按吞吐、加工和可靠传输需求选择架构。本文对比两种架构。
核心区别：REST 客户端可以先加工数据，也可以调用 Elasticsearch ingest pipeline；Logstash 的价值在写入之前——解析非结构化日志、字段加工与富化、多来源汇聚、缓冲削峰、按条件路由。数据规整时直连完全可行，高吞吐也可用 bulk API；需要清洗或可靠传输时，应比较客户端、ingest pipeline 与独立采集层，而非认定必须用 Logstash。
Logstash 提供的四种能力
1. 解析与加工
原始日志是一行文本，可先在客户端解析，或通过 Elasticsearch ingest pipeline 加工。Logstash 用 grok/date/mutate 把文本切成字段、解析时间、转换类型，检索和聚合才有意义。
2. 多源采集
文件、TCP/UDP、消息队列（Kafka、RabbitMQ）、数据库、HTTP——几十种输入插件统一进一条管道，应用不必各自实现上报客户端。
3. 缓冲与削峰
配合队列（或直接对 Kafka 消费），可在容量范围内缓冲写入峰值；ES 不可用时仍受队列容量、持久化、确认与重试策略限制，不能保证绝不丢失。
4. 路由与多输出
按条件把不同日志发到不同索引、不同集群，或同时发一份到对象存储归档。
什么时候可以直连 REST
- 应用本身输出结构化 JSON，无需加工
- 写入量小且平稳，ES 偶发不可用可接受重试或丢失
- 来源单一（就一两个服务），不想多维护一层组件
直连时应按负载设计批量写入（bulk API）与失败重试，并检查每个 bulk item 的结果；HTTP 成功不代表每条写入成功，重试还需考虑幂等性，单条一写既慢又脆。
典型取舍
| 场景 | 建议 |
|---|---|
| 原型验证、个人项目 | 直连 REST，架构最简 |
| 多服务文本日志集中分析 | Logstash/采集层做解析 |
| 高峰流量、不允许丢日志 | 队列 + 消费写入 |
| 需富化（GeoIP、字段映射） | 客户端、ingest pipeline 或独立加工层均可 |
常见问题（FAQ）
Q：直连 REST 如何保证不丢数据？
A：可用客户端本地磁盘队列 + 有界重试，并验证确认、容量及幂等策略；没有单一配置能保证所有故障下绝不丢失。或者先写 Kafka 再消费写入——后者其实已经把中间层加回来了。
Q：Filebeat 能替代 Logstash 吗？
A：采集+轻加工可以；复杂解析与富化仍需 Logstash 或同等的加工层。
Q：Logstash 性能不够怎么办？
A：横向扩实例、管道批量调大、重活（grok）尽量前置到轻量采集器或用队列削峰。
