[Elasticsearch Monitor] 如何监控Elasticsearch(二)

上一篇文章如何监控Elasticsearch主要描述了对于Es服务器应该监控哪些指标。本文旨在介绍es api中的各统计指标含义。

Elasticsearch’s RESTful API + JSON

默认情况下,Elasticsearch在9200端口上提供了restful http服务,返回集群,节点,索引状况的JSON结果。主要有五个HTTP REST API可用于监视Elasticsearch:

  • Cluster Health API
  • Cluster Stats API
  • Node Stats API
  • Index Stats API
  • Pending Tasks API

下面的表格总结了上一篇文章中提到搜索性能,索引性能,内存性能,网络性能对应的ES API。其中有些性能数据是从多个维度描述的,比如搜索性能在节点维度和索引维度都有提供。

Metric category Availability
Search performance metrics Node Stats API, Index Stats API
Indexing performance metrics Node Stats API, Index Stats API
Memory and garbage collection Node Stats API, Cluster Stats API
Network metrics Node Stats API
Cluster health and node availability Cluster Health API
Resource saturation and errors Node Stats API, Index Stats API, Cluster Stats API, Pending Tasks API

(一)Cluster Health API

Cluster Health API提供了描述集群健康状态的JSON对象数据。

API接口:

GET _cluster/health

返回结果JSON:

{
  "cluster_name": "elasticsearch",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 11,
  "active_shards": 11,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 10,
  "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": 52.38095238095239
}
  • status一共有3个状态:green表示所有主分片及备份分片都分配好了,集群100%健康。yellow表示所有主分片都分配好了,但至少有一个备份分片未分配。数据没有丢失,搜索结果是完整的。但高可用性会缺失,存在丢失数据风险,以黄色表示警告。red表示至少有一个主分片未分配,并且这个主分片的所有分片都丢失了。数据已经丢失了,搜索结果不完整,并且往这个分片索引数据会发生异常。
  • number_of_nodesnumber_of_data_nodes,从名字就可以知道分别是节点数和数据节点数。
  • active_primary_shards,集群中所有index的主分片数量的总和。
  • active_shards,集群中所有index的分片数量的总和,包括备份分片。
  • relocating_shards,正在被移动的分片数量。通常为0,在集群rebalance的时候会有变化。

(二)Cluster Stats API

Cluster Stats API提供了集群维度的信息。基本上是Node Stats API的数据的总和。虽然没有每个节点的详细信息,但是可以让你快速了解掌握整个集群当前的运行状态。

API接口:

GET _cluster/stats
{
  "_nodes": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "cluster_name": "elasticsearch",
  "timestamp": 1500175210218,
  "status": "yellow",
  "indices": {
    "count": 11,
    "shards": {...},
    "docs": {...},
    "store": {...},
    "fielddata": {...},
    "query_cache": {...},
    "completion": {...},
    "segments": {...}
  },
  "nodes": {
    "count": {...},
    "versions": [...],
    "os": {...},
    "process": {...},
    "jvm": {...},
    "fs": {...},
    "plugins": [...],
    "network_types": {...}
  }
}

对于indices和nodes内部属性的含义会在Node Stats API里介绍

(三)Node Stats API

Node Stats API是一个非常有用的API,用于监控集群每台服务器的状态。它统计了我们想要监控的主要的那些指标,包括了我们上一篇列举的大部分指标。

API接口:

