学习Elasticsearch有一段时间了,参考网上的一些资料,对于Elasticsearch集群状态一些重要监控指标数据在此进行小结,以加深理解。

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

一、集群级别                                            

1.  查看集群健康状态 (GET _cluster/health)

[root@elk-node01 ~]# curl -X GET 'http://10.0.8.47:9200/_cluster/health?pretty'
{
"cluster_name" : "kevin-elk",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 2234,
"active_shards" : 4468,
"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
}

关键指标说明
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分配给节点。

2. 查看集群状态信息 (GET _cluster/stats?pretty)
#集群状态信息 ,整个集群的一些统计信息,例如文档数、分片数、资源使用情况等信息,从这个接口基本能够获取到集群所有关键指标项.

[root@elk-node01 ~]# curl -X GET 'http://10.0.8.47:9200/_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:文件系统剩余总容量。

二、节点级别                                               

节点监控, 即node线程组状态  (GET _nodes/stats/thread_pool?pretty)

[root@elk-node01 ~]# curl -X GET 'http://10.0.8.47:9200/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:老年代垃圾回收总耗时。

三、索引级别                                         
可以查看所有index的相关信息 (GET _stats)

[root@elk-node01 ~]# curl -X GET 'http://10.0.8.47:9200/_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请求总耗时。

         Prometheus+Elasticsearch+Grafana环境里ES的监控指标         

-  简单安装elasticsearch

[root@elk-node1 ~]# wget https://github.com/justwatchcom/elasticsearch_exporter/releases/download/v1.0.4rc1/elasticsearch_exporter-1.0.4rc1.linux-amd64.tar.gz
[root@elk-node1 ~]# tar zxvf elasticsearch_exporter-1.0.4rc1.linux-amd64.tar.gz
[root@elk-node1 ~]# cd elasticsearch_exporter
[root@elk-node1 ~]# cp elasticsearch_exporter  /usr/local/bin
[root@elk-node1 ~]# /usr/local/bin/elasticsearch_exporter --web.listen-address "0.0.0.0:9109"  --es.uri http://elastic:changeme@localhost:9201
[root@elk-node1 ~]# curl localhost:9109/metrics

-  配置Prometheus

- job_name: 'elasticsearch'
file_sd_configs:
- refresh_interval: 1m
files:
- ./conf.d/es*.json

-  配置consul或etcd自动发现(这里省略)

-  监控指标解析

#######################  搜索和索引性能  ##########################
elasticsearch_indices_search_query_total
查询总数(吞吐量)

elasticsearch_indices_search_query_time_seconds
查询总时间(性能)

elasticsearch_indices_search_fetch_total
提取总数

elasticsearch_indices_search_fetch_time_seconds
花费在提取上的总时间

########################  索引请求  ##############################
elasticsearch_indices_indexing_index_total
索引的文件总数

elasticsearch_indices_indexing_index_time_seconds_total
索引文档总时间

elasticsearch_indices_indexing_delete_total
索引的文件删除总数

elasticsearch_indices_indexing_delete_time_seconds_total
索引的文件删除总时间

elasticsearch_indices_refresh_total
索引刷新总数

elasticsearch_indices_refresh_time_seconds_total
刷新指数的总时间

elasticsearch_indices_flush_total
索引刷新总数到磁盘

elasticsearch_indices_flush_time_seconds
将索引刷新到磁盘上的总时间 累计flush时间

########################  JVM内存和垃圾回收  ######################
elasticsearch_jvm_gc_collection_seconds_sum
GC run time in seconds垃圾回收时间

elasticsearch_jvm_gc_collection_seconds_count
Count of JVM GC runs垃圾搜集数

elasticsearch_jvm_memory_committed_bytes
JVM memory currently committed by area最大使用内存限制

elasticsearch_jvm_memory_max_bytes
配置的最大jvm值

elasticsearch_jvm_memory_pool_max_bytes
JVM内存最大池数

elasticsearch_jvm_memory_pool_peak_max_bytes
最大的JVM内存峰值

elasticsearch_jvm_memory_pool_peak_used_bytes
池使用的JVM内存峰值

