Elasticsearch故障诊断常用方法

背景

在大部分情况下，我们遇到的问题都是由一些简单的原因导致的。但由于分布式系统的复杂性，有时候故障现象只出现了一次，并且难以复现，这就需要采取一些措施来缩小可疑的问题范围，虽然不能立刻解决问题，但是可以向前迈进一步。综合来说，当遇到故障时，分析问题有两种思路：

1. 系统化调试思想：从故障的具体现象和具体信息出发，逻辑性地向上推理可能的因素，并逐步排除，渐渐缩小问题范围，直到定位问题。
2. 假设猜测思想：根据故障信息和经验直接猜测故障原因，这种凭空设想在面对简单问题时能比较快速定位，但在面对错综复杂、多种因素混合的问题时更多地需要理性推导。尽管如此，“假设故障原因”仍然很重要，在推导问题过程中，以及不可重现的问题时，需要联想到与其相关的都有哪些因素。

下面介绍一些通用的分析问题方法和工具。

使用Profile API定位慢查询

有时在发起一个查询时，查询会被延迟执行，或者响应时间很慢，查询缓慢可能会有多种原因：分片问题，或者计算查询中的某些元素。ES提供Profile API供用户检查查询执行时间和其他详细信息。Profile API返回所有分片的详细信息，其结果是基于每个分片计算的，每个分片信息主要包含三大部分：1. Query；2. Rewrite Time；3. Collectors。

Profile API让我们清楚地看到查询时间。通过向我们提供有关子查询的详细信息，我们可以清楚地知道在哪个环节查询慢，这是非常有用的。另外，在API返回的结果中，关于Lucene的详细信息也让我们深入了解到ES是如何执行查询的。

1. Query

Query部分由构成Query的元素及它们的时间信息组成。Profile API结果中Query部分的基本组成如下：

• query_type，触发的查询类型。
• lucene，启动查询的Lucene方法。
• time，Lucene执行此查询所用的时间。单位是毫秒。
• breaddown，有关查询的更详细的细节，主要与Lucene参数有关。
• children，具有多个关键字的查询被拆分成相应术语的布尔查询，每个查询都作为单独的查询来执行。每个子查询的详细信息将填充到Profile API输出的子段中。从查询中的子段中，我们可以得到关于哪个搜索项在总体搜索中造成最大延迟的信息。

2. Rewrite Time

由于多个关键字会分解以创建个别查询，所以在这个过程中肯定会花费一些时间。将查询重写一个或多个组合查询的时间被称为“重写时间”（单位为纳秒）。

3. Collectors

在Lucene中，收集器负责收集原始结果，并对它们进行组合、过滤、排序等处理。

使用Explain API分析未分配的分片（Unassigned Shards）

一个ES索引由多个分片组成，由于某些原因，某些分片可能会处于未分配状态（Unassigned），导致集群健康处于Yellow或Red状态，这是一种比较常见的错误信息，导致分片处于未分配的原因可能是节点离线、分片数量设置错误等原因，使用Explain API可以很容易分析当前的分片分配情况。这个API主要为了解决下面两个问题：

1. 对于未分配的分片，给出为什么没有分配的具体原因。
2. 对于已分配的分片，给出为什么将分片分配给特定节点的理由。

接下来我们通过几个例子来演示如何通过Explain API来定位分片分配问题。

诊断未分配的主分片

我们创建一个名为test_idx的索引，该索引只有一个主分片，没有副分片。集群有两个节点，名为A和B。但是在创建索引时，我们设置分配过滤器，使其不能被分配到节点A和B上。

虽然索引能创建成功，但是因为过滤规则的限制，索引分片无法分配到集群仅有的A和B两个节点。此时集群处于Red状态，我们通过Explain API来获取第一个未分配分片的原因解释。

GET /_cluster/allocation/explain

Explain API给出发该分片未分配的原因，由于索引刚创建（unassigned_info），它处于未分配状态（current_state）。由于没有节点允许分配给该分片（allocate_explain），所以无法分配分片（can_allocation）。深入每个节点的决策信息（node_allocation_decisions），可以看到由于索引的过滤器设置，分配操作被decider拦截。decider给出了具体的decider名称，接下来是决策结果及具体的原因（explanation）。