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拒绝请求时候，你应该采取如下措施：

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

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

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

有十几个线程池，大部分你可以忽视，但是有少部分需要你特别注意：

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