ElasticSearch 单个节点监控

集群健康监控是对集群信息进行高度的概括，节点统计值 API 提供了集群中每个节点的统计值。节点统计值很多，在监控的时候仍需要我们清楚哪些指标是最值得关注的。

集群健康监控可以参考这篇文章：ElasticSearch 集群监控

节点信息 Node Info :

1. curl -XGET 'http://localhost:9200/_nodes'

执行上述命令可以获取所有 node 的信息

1. _nodes: {

2.  total: 2,

3.  successful: 2,

4.  failed: 0

5. },

6. cluster_name: "elasticsearch",

7. nodes: {

8.    MSQ_CZ7mTNyOSlYIfrvHag: {

9.    name: "node0",

10.    transport_address: "192.168.180.110:9300",

11.    host: "192.168.180.110",

12.    ip: "192.168.180.110",

13.    version: "5.5.0",

14.    build_hash: "260387d",

15.    total_indexing_buffer: 103887667,

16.    roles:{...},

17.    settings: {...},

18.    os: {

19.      refresh_interval_in_millis: 1000,

20.      name: "Linux",

21.      arch: "amd64",

22.      version: "3.10.0-229.el7.x86_64",

23.      available_processors: 4,

24.      allocated_processors: 4

25.    },

26.    process: {

27.      refresh_interval_in_millis: 1000,

28.      id: 3022,

29.      mlockall: false

30.    },

31.    jvm: {

32.      pid: 3022,

33.      version: "1.8.0_121",

34.      vm_name: "Java HotSpot(TM) 64-Bit Server VM",

35.      vm_version: "25.121-b13",

36.      vm_vendor: "Oracle Corporation",

37.      start_time_in_millis: 1507515225302,

38.      mem: {

39.      heap_init_in_bytes: 1073741824,

40.      heap_max_in_bytes: 1038876672,

41.      non_heap_init_in_bytes: 2555904,

42.      non_heap_max_in_bytes: 0,

43.      direct_max_in_bytes: 1038876672

44.      },

45.      gc_collectors: [],

46.      memory_pools: [],

47.      using_compressed_ordinary_object_pointers: "true",

48.      input_arguments:{}

49.    }

50.    thread_pool:{

51.      force_merge: {},

52.      fetch_shard_started: {},

53.      listener: {},

54.      index: {},

55.      refresh: {},

56.      generic: {},

57.      warmer: {},

58.      search: {},

59.      flush: {},

60.      fetch_shard_store: {},

61.      management: {},

62.      get: {},

63.      bulk: {},

64.      snapshot: {}

65.    }

66.    transport: {...},

67.    http: {...},

68.    plugins: [],

69.    modules: [],

70.    ingest: {...}

71. }

上面是我已经简写了很多数据之后的返回值，但是指标还是很多，有些是一些常规的指标，对于监控来说，没必要拿取。从上面我们可以主要关注以下这些指标:

1. os, process, jvm, thread_pool, transport, http, ingest and indices

节点统计 nodes-statistics

节点统计值 API 可通过如下命令获取：

1. GET /_nodes/stats

得到：

1. _nodes: {

2.  total: 2,

3.  successful: 2,

4.  failed: 0

5. },

6. cluster_name: "elasticsearch",

7. nodes: {

8.  MSQ_CZ7mTNyOSlYI0yvHag: {

9.    timestamp: 1508312932354,

10.    name: "node0",

11.    transport_address: "192.168.180.110:9300",

12.    host: "192.168.180.110",

13.    ip: "192.168.180.110:9300",

14.    roles: [],

15.    indices: {

16.      docs: {

17.           count: 6163666,

18.           deleted: 0

19.        },

20.      store: {

21.           size_in_bytes: 2301398179,

22.           throttle_time_in_millis: 122850

23.        },

24.      indexing: {},

25.      get: {},

26.      search: {},

27.      merges: {},

28.      refresh: {},

29.      flush: {},

30.      warmer: {},

31.      query_cache: {},

32.      fielddata: {},

33.      completion: {},

34.      segments: {},

35.      translog: {},

36.      request_cache: {},

37.      recovery: {}

38.  },

39.  os: {

40.    timestamp: 1508312932369,

41.    cpu: {

42.      percent: 0,

43.      load_average: {

44.        1m: 0.09,

45.        5m: 0.12,

46.        15m: 0.08

47.      }

48.    },

49.    mem: {

50.      total_in_bytes: 8358301696,

51.      free_in_bytes: 1381613568,

52.      used_in_bytes: 6976688128,

53.      free_percent: 17,

54.      used_percent: 83

55.    },

56.    swap: {

57.      total_in_bytes: 8455712768,

58.      free_in_bytes: 8455299072,

59.      used_in_bytes: 413696

60.    },

61.    cgroup: {

62.      cpuacct: {},

63.      cpu: {

64.        control_group: "/user.slice",

65.        cfs_period_micros: 100000,

66.        cfs_quota_micros: -1,

67.        stat: {}

68.      }

69.  }

70. },

71. process: {

72.  timestamp: 1508312932369,

73.  open_file_descriptors: 228,

74.  max_file_descriptors: 65536,

75.  cpu: {

76.    percent: 0,

77.    total_in_millis: 2495040

78.  },

79.  mem: {

80.    total_virtual_in_bytes: 5002465280

81.  }

82. },

83. jvm: {

84.  timestamp: 1508312932369,

85.  uptime_in_millis: 797735804,

86.  mem: {

87.    heap_used_in_bytes: 318233768,

88.    heap_used_percent: 30,

89.    heap_committed_in_bytes: 1038876672,

90.    heap_max_in_bytes: 1038876672,

91.    non_heap_used_in_bytes: 102379784,

92.    non_heap_committed_in_bytes: 108773376,

93.  pools: {

94.    young: {

95.      used_in_bytes: 62375176,

96.      max_in_bytes: 279183360,

97.      peak_used_in_bytes: 279183360,

98.      peak_max_in_bytes: 279183360

99.    },

100.    survivor: {

101.      used_in_bytes: 175384,

102.      max_in_bytes: 34865152,

103.      peak_used_in_bytes: 34865152,

104.      peak_max_in_bytes: 34865152

105.    },

106.    old: {

107.      used_in_bytes: 255683208,

108.      max_in_bytes: 724828160,

109.      peak_used_in_bytes: 255683208,

110.      peak_max_in_bytes: 724828160

111.    }

112.  }

113.  },

114.  threads: {},

115.  gc: {},

116.  buffer_pools: {},

117.  classes: {}

118. },

119.  thread_pool: {

120.    bulk: {},

121.    fetch_shard_started: {},

122.    fetch_shard_store: {},

123.    flush: {},

124.    force_merge: {},

125.    generic: {},

126.    get: {},

127.    index: {

128.       threads: 1,

129.       queue: 0,

130.       active: 0,

131.       rejected: 0,

132.       largest: 1,

133.       completed: 1

134.    }

135.    listener: {},

136.    management: {},

137.    refresh: {},

138.    search: {},

139.    snapshot: {},

140.    warmer: {}

141.  },

142.  fs: {},

143.  transport: {

144.    server_open: 13,

145.    rx_count: 11696,

146.    rx_size_in_bytes: 1525774,

147.    tx_count: 10282,

148.    tx_size_in_bytes: 1440101928

149.  },

150.  http: {

151.    current_open: 4,

152.    total_opened: 23

153.  },

154.  breakers: {},

155.  script: {},

156.  discovery: {},

157.  ingest: {}

158. }

节点名是一个 UUID，上面列举了很多指标，下面讲解下：

索引部分 indices

这部分列出了这个节点上所有索引的聚合过的统计值 ：

• docs 展示节点内存有多少文档，包括还没有从段里清除的已删除文档数量。

• store 部分显示节点耗用了多少物理存储。这个指标包括主分片和副本分片在内。如果限流时间很大，那可能表明你的磁盘限流设置得过低。

• indexing 显示已经索引了多少文档。这个值是一个累加计数器。在文档被删除的时候，数值不会下降。还要注意的是，在发生内部 索引操作的时候，这个值也会增加，比如说文档更新。

  还列出了索引操作耗费的时间，正在索引的文档数量，以及删除操作的类似统计值。

• get 显示通过 ID 获取文档的接口相关的统计值。包括对单个文档的 GET 和 HEAD 请求。

• search 描述在活跃中的搜索（ open_contexts ）数量、查询的总数量、以及自节点启动以来在查询上消耗的总时间。用 query_time_in_millis/query_total 计算的比值，可以用来粗略的评价你的查询有多高效。比值越大，每个查询花费的时间越多，你应该要考虑调优了。

  fetch 统计值展示了查询处理的后一半流程（query-then-fetch 里的 fetch ）。如果 fetch 耗时比 query 还多，说明磁盘较慢，或者获取了太多文档，或者可能搜索请求设置了太大的分页（比如， size:10000 ）。

• merges 包括了 Lucene 段合并相关的信息。它会告诉你目前在运行几个合并，合并涉及的文档数量，正在合并的段的总大小，以及在合并操作上消耗的总时间。

• filter_cache 展示了已缓存的过滤器位集合所用的内存数量，以及过滤器被驱逐出内存的次数。过多的驱逐数 可能 说明你需要加大过滤器缓存的大小，或者你的过滤器不太适合缓存（比如它们因为高基数而在大量产生，就像是缓存一个 now 时间表达式）。

  不过，驱逐数是一个很难评定的指标。过滤器是在每个段的基础上缓存的，而从一个小的段里驱逐过滤器，代价比从一个大的段里要廉价的多。有可能你有很大的驱逐数，但是它们都发生在小段上，也就意味着这些对查询性能只有很小的影响。

  把驱逐数指标作为一个粗略的参考。如果你看到数字很大，检查一下你的过滤器，确保他们都是正常缓存的。不断驱逐着的过滤器，哪怕都发生在很小的段上，效果也比正确缓存住了的过滤器差很多。

• field_data 显示 fielddata 使用的内存， 用以聚合、排序等等。这里也有一个驱逐计数。和 filter_cache 不同的是，这里的驱逐计数是很有用的：这个数应该或者至少是接近于 0。因为 fielddata 不是缓存，任何驱逐都消耗巨大，应该避免掉。如果你在这里看到驱逐数，你需要重新评估你的内存情况，fielddata 限制，请求语句，或者这三者。

• segments 会展示这个节点目前正在服务中的 Lucene 段的数量。 这是一个重要的数字。大多数索引会有大概 50–150 个段，哪怕它们存有 TB 级别的数十亿条文档。段数量过大表明合并出现了问题（比如，合并速度跟不上段的创建）。注意这个统计值是节点上所有索引的汇聚总数。记住这点。

  memory 统计值展示了 Lucene 段自己用掉的内存大小。 这里包括底层数据结构，比如倒排表，字典，和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销，这个内存使用量就是一个方便用来衡量开销的度量值。

操作系统和进程部分

OS 和 Process 部分基本是自描述的，不会在细节中展开讲解。它们列出来基础的资源统计值，比如 CPU 和负载。 OS 部分描述了整个操作系统，而 Process 部分只显示 Elasticsearch 的 JVM 进程使用的资源情况。

这些都是非常有用的指标，不过通常在你的监控技术栈里已经都测量好了。统计值包括下面这些：

• CPU

• 负载

• 内存使用率 （mem.used_percent）

• Swap 使用率

• 打开的文件描述符 （openfiledescriptors）

JVM 部分

jvm 部分包括了运行 Elasticsearch 的 JVM 进程一些很关键的信息。 最重要的，它包括了垃圾回收的细节，这对你的 Elasticsearch 集群的稳定性有着重大影响。

1. jvm: {

2.  timestamp: 1508312932369,

3.  uptime_in_millis: 797735804,

4.  mem: {

5.    heap_used_in_bytes: 318233768,

6.    heap_used_percent: 30,

7.    heap_committed_in_bytes: 1038876672,

8.    heap_max_in_bytes: 1038876672,

9.    non_heap_used_in_bytes: 102379784,

10.    non_heap_committed_in_bytes: 108773376,

11.  }

12. }

jvm 部分首先列出一些和 heap 内存使用有关的常见统计值。你可以看到有多少 heap 被使用了，多少被指派了（当前被分配给进程的），以及 heap 被允许分配的最大值。理想情况下， heap_committed_in_bytes 应该等于 heap_max_in_bytes 。如果指派的大小更小，JVM 最终会被迫调整 heap 大小——这是一个非常昂贵的操作。如果你的数字不相等，阅读 堆内存:大小和交换 学习如何正确的配置它。

heap_used_percent 指标是值得关注的一个数字。Elasticsearch 被配置为当 heap 达到 75% 的时候开始 GC。如果你的节点一直 >= 75%，你的节点正处于 内存压力 状态。这是个危险信号，不远的未来可能就有慢 GC 要出现了。

如果 heap 使用率一直 >=85%，你就麻烦了。Heap 在 90–95% 之间，则面临可怕的性能风险，此时最好的情况是长达 10–30s 的 GC，最差的情况就是内存溢出（OOM）异常。

线程池部分

Elasticsearch 在内部维护了线程池。 这些线程池相互协作完成任务，有必要的话相互间还会传递任务。通常来说，你不需要配置或者调优线程池，不过查看它们的统计值有时候还是有用的，可以洞察你的集群表现如何。

每个线程池会列出已配置的线程数量（ threads ），当前在处理任务的线程数量（ active ），以及在队列中等待处理的任务单元数量（ queue ）。

如果队列中任务单元数达到了极限，新的任务单元会开始被拒绝，你会在 rejected 统计值上看到它反映出来。这通常是你的集群在某些资源上碰到瓶颈的信号。因为队列满意味着你的节点或集群在用最高速度运行，但依然跟不上工作的蜂拥而入。

这里的一系列的线程池，大多数你可以忽略，但是有一小部分还是值得关注的：

• indexing 普通的索引请求的线程池

• bulk 批量请求，和单条的索引请求不同的线程池

• get Get-by-ID 操作

• search 所有的搜索和查询请求

• merging 专用于管理 Lucene 合并的线程池

网络部分

• transport 显示和 传输地址 相关的一些基础统计值。包括节点间的通信（通常是 9300 端口）以及任意传输客户端或者节点客户端的连接。如果看到这里有很多连接数不要担心；Elasticsearch 在节点之间维护了大量的连接。

• http 显示 HTTP 端口（通常是 9200）的统计值。如果你看到 total_opened 数很大而且还在一直上涨，这是一个明确信号，说明你的 HTTP 客户端里有没启用 keep-alive 长连接的。持续的 keep-alive 长连接对性能很重要，因为连接、断开套接字是很昂贵的（而且浪费文件描述符）。请确认你的客户端都配置正确。

参考资料

1、nodes-info

2、nodes-stats

3、ES监控指标

最后：

转载请注明地址：http://www.54tianzhisheng.cn/2017/10/18/ElasticSearch-nodes-metrics/

关注我