转载：监控每个节点(jvm部分)

操作系统和进程部分

操作系统和进程部分的含义是很清楚的，这里不会描述的很详细。他们列出了基本的资源统计，例如CPU和负载。操作系统部分描述了整个操作系统的情况，进程部分只是描述了Elasticsearch的JVM进程的使用情况。

这显然是很有用的统计， 但是往往会被忽视，一些统计包括如下部分：

>CPU
>负载
>内存使用情况
>swap使用情况
>打开文件句柄数

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

>垃圾收集（GC）入门

在我们描述这个之前，很有必要先介绍下GC以及它对elasticsearch的影响。如果你对jvm中的GC很熟悉，可以跳过这一章。

java是一个自己进行垃圾回收的语言，也就是说程序员不需要主动管理内存的分配和释放。程序员只要专心写自己的代码，java虚拟机会管理根据需要分配内存的过程，然后当内存不再使用的时候，它自己会去释放。

当内存被分配给JVM进程，它会被分配成一个叫堆的大块区域。JVM会把这个堆分成两组，叫做“代”：

年轻代（或者伊甸园）

新实例化的对象就在这里分配空间，年轻代的空间通常很小，大约100MB-500MB。年轻代包含两个幸存者区域

老年代

存储那些老的对象的区域。这些对象是长期存在，并且持续很长时间。老年代通常比年轻代大很多。你可以看到elasticsearch节点的老年代可能大到30GB

当一个对象被实例化后，它会被放置到年轻代，当年轻代的空间满了，一个年轻代的垃圾回收就启动了。那些仍然存活的对象就会被移动到其中一个幸存者区域。而死了的对象就会被清除了。如果一个对象在年轻代中经历了多次GC仍然幸存，那它将被晋升到老年代。

类似的过程也发生在老年代，当老年代的空间越来越满了，一个垃圾回收就启动了，同时死了对象会被清除。

天下没有免费的午餐，年轻代和老年代的垃圾回收都包含一个“stop-the-world”的阶段。在这个时间内，JVM会停止程序的执行，进行对象的标记和收集，在这个stop-the-world的阶段，没有任何事情发生，请求不会被处理，ping不会被会回应。shards不会再进行迁移。整个世界真的停止了。

对于年轻代这不是一个问题，因为它很小，GC执行的很快。但是对于大一点的老年代，缓慢的GC意味着1s甚至15s的停顿，这对于一个服务器软件来说是不可接受的。

垃圾回收在JVM是很复杂的算法，为了减少停顿做了很多的工作。同时Elasticsearch很努力适应GC，比如通过内部对象的重用，利用网络缓冲区，并挺贵一些特征值例如文档的数量。但是GC的频率和长短是需要你特别留意的信息，因为它是集群不稳定的头号元凶。

如果一个集群经常性的发生长时间GC，那么你的集群一定内存不足并且负载特别高。这些长时间GC会导致节点周期性的脱离集群。这种不稳定会导致分片数据不断的重新生成，以保证集群内的平衡以及足够的分片数量。这会增加网络贷款和磁盘IO，同时你的集群还要承担进行正常的索引数据和查询。

简而言之，长时间的GC是很糟糕的，需要尽可能的减少。

因为GC对Elasticsearch如此重要，你必须对node stats的API显示的这个部分特别熟悉才行。

"jvm": {
	"timestamp": 1408556438203,
	"uptime_in_millis": 14457,
	"mem": {
	   "heap_used_in_bytes": 457252160,
	   "heap_used_percent": 44,
	   "heap_committed_in_bytes": 1038876672,
	   "heap_max_in_bytes": 1038876672,
	   "non_heap_used_in_bytes": 38680680,
	   "non_heap_committed_in_bytes": 38993920,

jvm部分首先列出的是有关堆内存使用情况的一般情况，你可以看到多少heap被用到，有多少可以被使用（已经分配了线程），还有堆内存最大可以长到多少。理想情况下heap_committed_in_bytes应该和heap_max_in_bytes相同，如果被分配的堆较小，那JVM将会不得不调整堆的大小，这个过程代价是很高的。如果你的这两个值是不同的，请看《Heap: Sizing and Swapping》章节，确认你配置的是否正确。

heap_used_percent 是你必须盯着看的一个有用的参数。Elasticsearch配置的是当堆使用到75%的时候进行GC，如果你的节点总是大约75%，那你节点正在承受内存方面的压力，这是一个告警，预示着你不久就会出现慢GC。

如果你的heap使用率一直在85%以上，那你有麻烦了，90-95%的概率会因为10-30s的GC 发生性能问题，这还是好的，最坏的就是发生内存溢出。

"pools": {
      "young": {
         "used_in_bytes": 138467752,
         "max_in_bytes": 279183360,
         "peak_used_in_bytes": 279183360,
         "peak_max_in_bytes": 279183360
      },
      "survivor": {
         "used_in_bytes": 34865152,
         "max_in_bytes": 34865152,
         "peak_used_in_bytes": 34865152,
         "peak_max_in_bytes": 34865152
      },
      "old": {
         "used_in_bytes": 283919256,
         "max_in_bytes": 724828160,
         "peak_used_in_bytes": 283919256,
         "peak_max_in_bytes": 724828160
      }
   }
},

young, survivor, and old sections 显示了每个代在GC中的使用情况，供你分析。这些数据方便你看到他们的相对大小，但是对于你调查问题往往不是很重要。

gc": {
   "collectors": {
      "young": {
         "collection_count": 13,
         "collection_time_in_millis": 923
      },
      "old": {
         "collection_count": 0,
         "collection_time_in_millis": 0
      }
   }
}

gc区域显示的GC的次数和时间，包括年轻代和老年代。大部分时间，你可以忽略关于年轻代的手机次数，这个次数往往很大，这是很正常的。

相反，老年代的GC应该少一点，collection_time_in_millis也要小。这是个累计数字，很难给你一个你应该担心时候的数字（举个例子，一个节点运行了一年，可能有很多次GC，但是这个节点却很健康稳定）。这也是一些工具例如Maverl特别有用的原因。多长时间内的GC次数是个很重要的考虑因素。

花在GC上的时间也很重要，例如，在索引数据的时候会产生一定量的内存垃圾，这很正常，会让GC不时的发生。这些GC通常都是很快的，对节点也没有多少英雄。年轻代只需要一两毫秒。老年代可能需要几百毫秒。这和十秒级的GC是很大不同的。

我们最佳的建议是周期性的收集GC的个数和时间（或者使用Marverl) 并且留意频繁GC，你也可以打开慢GC日志，记录在日志里。