[Elasticsearch 5.6 Java API 中文手册]

本手册由 全科 翻译，并且整理成电子书，支持PDF,ePub,Mobi格式，方便大家下载阅读。

不只是官方文档的翻译，还包含使用实例，包含我们使用踩过的坑

阅读地址：https://es.quanke.name

下载地址：https://www.gitbook.com/book/q ... -java

github地址：https://github.com/quanke/elasticsearch-java

编辑：http://quanke.name

编辑整理辛苦，还望大神们点一下star ，抚平我虚荣的心

[全科的公众号]


 

2018年8月24日更新: 今天放出的6.4版修复了这个问题。


原文链接: http://www.jianshu.com/p/d4f7a6d58008

前天公司度假部门一个线上ElasticSearch集群发出报警，有Data Node的Heap使用量持续超过80%警戒线。 收到报警邮件后，不敢怠慢，立即登陆监控系统查看集群状态。还好，所有的结点都在正常服务，只是有2个结点的Heap使用率非常高。此时，Old GC一直在持续的触发，却无法回收内存。

---

初步排查

问题结点的Heap分配了30GB，80%的使用率约等于24GB。 但集群的数据总量并不大，5个结点所有索引文件加起来占用的磁盘空间还不到10GB。
<br /> GET /_cat/allocation?v&h=shards,disk.indices,disk.used,disk.avail<br /> <br /> shards disk.indices disk.used disk.avail<br /> 3 1.9gb 38.3gb 89.7gb<br /> 4 2.2gb 13.4gb 114.6gb<br /> 4 2.5gb 20.3gb 107.7gb<br /> 4 2.3gb 33.9gb 94.1gb<br /> 3 1.7gb 12.8gb 115.2gb<br />

查看各结点的segment memory和cache占用量也都非常小，是MB级别的。
<br /> GET /_cat/nodes?v&h=id,port,v,m,fdp,mc,mcs,sc,sm,qcm,fm,im,siwm,svmm<br /> <br /> id port v m fdp mc mcs sc sm qcm fm siwm svmm<br /> e1LV 9300 5.3.2 - 1 0 0b 68 69mb 1.5mb 1.9mb 0b 499b<br /> 5VnU 9300 5.3.2 - 1 0 0b 75 79mb 1.5mb 1.9mb 0b 622b<br /> _Iob 9300 5.3.2 - 1 0 0b 56 55.7mb 1.3mb 914.1kb 0b 499b<br /> 4Kyl 9300 5.3.2 * 1 1 330.1mb 81 84.4mb 1.2mb 1.9mb 0b 622b<br /> XEP_ 9300 5.3.2 - 1 0 0b 45 50.4mb 748.5kb 1mb 0b 622b<br />
集群的QPS只有30上下，CPU消耗10%都不到，各类thread pool的活动线程数量也都非常低。

非常费解是什么东西占着20多GB的内存不释放？

出现问题的集群ES版本是5.3.2，而这个版本的稳定性在公司内部已经经过长时间的考验，做为稳定版本在线上进行了大规模部署。 其他一些读写负载非常高的集群也未曾出现过类似的状况，看来是遇到新问题了。

查看问题结点ES的日志，除了看到一些Bulk异常以外，未见特别明显的其他和资源相关的错误:
<br /> [2017-11-06T16:33:15,668][DEBUG][o.e.a.b.TransportShardBulkAction] [] [suggest-3][0] failed to execute bulk item (update) BulkShardRequest [[suggest-3][0]] containing [44204<br /> ] requests<br /> org.elasticsearch.index.engine.DocumentMissingException: [type][纳格尔果德_1198]: document missing<br /> at org.elasticsearch.action.update.UpdateHelper.prepare(UpdateHelper.java:92) ~[elasticsearch-5.3.2.jar:5.3.2]<br /> at org.elasticsearch.action.update.UpdateHelper.prepare(UpdateHelper.java:81) ~[elasticsearch-5.3.2.jar:5.3.2]<br />

