elasticsearch遇到的问题(五) 各类问题集合一

问题1：链接超时

问题描述用户反馈ES出现连接超时的情况告警，且为偶然现象

原因

用户在连接ES的过程中，连接时长因为网络波动等原因导致连接时间较长从而被设定的相关参数定义为超时而停止连接服务服务

解决方案：https://blog.csdn.net/unix21/article/details/8743537  

建议把以下两个参数稍作调整，将其减小一些，让客户端能更快“发现”TCP连接被释放： net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_keepalive_probes = 3 因该参数会影响所有的TCP连接，建议您在配置后，观察问题有所缓解后，再根据您客户端的实际情况进行调整。

无法链接，链接超时

1，去检查集群状态是否正常，同时让客户ping一下ES地址和Telnet端口，确认是否正常。

1. 若集群出现问题，则按照集群问题进行处理，保证集群状态greey后再连接
2. 若ES地址无法ping通，则说明在进行配置操作时出现问题，未成功指定ES地址，让用户按照文档重新配置。
3. 若时端口无法ping通，则说明ES集群对访问进行了限制，此时需要求用户查看是否添加了相关IP进入白名单

问题2：ES冷数据节点未配置策略出现数据迁移问题

冷数据节点未设置迁移策略的情况下就会在新添加的冷节点中迁移频繁使用的索引和数据。

原因

选用添加冷数据节点时，并未对相关的索引数据进行冷热分离，而ES本身自带的机制是新加入冷节点后，索引上如果没有配置冷热分离属性，会均衡到冷节点上。也就是说如果对索引数据未添加冷热的标签 在创建冷节点后系统就会对这些数据进行分配。会出现有数据或者说频繁使用的索引“被迁移”到冷节点的情况

解决方案

1、对相关索引配置冷热隔离属性，在添加相关标签后则会避免这种问题的出现。
2、选择使用阿里ES的日志增强版本，日志增强版对相关架构进行了设置，在不对标签进行处理也会保证数据索引不会被打散分配到冷节点中区

阿里相关文档：

冷热分离与索引生命周期管理：

https://help.aliyun.com/document_detail/178307.html?spm=5176.21213303.J_6028563670.17.1c3f3edaqamAmi&scm=20140722.S_help%40%40%E6%96%87%E6%A1%A3%40%40178307.S_hot.ID_178307-RL_%E5%86%B7%E7%83%AD%E9%9A%94%E7%A6%BB-OR_s%2Bhelpproduct-V_1-P0_2

冷热分离：

https://help.aliyun.com/document_detail/173474.html?spm=5176.21213303.J_6028563670.7.1c3f3edaqamAmi&scm=20140722.S_help%40%40%E6%96%87%E6%A1%A3%40%40173474.S_hot.ID_173474-RL_%E5%86%B7%E7%83%AD%E9%9A%94%E7%A6%BB-OR_s%2Bhelpproduct-V_1-P0_0

问题3：并发问题

客户反馈出现“org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor[Running, pool size = 8, active threads = 8, queued tasks = 3491, completed tasks = 291280076]]]"},"status":429}”的报错信息

问题原因

超过了最大的线程数，导致出现报错信息

解决方案

如果是阿里云的es集群，ES线程数 暂时无法通过控制台 yml 页面进行配置修改。同时这里也不建议修改。会影响es 的稳定性。 建议升配实例，或者qos 插件进行控制。线程不够的话可以控制并发，减少写入。

阿里云相关文档：https://help.aliyun.com/document_detail/156622.html?spm=5176.21213303.J_6028563670.7.19f13eda4oyTBG&scm=20140722.S_help%40%40%E6%96%87%E6%A1%A3%40%40156622.S_0.ID_156622-RL_qos%20%E6%8F%92%E4%BB%B6-OR_s%2Bhelpproduct-V_1-P0_0

更多信息

活跃并发数尽量控制在cpu核数的2到3倍左右

问题4：索引节点分配不均

在索引创建时创建了多于【节点数-1】的副本数，搜索在多次执行后由于反馈时间较长从而导致返回数据随机出现失败。解决办法：需要对副本分片进行修改，将副本分片修改为【数据节点-1】数量就可以了。

实例CPU占用过高

设置冷热节点后，对每个结点都设置了1shard的业务索引，由于热节点数据使用量远大于与冷节点，导致shard压力倾斜。

解决办法：重新规划相关的shard将shard数设置为相关数据节点的倍数，保证在某个shard数据量过大时有其他的shard分担。

问题5：集群状态为yellow

问题描述

es集群状态为yellow

问题原因

索引在创建过程中创建了7个副本，但只有6个数据节点，有两个副本分片无法分配数据节点

解决方案

首先确定副本分片是否丢失：GET _cat/indices/material_design?v对副本分片进行确认，再对副本分片及数据节点进行确认，从而定位到问题原因，重新修改副本分片数量即可解决

问题6：触发内存熔断机制

问题原因

在业务操作过程中出现业务高峰，读写的qps持续上涨，集群内存饱满，触发了内存的熔断。从而导致报错出现。

解决方案

由于内存不足原因导致，有以下解决方案：

    1、减少写入量，或者对写入进行qos限流；

    2、等待内存自行释放，或者强制重启集群直接释放内存；

    3、在无法降低写入量且该业务为常态业务的话，需要对集群进行升配，扩容内存资源。