GET _nodes/stats (或者指定node获取 _nodes/node1,node2/stats)
{
  "_nodes": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "cluster_name": "elasticsearch",
  "nodes": {
    "SdRLvOO7RKSiaBW_hmwvZg": {
      "name": "node1",
      "indices": {...},
      "os": {...},
      "process": {...},
      "jvm": {...},
      "thread_pool": {...},
      "fs": {...},
      "transport": {...},
      "http": {...}
    }
    ...
  }
}
  • 查询性能指标,前缀indices.search.*的指标
    • indices.search.query_total 查询总量
    • indices.search.query_time_in_millis 查询总耗时
    • indices.search.query_current 正在处理的查询量
    • indices.search.fetch_total 查询的第二阶段fetch总量
    • indices.search.fetch_time_in_millis fetch耗时
    • indices.search.fetch_current 正在处理的fetch数量
  • 索引性能指标,前缀indices.indexing.* ,indices.refresh.* ,indices.flush.* 的指标
    • indices.indexing.index_total 索引总量
    • indices.indexing.index_time_in_millis 索引耗时
    • indices.indexing.index_current 正在处理的索引量
    • indices.refresh.total 刷新内存总量
    • indices.refresh.total_time_in_millis 刷新内存耗时
    • indices.flush.total 同步磁盘总量
    • indices.flush.total_time_in_millis 同步磁盘耗时
  • Cache性能指标,前缀indices.query_cache.* ,indices.fielddata.* ,indices.request_cache.* 的指标。fielddata可能会成为内存消耗大户,需要特别注意
    • indices.query_cache.memory_size_in_bytes 查询缓存大小
    • indices.query_cache.evictions 查询缓存剔除大小
    • indices.fielddata.memory_size_in_bytes fielddata缓存大小
    • indices.fielddata.evictions fielddata缓存剔除大小
    • indices.request_cache.memory_size_in_bytes 所有请求缓存大小
    • indices.request_cache.evictions 所有请求缓存剔除大小
  • os指标
    • os.cpu.percent 系统CPU使用百分比
    • os.cpu.load_average.1m 系统CPU 1分钟平均load
    • os.cpu.load_average.5m 系统CPU 5分钟平均load
    • os.cpu.load_average.15m 系统CPU 15分钟平均load
    • os.mem.free_percent 系统内存可用百分比
    • os.mem.used_percent 系统内存已使用百分比
    • os.mem.total_in_bytes 系统内存总大小
    • os.mem.free_in_bytes 系统内存可用大小
    • os.mem.used_in_bytes 系统内存已使用大小
    • os.swap.total_in_bytes 系统swap总大小
    • os.swap.free_in_bytes 系统swap可用大小
    • os.swap.used_in_bytes 系统swap已使用大小
  • process指标,专用与es jvm进程的资源消耗指标
    • process.cpu.percent 进程CPU使用百分比
    • process.cpu.total_in_millis 进程CPU使用时间
    • process.mem.total_virtual_in_bytes 进程可用虚拟内存大小
    • process.open_file_descriptors 进程打开文件句柄数
    • process.max_file_descriptors 进程可用句柄数
  • JVM性能指标,前缀jvm.*的指标,内存使用及GC指标
    • jvm.gc.collectors.young.collection_count young gc 大小
    • jvm.gc.collectors.young.collection_time_in_millis young gc 耗时
    • jvm.gc.collectors.old.collection_count old gc 大小
    • jvm.gc.collectors.old.collection_time_in_millis old gc 耗时
    • jvm.mem.heap_used_percent 内存使用百分比
    • jvm.mem.heap_used_in_bytes 内存使用量
    • jvm.mem.heap_committed_in_bytes 内存占用量
  • 线程池性能指标,前缀thread_pool.*的指标
    • thread_pool.bulk.queue thread_pool.index.queue thread_pool.search.queue thread_pool.merge.queue 各队列长度
    • thread_pool.bulk.rejected thread_pool.index.rejected thread_pool.search.rejected thread_pool.merge.rejected 各队列溢出量(未执行,被放弃)
  • 文件系统指标
    • fs.total.total_in_bytes 数据目录总大小
    • fs.total.free_in_bytes 数据目录剩余大小
    • fs.total.vailable_in_bytes 数据目录可用大小
  • 集群通信指标
    • transport.rx_count 集群通信中接收的数据包总数
    • transport.rx_size_in_bytes 集群通信中接收的数据的总大小
    • transport.tx_count 集群通信中发送的数据包总数
    • transport.tx_size_in_bytes 集群通信中发送的数据的总大小
    • transport.server_open 为集群通信打开的连接数
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容