【最佳实践】巡检项：Elasticsearch Service（ES）集群健康值

原创

shanizeng

修改于 2023-04-13 16:33:28

3.1K0

修改于 2023-04-13 16:33:28

文章被收录于专栏：Elasticsearch ServiceElasticsearch Service

文档中涉及到的所有 DSL 命令，都可以通过 kibana 的 dev tools 执行

集群健康值的含义

通过集群健康值的状态，可以反映出集群当前索引分片的情况。

0：绿色，表示集群所有主分片和副本分片都可用，集群处于最健康的状态。

1：黄色，表示所有的主分片均可用，但存在不可用副本分片。此时，搜索结果仍然是完整的，但集群的高可用性在一定程度上受到影响，一般会自动恢复。

2：红色，表示至少一个主分片以及它的全部副本分片均不可用。集群处于红色状态意味着已有部分数据不可用，搜索只能返回部分数据，而分配到丢失分片上的请求会返回异常。

集群状态为红（red）问题分类

节点失联

问题表现

监控体现

通过控制台的“在线节点数”，可以关注到节点的在线情况

日志体现

出现关键字：“node-left”；“master left”；“although publication of cluster state version completed ago”

原因分析和解决方案

1、“although publication of cluster state version completed ago”

原因分析：数据节点负载过高，与主节点通信超时引发失联

查看监控指标，“最大 CPU 利用率”、“集群1分钟最大负载”等资源相关有突增，判断可能是业务行为引起；

查看监控指标，若“平均每秒写入次数”、“单周期查询cache命中次数”等读写量有突增，确认可能是业务上的读写请求突增导致；若请求量没有太大变化，查看“磁盘有IO操作的时间与总时间的百分比”、“最大查询延迟”是否有突增，确认可能是有跨时间大或者大聚合的查询请求导致。

解决方案：

1）确认集群是否有热点现象——“最大 CPU 利用率”与“平均 CPU 利用率”相差大，同时尽可能降低当前的读写；

2）若有热点现象——登录 cerebro，确认分片分布是否均匀，若分布不均，可临时将负载大节点上的分片搬迁到负载小的节点；

3）若无热点想象，且请求量持续处于高位——建议进行扩容，扩容的量可根据集群规格和容量配置评估进行测算；

4）若长时间（20min）以内，集群未能自动恢复，及时提单解决。

2、“node-left”、“master left”

原因分析：通常是节点 hang 死，或节点上文件系统损坏引发节点失联
解决方案：提单解决

分片损坏

问题表现

监控体现

指标“健康状态”显示为红色

尝试重新分配分片

POST _cluster/reroute?retry_failed=true

若执行后分片依然没有恢复，及时提单

磁盘利用率到达水位

ES 集群节点的磁盘利用率超过85%时会导致新的分片无法分配

问题表现

监控体现

指标“硬盘存储利用率”中的最大值>85%

cerebro 体现

在 rest 执行

GET /_cluster/allocation/explain

"explanation"字段显示报错信息

the node is above the low watermark cluster setting [cluster.routing.allocation.disk.watermark.low=85%], using more disk space than the maximum allowed [85.0%], actual free: [6.210757516951154%]"

原因分析和解决方案

原因分析：用户集群的数据量达到磁盘容量的水位线
解决方案：

将部分过期或者不重要的数据进行删除；
若集群因为磁盘满无法进行数据删除，可临时将集群磁盘水位适当调大，再行删除；

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

删除数据后切记将水位线复原！

PUT _cluster/settings
{
   "transient":{
      "cluster.routing.allocation.disk.watermark.high":"null",
      "cluster.routing.allocation.disk.watermark.low":"null"
    }
}

若没有可删除的数据，需要进行磁盘扩容；
若集群为7.5.1之前的版本，在执行完以上操作后，需要关闭只读状态

关闭索引只读

PUT _all/_settings
{
            "index.blocks.read_only_allow_delete": null
}

关闭集群只读

PUT _cluster/settings
{
            "persistent": {
                "cluster.blocks.read_only_allow_delete": null
            }
}

若集群为7.5.1之后的版本，执行完1.2.后，集群状态会自动恢复;
建议配置“最大磁盘利用率>80%”的告警，及时关注集群使用情况

问题表现

监控体现

观察当前集群分片数，对比集群理论上可容纳分片数。默认情况下，单节点可容纳1000分片

日志体现

出现关键字“this action would add [1] total shards, but this cluster currently has [29998]/[3000] maximum shards open”

原因分析和解决方案