问题7 ：es一个数据节点cpu和内存高，其他节点正常

      1、遇到这种问题首先看监控，分析是否是内存高，还是cpu高，都是两个指标都高

      2、如果是cpu高，基本可以定位到热线程找原因。检查该集群发现没有长期占用cpu的热线程。如果cpu和内存都高，进而结合分析日志，慢查，慢索引等。

      3、经过分析是慢查很多，都是一个数据节点的慢查多

      4、es是负载均衡的，为什么负载都是一个数据节点高呢？请求分发是否均衡(不均衡有可能影响slb的域名的均衡转发请求)

      5、查看确认每个节点的shard数量均衡分布的

      6、这种时候分析是否有热点访问，他们正好这段慢业务的查询的数据都落在这个节点的shard上。

      7、然后查日志发现都是一个索引引发的慢日志查询

      8、接着检查这个索引在各个数据节点的分布情况，发现这个索引的所有主分片都分在该数据节点上

      9、客户疑问：为什么建索引会这么不均衡。经过查了一下，这种情况一般都是新建索引时候集群其他节点有问题导致的。出现故障主分片应该不会也转移到一个数据节点上。

      10、es读写的请求具体在主副分片如何轮询的不是很清楚，但三个主分片都在一个数据节点上是不合理的。可以看下这个社区文档：https://elasticsearch.cn/question/7689

      11、给出以下优化建议：

      经过排查发现该数据节点是由于shard分配不均衡导致的慢查过多，引起该数据节点的资源使用率过高。可以考虑重建索引或者重新reroute分片解决该问题。

      同时给出以下的优化建议能一定程度上避免单节点负载过高问题：建议对小索引按照时间周期进行合并，索引shard数等于数据节点个数的整数倍，其次单个shard大小在30gb左右

问题8：bulk写入延时

常见的写入调优 ：
1. 不带主键会快很多，数据量大了甚至比带主键快一倍，减少check 主键的过程；
2. 尽量一个bulk一个索引，避免拆分到每个shard的数据太小；
3、把重要的数据拆到单独的集群。
4、调高refresh间隔ES内存索引只有refresh之后才能被搜索到(默认1秒refresh一次)。refresh过程会创建新的Lucence segment，且后台会进行segment merge 操作,降低refresh频率，能减少segment的创建跟合并。特定场景下，可以关闭自动refresh，待索引完后手工refresh。
5、禁用_all属性

https://blog.csdn.net/qq_29860591/article/details/111244590?utm_medium=distribute.wap_relevant.none-task-blog-baidujs_baidulandingword-4

https://www.infoq.cn/article/a4updrlsgevvo8kpmajz

4c8g，六个数据节点。每分钟50万+数据，20个并发写入，一次bulk5000-10000条数据，延时25s左右。cpu 40%左右、负载2左右、内存40%，左右，资源使用率很低

写入是写入到buffer就算一次完成写入

1、检查分片数量，大小。比如一个分片100G了这样。如果分片数量过多，routing寻址时间会比较长，导致写入延时

2、bulk数据是不是指定routing，所有数据并发到一个节点上，导致没有均衡routing造成的延时

3、延时的波峰是不是refresh的时间间隔一致，比如refresh 60s，延时则间隔一分钟出现波峰，这样情况，可以将refresh调小一点

4、bulk批次调小一点，bulk写入改频繁一点，es的java客户端请求变更为异步后，延时降低到100ms左右。

问题9：es做跨集群搜索的时候出现了鉴权错误

跨集群查询索引，部分数据节点出现访问失败：报错鉴权错误。user取消赋予transport_client这个role，就可以正常访问了。

猜测原理：因为节点tcp client嗅探开了，请求会client会自动连接到其他节点上面。但其他节点上面权限没有配这个用户，所以就导致其他的那个节点发到其他节点上，那个请求把你部分请求给锯掉了。去掉role之后，使用的不是这种链接方式就好了。

 

 

无法复现问题，一开始按照上面两个角色创建，然后跨集群访问，报权限的错。

后面在对端加了一个同样的user，elastic_sync，权限赋予：read_cross_cluster之后就可以访问了

然后删除对端user

再用上面两个角色的user去查询对端数据，还是可以查询数据。

问题10：无法bulk数据 

一般都是关闭动态创建索引

用elastic用户，bulk数据试试，是不是用transport client 做的bulk 管理。 如果是，关闭一下嗅探。

建议如果是transport client 连接方式，建议换成High Level REST Client

看一下这篇官档参考参考呢，https://help.aliyun.com/document_detail/172371.html?spm=a2c4g.11186623.6.836.54cf63e2y4qrEX

elasticsearch采用TransportClient这种方式，官方明确表示在ES 7.0版本中将弃用TransportClient客户端，且在8.0版本中完全移除它.

https://stackoverflow.com/questions/45793117/elastic-search-no-living-connection-when-sniffing-on-startup/50811713

Transport client连接需要关闭嗅探。当ES服务器监听使用内网服务器IP而访问使用外网IP时，不要使用client.transport.sniff为true，在自动发现时会使用内网IP进行通信，导致无法连接到ES服务器，而直接使用addTransportAddress方法进行指定ES服务器。

问题11：cpu偶尔过高的优化建议

如果没有现场环境，无法获取cpu hot_threads ，只能从监控和日志观察，不排除和当时的热点数据有关系，再加上集群负载不均比较严重，这种现象表现比较明显，建议对小索引按照时间周期进行合并，索引shard数等于数据节点个数的整数倍，其次单个shard大小在30gb左右。其次优化后，还出现cpu高，使用 GET _nodes/hot_threads获取下热线程