Q:有两个人掉到陷阱里了,死的人叫死人,活人叫什么?

elasticsearch 实现字符串截取再进行分组

laoyang360 回复了问题 • 4 人关注 • 2 个回复 • 7841 次浏览 • 2017-11-08 12:29 • 来自相关话题

Elasticsearch如何多个索引进行联合查询?

laoyang360 回复了问题 • 3 人关注 • 1 个回复 • 12870 次浏览 • 2017-11-08 12:22 • 来自相关话题

elasticsearch中的mapping有什么用?哪位大神能给解释下,具体怎么用?

laoyang360 回复了问题 • 2 人关注 • 1 个回复 • 1640 次浏览 • 2017-11-08 12:21 • 来自相关话题

如何用spring-data-elasticsearch搜索对象子类属性?

回复

13656185373 发起了问题 • 1 人关注 • 0 个回复 • 2438 次浏览 • 2017-11-07 22:00 • 来自相关话题

搜索大字段文档的性能问题

laoyang360 回复了问题 • 4 人关注 • 2 个回复 • 2129 次浏览 • 2017-11-07 15:31 • 来自相关话题

ik分词 maxword的slop

Wen Tan 回复了问题 • 4 人关注 • 2 个回复 • 2694 次浏览 • 2017-11-07 10:14 • 来自相关话题

无法更改系统的文件描述符数量

yangjiajun111 回复了问题 • 3 人关注 • 3 个回复 • 1966 次浏览 • 2017-11-07 09:52 • 来自相关话题

transportClient有连接数限制吗

eric930721 回复了问题 • 3 人关注 • 2 个回复 • 7861 次浏览 • 2017-11-07 09:34 • 来自相关话题

使用es事大家都是如何清除历史数据的

truman.p.du 回复了问题 • 5 人关注 • 2 个回复 • 19583 次浏览 • 2017-11-07 08:26 • 来自相关话题

ElasticSearch 集群监控

zhisheng 发表了文章 • 3 个评论 • 10174 次浏览 • 2017-11-07 00:41 • 来自相关话题

原文地址:http://www.54tianzhisheng.cn/2 ... rics/
 

