amazon-web-services - ELK 在 AWS 上的良好设置

Question

我们正在考虑在 Amazon 上设置 ELK 堆栈，但我们真的不知道我们需要什么机器才能顺利处理它。
现在我知道如果它运行不顺利就会变得很明显，但我们仍然希望了解我们需要什么来应对我们的情况。

所以我们 4 个服务器以自定义格式生成日志文件。每天约 4500 万行日志，生成约 4 个 600mb(gzipped)文件，因此每天约 24GB 的日志。

现在我们正在研究 ELK 堆栈，并希望 Kibana 的仪表板显示实时数据，因此我考虑使用 syslog 将日志记录到 logstash。

4 服务器 -> Rsyslog(在这 4 台服务器上) -> Logstash (AWS) -> ElasticSearch (AWS) -> Kibana (AWS)

所以现在我们需要弄清楚我们在 AWS 中需要什么样的硬件来处理这个问题。

我至少在某处阅读了 3 个 ElasticSearch 大师和 2 个数据节点。
那么总共 5 台服务器 + 1 台服务器用于 Kibana，1 台用于 Logstash？
所以我总共需要 7 台服务器才能开始，但这似乎有点矫枉过正？
我想将我的数据保留 1 个月，所以最多 31 天，所以我在 Elastic Search 中有大约 1.4TB 的原始日志数据(~45GB x 31)

但是，由于我真的不知道最佳设置是什么，因此欢迎提供任何提示/提示/信息。

此外，可以为我处理此问题的系统或工具(节点故障等)可能很有用。

提前致谢，

黑暗之城

Answer 1

以下是我构建云集群的方式:

3 个主节点 - 这些节点协调集群并保留其中三个有助于容忍故障。理想情况下，这些将分布在可用区中。这些可以相当小，理想情况下不接收任何请求——它们唯一的工作是维护集群。在这种情况下设置 discovery.zen.minimum_master_nodes = 2以维持法定人数。这些 IP 和仅这些 IP 是您应该提供给 discovery.zen.ping.unicast.hosts 中的所有集群节点的内容。

索引:您可能应该利用每日索引 - 参见 https://www.elastic.co/guide/en/elasticsearch/guide/current/time-based.html这在下面会更有意义，但如果您开始扩大规模也会有好处 - 您可以随着时间的推移增加分片数量而无需重新编制索引。

数据节点:根据您的规模或性能要求，有几个选项 - i2.xlarge 或 d2.xlarge 可以很好地工作，但 r3.2xlarge 也是一个不错的选择。确保保持 JVM 堆 <30GB。将数据路径保留在实例本地的临时驱动器上 - EBS 对于此用例并不是很理想，但根据您的要求可能就足够了。确保您有多个数据节点，以便副本分片可以跨可用区拆分。随着您的数据需求的增加，只需扩大这些需求即可。

热/暖:取决于用例 - 有时将数据节点拆分为热/暖(快速 SSD/慢速 HDD)是有益的。这主要是因为所有写入都是实时的，并且大部分读取发生在过去几个小时内。如果您可以将昨天的数据移动到更便宜、速度更慢的驱动器上，那将大有帮助。这有点复杂，但您可以在 https://www.elastic.co/blog/hot-warm-architecture 阅读更多内容。 .这需要每晚添加一些标签并使用 curator，但通常是值得的，因为将大部分未搜索的数据从更昂贵的 SSD 上移走可以节省成本。

在生产中，我为热层运行 ~20 r3.2xlarge，为热层运行 4-5 d2.xlarge，复制因子为 2 - 这允许每天摄取 ~TB 和相当数量的保留。我们将 Hot 扩展为容量，将 Warm 扩展为保留。

总的来说 - 祝你好运!一旦一切顺利运行，就可以构建和运行一个有趣的堆栈。

PS - 根据您可用的时间/资源，您可以在 AWS 上运行托管的 elasticsearch 服务，但上次我认为它比在您自己的实例上运行它贵约 60%，而且 YMMV。