failed to execute pipeline for a bulk request问题
客户使用场景是使用第三方工具大批量往ES写入数据，报错写入失败，需排查。
已知情况：
当前环境各组件运行正常，数据由HBase侧不停写入ES
索引主分片数10个，副本1个
ES HEAP设置是8GB，JVM内存资源较为紧张
问题分析：
查报错日志推断是写入侧推送数据过快，ES处理能力不足导致！
解决办法：
常规场景下应该下调往ES推送的数据大小或频率。
增大ES的内存，现场距离ES内存峰值30GB仍有很大空间。
考虑线程池过小导致，参考后面章节。
实际处理：
略微下调主分片个数使其均匀分布（10 -> 8），将索引的副本数从1减为0，相当于写入压力减少一半，至此现场问题解决，没再出现上述报错。
磁盘I/O异常引起的问题修复
用户在例行巡检过程发现es有data节点处于停止状态，进行启动后，页面进度条显示绿色已完成，但实际进程启动失败了。
问题排查与处理：
-
排查节点日志，发现不能访问数据路径，报错关键内容如下：
Unable to access ‘path.data’ (/mnt/elasticsearch/slave/data)……
-
检查挂载磁盘，使用命令
df -Th或lsblk -f发现磁盘没有占满，使用容量还有剩余很多，文件系统为
xfs。 cd到数据路径，没有报错，但ls有报错：ls: cannot open directory Input/output error。据此怀疑磁盘或文件系统故障。我们先排除文件系统故障。
此时设备已经处于不可用状态，先尝试重启机器（reboot）-> 就这样解决了。
如果重启没有解决，依然是Input/output error，那么尝试进行文件系统修复操作如下：
从【2】中获取到要修复的挂载点，如
/dev/sdbxfs的文件系统，使用如下命令进行修复:
xfs_repair /dev/sdb正常的话要提示“设备或资源忙”,"couldn't initialize XFS library"，需要先取消挂载
umount /dev/sdb继续执行修复：
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
- 修复完成后再把磁盘挂上，即可生效：
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