![](http://ohfk1r827.bkt.clouddn.com/cb5.jpeg-1)

最近在做 ElasticSearch 的信息(集群和节点)监控,特此稍微整理下学到的东西。这篇文章主要介绍集群的监控。


要监控哪些 ElasticSearch metrics


![](https://datadog-prod.imgix.net ... %3Dmax)

Elasticsearch 提供了大量的 Metric,可以帮助您检测到问题的迹象,在遇到节点不可用、out-of-memory、long garbage collection times 的时候采取相应措施。但是指标太多了,有时我们并不需要这么多,这就需要我们进行筛选。

集群健康


一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它 可能有一百个数据节点、三个单独的主节点,以及一小打客户端节点——这些共同操作一千个索引(以及上万个分片)。

不管集群扩展到多大规模,你都会想要一个快速获取集群状态的途径。Cluster Health API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好,或者警告你集群某个地方有问题。

让我们执行一下 cluster-health API 然后看看响应体是什么样子的:

<br /> GET _cluster/health<br />

和 Elasticsearch 里其他 API 一样,cluster-health 会返回一个 JSON 响应。这对自动化和告警系统来说,非常便于解析。响应中包含了和你集群有关的一些关键信息:

json<br /> {<br /> "cluster_name": "elasticsearch_zach",<br /> "status": "green",<br /> "timed_out": false,<br /> "number_of_nodes": 1,<br /> "number_of_data_nodes": 1,<br /> "active_primary_shards": 10,<br /> "active_shards": 10,<br /> "relocating_shards": 0,<br /> "initializing_shards": 0,<br /> "unassigned_shards": 0<br /> }<br />

响应信息中最重要的一块就是 status 字段。状态可能是下列三个值之一 :

| status | 含义 |
| :----: | :--------------------------------------: |
| green | 所有的主分片和副本分片都已分配。你的集群是 100% 可用的。 |
| yellow | 所有的主分片已经分片了,但至少还有一个副本是缺失的。不会有数据丢失,所以搜索结果依然是完整的。不过,你的高可用性在某种程度上被弱化。如果 更多的 分片消失,你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。 |
| red | 至少一个主分片(以及它的全部副本)都在缺失中。这意味着你在缺少数据:搜索只能返回部分数据,而分配到这个分片上的写入请求会返回一个异常。 |

  • number_of_nodesnumber_of_data_nodes 这个命名完全是自描述的。
  • active_primary_shards 指出你集群中的主分片数量。这是涵盖了所有索引的汇总值。
  • active_shards 是涵盖了所有索引的所有分片的汇总值,即包括副本分片。
  • relocating_shards 显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0,不过在 Elasticsearch 发现集群不太均衡时,该值会上涨。比如说:添加了一个新节点,或者下线了一个节点。
  • initializing_shards 是刚刚创建的分片的个数。比如,当你刚创建第一个索引,分片都会短暂的处于 initializing 状态。这通常会是一个临时事件,分片不应该长期停留在 initializing状态。你还可能在节点刚重启的时候看到 initializing 分片:当分片从磁盘上加载后,它们会从initializing 状态开始。
  • unassigned_shards 是已经在集群状态中存在的分片,但是实际在集群里又找不着。通常未分配分片的来源是未分配的副本。比如,一个有 5 分片和 1 副本的索引,在单节点集群上,就会有 5 个未分配副本分片。如果你的集群是 red 状态,也会长期保有未分配分片(因为缺少主分片)。


    集群统计


    集群统计信息包含 集群的分片数,文档数,存储空间,缓存信息,内存作用率,插件内容,文件系统内容,JVM 作用状况,系统 CPU,OS 信息,段信息。

    查看全部统计信息命令:

    <br /> curl -XGET 'http://localhost:9200/_cluster/stats?human&pretty'<br />

    返回 JSON 结果:

    json<br /> {<br /> "timestamp": 1459427693515,<br /> "cluster_name": "elasticsearch",<br /> "status": "green",<br /> "indices": {<br /> "count": 2,<br /> "shards": {<br /> "total": 10,<br /> "primaries": 10,<br /> "replication": 0,<br /> "index": {<br /> "shards": {<br /> "min": 5,<br /> "max": 5,<br /> "avg": 5<br /> },<br /> "primaries": {<br /> "min": 5,<br /> "max": 5,<br /> "avg": 5<br /> },<br /> "replication": {<br /> "min": 0,<br /> "max": 0,<br /> "avg": 0<br /> }<br /> }<br /> },<br /> "docs": {<br /> "count": 10,<br /> "deleted": 0<br /> },<br /> "store": {<br /> "size": "16.2kb",<br /> "size_in_bytes": 16684,<br /> "throttle_time": "0s",<br /> "throttle_time_in_millis": 0<br /> },<br /> "fielddata": {<br /> "memory_size": "0b",<br /> "memory_size_in_bytes": 0,<br /> "evictions": 0<br /> },<br /> "query_cache": {<br /> "memory_size": "0b",<br /> "memory_size_in_bytes": 0,<br /> "total_count": 0,<br /> "hit_count": 0,<br /> "miss_count": 0,<br /> "cache_size": 0,<br /> "cache_count": 0,<br /> "evictions": 0<br /> },<br /> "completion": {<br /> "size": "0b",<br /> "size_in_bytes": 0<br /> },<br /> "segments": {<br /> "count": 4,<br /> "memory": "8.6kb",<br /> "memory_in_bytes": 8898,<br /> "terms_memory": "6.3kb",<br /> "terms_memory_in_bytes": 6522,<br /> "stored_fields_memory": "1.2kb",<br /> "stored_fields_memory_in_bytes": 1248,<br /> "term_vectors_memory": "0b",<br /> "term_vectors_memory_in_bytes": 0,<br /> "norms_memory": "384b",<br /> "norms_memory_in_bytes": 384,<br /> "doc_values_memory": "744b",<br /> "doc_values_memory_in_bytes": 744,<br /> "index_writer_memory": "0b",<br /> "index_writer_memory_in_bytes": 0,<br /> "version_map_memory": "0b",<br /> "version_map_memory_in_bytes": 0,<br /> "fixed_bit_set": "0b",<br /> "fixed_bit_set_memory_in_bytes": 0,<br /> "file_sizes": {}<br /> },<br /> "percolator": {<br /> "num_queries": 0<br /> }<br /> },<br /> "nodes": {<br /> "count": {<br /> "total": 1,<br /> "data": 1,<br /> "coordinating_only": 0,<br /> "master": 1,<br /> "ingest": 1<br /> },<br /> "versions": [<br /> "5.6.3"<br /> ],<br /> "os": {<br /> "available_processors": 8,<br /> "allocated_processors": 8,<br /> "names": [<br /> {<br /> "name": "Mac OS X",<br /> "count": 1<br /> }<br /> ],<br /> "mem" : {<br /> "total" : "16gb",<br /> "total_in_bytes" : 17179869184,<br /> "free" : "78.1mb",<br /> "free_in_bytes" : 81960960,<br /> "used" : "15.9gb",<br /> "used_in_bytes" : 17097908224,<br /> "free_percent" : 0,<br /> "used_percent" : 100<br /> }<br /> },<br /> "process": {<br /> "cpu": {<br /> "percent": 9<br /> },<br /> "open_file_descriptors": {<br /> "min": 268,<br /> "max": 268,<br /> "avg": 268<br /> }<br /> },<br /> "jvm": {<br /> "max_uptime": "13.7s",<br /> "max_uptime_in_millis": 13737,<br /> "versions": [<br /> {<br /> "version": "1.8.0_74",<br /> "vm_name": "Java HotSpot(TM) 64-Bit Server VM",<br /> "vm_version": "25.74-b02",<br /> "vm_vendor": "Oracle Corporation",<br /> "count": 1<br /> }<br /> ],<br /> "mem": {<br /> "heap_used": "57.5mb",<br /> "heap_used_in_bytes": 60312664,<br /> "heap_max": "989.8mb",<br /> "heap_max_in_bytes": 1037959168<br /> },<br /> "threads": 90<br /> },<br /> "fs": {<br /> "total": "200.6gb",<br /> "total_in_bytes": 215429193728,<br /> "free": "32.6gb",<br /> "free_in_bytes": 35064553472,<br /> "available": "32.4gb",<br /> "available_in_bytes": 34802409472<br /> },<br /> "plugins": [<br /> {<br /> "name": "analysis-icu",<br /> "version": "5.6.3",<br /> "description": "The ICU Analysis plugin integrates Lucene ICU module into elasticsearch, adding ICU relates analysis components.",<br /> "classname": "org.elasticsearch.plugin.analysis.icu.AnalysisICUPlugin",<br /> "has_native_controller": false<br /> },<br /> {<br /> "name": "ingest-geoip",<br /> "version": "5.6.3",<br /> "description": "Ingest processor that uses looksup geo data based on ip adresses using the Maxmind geo database",<br /> "classname": "org.elasticsearch.ingest.geoip.IngestGeoIpPlugin",<br /> "has_native_controller": false<br /> },<br /> {<br /> "name": "ingest-user-agent",<br /> "version": "5.6.3",<br /> "description": "Ingest processor that extracts information from a user agent",<br /> "classname": "org.elasticsearch.ingest.useragent.IngestUserAgentPlugin",<br /> "has_native_controller": false<br /> }<br /> ]<br /> }<br /> }<br />

    内存使用和 GC 指标


    在运行 Elasticsearch 时,内存是您要密切监控的关键资源之一。 Elasticsearch 和 Lucene 以两种方式利用节点上的所有可用 RAM:JVM heap 和文件系统缓存。 Elasticsearch 运行在Java虚拟机(JVM)中,这意味着JVM垃圾回收的持续时间和频率将成为其他重要的监控领域。

    上面返回的 JSON监控的指标有我个人觉得有这些:

  • nodes.successful
  • nodes.failed
  • nodes.total
  • nodes.mem.used_percent
  • nodes.process.cpu.percent
  • nodes.jvm.mem.heap_used

    可以看到 JSON 文件是很复杂的,如果从这复杂的 JSON 中获取到对应的指标(key)的值呢,这里请看文章 :[JsonPath —— JSON 解析神器](http://www.54tianzhisheng.cn/2017/10/13/JsonPath/)

    最后


    这里主要讲下 ES 集群的一些监控信息,有些监控指标是个人觉得需要监控的,但是具体情况还是得看需求了。下篇文章主要讲节点的监控信息。转载请注明地址:[http://www.54tianzhisheng.cn/2 ... rics/](http://www.54tianzhisheng.cn/2 ... trics/)

    参考资料


    1、[How to monitor Elasticsearch performance](https://www.datadoghq.com/blog ... trics/)

    2、[ElasticSearch 性能监控](http://www.oneapm.com/ci/elasticsearch.html)

    3、[cluster-health](https://www.elastic.co/guide/e ... h.html)

    4、[cluster-stats](https://www.elastic.co/guide/e ... s.html)

    相关阅读


    1、[Elasticsearch 默认分词器和中分分词器之间的比较及使用方法](http://www.54tianzhisheng.cn/2 ... yzers/)

    2、[全文搜索引擎 Elasticsearch 集群搭建入门教程](http://www.54tianzhisheng.cn/2 ... stall/)

ElasticSearch 单个节点监控

zhisheng 发表了文章 • 1 个评论 • 3402 次浏览 • 2017-11-07 00:39 • 来自相关话题

原文地址:http://www.54tianzhisheng.cn/2 ... rics/
 

![](http://ohfk1r827.bkt.clouddn.com/cb6.jpeg-1)

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

集群健康监控可以参考这篇文章:[ElasticSearch 集群监控](http://www.54tianzhisheng.cn/2 ... trics/)

节点信息   Node Info :


<br /> curl -XGET 'http://localhost:9200/_nodes'<br />

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

json<br /> _nodes: {<br />   total: 2,<br />   successful: 2,<br />   failed: 0<br /> },<br /> cluster_name: "elasticsearch",<br /> nodes: {<br />     MSQ_CZ7mTNyOSlYIfrvHag: {<br />     name: "node0",<br />     transport_address: "192.168.180.110:9300",<br />     host: "192.168.180.110",<br />     ip: "192.168.180.110",<br />     version: "5.5.0",<br />     build_hash: "260387d",<br />     total_indexing_buffer: 103887667,<br />     roles:{...},<br />     settings: {...},<br />     os: {<br />       refresh_interval_in_millis: 1000,<br />       name: "Linux",<br />       arch: "amd64",<br />       version: "3.10.0-229.el7.x86_64",<br />       available_processors: 4,<br />       allocated_processors: 4<br />     },<br />     process: {<br />       refresh_interval_in_millis: 1000,<br />       id: 3022,<br />       mlockall: false<br />     },<br />     jvm: {<br />       pid: 3022,<br />       version: "1.8.0_121",<br />       vm_name: "Java HotSpot(TM) 64-Bit Server VM",<br />       vm_version: "25.121-b13",<br />       vm_vendor: "Oracle Corporation",<br />       start_time_in_millis: 1507515225302,<br />       mem: {<br />       heap_init_in_bytes: 1073741824,<br />       heap_max_in_bytes: 1038876672,<br />       non_heap_init_in_bytes: 2555904,<br />       non_heap_max_in_bytes: 0,<br />       direct_max_in_bytes: 1038876672<br />       },<br />       gc_collectors: [],<br />       memory_pools: [],<br />       using_compressed_ordinary_object_pointers: "true",<br />       input_arguments:{}<br />     }<br />     thread_pool:{<br />       force_merge: {},<br />       fetch_shard_started: {},<br />       listener: {},<br />       index: {},<br />       refresh: {},<br />       generic: {},<br />       warmer: {},<br />       search: {},<br />       flush: {},<br />       fetch_shard_store: {},<br />       management: {},<br />       get: {},<br />       bulk: {},<br />       snapshot: {}<br />     }<br />     transport: {...},<br />     http: {...},<br />     plugins: [],<br />     modules: [],<br />     ingest: {...}<br />  }<br />

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

<br /> os, process, jvm, thread_pool, transport, http, ingest and indices<br />


节点统计     nodes-statistics


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

<br /> GET /_nodes/stats<br />

得到:

json<br /> _nodes: {<br />   total: 2,<br />   successful: 2,<br />   failed: 0<br /> },<br /> cluster_name: "elasticsearch",<br /> nodes: {<br />   MSQ_CZ7mTNyOSlYI0yvHag: {<br />     timestamp: 1508312932354,<br />     name: "node0",<br />     transport_address: "192.168.180.110:9300",<br />     host: "192.168.180.110",<br />     ip: "192.168.180.110:9300",<br />     roles: [],<br />     indices: {<br />       docs: {<br />            count: 6163666,<br />            deleted: 0<br />         },<br />       store: {<br />            size_in_bytes: 2301398179,<br />            throttle_time_in_millis: 122850<br />         },<br />       indexing: {},<br />       get: {},<br />       search: {},<br />       merges: {},<br />       refresh: {},<br />       flush: {},<br />       warmer: {},<br />       query_cache: {},<br />       fielddata: {},<br />       completion: {},<br />       segments: {},<br />       translog: {},<br />       request_cache: {},<br />       recovery: {}<br />   },<br />   os: {<br />     timestamp: 1508312932369,<br />     cpu: {<br />       percent: 0,<br />       load_average: {<br />         1m: 0.09,<br />         5m: 0.12,<br />         15m: 0.08<br />       }<br />     },<br />     mem: {<br />       total_in_bytes: 8358301696,<br />       free_in_bytes: 1381613568,<br />       used_in_bytes: 6976688128,<br />       free_percent: 17,<br />       used_percent: 83<br />     },<br />     swap: {<br />       total_in_bytes: 8455712768,<br />       free_in_bytes: 8455299072,<br />       used_in_bytes: 413696<br />     },<br />     cgroup: {<br />       cpuacct: {},<br />       cpu: {<br />         control_group: "/user.slice",<br />         cfs_period_micros: 100000,<br />         cfs_quota_micros: -1,<br />         stat: {}<br />       }<br />   }<br /> },<br /> process: {<br />   timestamp: 1508312932369,<br />   open_file_descriptors: 228,<br />   max_file_descriptors: 65536,<br />   cpu: {<br />     percent: 0,<br />     total_in_millis: 2495040<br />   },<br />   mem: {<br />     total_virtual_in_bytes: 5002465280<br />   }<br /> },<br /> jvm: {<br />   timestamp: 1508312932369,<br />   uptime_in_millis: 797735804,<br />   mem: {<br />     heap_used_in_bytes: 318233768,<br />     heap_used_percent: 30,<br />     heap_committed_in_bytes: 1038876672,<br />     heap_max_in_bytes: 1038876672,<br />     non_heap_used_in_bytes: 102379784,<br />     non_heap_committed_in_bytes: 108773376,<br />   pools: {<br />     young: {<br />       used_in_bytes: 62375176,<br />       max_in_bytes: 279183360,<br />       peak_used_in_bytes: 279183360,<br />       peak_max_in_bytes: 279183360<br />     },<br />     survivor: {<br />       used_in_bytes: 175384,<br />       max_in_bytes: 34865152,<br />       peak_used_in_bytes: 34865152,<br />       peak_max_in_bytes: 34865152<br />     },<br />     old: {<br />       used_in_bytes: 255683208,<br />       max_in_bytes: 724828160,<br />       peak_used_in_bytes: 255683208,<br />       peak_max_in_bytes: 724828160<br />     }<br />   }<br />   },<br />   threads: {},<br />   gc: {},<br />   buffer_pools: {},<br />   classes: {}<br /> },<br />   thread_pool: {<br />     bulk: {},<br />     fetch_shard_started: {},<br />     fetch_shard_store: {},<br />     flush: {},<br />     force_merge: {},<br />     generic: {},<br />     get: {},<br />     index: {<br />        threads: 1,<br />        queue: 0,<br />        active: 0,<br />        rejected: 0,<br />        largest: 1,<br />        completed: 1<br />     }<br />     listener: {},<br />     management: {},<br />     refresh: {},<br />     search: {},<br />     snapshot: {},<br />     warmer: {}<br />   },<br />   fs: {},<br />   transport: {<br />     server_open: 13,<br />     rx_count: 11696,<br />     rx_size_in_bytes: 1525774,<br />     tx_count: 10282,<br />     tx_size_in_bytes: 1440101928<br />   },<br />   http: {<br />     current_open: 4,<br />     total_opened: 23<br />   },<br />   breakers: {},<br />   script: {},<br />   discovery: {},<br />   ingest: {}<br /> }<br />

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

索引部分 indices


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

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

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

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

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

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

  • 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 段自己用掉的内存大小。 这里包括底层数据结构,比如倒排表,字典,和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销,这个内存使用量就是一个方便用来衡量开销的度量值。

    操作系统和进程部分


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

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

  • CPU
  • 负载
  • 内存使用率 (mem.used_percent)
  • Swap 使用率
  • 打开的文件描述符 (open_file_descriptors)

    JVM 部分


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

    json<br /> jvm: {<br />   timestamp: 1508312932369,<br />   uptime_in_millis: 797735804,<br />   mem: {<br />     heap_used_in_bytes: 318233768,<br />     heap_used_percent: 30,<br />     heap_committed_in_bytes: 1038876672,<br />     heap_max_in_bytes: 1038876672,<br />     non_heap_used_in_bytes: 102379784,<br />     non_heap_committed_in_bytes: 108773376,<br />   }<br /> }<br />

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

    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](https://www.elastic.co/guide/e ... o.html)

    2、[nodes-stats](https://www.elastic.co/guide/e ... s.html)

    3、[ES监控指标](http://www.oneapm.com/ci/elasticsearch.html)

    最后:


    转载请注明地址:http://www.54tianzhisheng.cn/2 ... rics/

没找到merge bitset代码。

回复

famoss 发起了问题 • 1 人关注 • 0 个回复 • 1198 次浏览 • 2017-11-06 17:16 • 来自相关话题

kopf安装在数据节点还是master节点啊?

回复

redhat 发起了问题 • 1 人关注 • 0 个回复 • 1665 次浏览 • 2017-11-06 16:35 • 来自相关话题

elasticsearch5.50 无法使用java bulk插入数据

回复

elasticsearch9 回复了问题 • 1 人关注 • 1 个回复 • 2147 次浏览 • 2017-11-06 14:46 • 来自相关话题

Elasticsearch 如何在同一个字段内多个must必须同时满足查询

rhwayfun 回复了问题 • 3 人关注 • 2 个回复 • 14344 次浏览 • 2017-11-06 13:49 • 来自相关话题