和用户确认这些异常的原因，是因为写入程序会从数据源拿到数据后，根据doc_id对ES里的数据做update。会有部分doc_id在ES里不存在的情况，但并不影响业务逻辑，因而ES记录的document missing异常应该可以忽略。

至此别无他法，只能对JVM做Dump分析了。

---

Heap Dump分析

用的工具是[Eclipse MAT](http://wiki.eclipse.org/MemoryAnalyzer)，从这里下载的Mac版:[Downloads](https://www.eclipse.org/mat/downloads.php) 。 使用这个工具需要经过以下2个步骤:

• 获取二进制的head dump文件 jmap -dump:format=b,file=/tmp/es_heap.bin <pid> 其中pid是ES JAVA进程的进程号。
  
• 将生成的dump文件下载到本地开发机器，启动MAT，从其GUI打开文件。
  
  要注意，MAT本身也是JAVA应用，需要有JDK运行环境的支持。
  
  MAT第一次打dump文件的时候，需要对其解析，生成多个索引。这个过程比较消耗CPU和内存，但一旦完成，之后再打开dump文件就很快，消耗很低。 对于这种20多GB的大文件，第一次解析的过程会非常缓慢，并且很可能因为开发机内存的较少而内存溢出。因此，我找了台大内存的服务器来做第一次的解析工作:
  
• 将linux版的MAT拷贝上去，解压缩后，修改配置文件MemoryAnalyzer.ini，将内存设置为20GB左右:
  <br /> $ cat MemoryAnalyzer.ini <br /> <br /> -startup<br /> plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar<br /> --launcher.library<br /> plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.300.v20150602-1417<br /> -vmargs<br /> -Xmx20240m<br />
  这样能保证解析的过程中不会内存溢出。
  
• 将dump文件拷贝上去，执行下面几个命令生成索引及3个分析报告:
  
  • mat/ParseHeapDump.sh es_heap.bin org.eclipse.mat.api:suspects
    
  • mat/ParseHeapDump.sh es_heap.bin org.eclipse.mat.api:overview
    
  • mat/ParseHeapDump.sh es_heap.bin org.eclipse.mat.api:top_components
    
    分析成功以后，会生成如下一堆索引文件(.index)和分析报告(.zip)
    <br /> -rw-r--r--@ 1 xgwu staff 62M Nov 6 16:18 es_heap.a2s.index<br /> -rw-r--r--@ 1 xgwu staff 25G Nov 6 14:59 es_heap.bin<br /> -rw-r--r--@ 1 xgwu staff 90M Nov 6 16:21 es_heap.domIn.index<br /> -rw-r--r--@ 1 xgwu staff 271M Nov 6 16:21 es_heap.domOut.index<br /> -rw-r--r-- 1 xgwu staff 144K Nov 7 18:38 es_heap.i2sv2.index<br /> -rw-r--r--@ 1 xgwu staff 220M Nov 6 16:18 es_heap.idx.index<br /> -rw-r--r--@ 1 xgwu staff 356M Nov 6 16:20 es_heap.inbound.index<br /> -rw-r--r--@ 1 xgwu staff 6.8M Nov 6 16:20 es_heap.index<br /> -rw-r--r--@ 1 xgwu staff 76M Nov 6 16:18 es_heap.o2c.index<br /> -rw-r--r--@ 1 xgwu staff 231M Nov 6 16:20 es_heap.o2hprof.index<br /> -rw-r--r--@ 1 xgwu staff 206M Nov 6 16:21 es_heap.o2ret.index<br /> -rw-r--r--@ 1 xgwu staff 353M Nov 6 16:20 es_heap.outbound.index<br /> -rw-r--r--@ 1 xgwu staff 399K Nov 6 16:16 es_heap.threads<br /> -rw-r--r--@ 1 xgwu staff 89K Nov 7 17:40 es_heap_Leak_Suspects.zip<br /> -rw-r--r--@ 1 xgwu staff 78K Nov 6 19:22 es_heap_System_Overview.zip<br /> -rw-r--r--@ 1 xgwu staff 205K Nov 6 19:22 es_heap_Top_Components.zip<br /> drwxr-xr-x@ 3 xgwu staff 96B Nov 6 16:15 workspace<br />
    将这些文件打包下载到本地机器上，用MAT GUI打开就可以分析了。
    
    在MAT里打开dump文件的时候，可以选择打开已经生成好的报告，比如Leak suspects:
    
    
    
    通过Leak Suspects，一眼看到这20多GB内存主要是被一堆bulk线程实例占用了，每个实例则占用了接近1.5GB的内存。
    
    
    进入"dominator_tree"面板，按照"Retained Heap"排序，可以看到多个bulk线程的内存占用都非常高。
    
    
    将其中一个thread的引用链条展开，看看这些线程是如何Retain这么多内存的，特别注意红圈部分:
    
    
    这个引用关系解读如下:
    
    1. 这个bulk线程的thread local map里保存了一个log4j的MultableLogEvent对象。
       
    2. MutablelogEvent对象引用了log4j的ParameterizedMessage对象。
       
    3. ParameterizedMessage引用了bulkShardRequest对象。
       
    4. bulkShardRequest引用了4万多个BulkitemRequest对象。
       
       这样看下来，似乎是log4j的logevent对一个大的bulk请求对象有强引用而导致其无法被垃圾回收掉，产生内存泄漏。
       
       联想到ES日志里，有记录一些document missing的bulk异常，猜测是否在记录这些异常的时候产生的泄漏。
       
       ---
       

       问题复现
       

       为了验证猜测，我在本地开发机上，启动了一个单结点的5.3.2测试集群，用bulk api做批量的update，并且有意为其中1个update请求设置不存在的doc_id。为了便于测试，我在ES的配置文件elasticsearch.yml里添加了配置项processors: 1。 这个配置项影响集群thread_pool的配置，bulk thread pool的大小将减少为1个，这样可以更快速和便捷的做各类验证。
       
       启动集群，发送完bulk请求后，立即做一个dump，重复之前的分析过程，问题得到了复现。 这时候想，是否其他bulk异常也会引起同样的问题，比如写入的数据和mapping不匹配？ 测试了一下，问题果然还是会产生。再用不同的bulk size进行测试，发现无法回收的这段内存大小，取决于最后一次抛过异常的bulk size大小。至此，基本可以确定内存泄漏与log4j记录异常消息的逻辑有关系。
       
       为了搞清楚这个问题是否5.3.2独有，后续版本是否有修复，在最新的5.6.3上做了同样的测试，问题依旧，因此这应该是一个还未发现的深层Bug.
       
       ---
       

       读源码查根源
       

       大致搞清楚问题查找的方向了，但根源还未找到，也就不知道如何修复和避免，只有去扒源码了。
       在TransportShardBulkAction 第209行，找到了ES日志里抛异常的代码片段。
       java<br /> if (isConflictException(failure)) {<br /> logger.trace((Supplier<?>) () -> new ParameterizedMessage("{} failed to execute bulk item ({}) {}",<br /> request.shardId(), docWriteRequest.opType().getLowercase(), request), failure);<br /> } else {<br /> logger.debug((Supplier<?>) () -> new ParameterizedMessage("{} failed to execute bulk item ({}) {}",<br /> request.shardId(), docWriteRequest.opType().getLowercase(), request), failure);<br /> }<br />
       这里看到了ParameterizedMessage实例化过程中，request做为一个参数传入了。这里的request是一个BulkShardRequest对象，保存的是要写入到一个shard的一批bulk item request。 这样以来，一个批次写入的请求数量越多，这个对象retain的内存就越多。 可问题是，为什么logger.debug（）调用完毕以后，这个引用不会被释放？
       
       通过和之前MAT上的dominator tree仔细对比，可以看到ParameterizedMessage之所以无法释放，是因为被一个MutableLogEvent在引用，而这个MutableLogEvent被做为一个thread local存放起来了。 由于ES的Bulk thread pool是fix size的，也就是预先创建好，不会销毁和再创建。 那么这些MutableLogEvent对象由于是thread local的，只要线程没有销毁，就会对该线程实例一直全局存在，并且其还会一直引用最后一次处理过的ParameterizedMessage。 所以在ES记录bulk exception这种比较大的请求情况下， 整个request对象会被thread local变量一直强引用无法释放，产生大量的内存泄漏。
       
       再继续挖一下log4j的源码，发现MutableLogEvent是在org.apache.logging.log4j.core.impl.ReusableLogEventFactory里做为thread local创建的。
       java<br /> public class ReusableLogEventFactory implements LogEventFactory {<br /> private static final ThreadNameCachingStrategy THREAD_NAME_CACHING_STRATEGY = ThreadNameCachingStrategy.create();<br /> private static final Clock CLOCK = ClockFactory.getClock();<br /> <br /> private static ThreadLocal<MutableLogEvent> mutableLogEventThreadLocal = new ThreadLocal<>();<br />
       而org.apache.logging.log4j.core.config.LoggerConfig则根据一个常数ENABLE_THREADLOCALS的值来决定用哪个LogEventFactory。
       java<br /> if (LOG_EVENT_FACTORY == null) {<br /> LOG_EVENT_FACTORY = Constants.ENABLE_THREADLOCALS<br /> ? new ReusableLogEventFactory()<br /> : new DefaultLogEventFactory();<br /> }<br />
       
       继续深挖，在org.apache.logging.log4j.util.Constants里看到，log4j会根据运行环境判断是否是WEB应用，如果不是，就从系统参数log4j2.enable.threadlocals读取这个常量，如果没有设置，则默认值是true。
       java<br /> public static final boolean ENABLE_THREADLOCALS = !IS_WEB_APP && PropertiesUtil.getProperties().getBooleanProperty(<br /> "log4j2.enable.threadlocals", true);<br />
       
       由于ES不是一个web应用，导致log4j选择使用了ReusableLogEventFactory，因而使用了thread_local来创建MutableLogEvent对象，最终在ES记录bulk exception这个特殊场景下产生非常显著的内存泄漏。
       
       再问一个问题，为何log4j要将logevent做为thread local创建？ 跑到log4j的官网去扒了一下文档，在这里 [Garbage-free Steady State Logging](https://logging.apache.org/log ... e.html) 找到了合理的解释。 原来为了减少记录日志过程中的反复创建的对象数量，减轻GC压力从而提高性能，log4j有很多地方使用了thread_local来重用变量。 但使用thread local字段装载非JDK类，可能会产生内存泄漏问题，特别是对于web应用。 因此才会在启动的时候判断运行环境，对于web应用会禁用thread local类型的变量。
       

       ThreadLocal fields holding non-JDK classes can cause memory leaks in web applications when the application server's thread pool continues to reference these fields after the web application is undeployed. To avoid causing memory leaks, Log4j will not use these ThreadLocals when it detects that it is used in a web application (when the javax.servlet.Servlet class is in the classpath, or when system property log4j2.is.webapp is set to "true").
       
       参考上面的文档后，也为ES找到了规避这个问题的措施： 在ES的JVM配置文件jvm.options里，添加一个log4j的系统变量-Dlog4j2.enable.threadlocals=false，禁用掉thread local即可。 经过测试，该选项可以有效避开这个内存泄漏问题。
       
       这个问题Github上也提交了Issue，对应的链接是: [Memory leak upon partial TransportShardBulkAction failure](https://github.com/elastic/ela ... /27300)
       
       ---
       

       写在最后
       

       ES的确是非常复杂的一个系统，包含非常多的模块和第三方组件，可以支持很多想象不到的用例场景，但一些边缘场景可能会引发一些难以排查的问题。完备的监控体系和一个经验丰富的支撑团队对于提升业务开发人员使用ES开发的效率、提升业务的稳定性是非常重要的！
        

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


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

要监控哪些 ElasticSearch metrics


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_nodes 和 number_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/)