elasticsearch_jvm_memory_pool_used_bytes
目前使用的JVM内存池

elasticsearch_jvm_memory_used_bytes
JVM memory currently used by area 内存使用量

#######################  集群健康和节点可用性  ####################
elasticsearch_cluster_health_status
集群状态,green( 所有的主分片和副本分片都正常运行)、yellow(所有的主分片都正常运行,但不是所有的副本分片都正常运行)red(有主分片没能正常运行)值为1的即为对应状态

elasticsearch_cluster_health_number_of_data_nodes
node节点的数量

elasticsearch_cluster_health_number_of_in_flight_fetch
正在进行的碎片信息请求的数量

elasticsearch_cluster_health_number_of_nodes
集群内所有的节点

elasticsearch_cluster_health_number_of_pending_tasks
尚未执行的集群级别更改

elasticsearch_cluster_health_initializing_shards
正在初始化的分片数

elasticsearch_cluster_health_unassigned_shards
未分配分片数

elasticsearch_cluster_health_active_primary_shards
活跃的主分片总数

elasticsearch_cluster_health_active_shards
活跃的分片总数(包括复制分片)

elasticsearch_cluster_health_relocating_shards
当前节点正在迁移到其他节点的分片数量,通常为0,集群中有节点新加入或者退出时该值会增加

###########################  资源饱和度  ###########################
elasticsearch_thread_pool_completed_count
线程池操作完成(bulk、index、search、force_merge)

elasticsearch_thread_pool_active_count
线程池线程活动(bulk、index、search、force_merge)

elasticsearch_thread_pool_largest_count
线程池最大线程数(bulk、index、search、force_merge)

elasticsearch_thread_pool_queue_count
线程池中的排队线程数(bulk、index、search、force_merge)

elasticsearch_thread_pool_rejected_count
线程池的被拒绝线程数(bulk、index、search、force_merge)

elasticsearch_indices_fielddata_memory_size_bytes
fielddata缓存的大小(字节)

elasticsearch_indices_fielddata_evictions
来自fielddata缓存的驱逐次数

elasticsearch_indices_filter_cache_evictions
来自过滤器缓存的驱逐次数(仅版本2.x)

elasticsearch_indices_filter_cache_memory_size_bytes
过滤器高速缓存的大小(字节)(仅版本2.x)

elasticsearch_cluster_health_number_of_pending_tasks
待处理任务数

elasticsearch_indices_get_time_seconds

elasticsearch_indices_get_missing_total
丢失的文件的GET请求总数

elasticsearch_indices_get_missing_time_seconds
花费在文档丢失的GET请求上的总时间

elasticsearch_indices_get_exists_time_seconds

elasticsearch_indices_get_exists_total

elasticsearch_indices_get_total

###################  主机级别的系统和网络指标  ####################
elasticsearch_process_cpu_percent
Percent CPU used by process CPU使用率

elasticsearch_filesystem_data_free_bytes
Free space on block device in bytes 磁盘可用空间

elasticsearch_process_open_files_count
Open file descriptors ES进程打开的文件描述符

elasticsearch_transport_rx_packets_total
Count of packets receivedES节点之间网络入流量

elasticsearch_transport_tx_packets_total
Count of packets sentES节点之间网络出流量

-  预警rules

