ElasticSearch集群常规检查及优化

从2014年开始接触ElasticSearch到现在已8年有余，由单点使用、主从复制、冷热架构到ILM机制的使用。这些年踩过不少坑，也总结了一些常规检查及优化方法今天分享给大家。

健康状态

集群是否健康，通常由三种状态颜色区分green、yellow、red。非green状态通常由于有分片处于未分配状态导致，如果有副本分配未分配则会变为yellow，若主分片存在问题则直接为red。可以通过这么几个接口进行查看处理：

1.查看集群状态
GET _cluster/health

2.查看索引列表
GET _cat/indices?v
若要返回json列表格式，则使用
GET _cat/indices?format=json

3.查看分片列表
GET _cat/shards

4.查看集群节点分配
GET _cluster/allocation/explain

角色分配

集群通常至少由两种角色的节点组成，master节点和data节点，那我们如何判断角色配置的合理与否呢？官方建议，当节点总数大于5个的时候，需要将主节点、协调节点与data节点进行独立，也就是每一个节点只能承担一种角色。

主节点(需要至少3个)

node.master:true
node.data:false
node.ingest:false

协调节点（需要至少2个）

node.master:false
node.data:false
node.ingest:true

数据节点

node.master:false
node.data:true
node.ingest:false

分片迁移

当集群数据节点发生波动的时候，则意味着分片会进行迁移确保集群数据的稳定，这样迁移的速度则会直接决定造成影响的大小，可以调整集群配置参数进行优化：

PUT _cluster/settings
{
    "persistent": {
        "cluster":{
            "routing": {
                "allocation": {
                    "cluster_concurrent_rebalance": 2, //可以提升集群维度并发均衡的分片数
                    "node_concurrent_recoveries": 4 //可以提升单点兵法迁移恢复的分片数，不建议超过节点的CPU数量
                }
            }
        },
        "indices":{
            "recovery": {
                "max_bytes_per_sec": "60mb" //用于限制网络，取决于所使用服务器环境局域网内传输速率
            }
        }
    }
}

索引误删保护

默认情况下删除索引可以通过关键字携带通配符模糊批量删除索引，若在投产环境中有人误操作后果不堪设想，那么防止这种结局的产生也有对应的配置可供参考。

PUT _cluster/settings
{
    "persistent":{
        "action.destructive_"requires_name": true
    }
}

主节点数量合理性

上面有写主节点数量需要至少三个，那么是根据什么计算的，集群配置又是否合理如何确认。可以通过查看集群配置参数discovery.zen.minimum_master_nodes与以下公式计算结构进行对比

minimum_master_nodes=floor(master_nodes/2 +1)
//如可选主节点数量master_nodew为3个的话则最小主节点数量discover_zen.minimum_master_nodes应该为2

集群的高可用

若应用场景对数据可用性要求很高，如应用于关键流程上核心数据的全文检索则需要检查集群是否有通过配置cluster.routing.allocation.awareness.attributes引入可用区概念。

慢请求检查

有时候慢请求会导致整个集群卡住，类似关系型数据库中出现锁库的场景。那么我们可以通过查询集群中的慢请求任务，若有必要可取消之以释放资源。

GET _cat/tasks //查询任务列表

POST _tasks/{taksId}/_cancel //根据任务ID取消任务

GET _cat/pending_tasks //查询主节点Pending 任务

存储容量

ES集群对存储容量默认有根据不同的水位线进行保护，若超过水位线则无法再提供写入特性。我们可以监视集群存储占用情况，亦可根据实际服务器存储配置调高水位线（比率取决于服务器空间规模）。当然如果出现空间满了的状况，还是建议及时扩容、删除冗余废弃数据或停止写入，防止数据丢失。

PUT _cluster/settings
{
    "persistent":{
        "cluster.routing.allocation.disk.watermark.low": 85%,
        "cluster.routing.allocation.disk.watermark.high": 90%,
        "cluster.routing.allocation.disk.watermark.flood_stage": 95%
    }
}

硬资源合理性

• 通常建议JVM堆内存大小控制在30GB以内，且不宜超过系统总内存的1/2，以确保给文件缓存留有足够的内存使用。
• 需确保各角色节点堆内存大小及CPU配置一致性，这样以来方可更好地分摊集群压力，避免由于单节点性能处理过低时拖慢整个集群的处理速率。
• 数据节点内存与磁盘的配置应该控制在合理的比例范围内，有助于提升集群的读写性能。比值的上升则意味着单节点存储的数据越少，即更多的数据可以缓存在文件系统中，读取性能则更高。通常建议核心业务场景控制在16以内，日志则可以为32、48、96甚至更高。

分片数的合理性

通常单个索引分片数应该为数据节点数的整数倍数，如数据节点数为5个，那分片数可设置为5、10、15等，当然每个分片可承载的存储量可控制在30G-50G范围内，这样以来亦可对分片数的确定行程一定的逻辑。若已有设置不合理的状况出现，亦可通过激活自动均衡配置cluster.routing.rebalance.enabled:true来启用自动均衡机制。

mapping字段检查

mapping字段数过多有字段爆炸的风险，给master节点带来超重负担，亦会影响集群的写入性能。因此需严格控制字段的定义，最好关闭动态manpping，类似关系型数据库先通过template建立字段结构。针对字符串类型的字段，应根据场景明确为keyword还是text（支持分词及全文检索），以节省存储空间。

segment数是否过多

segment数过多会影响读写性能，可在业务低峰期执行强制合并操作：

POST /{index}/_forcemerge?max_mum_segments=10
//max_mum_segments可以用分片大小/2G 估算获得