logstash 的scale out的问题
匿名 | 发布于2017年07月21日 | 阅读数：3073
我是刚刚开始接触ELK， 我们系统准备部署elk的集群，有个问题请教下。
通常logstash 是 ，每个shipper broker， indexer的结构，我可不可以在每天机器（比如每个app server）上完成数据采集，清洗（filter），并直接输出到后方的es 集群那，这样就不用考虑部署broker， indexer 了。也就是说，每个采集点用logstash做完处理后直接送es。 这样设计的话，在大规模生产环境，会有问题吗？
（实际上就是broker我是否一定要采用）
通常logstash 是 ，每个shipper broker， indexer的结构，我可不可以在每天机器（比如每个app server）上完成数据采集，清洗（filter），并直接输出到后方的es 集群那，这样就不用考虑部署broker， indexer 了。也就是说，每个采集点用logstash做完处理后直接送es。 这样设计的话，在大规模生产环境，会有问题吗？
（实际上就是broker我是否一定要采用）
2 个回复
ggg
赞同来自:
xunidi
赞同来自:
我中午研究了下elastic的文档https://www.elastic.co/guide/e ... ueues
我的理解是这样的：
（1）我想的这种 在每个log源的机器节点上 直接做完ingest， filter，out后发送给es cluster 应该是可行的
For first time users, if you simply want to tail a log file to grasp the power of the Elastic Stack, we recommend trying Filebeat Modules. Filebeat Modules enable you to quickly collect, parse, and index popular log types and view pre-built Kibana dashboards within minutes.
把上文中的 filebeat换成logstash 应该也没道理不可以
（2）我猜测
之所有有 shipper 和 后面的indexer这种结构，原因 是：
一个就是 ggg 提到的数据源上不方便部署这种“重”服务， 所以采用轻量的shipp +集中的 ｌｏｇｓｔａｓｈ
一个估计是不同ｌｏｇ源 可能采用不同的ｓｈｉｐｐｅｒ工具，ｌｏｇｓｔａｓｈ在一些场景下不如有些ｓｈｉｐｐｅｒ好用。
（３）对于ｂｒｏｋｅｒ
看看文档和persist queue
In summary, the benefits of enabling persistent queues are as follows:
Absorbs bursts of events without needing an external buffering mechanism like Redis or Apache Kafka.
Provides an at-least-once delivery guarantee against message loss during a normal shutdown as well as when Logstash is terminated abnormally. If Logstash is restarted while events are in-flight, Logstash will attempt to deliver messages stored in the persistent queue until delivery succeeds at least once.
感觉上这些事在 shipper + indexer 这种情况下提供输入平滑 和 故障数据恢复
（4）
我暂时不知道，两种方法对 es 机器方面的影响