ELK 在 AWS 上的良好设置
Good setup on AWS for ELK
我们正在考虑在亚马逊上设置 ELK 堆栈，但我们真的不知道我们需要什么机器来顺利处理它。
现在我知道，如果它 运行 不顺利，那将变得很明显，但我们仍然希望了解我们的情况需要什么。
所以我们有 4 个服务器以自定义格式生成日志文件。每天大约 4500 万行日志，生成大约 4 个 600mb（gzip 压缩）文件，所以每天大约 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)
但是因为我真的不知道什么是最好的设置，欢迎任何 hints/tips/info。
还有一个系统或工具可以帮我处理这个问题（节点故障等）。
提前致谢，
黑暗王国
似乎您需要一些东西来开始使用 AWS 上的 ELK Stack
你试过这两个 CloudFormation 脚本了吗，它会简化你的安装过程，并会帮助你一次性设置你的环境。
ELK-Cookbook - CloudFormation Script
ELK-Stack with Google OAuth in Private VPC
如果这不能解决您的问题，请在下方发表评论。
以下是我构建云集群的方式：
3 个主节点 - 这些节点协调集群，保留其中三个节点有助于容忍故障。理想情况下，这些将分布在可用区域中。这些可以相当小，理想情况下不接收任何请求——它们唯一的工作是维护集群。在这种情况下，设置 discovery.zen.minimum_master_nodes = 2 以维持法定人数。这些 IP 和这些 IP 是您应该提供给 discovery.zen.ping.unicast.hosts
中所有集群节点的 IP
索引：您可能应该利用每日索引 - 请参阅 https://www.elastic.co/guide/en/elasticsearch/guide/current/time-based.html 这将在下面更有意义，但如果您开始扩大规模也会有益 - 您可以随着时间的推移增加分片数量而无需重新索引。
数据节点：根据您的规模或性能要求，有几个选项 - i2.xlarge 或 d2.xlarge 可以很好地工作，但 r3.2xlarge 也是一个不错的选择。确保 JVM 堆 <30GB。将临时驱动器上的数据路径保留在实例本地 - EBS 对于这种用例来说并不是那么理想，但根据您的要求可能就足够了。确保您有多个数据节点，以便副本分片可以跨可用性区域拆分。随着数据需求的增加，只需按比例增加即可。
Hot/Warm：根据用例 - 有时将数据节点拆分为 Hot/Warm（快速 SSD/Slow HDD）是有益的。这主要是因为所有写入都是实时的，而大部分读取都是在过去几个小时内进行的。如果您可以将昨天的数据转移到更便宜、更慢的驱动器上，那将大有帮助。这有点复杂，但您可以在 https://www.elastic.co/blog/hot-warm-architecture 阅读更多内容。这需要添加一些标签并每晚使用 curator，但通常是值得的，因为将大部分未搜索的数据从更昂贵的 SSD 中移出可以节省成本。
在生产中，我 运行 ~20 r3.2xlarge 用于热层，4-5 d2.xlarge 用于热层，复制因子为 2 - 这允许每天 ~TB摄取和相当数量的保留。我们将 Hot 缩放为体积，将 Warm 缩放为保留。
总的来说 - 祝你好运！一旦一切都 运行 顺利进行，构建和操作它是一个有趣的堆栈。
PS - 根据您可用的 time/resources，您可以 运行 AWS 上的托管弹性搜索服务，但我上次看到它比上次贵 60% 运行在您自己的实例和 YMMV 上安装它。
我们正在考虑在亚马逊上设置 ELK 堆栈，但我们真的不知道我们需要什么机器来顺利处理它。 现在我知道，如果它 运行 不顺利，那将变得很明显，但我们仍然希望了解我们的情况需要什么。
所以我们有 4 个服务器以自定义格式生成日志文件。每天大约 4500 万行日志，生成大约 4 个 600mb（gzip 压缩）文件，所以每天大约 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)
但是因为我真的不知道什么是最好的设置，欢迎任何 hints/tips/info。
还有一个系统或工具可以帮我处理这个问题（节点故障等）。
提前致谢，
黑暗王国
似乎您需要一些东西来开始使用 AWS 上的 ELK Stack
你试过这两个 CloudFormation 脚本了吗，它会简化你的安装过程，并会帮助你一次性设置你的环境。
ELK-Cookbook - CloudFormation Script
ELK-Stack with Google OAuth in Private VPC
如果这不能解决您的问题，请在下方发表评论。
以下是我构建云集群的方式：
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 对于这种用例来说并不是那么理想，但根据您的要求可能就足够了。确保您有多个数据节点，以便副本分片可以跨可用性区域拆分。随着数据需求的增加，只需按比例增加即可。
Hot/Warm：根据用例 - 有时将数据节点拆分为 Hot/Warm（快速 SSD/Slow HDD）是有益的。这主要是因为所有写入都是实时的，而大部分读取都是在过去几个小时内进行的。如果您可以将昨天的数据转移到更便宜、更慢的驱动器上，那将大有帮助。这有点复杂，但您可以在 https://www.elastic.co/blog/hot-warm-architecture 阅读更多内容。这需要添加一些标签并每晚使用 curator，但通常是值得的，因为将大部分未搜索的数据从更昂贵的 SSD 中移出可以节省成本。
在生产中，我 运行 ~20 r3.2xlarge 用于热层，4-5 d2.xlarge 用于热层，复制因子为 2 - 这允许每天 ~TB摄取和相当数量的保留。我们将 Hot 缩放为体积，将 Warm 缩放为保留。
总的来说 - 祝你好运！一旦一切都 运行 顺利进行，构建和操作它是一个有趣的堆栈。
PS - 根据您可用的 time/resources，您可以 运行 AWS 上的托管弹性搜索服务，但我上次看到它比上次贵 60% 运行在您自己的实例和 YMMV 上安装它。