Elasticsearch 线上问题排查——搞一天了，明天还要给客户解决这个问题

Posted 2021-10-03 铭毅天下

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Elasticsearch 线上问题排查——搞一天了，明天还要给客户解决这个问题相关的知识，希望对你有一定的参考价值。

1、线上问题

线上问题描述：

原来是聊天形式，比较冗长，精简后的问题描述如下：

症状：新增节点后，shard 没有分配到新节点上。如下图所示：

2、问题排查

我的大致排解思路：

如下第一、第二、第三......代表排查问题的推进步骤。

2.1 第一：确定节点角色划分，核实未被分配的节点类型。

仅主节点是不参与分片数据落地存储的，这是认知大前提。

经对方核实，未分配的节点的确是数据节点。

集群有3个候选主节点，3个数据节点，其中1个数据节点为新添加的节点。

2.2 第二：关闭索引再打开试试。

close 再 open 之前验证过会走重新分配机制，部分场景适用。

经对方核查，没有生效。

2.3 第三：独立创立一个新索引，设置3个副本。

分片分配策略是：主、副本会分配到不同的节点上。

多个副本，如果数据节点够多，肯定会相对均匀的分片到多个节点。

经核查：仍然无法分配到新增的数据节点。

不过，此时看截图，已有了未分配的灰色分片。

2.4 第四：查看分片未分配的原因。

排查方法：

GET _cluster/allocation/explain

这时候，客户反馈：“我设置了节点踢出集群的设置”。

我的第一反应：“和这个有关系，为什么要设置？！”

且 explain 执行结果验证了刚才的推断：

“cannot allocate because allocation is not permitted to any of the nodes”。

2.5 第五：为什么设置？在哪里设置的？如何设置的？

为什么设置？

客户反馈：“我看书上写的只要有节点离开集群就会触发 rebalance。所以就设置了这个参数。”

在哪里设置？

经反复确认，是集群层面的设置，非索引层面。

起初认为是索引层面的设置，我单独验证后不对，才想起来是集群层面的配置。

如何设置的？

这个之前的博文：Elasticsearch集群管理之1——如何高效的添加、删除节点？中讲过，我自己也在实战环境中用过。

命令行如下：

PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : "10.0.0.1"
  }
}

2.6 取消这个设置就会恢复新节点的分片分配。

我推荐的命令行如下：

PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : ""
  }
}

经客户验证也是 ok 的。

3、我的几点观察和思考

3.1 关于 head 插件和 Kibana dev tools 的选型

head 插件在集群节点、分片可视化方面做得的确不错。

如果在 1.X版本、2.X版本，由于当时 Kibana 功能还不尽完善，甚至还没有被 Elastic 官方收购，选型 head 插件做问题排查无可厚非。

但是，5.X、6.X、7.X 后，Kibana 已经有了突飞猛进的发展，无论是 dev tools 的命令行提示功能，还是多维度的可视化监控。

head 插件做命令行的调试的确稍显笨拙，就类似早期的C、C++编译器 VC6.0一样。

而 Kibana dev tools 类似 VS2020+版本或者开源的 Codeblocks，用过你会发现“如丝般顺滑”般的效率提升。

3.2 关于优化参数配置

我自己在管理集群、维护集群的阶段，也是看到网上有好的优化参数、新版本新特性参数都会在集群中试验，对比看看有没有功能提升或者性能改善。

但，一定得了解参数的确切含义、函数的用途、加与不加对集群或分片等层面的影响；明确相关参数的应用背景，贴合自己应用场景的经验证 ok 才可以使用。

且，一定得先小范围测试环境没有问题，甚至连续3天+没有问题后，才能有的放矢的应用到生成环境。

比如：线程池队列的参数优化，和 CPU 核数相关，不见得是放之四海而皆准的“万能参数”。

3.3 关于设置，在哪个层面设置？

从全局角度考虑，Elasticsearch 设置分为：集群层面设置、索引层面设置等。

而集群层面设置又细分为：

临时设置
永久设置
配置文件设置

索引层面设置又细分为：

静态设置
1. 在索引创建阶段或者关闭索引阶段设置。
动态设置
1. 通过 update-index-settings 方式随时更新设置。

如上图所示，不同的设置含义不同。

需要设置前仔细核对各个参数的含义以及各个参数的设置方式。

3.4 设置生效容易，使得设置失效一样得会

参数生效、参数失效是一对“好兄弟”，两个都得灵活掌握。

设置完参数、参数生效的同时要考虑：如何回退？如何恢复到没有加参数的原始状态。

比如：前面设置的 "cluster.routing.allocation.exclude._ip" : ""，不加具体的 IP 就是回退、不设置的含义。

官方对于设置回退有没有说明呢？

有的，官方明确说明如下：

You can reset persistent or transient settings by assigning a null value.

也就是我们上面的命令行操作更严谨的写法应该是：

PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : null
  }
}

如果有标准写法，上面的这个才是最正宗、最标准的写法。

4、小结

事后观察，只通过后面的第四、五、六步，就能定位问题的根本原因。

但，毕竟不在现场，多去了解问题的来龙去脉，更有助于辅助解决问题。

复盘总结一下，希望对大家也有所帮助。

参考

集群层面设置
- https://www.elastic.co/guide/en/elasticsearch/reference/7.14//cluster-update-settings.html
索引层面设置
- https://www.elastic.co/guide/en/elasticsearch/reference/7.x/index-modules.html