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

我的大致排解思路：

 

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

 

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

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

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

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

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

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

经对方核查，没有生效。

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

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

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

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

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

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

排查方法：

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

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

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

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

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

 • 为什么设置？

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

 • 在哪里设置？

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

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

 • 如何设置的？

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

命令行如下：

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

我推荐的命令行如下：

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.临时设置

 

2.永久设置

 

3.配置文件设置

 

索引层面设置又细分为：

 

1.静态设置

 

    a.在索引创建阶段或者关闭索引阶段设置。

 

2.动态设置

 

    a.通过 update-index-settings 方式随时更新设置。
 
如上图所示，不同的设置含义不同。

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

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

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

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

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

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

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

 

 

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

 

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

 

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