Elasticsearch重要文章之四：监控每一个节点(ThreadPool部分)

http://zhaoyanblog.com/archives/754.html

 

ThreadPool部分

Elasticsearch 内部使用了线程池，经过这些线程池之间的合做完成工做，在须要时传递工做。通常来讲你不须要调整和优化线程池。可是有时候你看着这些线程池的状态，对你掌握你的集群行为是颇有帮助的。

这有十几个线程池，他们的格式都是相似的：

"index": {
     "threads": 1,
     "queue": 0,
     "active": 0,
     "rejected": 0,
     "largest": 1,
     "completed": 1
  }

每一个线程都列出了配置的线程数，其中有多少个线程是正在处理事务的，也就是活动的，还有多少等待处理的事务在队列里。

若是队列满了，超出了限制，新的事务就会开始被拒绝，你能够看到拒绝的事务的统计，这一般表示你的集群正处在一个资源瓶颈，由于一个满的队列表示你的集群或者节点正在以最大的速度处理事务，可是依然赶不上新事务增长的速度。

关于bulk的拒绝

若是你的线程队列出现拒绝请求的事情，那么醉有可能发生的就是bulk批量索引的请求，经过采用并发导入线程，很容易发给elasticsearch不少的bulk请求，并发请求越多越好吗？

现实中，任何集群都有必定的线程，形成入不敷出。一旦这个阈值达到了，你的队列就会被迅速的填满，新的bulk请求就会被拒绝。

这是一个好事，队列的拒绝是对压力的一个有效措施，他们告诉你你的集群正在处于最大的容量，这要好过把数据所有塞到内存队列里。增大队列大小不会提高性能，它只会隐藏问题，若是你的集群每秒只能处理1万个文档，这和你的队列大小是100仍是一千万没有任何关系，你的集群每秒的处理能力仍然是1万个文档。

队列只会隐藏性能问题，而且带来数据丢失的风险，在队列里的表示尚未被处理的，若是你的节点挂了，那么这些请求就会永远的丢失了，此外队列会消耗很大的内存，这不是个好主意。

最好咱们经过优雅的解决队列满了的问题来清理队列。当你遇到bulk拒绝请求时候，你应该采起以下措施：

一、中止插入线程3-5秒
二、从bluk请求里提取被拒绝的操做，可能大部分请求都成功了。bulk的响应里会告诉你哪些操做成功了，哪些操做被拒绝了。
三、把拒绝的操做从新生成一个新的bulk请求。
四、若是再有拒绝请求发生，就重复上面的步骤。

经过这种方式，你的代码会天然的适应你的集群的负载，天然的减压。

请求拒毫不是错误，它们只是表示你须要过会重试。

有十几个线程池，大部分你能够忽视，可是有少部分须要你特别注意：

indexing 正常的索引文档的请求
bulk 批量请求，这有区别于非批量的请求
get 根据id获取文档的操做
search 索引的检索和查询请求
merging 专门管理lucene合并的线程池

FS和Network部分（剩余空间和网络）

继续看node stats api返回的信息，你会看到一个关于文件系统的统计信息，剩余空间，数据存放目录，磁盘io等待。若是你没有监控剩余磁盘空间大小，你能够从这里获得。磁盘io也是很容易获得，可是一些更专业的命令行工具（例如iostat）可能更有用。

很显然，若是你的磁盘空间不足了，elasticsearch确定完蛋了，因此必定要保证充足的磁盘空间。

下面是关于network统计的两个部分：

"transport": {
	"server_open": 13,
	"rx_count": 11696,
	"rx_size_in_bytes": 1525774,
	"tx_count": 10282,
	"tx_size_in_bytes": 1440101928
 },
 "http": {
	"current_open": 4,
	"total_opened": 23
 },

transport: 显示了网络传输的基本信息，这涉及到节点之间的通讯（一般是9300端口）和一些客户端和节点之间的连接。若是你看到不少连接在这里，不要担忧，elasticsearch会保持大量的节点之间的连接。

http表示关于http端口（一般是9200）的基本信息，若是你看到一个很是大的total_opened,而且在不断增长，这是一个很明确的信号：你的客户端没有使用HTTP的keep-alive。keep-alive的连接对性能很重要，由于不断的建立和断开socket连接是很昂贵的（同事也会浪费open files个数），确保你的客户端都使用了正确的配置。

Circuit Breaker(断路器）

最后咱们来到最后一个部分，关于fieldata 阻断的统计（在《Circuit Breaker》章节中有介绍。

"fielddata_breaker": {
	"maximum_size_in_bytes": 623326003,
	"maximum_size": "594.4mb",
	"estimated_size_in_bytes": 0,
	"estimated_size": "0b",
	"overhead": 1.03,
	"tripped": 0
 }

这里，你能够看到最大阻断的大小（例如，你的查询请求使用多大的内存的时候，这个断路器就会进行左右）。这个部分就是告诉你断路器发挥做用的次数，以及当前配置的过载值，这个值是用来估计的（译者注：用来估计查询可能须要使用的内存）。由于有些查询比其它的比较难估计。

最主要的东西仍是关于断路器起做用的次数的统计，若是这个值很大而且持续增长，表示你的查询须要优化，或者你须要更多的内存（总体上增长内存，或者增长更多的节点）。

原文地址：https://www.elastic.co/guide/en/elasticsearch/guide/current/_monitoring_individual_nodes.html