原因分析：单个节点的索引分片有最大数限制，超出限制后会导致无法新增分片
解决方案：

查看当前集群单个节点可容纳的最大分片数

GET _cluster/settings?include_defaults&flat_settings

2）根据集群情况，调整最大分片数大小。注意，这里调整的是单个节点最大分片数，集群的最大总分片数需要用单节点最大分片数*节点数。调整的原则基本可参考2C对应1000分片（建议让用户自行调整）

PUT _cluster/settings
{
    "persistent":{
        "cluster":{
            "max_shards_per_node":5000 #根据集群情况进行调整
        }
    },
    "transient":{
        "cluster":{
            "max_shards_per_node":5000
        }
    }
}

集群状态为黄（yellow）问题分类

集群状态为黄与为红的情况不同，当为黄时仅表示有副本分片不可用，对集群使用不一定有直接影响，需要进一步定位分析。

无影响

问题表现

监控体现

日志体现

无“error”、“warning”等日志

cerebro 体现

原因分析和解决方案

原因分析：监控中除了“集群健康状态”异常，没有其他异常项，cerebro 中无⚠️类似标识。基本可判断为此集群是有副本分片在正常初始化或者搬迁中。
解决方案

建议用户耐心等待集群变绿，并告知用户是有副本在进行初始化，不影响使用。初始化的时间需要根据集群当前的读写情况以及分片数据量来确定；
若长时间未恢复，可手动触发一次分片分配任务

POST _cluster/reroute?retry_failed=true

磁盘利用率高

问题表现

监控体现

原因分析和解决方案

和以上集群“健康值为红”的解决方案一致

索引副本分片数大于集群节点数

问题表现

cerebro 体现

原因分析和解决方案

原因分析：对于单个索引，副本数不可超过数据节点的个数
解决方案

调整索引副本数，降低至小于数据节点数

PUT /indexname(索引名)/_settings
{
"number_of_replicas" : 2 #合理值，由用户决定
}

索引分片恢复速度超出最大并发数

问题表现

cerebro 体现

在 rest 执行

GET /_cluster/allocation/explain

"explanation"字段显示报错信息

{
	"node_id": "***",
	"node_name": "mastersha",
	"transport_address": "***",
	"node_decision": "throttled",
	"deciders": [{
		"decider": "throttling",
		"decision": "THROTTLE",
		"explanation": "reached the limit of incoming shard recoveries [2], cluster setting [cluster.routing.allocation.node_concurrent_incoming_recoveries=2] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
	}]
}
 
{
	"node_id": "***",
	"node_name": "master",
	"transport_address": ***,
	"node_decision": "no",
	"store": {
		"matching_sync_id": true
	},
	"deciders": [{
			"decider": "same_shard",
			"decision": "NO",
			"explanation": "the shard cannot be allocated to the same node on which a copy of the shard already exists [[index_execution][2], node[***], [P], s[STARTED], a[id=***]]"
		},
		{
			"decider": "throttling",
			"decision": "THROTTLE",
			"explanation": "reached the limit of outgoing shard recoveries [2] on the node [***] which holds the primary, cluster setting [cluster.routing.allocation.node_concurrent_outgoing_recoveries=2] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
		}
	]
}

原因分析和解决方案

原因分析：集群具有节点最大并发分片数，当集群当前的恢复速度到达并发阈值时，超出的分片会暂时无法分配而变黄
解决方案：

判断当前集群负载情况，若不高的话可适当调高并发速度，若过高的话建议用户耐心等待恢复。注意：调整的值需要根据集群规格判断，尽量不要调高

PUT _cluster/settings
{
    "transient":{
"cluster.routing.allocation.node_concurrent_recoveries":10,		"cluster.routing.allocation.node_concurrent_incoming_recoveries":10,
"cluster.routing.allocation.node_initial_primaries_recoveries":10,	"cluster.routing.allocation.node_concurrent_outgoing_recoveries":10,	
"cluster.routing.allocation.cluster_concurrent_rebalance":10,
"indices.recovery.max_bytes_per_sec":"100mb"
}, // 临时
}

场景

Q：当集群变红时，是否会影响业务使用？

A：是。集群为红色说明有主分片不可用，影响数据到此分片的读写。

Q：集群健康值为红的时候可以重启恢复么？

A：不建议重启。可能会导致重启流程卡住或者分片损坏。

Q：如何避免集群状态变红（red）？

A：对于数据容灾性要求高的场景，建议添加副本分片。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

Elasticsearch Service

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

Elasticsearch Service

登录后参与评论

0 条评论

热度