groups:
- name: elasticsearchStatsAlert
  rules:
  - alert: Elastic_Cluster_Health_RED
    expr: elasticsearch_cluster_health_status{color="red"}==1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }}: not all primary and replica shards are allocated in elasticsearch cluster {{ $labels.cluster }}"
      description: "Instance {{ $labels.instance }}: not all primary and replica shards are allocated in elasticsearch cluster {{ $labels.cluster }}."
  - alert: Elastic_Cluster_Health_Yellow
    expr: elasticsearch_cluster_health_status{color="yellow"}==1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: " Instance {{ $labels.instance }}: not all primary and replica shards are allocated in elasticsearch cluster {{ $labels.cluster }}"
      description: "Instance {{ $labels.instance }}: not all primary and replica shards are allocated in elasticsearch cluster {{ $labels.cluster }}."
  - alert: Elasticsearch_JVM_Heap_Too_High
    expr: elasticsearch_jvm_memory_used_bytes{area="heap"} / elasticsearch_jvm_memory_max_bytes{area="heap"} > 0.8
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "ElasticSearch node {{ $labels.instance }} heap usage is high "
      description: "The heap in {{ $labels.instance }} is over 80% for 15m."
  - alert: Elasticsearch_health_up
    expr: elasticsearch_cluster_health_up !=1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: " ElasticSearch node: {{ $labels.instance }} last scrape of the ElasticSearch cluster health failed"                               
      description: "ElasticSearch node: {{ $labels.instance }} last scrape of the ElasticSearch cluster health failed"
  - alert: Elasticsearch_Too_Few_Nodes_Running
    expr: elasticsearch_cluster_health_number_of_nodes < 12
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "There are only {{$value}} < 12 ElasticSearch nodes running "                               
      description: "lasticSearch running on less than 12 nodes(total 14)"
  - alert: Elasticsearch_Count_of_JVM_GC_Runs
    expr: rate(elasticsearch_jvm_gc_collection_seconds_count{}[5m])>5
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "ElasticSearch node {{ $labels.instance }}: Count of JVM GC runs > 5 per sec and has a value of {{ $value }} "
      description: "ElasticSearch node {{ $labels.instance }}: Count of JVM GC runs > 5 per sec and has a value of {{ $value }}"
  - alert: Elasticsearch_GC_Run_Time
    expr: rate(elasticsearch_jvm_gc_collection_seconds_sum[5m])>0.3
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: " ElasticSearch node {{ $labels.instance }}: GC run time in seconds > 0.3 sec and has a value of {{ $value }}"
      description: "ElasticSearch node {{ $labels.instance }}: GC run time in seconds > 0.3 sec and has a value of {{ $value }}"
  - alert: Elasticsearch_json_parse_failures
    expr: elasticsearch_cluster_health_json_parse_failures>0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: " ElasticSearch node {{ $labels.instance }}: json parse failures > 0 and has a value of {{ $value }}"
      description: "ElasticSearch node {{ $labels.instance }}: json parse failures > 0 and has a value of {{ $value }}"
  - alert: Elasticsearch_breakers_tripped
    expr: rate(elasticsearch_breakers_tripped{}[5m])>0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: " ElasticSearch node {{ $labels.instance }}: breakers tripped > 0 and has a value of {{ $value }}"
      description: "ElasticSearch node {{ $labels.instance }}: breakers tripped > 0 and has a value of {{ $value }}"
  - alert: Elasticsearch_health_timed_out
    expr: elasticsearch_cluster_health_timed_out>0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: " ElasticSearch node {{ $labels.instance }}: Number of cluster health checks timed out > 0 and has a value of {{ $value }}"
      description: "ElasticSearch node {{ $labels.instance }}: Number of cluster health checks timed out > 0 and has a value of {{ $value }}"

-  Prometheus 配置

rule_files:
- /usr/local/prometheus/rules/es*.rules

-  最后可在Grafana 上通过Prometheus数据源进行监控图形展示

