ES迭代更新较快，官方文档非常完善，但是中文文档和资料比较滞后，从个人使用经验来说通过国内站点搜索方案和问题解决方法往往容易走弯路，很多时候反而不及直接查找官方文档相关章节通篇阅读高效，建议有兴趣和时间的同学多花点时间学习官方文档
资源评估存储容量评估计算资源评估实例类型选择及测试分片数量评估ES主要配置参数详解ES节点类型详解jvm.options配置建议集群部署实战集群设计安装准备工作集群节点详细配置ES客户端/协调器节点ES主节点/数据节点Kibana详细配置集群启停安全通信配置常见错误解决方案最佳实践Elastic系列文章
资源评估存储容量评估影响ES服务存储容量的主要因素如下：
副本数量：副本有利于增加数据的可靠性，但同时会增加存储成本。默认和建议的副本数量为1，对于部分可以承受异常情况导致数据丢失的场景，可考虑设置副本数量为0。
数据膨胀：除原始数据外，ES需要存储索引、列存数据等，在应用编码压缩等技术后，一般膨胀10%。
内部任务开销：ES占用约20%的磁盘空间，用于segment合并、ESTranslog、日志等。
操作系统预留：Linux操作系统默认为root用户预留5%的磁盘空间，用于关键流程处理、系统恢复、防止磁盘碎片化问题等。
因此，数据在ES中占用的实际空间可通过下面公式估算：
实际空间=源数据*(1+副本数量)*(1+数据膨胀)/(1-内部任务开销)/(1-操作系统预留)≈源数据*(1+副本数量)*1.45
为保证服务的稳定运行，建议至少预留50%的存储空间，因此建议申请的存储容量为：
存储容量=源数据*(1+副本数量)*1.45*（1+预留空间）≈源数据*(1+副本数量)*2.2计算资源评估
ES的计算资源主要消耗在写入和查询过程，而不同业务场景在写入和查询方面的复杂度不同、比重不同，导致计算资源相比存储资源较难评估。但一般情况下，存储资源会较早成为瓶颈，因此建议优先评估存储资源量，然后初步选择计算资源，在测试过程中确认计算资源是否足够。
下面针对几种常见使用场景，介绍计算资源评估过程中的一些经验(腾讯云)：
日志场景：日志属于典型的写多读少类场景，计算资源主要消耗在写入过程中。日志场景的经验是：2核8GB内存的资源最大可支持0.5w/s的写入能力，但注意不同业务场景可能有偏差。由于实例性能基本随计算资源总量呈线性扩容，可以按实例资源总量估算写入能力。例如6核24GB内存的资源可支持1.5w/s的写入能力，40核GB内存的资源可支持10w/s的写入能力。
Metric及APM等结构化数据场景：这也是写多读少类场景，但相比日志场景计算资源消耗较小，2核8GB内存的资源一般可支持1w/s的写入能力，可参照日志场景线性扩展的方式，评估不同规格实例的实际写入能力。
站内搜索及应用搜索等搜索场景：此类为读多写少类场景，计算资源主要消耗在查询过程，由于查询复杂度在不同使用场景差别非常大，计算资源也最难评估，建议结合存储资源初步选择计算资源，然后在测试过程中验证、调整。
实例类型选择及测试在完成存储、计算资源评估后，对选择实例类型的常用建议如下：
建议至少选择3个节点，避免ES实例出现脑裂问题，保证ES实例具有较高的节点故障容错能力。
脑裂：两个节点同时认为自己是唯一处于活动状态的服务器，从而出现争用资源的情况。
如果有非常大的存储容量需求，建议选择高规格的节点，避免大量低规格节点，这对大实例的性能、稳定性等有较大好处。
当完成实例类型的初步选择后，可以使用真实数据进行测试，通过观察CPU使用率、写入指标（性能、拒绝率）、查询指标（QPS、拒绝率）等监控信息，进一步确认实例类型是否合适。另外，建议针对上述监控信息配置告警，方便在线上使用时，及时发现资源不足等问题。
分片数量评估每个ES索引被分为多个分片，数据按哈希算法打散到不同的分片中。由于索引分片的数量影响读写性能、故障恢复速度，且通常无法轻松更改，需要提前考虑。这里给出配置分片数量的一些常用建议：
建议单个分片大小保持在10GB-50GB之间，可据此初步确定Index的分片数量。分片不宜过大或过小：过大可能使ES的故障恢复速度变慢；过小可能导致非常多的分片，但因为每个分片使用一些数量的CPU和内存，从而导致读写性能、内存不足等问题。
在测试阶段，可以根据每个Index的实际大小、预期未来增长情况，适当调整分片数量。
当分片数量超过数据节点数量时，建议分片数量接近数据节点的整数倍，方便分片在所有数据节点均匀分布。
对于日志、Metric等场景中，建议使用ES自带的RolloverIndex功能，持续滚动产生新的Index。方便在发现分片大小不合理时，通过该功能及时调整分片数量。
例如，假设实例有5个数据节点，Index当前大小为GB，预期半年后增长50%。如果我们控制每个单分片为30GB，则大约需要GB*（1+50%）/30≈7个分片，考虑到有两个数据节点支撑2/7的数据压力，节点间压力相对不均匀，我们把分片数量调整到10个。
ES主要配置参数详解参数名称参数描述cluster.name集群名称，只有具有相同名称的节点才能加入node.name节点名称，未定义则会自动分配，建议设置为有意义的名称，如果需要监视服务器，则必须始终设置，一般来说，节点名称与主机服务器名称相同便于维护node.master节点是否为主节点，默认值为true。主节点是晕的仲裁者，它负责有关分片管理的决策，保持集群的状态，并且是每个索引操作的主要控制者，主节点是在所有数据节点上分布搜索并汇总/重新计算结果以将结果返回给用户的节点，相当于大数据Map/Redux搜索中的Redux层。主节点的数量必须始终为偶数node.data节点是否为数据节点，默认值为true。允许将数据存储在节点中，负责索引和搜索数据的Workernode.ingest节点是否为采集节点，默认值为true。允许将数据存储在节点中，负责索引和搜索数据的Workernetwork.host用于绑定节点的计算机IP,多网卡机器上，如果你的服务器位于不同的LAN上，或者你想绑定限制在一个LAN上，则必须使用服务器IP设置此值。未配置时默认绑定到本地回环地址。discovery.zen.ping.unicast.hosts早先的参数，目前仍然支持，但是一般会用最新的discovery.seed_hosts参数替代，允许自定义主机列表（包含端口或者端口范围），用于发现其他要加入集群的节点。首选端口是传输端口，通常为.主机列表可以使主机名、IP地址、包含端口的IP地址或者主机、包含端口范围的IP地址或者主机名，如myhost1:[-]discovery.seed_hosts允许自定义主机列表（master节点）（包含端口或者端口范围），用于发现其他要加入集群的节点。首选端口是传输端口，通常为.主机列表可以使主机名、IP地址、包含端口的IP地址或者主机、包含端口范围的IP地址或者主机名，如myhost1:[-]cluster.initial_master_nodes用来指定一个初始集群的所有master节点，默认值为空，代表加入一个已经启动的集群path.config配置文件目录，主要是elasticsearch.yml、logging.yml，默认路径为$ES_HOME/config，在应用程序之外设置config目录非常有用，这样就无需每次升级elasticsearch服务器时都复制配置文件path.data数据目录，最重要的参数之一，可以定义一个或者多个目录（在不同磁盘中），可以用于存储索引数据，当定义多个目录是，对它们的管理与RAID类似（es将所有磁盘视为单个磁盘，它是所有组成部分的综合），倾向于使用具有最大可用空间的位置path.workes存储临时文件的位置path.logs存放日志文件的位置，这些控制着如何在logging.yml中管理日志path.plugins插件路径，将系统范围的插件放在共享路径中很有用，这种共享路径通常使用网络文件系，可以将所有集群的插件存储在同一个位置index.number_of_shards重要参数，用于控制新创建的索引的标准分片数index.number_of_replicas重要参数，用于控初始副本数ES节点类型详解node.masternode.master节点描述truetrue默认节点，是可以包含数据的主节点falsetrue该节点永远不会成为主节点，它只保存数据，可以将其定义为集群的Workhorsetruefalse该节点仅用作主节点，以避免存储任何数据并拥有可用资源，将是你的集群协调器falsefalse该节点充当搜索均衡器（从节点中获取数据，汇总结果等），这种节点也称为协调器节点或者客户端节点，可用作通信节点。最常用的节点是第一种，如果有非常大的集群或者特殊需求，则可以更改节点的使用范围，以更好的搜索和聚合服务。要拥有高可用集群，至少需要3个作为主节点的节点，意味着minimum_master_nodes的值将设置为2。为了防止查询和聚合在集群中造成不稳定，可以使用协调器（或客户端/代理）节点来提供与集群的安全通。协调器节点可以轻松的关闭/终止（kill）或从集群删除而不会引起任何问题，他不是主服务器，因此不参与集群功能并且不包含数据，不会由于它的故障进行数据重定位或复制。
节点说明的官方参考文档