failed to execute pipeline for a bulk request问题

客户使用场景是使用第三方工具大批量往ES写入数据，报错写入失败，需排查。

已知情况：

1. 当前环境各组件运行正常，数据由HBase侧不停写入ES

2. 索引主分片数10个，副本1个

3. ES HEAP设置是8GB，JVM内存资源较为紧张

问题分析：

查报错日志推断是写入侧推送数据过快，ES处理能力不足导致！

解决办法：

1. 常规场景下应该下调往ES推送的数据大小或频率。

2. 增大ES的内存，现场距离ES内存峰值30GB仍有很大空间。

3. 考虑线程池过小导致，参考后面章节。

实际处理：

略微下调主分片个数使其均匀分布（10 -> 8），将索引的副本数从1减为0，相当于写入压力减少一半，至此现场问题解决，没再出现上述报错。

磁盘I/O异常引起的问题修复

用户在例行巡检过程发现es有data节点处于停止状态，进行启动后，页面进度条显示绿色已完成，但实际进程启动失败了。

问题排查与处理：

1. 排查节点日志，发现不能访问数据路径，报错关键内容如下：

   Unable to access ‘path.data’ (/mnt/elasticsearch/slave/data)……

2. 检查挂载磁盘，使用命令df -Th或lsblk -f

   发现磁盘没有占满，使用容量还有剩余很多，文件系统为xfs。

3. cd到数据路径，没有报错，但ls有报错：ls: cannot open directory Input/output error。据此怀疑磁盘或文件系统故障。我们先排除文件系统故障。

4. 此时设备已经处于不可用状态，先尝试重启机器（reboot）-> 就这样解决了。

5. 如果重启没有解决，依然是Input/output error，那么尝试进行文件系统修复操作如下：

6. 从【2】中获取到要修复的挂载点，如/dev/sdb

7. xfs的文件系统，使用如下命令进行修复:xfs_repair /dev/sdb

8. 正常的话要提示“设备或资源忙”,“couldn’t initialize XFS library”，需要先取消挂载umount /dev/sdb

9. 继续执行修复：

xfs_repair /dev/sdb -L

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 3
- agno = 4
- agno = 2
- agno = 5

- 【注：有剪辑省略内容】

Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

10. 修复完成后再把磁盘挂上，即可生效：mount /dev/sdb /mnt/elasticsearch/data。经实测，数据没有丢失，也就是不会使情况更糟——要么修好了，要么修不好保持原样。

p.s：这个问题不是ES自身引起的，而是外界干扰，不要浪费太多时间去处理。如果修复失败，报修硬件。

http请求长度超过限制

最近（22年10月）接用户反馈，使用ES查询的索引表越来越多了，出现“400 Bad Request”

问题描述：

ElasticSearch exception：too_long_frame_exception，reason：An HTTP line is larger than 4096 bytes。

ElasticsearchStatusException[Elasticsearch exception [type=too_long_frame_exception, reason=An HTTP line is larger than 4096 bytes.]]

    at org.elasticsearch.rest.BytesRestResponse.errorFromXContent(BytesRestResponse.java:177)

    at org.elasticsearch.client.RestHighLevelClient.parseEntity(RestHighLevelClient.java:526)

解决办法：

官网有如下3个参数控制请求大小：

需在elasticserach.yml中设置ES参数（http.max_initial_line_length默认4kb，具体大小根据自己实际情况设置）：

http.max_initial_line_length: 8k
http.max_header_size: 16k
http.max_content_length: 500mb

如果有集群管理，从集群页面的自定义配置中添加，保存，最后重启ES集群。

ES的线程池设置

ElasticSearch开箱即用，在生产环境一般不需要对参数进行特别调优，但在某些特殊、极端场景下（如压测）则需要对ES各项服务线程池进行设置。

问：什么时候才需要调整这些参数？

答：除了刚才提到的压测情境，在遇到相关报错时，根据日志提示调整。

通过curl -XGET ‘http://localhost:9200/_nodes/stats?pretty’ 接口观察thread_pool部分的统计，关注rejected的值，elasticsearch将拒绝请求（bulk HTTP状态码429）的次数累加到rejected中。

问：怎么调整这些参数？

答：2.x版本可API动态设置，在ES 5版本之后就不能动态设置这些参数了，通过修改ES主配置文件，然后重启ES生效。（“reason”: “transient setting thread_pool.write.queue_size, not dynamically updateable”）

问：最佳实践是什么？

答：非必要不调整，独占时最大化。

参考：

thread_pool.write.size：cpu核数+1

thread_pool.search.size: （最大cpu核数*3/2+1）

thread_pool.write.queue_size: 1000

thread_pool.search.queue_size: 1000

ES的双网分离设置

如果在生产环境配置了管理网和业务网分离（一般分别是千兆网和万兆网），怎么设置ES比较合理？

ES关于网络的配置参数丰富繁杂（它们都不是可动态更新的），ES双网分离场景的最佳实践是ES集群内部采用万兆-业务网，对外服务则双网都通，有管理及合规要求时按照要求设置单一网络。

实践举例：

到elasticsearch.yml中进行修改，首先注释掉network.host配置。

http.host是传入 HTTP 请求绑定到的端口；transport.host是要绑定用于节点之间通信的端口。

# elasticsearch.yml中增加

http.host: 0.0.0.0
transport.host: 192,168.1.23
# transport.host填写节点的实际万兆ip，http.host固定0.0.0.0，也可修改为指定ip

ES系列参考

ES集群red状态排查与恢复

ElasticSearch重要概念和常用操作

ES线程池设置

线程池-ES-官方文档