Docker容器学习梳理 - 基础环境安装的更多相关文章

  1. Docker容器学习梳理 - 基础知识(1)

    Docker是PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎,源代码托管在 Github 上, 基于go语言并遵从Apache2.0协议开源.Docker是通过内核虚拟化技 ...

  2. Docker容器学习梳理 - 基础知识(2)

    之前已经总结了Docker容器学习梳理--基础知识(1),但是不够详细,下面再完整补充下Docker学习的一些基础. Docker是个什么东西 Docker是一个程序运行.测试.交付的开放平台,Doc ...

  3. Docker容器学习梳理 - 应用程序容器环境部署

    关于国内Docker镜像,可以参考:Docker容器学习梳理--基础知识(2) 的Docker镜像使用. 如果我们需要在Docker环境下部署tomcat.redis.mysql.nginx.php等 ...

  4. Docker容器学习梳理 - 日常操作总结

    使用Docker已有一段时间了,今天正好有空梳理下自己平时操作Docker时的一些命令和注意细节: Docker 命令帮助 $ sudo docker Commands: attach Attach ...

  5. Docker容器学习梳理 - Dockerfile构建镜像

    在Docker的运用中,从下载镜像,启动容器,在容器中输入命令来运行程序,这些命令都是手工一条条往里输入的,无法重复利用,而且效率很低.所以就需要一 种文件或脚本,我们把想执行的操作以命令的方式写入其 ...

  6. Docker容器学习梳理 - 容器间网络通信设置(Pipework和Open vSwitch)

    自从Docker容器出现以来,容器的网络通信就一直是被关注的焦点,也是生产环境的迫切需求.容器的网络通信又可以分为两大方面:单主机容器上的相互通信,和跨主机的容器相互通信.下面将分别针对这两方面,对容 ...

  7. Docker容器学习梳理 - 容器硬盘热扩容

    前面已介绍了docker很多知识点的操作记录,今天这里梳理下docker容器空间扩展的操作.默认情况下,物理机下创建的docker容器的空间是10G(虚拟机下创建的docker容器空间就是虚拟机的空间 ...

  8. Docker容器学习梳理 - Volume数据卷使用

    之前部署了Docker容器学习梳理--基础环境安装,接下来看看Docker Volume的使用. Docker volume使用 Docker中的数据可以存储在类似于虚拟机磁盘的介质中,在Docker ...

  9. Docker容器学习梳理 - 容器时间跟宿主机时间同步

    在Docker容器创建好之后,可能会发现容器时间跟宿主机时间不一致,这就需要同步它们的时间,让容器时间跟宿主机时间保持一致.如下: 宿主机时间 [root@slave-1 ~]# date Fri M ...

随机推荐

  1. 将mssql数据库高版本迁移到低版本

    将mssql数据库高版本迁移到低版本 在低版本目标数据库中创建目标空数据库[TargetDb] ,注意新建数据库即可,不要创建任何表 在低版本数据库中,选中[服务器对象=>链接服务器] 右键[新 ...

  2. k-vim安装及The ycmd server SHUT DOWN (restart with ':YcmRestartServer')这种错误的解决方法

    vim配置 下载地址:https://github.com/wklken/k-vim 安装步骤: 1. clone 到本地 git clone https://github.com/wklken/k- ...

  3. Matplotlib:可视化颜色命名分类和映射颜色分类

    Matplotlib中支持的所有颜色分类 映射颜色分类

  4. Mysql基础之 binary关键字

    where子句的字符串比较是不区分大小写的,但是可以使用binary关键字设定where子句区分大小写

  5. 3.3Python数据处理篇之Numpy系列(三)---数组的索引与切片

    目录 (一)数组的索引与切片 1.说明: 2.实例: (二)多维数组的索引与切片 1.说明: 2.实例: 目录: 1.一维数组的索引与切片 2.多维数组的索引与切片 (一)数组的索引与切片 1.说明: ...

  6. Mysqli面向对象操作数据库

    Mysqli面向对象操作数据库 首先配置一下数据库: 接着用PHP中的Mysqli扩展库面向对象查询这个数据表. 操作分为以下几个步骤: 连接数据库 操作数据库 处理结果 关闭资源 <?php ...

  7. 第 15 章 位操作(fields)

    /*----------------------------------- fields.c -- 定义并使用字段 -----------------------------------*/ #inc ...

  8. Beta冲刺(2/5)(麻瓜制造者)

    今日完成任务 邓弘立:继续完成了昨天未完成的登录接口的重编码与测试. 李佳铭|:进一步完善了收藏UI 江郑: 对使用前端框架页面元素的进一步优化,基本功能进行中 刘双玉:部分图书馆租借接口修改 肖小强 ...

  9. 怎么配置 Oracle 侦听器来使用SQL操作ST_Geometry

    关于这个内容,其实从ArcSDE9.2推出ST_Geometry就让用户感到很有吸引力,而且特别是在ArcSDE9.3之后,用户使用SQL操作ST_geometry越来越多,但是在配置Oracle监听 ...

  10. JS控制台打印佛祖加持护身符

    console.log([     "                   _ooOoo_",     "                  o8888888o" ...