Elasticsearch版本：6.2.4

一、集群健康

一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它 可能有一百个数据节点、三个单独的主节点，以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。

不管集群扩展到多大规模，你都会想要一个快速获取集群状态的途径。Cluster Health API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好，或者警告你集群某个地方有问题。

让我们执行一下 cluster-health API 然后看看响应体是什么样子的：

1
GET _cluster/health

和 Elasticsearch 里其他 API 一样，cluster-health 会返回一个 JSON 响应。这对自动化和告警系统来说，非常便于解析。响应中包含了和你集群有关的一些关键信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
    cluster_name: "elasticsearch",
    status: "yellow",
    timed_out: false,
    number_of_nodes: 3,
    number_of_data_nodes: 3,
    active_primary_shards: 13,
    active_shards: 30,
    relocating_shards: 0,
    initializing_shards: 0,
    unassigned_shards: 4,
    delayed_unassigned_shards: 0,
    number_of_pending_tasks: 0,
    number_of_in_flight_fetch: 0,
    task_max_waiting_in_queue_millis: 0,
    active_shards_percent_as_number: 88.23529411764706
}

响应信息中最重要的一块就是 status 字段。状态可能是下列三个值之一：

  • green

    所有的主分片和副本分片都已分配。你的集群是 100% 可用的。

  • yellow

    所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果更多的分片消失，你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。

  • red

    至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。

green/yellow/red 状态是一个概览你的集群并了解眼下正在发生什么的好办法。剩下来的指标给你列出来集群的状态概要：

  • number_of_nodes 和 number_of_data_nodes 这个命名完全是自描述的，代表ElasticSearch节点数量。
  • active_primary_shards 指出你集群中所有索引的活跃的主分片数量。
  • active_shards 是涵盖了所有索引的所有活跃分片的汇总值，也包括副本分片。
  • relocating_shards 显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0，不过在 Elasticsearch 发现集群不太均衡时，该值会上涨。比如说：添加了一个新节点，或者下线了一个节点。
  • initializing_shards 是刚刚创建的分片的个数。比如，当你刚创建第一个索引，分片都会短暂的处于 initializing 状态。这通常会是一个临时事件，分片不应该长期停留在 initializing 状态。你还可能在节点刚重启的时候看到 initializing 分片：当分片从磁盘上加载后，它们会从 initializing 状态开始。
  • unassigned_shards 是已经在集群状态中存在的分片，但是实际在集群里又找不着（未分配）。通常未分配分片的来源是未分配的副本。比如，一个有 5 分片和 1 副本的索引，在单节点集群上，就会有 5 个未分配副本分片。如果你的集群是 red 状态，也会长期保有未分配分片（因为缺少主分片）。
  • active_shards_percent_as_number代表所有索引的活跃分片占总分片的百分比。

二、集群指标统计

集群统计API可以通过如下命令执行：

1
GET _cluster/stats

1. 索引部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
indices: {
    count: 3,
    shards: {
        total: 30,
        primaries: 13,
        replication: 1.3076923076923077,
        index: {...}
    },
    docs: {
        count: 3,
        deleted: 0
    },
    store: {
    	size_in_bytes: 35195
    },
  • count代表索引数量
  • shards.total代表集群中所有活跃的分片数量，也包括副本分片
  • shard.primaries代表集群中所有活跃的主分片数量
  • docs展示节点内存有多少文档，包括还没有从segments里清除的已删除文档数量
  • store显示集群索引耗用了多少物理存储。这个指标包括主分片和副本分片在内
1
2
3
4
"fielddata": {
    "memory_size_in_bytes": 0,
    "evictions": 0
}
  • field_data 显示 fielddata 使用的内存， 用以聚合、排序等等。这里也有一个驱逐计数。这里的驱逐计数是很有用的：这个数应该或者至少是接近于 0。因为 fielddata 不是缓存，任何驱逐都消耗巨大，应该避免掉。如果你在这里看到驱逐数，你需要重新评估你的内存情况，fielddata 限制，请求语句，或者这三者。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
segments: {
    count: 5,
    memory_in_bytes: 8492,
    terms_memory_in_bytes: 5945,
    stored_fields_memory_in_bytes: 1560,
    term_vectors_memory_in_bytes: 0,
    norms_memory_in_bytes: 640,
    points_memory_in_bytes: 7,
    doc_values_memory_in_bytes: 340,
    index_writer_memory_in_bytes: 0,
    version_map_memory_in_bytes: 0,
    fixed_bit_set_memory_in_bytes: 0,
    max_unsafe_auto_id_timestamp: -1,
    file_sizes: { }
}
  • segments 会展示这个节点目前正在服务中的 Lucene 段的数量。 这是一个重要的数字。大多数索引会有大概 50–150 个段，哪怕它们存有 TB 级别的数十亿条文档。段数量过大表明合并出现了问题（比如，合并速度跟不上段的创建）。注意这个统计值是节点上所有索引的汇聚总数。记住这点。
  • memory 统计值展示了 Lucene 段自己用掉的内存大小。 这里包括底层数据结构，比如倒排表，字典，和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销，这个内存使用量就是一个方便用来衡量开销的度量值。

2. 操作系统和进程部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
os: {
    available_processors: 6,
    allocated_processors: 6,
    names: [
        {
            name: "Linux",
            count: 3
        }
    ],
    mem: {
        total_in_bytes: 24558551040,
        free_in_bytes: 850542592,
        used_in_bytes: 23708008448,
        free_percent: 3,
        used_percent: 97
    }
},
process: {
    cpu: {
        percent: 0
    },
    open_file_descriptors: {
        min: 201,
        max: 221,
        avg: 213
    }
}

OS 和 Process 部分基本是自描述的，不会在细节中展开讲解。它们列出来基础的资源统计值，比如 CPU 和负载。OS 部分描述了整个操作系统，而 Process 部分只显示 Elasticsearch 的 JVM 进程使用的资源情况。

这些都是非常有用的指标，不过通常在你的监控技术栈里已经都测量好了。统计值包括下面这些：

  • CPU
  • 负载
  • 内存使用率
  • Swap 使用率
  • 打开的文件描述符

3. JVM部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
jvm: {
    max_uptime_in_millis: 89144412,
    versions: [
        {
            version: "1.8.0_151",
            vm_name: "Java HotSpot(TM) 64-Bit Server VM",
            vm_version: "25.151-b12",
            vm_vendor: "Oracle Corporation",
            count: 3
        }
    ],
    mem: {
        heap_used_in_bytes: 516307208,
        heap_max_in_bytes: 3168927744
    },
    threads: 111
}

  • max_uptime_in_millis显示Elasticsearch集群运行的时长

  • heap_used_in_bytes/heap_max_in_bytes代表heap_used_percent`

    heap_used_percent 指标是值得关注的一个数字。Elasticsearch 被配置为当 heap 达到 75% 的时候开始 GC。如果你的节点一直 >= 75%，你的节点正处于 内存压力 状态。这是个危险信号，不远的未来可能就有慢 GC 要出现了。

    如果 heap 使用率一直 >=85%，你就麻烦了。Heap 在 90–95% 之间，则面临可怕的性能风险，此时最好的情况是长达 10–30s 的 GC，最差的情况就是内存溢出（OOM）异常。

  • threads代表已配置的线程数量

三、参考链接