ES 集群关键状态指标

ES监控状态指标分三个级别：

1：集群级别：集群级别的监控主要是针对整个ES集群来说，包括集群的健康状况、集群的状态等。
2：节点级别：节点级别的监控主要是针对每个ES实例的监控，其中包括每个实例的查询索引指标和物理资源使用指标。
3：索引级别：索引级别的监控主要是针对每个索引来说，主要包括每个索引的性能指标。

1集群级别：

查看方法：

api获取：http://ip:9200/_cluster/health?pretty 或者 Kibana的开发工具Dev Tools中执行 ：

查看集群健康状态

GET _cluster/health

{  "cluster_name": "jp-pte-es-hot",  "status": "green",  "timed_out": false,  "number_of_nodes": 46,  "number_of_data_nodes": 30,  "active_primary_shards": 4857,  "active_shards": 12674,  "relocating_shards": 0,  "initializing_shards": 0,  "unassigned_shards": 0,  "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": 100}指标说明：status：集群状态，分为green、yellow和red。 number_of_nodes/number_of_data_nodes:集群的节点数和数据节点数。 active_primary_shards：集群中所有活跃的主分片数。 active_shards：集群中所有活跃的分片数。 relocating_shards：当前节点迁往其他节点的分片数量，通常为0，当有节点加入或者退出时该值会增加。 initializing_shards：正在初始化的分片。 unassigned_shards：未分配的分片数，通常为0，当有某个节点的副本分片丢失该值就会增加。 number_of_pending_tasks：是指主节点创建索引并分配shards等任务，如果该指标数值一直未减小代表集群存在不稳定因素 active_shards_percent_as_number：集群分片健康度，活跃分片数占总分片数比例。 number_of_pending_tasks：pending task只能由主节点来进行处理，这些任务包括创建索引并将shards分配给节点。

查看集群状态信息

#集群状态信息 ，整个集群的一些统计信息，例如文档数、分片数、资源使用情况等信息，从这个接口基本能够获取到集群所有关键指标项：

    GET _cluster/stats?pretty

输出数据量较大，省略关键指标说明： indices.count：索引总数。 indices.shards.total：分片总数。 indices.shards.primaries：主分片数量。 docs.count：文档总数。 store.size_in_bytes：数据总存储容量。 segments.count：段总数。 nodes.count.total：总节点数。 nodes.count.data：数据节点数。 nodes. process. cpu.percent：节点CPU使用率。 fs.total_in_bytes：文件系统使用总容量。 fs.free_in_bytes：文件系统剩余总容量。

2：节点级别

节点监控

GET _nodes/stats/thread_pool?pretty

node线程组状态

GET _nodes/stats/thread_pool?pretty

