版本 ElasticSearch 7.9.3
集群简介
nodes： 10
JVM Heap: 288 GB，
RAM: 32G/node
分片数量限制
某 ES 集群忽然没有数据了，查到写入端的报错日志如下：
官方解答
临时解决办法是将分片数量限制放开到 10000，在 Kibana 中的 Dev Tools 页面直接执行如下请求：
PUT _cluster/settings
{
"transient" : {
"cluster.max_shards_per_node": 10000
}
}
注意：此时并没有解决问题，只是恢复了数据写入。
限制索引数量
ES 索引根据空间名和日期做区分，对于目前不会用到的空间，关闭日志收集，减少索引数量，防止过早达到 max_shards 的限制。
日志字段缩减
日志字段有上百个，而分析时只用到少部分字段，可以通过配置 template 忽略掉不必要的字段。
Index Template 更新
新建一个 Component Template，将 Component 用于新建的 Index Template，配置更高的优先级（Priority）使其生效。
主要修改点:
mappings.dynamic: false，不包含在 Mapped fields 的字段都不会建立索引。- 需要用到的字段都定义在 Mapped fields 中。
效果
修改前：
修改后：
大幅减少索引字段数量。
注意
可能通过配置 mappings._source.includes 只保留我们关注的字段，详见：https://www.elastic.co/guide/en/elasticsearch/reference/7.9/mapping-source-field.html#include-exclude
但是考虑到保留完整 source json 方便定位问题，磁盘容量也足够，所以只是缩减了被索引的字段数量。
组合索引模版，按匹配的优先级生效，一个索引只会匹配一个模版，所以 components 要在每个模版中都添加
分片数量调整
每个节点上可以存储的分片数量与可用的堆内存大小成正比关系，但是 Elasticsearch 并未强制规定固定限值。这里有一个很好的经验法则：确保对于节点上已配置的每个 GB，将分片数量保持在 20 以下。如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片，但是在此限值范围内，您设置的分片数量越少，效果就越好。一般而言，这可以帮助集群保持良好的运行状态。
所以前面我们把分片数量限制放开到 10000， 是不合理的。
目前每个节点的堆内存是 32G，所对应的最大分片数量在 640 个；10 台节点对应 6400 个分片，2 副本存 32 天，按天分索引，每天可新增的主分片（Primaries）数量是 100 个。
分片过小会导致段过小，进而致使开销增加。您要尽量将分片的平均大小控制在至少几 GB 到几十 GB 之间。对时序型数据用例而言，分片大小通常介于 20GB 至 40GB 之间。
我们期望每个分片在 20-40G 之间，因此需要对不同大小的索引，设置不同数量的分片。
结论
index-a-*: 50 ～ 100 （取：54）
index-b-*: 2 ~ 3 （取：2）
index-c-*: 1 ~ 2 （取：2）
index-d-*: 1 （取：1）
如果要存 60 天，稍微降低一点集群的稳定性，节点最大分片数 700 ，分到每天是 59 ， 按结论的分片方案应该可能也可以扛得住。
