PROSAGA码农传奇-ELK-适用于ELK的AWS设置良好

<div class =“post-text”itemprop =“text”>
  
    以下是我构建云群的方法：
  
  
    3主节点 - 这些节点协调集群并保持其中三个节点有助于容忍故障。理想情况下，这些将分布在可用区域。这些可能相当小，理想情况下不会收到任何请求 - 他们唯一的工作就是维护集群。在这种情况下设置
     <code>
 discovery.zen.minimum_master_nodes = 2
 </code>
     维持法定人数。这些IP和这些IP只是您应该为所有群集节点提供的
     <code>
 discovery.zen.ping.unicast.hosts
 </code>
  
  
    索引：您应该利用每日索引 - 请参阅
    <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/time-based.html" rel="noreferrer">
      https://www.elastic.co/guide/en/elasticsearch/guide/current/time-based.html
    </A>
     这将在下面更有意义，但如果您开始扩展也将是有益的 - 您可以随着时间的推移增加分片计数而无需重新索引。
  
  
    数据节点：根据您的规模或性能要求，有一些选项 - i2.xlarge或d2.xlarge可以正常工作，但r3.2xlarge也是一个不错的选择。确保保持JVM堆<30GB。将数据路径保留在实例本地的临时驱动器上 - 对于此用例，EBS并不是那么理想，但根据您的要求可能就足够了。确保您有多个数据节点，因此副本分片可以跨可用区分割。随着您的数据需求的增加，只需扩展它们。
  
  
    热/暖：根据使用情况 - 有时将数据节点拆分为热/暖（快速SSD /慢速HDD）是有益的。这主要是因为所有写入都是实时的，并且大多数读取都是在过去的几个小时内完成的。如果你可以将昨天的数据移动到更便宜，速度更慢的驱动器上，那么它会有所帮助。这是一个更多的参与，但你可以阅读更多
    <a href="https://www.elastic.co/blog/hot-warm-architecture" rel="noreferrer">
      https://www.elastic.co/blog/hot-warm-architecture
    </A>
    。这需要在每晚添加一些标签和使用策展人，但通常是值得的，因为从更昂贵的SSD移动大量未搜索的数据可以节省成本。
  
  
    在生产中，我为热层运行~20 r3.2xlarge，为热层运行4-5 d2.xlarge，复制因子为2 - 这允许每天摄取~TB和相当大的保留量。我们按体积热量和热量保持量。
  
  
    总的来说 - 祝你好运！一切顺利运行，这是一个有趣的堆栈，可以构建和运行。
  
  
    PS - 根据您可用的时间/资源，您可以在AWS上运行托管弹性搜索服务，但上次我看起来比在您自己的实例上运行它的成本高出约60％，并且YMMV。
  
</DIV>