ES监控状态指标分三个级别:
1:集群级别:集群级别的监控主要是针对整个ES集群来说,包括集群的健康状况,集群的状态等。
2:节点级别:节点级别的监控主要是针对每个ES实例的监控,其中包括每个实例的查询索引指标和物理资源使用指标。
3:索引级别:索引级别的监控主要是针对每个索引来说,主要包括每个索引的性能指标。
1集群级别:
查看方法:
api获取:http://ip: 9200/_cluster/健康吗?漂亮或者Kibana的开发工具开发工具中执行:
<编辑>查看集群健康状态得到_cluster/健康
<代码> {
:“cluster_name jp-pte-es-hot”,
“状态”:“绿色”,
“timed_out”:假的,
“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
}
指标说明:
状态:集群状态,分为绿色,黄色和红色。
number_of_nodes/number_of_data_nodes:集群的节点数和数据节点数。
active_primary_shards:集群中所有活跃的主分片数。
active_shards:集群中所有活跃的分片数。
relocating_shards:当前节点迁往其他节点的分片数量,通常为0,当有节点加入或者退出时该值会增加。
initializing_shards:正在初始化的分片。
unassigned_shards:未分配的分片数,通常为0,当有某个节点的副本分片丢失该值就会增加。
number_of_pending_tasks:是指主节点创建索引并分配碎片等任务,如果该指标数值一直未减小代表集群存在不稳定因素
active_shards_percent_as_number:集群分片健康度,活跃分片数占总分片数比例。
number_of_pending_tasks:等待任务只能由主节点来进行处理,这些任务包括创建索引并将碎片分配给节点。
<编辑>查看集群状态信息
#集群状态信息,整个集群的一些统计信息,例如文档数,分片数,资源使用情况等信息,从这个接口基本能够获取到集群所有关键指标项:
<代码>得到_cluster/统计?漂亮
<代码>输出数据量较大,省略 关键指标说明: indices.count:索引总数。 indices.shards.total:分片总数。 indices.shards.primaries:主分片数量。 docs.count:文档总数。 store.size_in_bytes:数据总存储容量。 segments.count:段总数。 nodes.count.total:总节点数。 nodes.count.data:数据节点数。 节点。的过程。cpu.percent:节点CPU使用率。 fs.total_in_bytes:文件系统使用总容量。 fs.free_in_bytes:文件系统剩余总容量。
2:节点级别h5> 节点监控
得到_nodes/统计/thread_pool吗?漂亮的
<编辑>节点线程组状态得到_nodes/统计/thread_pool ?漂亮
<代码>输出信息较多部分省略.....
。。。。。。。。。。。。。。。
"指数":{
"文档":{
“数”:8111612,#显示节点上有多少文档
“删除”:16604 #有多少已删除的文档还未从数据段中删除
}，
“存储”:{
“size_in_bytes”: 2959876263 #显示该节点消耗了多少物理存储
}，
“索引”:{#表示索引文档的次数,这个是通过一个计数器累加计数的。当文档被删除时,它不会减少。注意这个值永远是递增的,发生在内部索引数据的时候,包括那些更新操作
“index_total”: 17703152,
“is_throttled”:假的,
“throttle_time_in_millis”: 0 #这个值高的时候,说明磁盘流量设置太低
}，
。。。。。。。。。。。。。。。
}，
"搜索":{
“open_contexts”: 0 #主动检索的次数,
“query_total”: 495447年,#查询总数
“query_time_in_millis”: 298344年,#节点启动到此查询消耗总时间,query_time_in_millis/query_total的比值可以作为你的查询效率的粗略指标。比值越大,每个查询用的时间越多,你就需要考虑调整或者优化。
“query_current”: 0,
#后面关于获取的统计,是描述了查询的第二个过程(也就是query_the_fetch里的获取).fetch花的时间比查询的越多,表示你的磁盘很慢,或者你要取的的文档太多,或者你的查询参数分页条件太大,(例如大小等于1万
“fetch_total”: 130194年,
“suggest_current”: 0
}，
“合并”:{#包含lucene段合并的信息,它会告诉你有多少段合并正在进行,参与的文档数,这些正在合并的段的总大小,以及花在合并上的总时间。
如果你的集群写入比较多,这个合并的统计信息就很重要.merge操作会消耗大量的磁盘io和cpu资源。如果你的索引写入很多,你会看到大量的合并操作
。。。。。。。。。。。。。。。
}，
“fielddata”:{#显示了fielddata使用的内存,fielddata用于聚合,排序等。这里也有一个淘汰数,不像filter_cache,这里的淘汰数很有用,它必须是0或者接近0,因为fielddata不是缓存,任何淘汰的代价都是很大的,必须要避免的。如果你看到了淘汰,你必须重新评估你的内存情况,关于fielddata的限制,以及查询,或者三者全部。
。。。。。。。。。。。。。。。
}，
“段”:{告诉你当前节点的lucene段的个数,这可能是一个很重要的数字。大多数的索引应该在50到150个段左右,即便是几T大小的数十亿的文档。大量的段会带来合并的问题(例如:合并赶不上段的产生)。注意这个统计是对一个节点上所有的索引而言的
其中内存的统计,可以告诉你Lucene的段自身需要多少内存。这里包括基础的数据结构,包括提交列表,词典,绽放过滤器等。段的数量多会增加承载这些数据结构的开销,这个内存的使用就是对这个开销的度量。
关键指标说明:
indices.docs.count:索引文档数。
segments.count:段总数。
jvm.heap_used_percent:内存使用百分比。
thread_pool。}{散装、索引,搜索。{活跃,队列,拒绝}:线程池的一些信息,包括散装,指数,得到和搜索线程池,主要指标有活跃(激活)线程数,线程队列(队)列数和拒绝(拒绝)线程数量。
以下一些指标是一个累加值,当节点重启之后会清零。
indices.indexing.index_total:索引文档数。
indices.indexing.index_time_in_millis:索引总耗时。
indices.get.total:请求数。
indices.get.time_in_millis:请求总耗时。
indices.search.query_total:搜索总请求数。
indices.search.query_time_in_millis:搜索请求总耗时。
indices.search.fetch_total:获取操作总数量。
indices.search.fetch_time_in_millis:获取请求总耗时。
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:老年代垃圾回收总耗时。
ES集群关键状态指标
