我最近提出了一个测试ELK堆栈的Ubuntu盒来测试功能，并对它非常满意。我的生产用例将涉及每天摄取至少100GB的日志。我想尽可能地扩展，因为我们有更多的日志源，这100GB /天可以快速上升。
我读了一些关于ELK制作的文章，包括幻想Logz.io ELK Deployment。虽然我对我需要做的事情有一个大概的了解，但我不确定一些核心概念，我需要多少台机器才能获得如此大量的数据以及我是否需要像我的架构中包含Redis这样的经纪人。
像Redis这样的经纪人有什么意义？在我的测试实例中，我有多个日志源通过TCP，syslog和logstash转发器将日志直接发送到我的Logstash直接在我的ELK服务器上（其中也安装了配置了SSL的Elasticsearch，Nginx和Kibana）。
为了保持高可用性，最先进的生产集群，我每天至少需要100GB数据才能获得哪些机器+规格，未来可能会扩展到150GB或更多？我正计划使用自己的服务器。根据我的研究，起点应该像（假设我包括Redis）：
编辑：计划将日志保留60天。
答案 0 :(得分：11)
至于Redis，它可以作为缓冲区，以防万一.logstash和/或elasticsearch停顿或缓慢。如果您使用完整的logstash或logstash-forwarder作为托运人，它将检测logstash何时不可用并停止发送日志（记住它停止的位置，至少暂时）。
因此，在纯logstash / logstash-forwarder环境中，我认为没有理由使用像redis这样的代理。
如果重要的是那些不关心logstash状态并且不在他们身边缓冲的消息来源。 syslog，snmptrap和其他类型都属于这一类。由于您的资源包括系统日志，我会在您的设置中调出代理。
Redis是一个RAM密集型应用程序，您拥有的内存量将决定您可以承受多长时间的垃圾邮件中断。在一个32GB的服务器上（与logstash共享），你会给你多少内存yo redis？您的平均文档大小有多大？填充内存需要多少文件？生成那么多文档需要多长时间？根据我的经验，当内存填满时，redis会失败，但那可能就是我。
Logstash是一个CPU密集型过程，因为所有过滤器都会被执行。
至于elasticsearch集群的大小，@ magnus已经向您指出了一些可能有用的信息。从64GB机器开始很好，然后根据需要水平扩展。
您应该有两个客户端（非数据）节点，用作插入的访问点（有效地将请求分派到正确的数据节点）和搜索（使用数据处理＆＃39; reduce＆＃39;阶段）从数据节点返回）。其中两个在故障转移配置中将是一个良好的开端。
两台kibana机器将为您提供冗余。将它们放在故障转移配置中也很好。我相信nginx更多地与kibana3一起使用。我不知道人们是否正在使用它与kibana4或者已经移动到屏蔽＆＃39;。
希望有所帮助。