输出信息较多部分省略。。。。。。。。。。。。。。。。。。。。       "indices": {         "docs": {           "count": 8111612,   # 显示节点上有多少文档           "deleted": 16604    # 有多少已删除的文档还未从数据段中删除         },         "store": {           "size_in_bytes": 2959876263  # 显示该节点消耗了多少物理存储         },         "indexing": {       #表示索引文档的次数，这个是通过一个计数器累加计数的。当文档被删除时，它不会减少。注意这个值永远是递增的，发生在内部索引数据的时候，包括那些更新操作            "index_total": 17703152,            "is_throttled": false,            "throttle_time_in_millis": 0    # 这个值高的时候，说明磁盘流量设置太低          },。。。。。。。。。。。。。。。          },          "search": {               "open_contexts": 0,   # 主动检索的次数，            "query_total": 495447,    # 查询总数            "query_time_in_millis": 298344,   # 节点启动到此查询消耗总时间，  query_time_in_millis / query_total的比值可以作为你的查询效率的粗略指标。比值越大，每个查询用的时间越多，你就需要考虑调整或者优化。            "query_current": 0,　　　　　　　　 #后面关于fetch的统计，是描述了查询的第二个过程（也就是query_the_fetch里的fetch)。fetch花的时间比query的越多，表示你的磁盘很慢，或者你要fetch的的文档太多。或者你的查询参数分页条件太大，（例如size等于1万           "fetch_total": 130194,           "suggest_current": 0         },         "merges": { # 包含lucene段合并的信息，它会告诉你有多少段合并正在进行，参与的文档数，这些正在合并的段的总大小，以及花在merge上的总时间。　　　　　　　　　　　　　 如果你的集群写入比较多，这个merge的统计信息就很重要。merge操作会消耗大量的磁盘io和cpu资源。如果你的索引写入很多，你会看到大量的merge操作。。。。。。。。。。。。。。。         },         "fielddata": {   #显示了fielddata使用的内存，fielddata用于聚合、排序等。这里也有一个淘汰数，不像filter_cache，这里的淘汰数很有用，它必须是0或者接近0，因为fielddata 不是缓存，任何淘汰的代价都是很大的，必须要避免的。如果你看到了淘汰，你必须重新评估你的内存情况，关于fielddata的限制，以及查询，或者三者全部。。。。。。。。。。。。。。。。         },         "segments": { 告诉你当前节点的lucene 段的个数，这可能是一个很重要的数字。大多数的索引应该在50到150个段左右，即便是几T大小的数十亿的文档。大量的段会带来合并的问题（例如：合并赶不上段的产生）。注意这个统计是对一个节点上所有的索引而言的　　　　　　　　　　　　　　其中内存的统计，可以告诉你Lucene的段自身需要多少内存。这里包括基础的数据结构，包括提交列表，词典，bloom过滤器等。段的数量多会增加承载这些数据结构的开销，这个内存的使用就是对这个开销的度量。关键指标说明： indices.docs.count：索引文档数。 segments.count：段总数。 jvm.heap_used_percent：内存使用百分比。 thread_pool.{bulk, index, get, search}.{active, queue, rejected}：线程池的一些信息，包括bulk、index、get和search线程池，主要指标有active（激活）线程数，线程queue（队列）数和rejected（拒绝）线程数量。以下一些指标是一个累加值，当节点重启之后会清零。 indices.indexing.index_total：索引文档数。 indices.indexing.index_time_in_millis：索引总耗时。 indices.get.total：get请求数。 indices.get.time_in_millis：get请求总耗时。 indices.search.query_total：search总请求数。 indices.search.query_time_in_millis：search请求总耗时。indices.search.fetch_total：fetch操作总数量。 indices.search.fetch_time_in_millis：fetch请求总耗时。 jvm.gc.collectors.young.collection_count：年轻代垃圾回收次数。 jvm.gc.collectors.young.collection_time_in_millis：年轻代垃圾回收总耗时。 jvm.gc.collectors.old.collection_count：老年代垃圾回收次数。 jvm.gc.collectors.old.collection_time_in_millis：老年代垃圾回收总耗时。

参考文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html

3：索引级别

索引级别

可以查看所有index的相关信息，方法如下：
GET _stats

输出信息较多部分省略。。。。。indexname.primaries.docs.count：索引文档数量。以下一些指标是一个累加值，当节点重启之后会清零。 indexname.primaries.indexing.index_total：索引文档数。 indexname.primaries.indexing.index_time_in_millis：索引总耗时。 indexname.primaries.get.total：get请求数。 indexname.primaries.get.time_in_millis：get请求总耗时。 indexname.primaries.search.query_total：search总请求数。 indexname.primaries.search.query_time_in_millis：search请求总耗时。indices.search.fetch_total：fetch操作总数量。 indexname.primaries.search.fetch_time_in_millis：fetch请求总耗时。 indexname.primaries.refresh.total：refresh请求总量。 indexname.primaries.refresh.total_time_in_millis：refresh请求总耗时。 indexname.primaries.flush.total：flush请求总量。 indexname.primaries.flush.total_time_in_millis：flush请求总耗时。

参考信息：
https://blog.csdn.net/joez/article/details/52171219
https://blog.csdn.net/u010824591/article/details/78614505