本文详细介绍了Elasticsearch的集群、节点和索引级别的监控指标，包括集群健康状态、节点资源使用、索引性能等关键参数，并提供了计算请求速率和延迟的指标方法。通过对这些指标的监控和分析，可以有效地管理和优化Elasticsearch集群的性能。
注： 部分概念介绍来源于网络
Elasticsearch集群监控状态指标分三个级别
集群级别：集群级别的监控主要是针对整个Elasticsearch集群来说，包括集群的健康状况、集群的状态等。
节点级别：节点级别的监控主要是针对每个Elasticsearch实例的监控，其中包括每个实例的查询索引指标和物理资源使用指标。
索引级别：索引级别的监控主要是针对每个索引来说，主要包括每个索引的性能指标。
一、集群级别
1.1、查看集群健康状态 (GET _cluster/health)
curl -X GET 'http://127.0.0.1:9200/_cluster/health?pretty'
{
"cluster_name" : "elasticsearch-1",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 28,
"active_shards" : 55,
"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.0
}1.2、关键指标说明
| 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分配给节点 |
1.3、查看集群状态信息 (GET _cluster/stats?pretty)
#集群状态信息 ，整个集群的一些统计信息，例如文档数、分片数、资源使用情况等信息，从这个接口基本能够获取到集群所有关键指标项.
curl -X GET 'http://127.0.0.1:9200/_cluster/stats?pretty'
GET /_cluster/stats/nodes/<node_id>
返回集群统计信息。返回基本的索引指标和集群节点的信息。stats有两种请求方式，其中第二种方式需要一个路径参数：逗号分隔的节点id或节点名称列表。stats还接受一个参数timeout：等待响应的超时时间，如果超时则请求失败并返回错误，默认30s。返回结果主要包含两大部分：indices和nodes。
1.4、关键指标说明
| indices.count | 索引总数 |
| indices.shards | 分片信息：总数、主分片数、副本分片数、以及最大、最小、均值 |
| indices.shards.total | 分片总数 |
| indices.shards.primaries | 主分片数量 |
| indices.docs | 文档信息：文档数、删除的文档数 |
| indices.docs.count | 文档总数 |
| indices.store | 存储大小 |
| indices.store.size_in_bytes | 数据总存储容量 |
| indices.fielddata | 字段缓存信息 |
| indices.query_cache | 查询缓存信息 |
| indices.completion | 自动补全信息 |
| indices.segments | 段信息 |
| indices.segments.count | 段总数 |
| nodes.count | 节点总数、以及各角色节点数 |
| nodes.count.total | 总节点数 |
| nodes.count.data | 数据节点数 |
| nodes.versions | 版本 |
| nodes.os | 操作系统信息：处理器数量、系统名称、内存 |
| nodes.process | 进程信息 |
| nodes.process.cpu.percent | 节点CPU使用率 |
| nodes.jvm | java虚拟机信息：版本、内存、线程 |
| nodes.fs | 文件系统信息 |
| nodes.fs.total_in_bytes | 文件系统使用总容量 |
| nodes.fs.free_in_bytes | 文件系统剩余总容量 |
| nodes.plugins | 插件信息 |
| nodes.network_types | 网络信息 |
| nodes.discovery_types | 自动发现信息 |
| nodes.packaging_types | 发布包信息 |
二、节点级别
2.1、节点监控, 即node线程组状态 (GET _nodes/stats/thread_pool?pretty)
curl -X GET 'http://127.0.0.1:9200/_nodes/stats/?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过滤器等。段的数量多会增加承载这些数据结构的开销，这个内存的使用就是对这个开销的度量。
}2.2、关键指标说明
| name | 节点名 |
| roles | 节点角色 |
| 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 | 老年代垃圾回收总耗时 |
2.3、备注：需要计算的指标分为两类，分别为请求速率指标和请求处理延迟指标。
1、index_per_min：每分钟索引请求数量。计算公式如下：
索引请求率=(index_total两次采集差值)/(系统时间差值（ms）)×60000 (公式1)
2、indexAverge_per_min：索引请求处理延迟。计算公式如下：
索引延迟=(index_time_in_millis两次采集差值)/(index_total两次采集差值) (公式2)
get_per_min：每分钟get请求数量，计算公式如(公式1)，更改相应参数。
getAverage_per_min：get请求处理延迟，计算公式如(公式2) ，更改相应参数。
merge_per_min：每分钟merge请求数量，计算公式如(公式1)，更改相应参数。
mergeAverage_per_min：merge请求处理延迟，计算公式如(公式2) ，更改相应参数。
searchQuery_per_min：每分钟query请求数量，计算公式如(公式1)，更改相应参数。
searchQueryAverage_per_min：query请求延迟，计算公式如(公式2) ，更改相应参数。
searchFetch_per_min：每分钟fetch请求数量，计算公式如(公式1)，更改相应参数。
searchFetchAverage_per_min：fetch请求延迟，计算公式如(公式2) ，更改相应参数。
youngGc_per_min：每分钟young gc数量，计算公式如(公式1)，更改相应参数。
youngGcAverage_per_min：young gc请求延迟，计算公式如(公式2) ，更改相应参数。
oldGc_per_min：每分钟old gc数量，计算公式如(公式1)，更改相应参数。
oldGcAverage_per_min：old gc请求延迟，计算公式如(公式2) ，更改相应参数。三、索引级别
3.1、可以查看所有index的相关信息 (GET _stats?pretty)
curl -X GET 'http://127.0.0.1:9200/_stats?pretty
3.2、关键指标说明(indexname指索引名称)
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请求总耗时。
indexname.primaries.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请求总耗时。
索引计算指标和节点监控的计算指标一样分为两类，分别为请求速率指标和请求处理延迟指标并且计算方式一样
3.3、备注
在节点监控和索引监控时可以获取到一些操作数据，例如index、search、get等。对于这些指标参数有一些需要注意的地方：
search.query
query_total：查询总数，指的每个分片上的查询次数，一般如果有五个分片的话进行一次查询query_total = 5。注意在统计指标的时候应该统计的是total分片的，不应该只统计主分片的值，因为查询请求不一定全部分发到主分片。
get
total:get请求数，一般get都需要指定文档id。同样get也应该统计total分片的值，如果只统计主分片会造成数据变少，因为有时候的get请求不是从主分片取的数据。
indexing
index_total和index_time_in_millis指标是根据索引的文档数来记录，同样需要统计total分片的数据，total分片包括副本的索引请求，一般1个副本的话index_total会乘以2。
search.fetch
一个查询分为两个阶段，一是query另一个是fetch，fetch的情况与get相似，fetch.total指fetch请求数，fetch有可能从主分片拉取数据，也有可能从副本拉取数据。如果只统计主分片的数据会丢失数据。
扫一扫
1422
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
