ELK系统之logstash问题：retrying failed action with response code: 429

喜欢ヅ旅行 2022-06-02 01:15 709阅读 0赞

## 问题来源 ##

logstash在进行单机导入数据的时候，效果一直都是不错的，但是，当使用es集群之后，多台集群服务器一起运行logstash导入程序，一开始还是没问题的，但是运行了一段时间之后，就可能会产生以下的问题：

1.  \[ERROR\]\[logstash.outputs.elasticsearch\]Retrying individual actions
2.  \[INFO\]\[logstash.outputs.elasticsearch\]retrying failed action with response code: 429 (“reason”=>”rejected execution of org.elasticsearch.transport.TransportService……
3.  \[ERROR\]\[logstash.outputs.elasticsearch\]Attempted to send a bulk request to elasticsearch’ but Elasticsearch appears to be unreachable or down! ……

## 问题说明 ##

从报错的内容提示来看，说明logstash写入到elasticsearch的速度赶不上从数据库读取数据的速度，输出数据阶段未完成的情况下，logstash仍然在不断的、快速的给ES发送bulk reuqest，从而导致ES集群的网络io过载，进而产生以上的问题提示，表明elasticsearch无法继续接收数据；

## 解决方法 ##

根据以上问题的产生提示，再参照官网的建议和网友的解决方案，以下则是解决问题的一些步骤：  
　　  
１. 首先，需要了解解决这个问题的相关的几个参数：

（1）. flush\_size: 批量写入ES数量，累计缓冲event事件条数达到flush\_size值会flush一次，这个参数默认是500；　这个参数就是调整缓冲区大小的；　为了高效使用elasticsearch的bulk API调用，我们将在刷新事件到Elasticsearch之前缓冲一定数量的事件；　flush\_size这个参数就是控制有多少事件在被批量写入到Elasticsearch之前需要被缓冲，增大flush\_size的同时也增大Logstash的Heap大小；　这个参数在logstash.conf的output进行设置；

（２）. idle\_flush\_time: 批量写入ES频率，距离上次flush的时间之后idle\_flush\_time秒后也会flush一次,通常会结合flush\_size一起来控制写入es的数量和频率，提高es的插入性能；　这个参数在logstash.conf的output进行设置；

（３）. pipeline.workers: pipeline管道线程数，官方建议是等于CPU内核数；

（４）. pipeline.output.workers: pipeline管道实际output时的线程数，一般小于或等于管道线程数，建议等于cpu内核数；

（５）. pipeline.batch.size: 单个工作线程在尝试执行过滤器和输出之前收集的最大事件数，默认125；　 数值越大，处理则通常更高效，但增加了内存开销；　某些硬件配置要求通过设置LS\_HEAP\_SIZE变量来增加JVM堆大小，以避免使用此选项导致性能下降；　此参数的值超过最佳范围会导致由于频繁的垃圾回收或与内存不足异常相关的JVM崩溃而导致性能下降；　调整pipeline.batch.size设置大小可调整发送到Elasticsearch的批量请求的大小。

（６）. pipeline.batch.delay: 此设置调整Logstash管道的延迟，默认5；　流水线批处理延迟是Logstash在当前管道工作线程中接收到事件后等待新消息的最大时间（毫秒）；　在此时间过后，Logstash开始执行过滤器和输出.Logstash在接收事件和在过滤器中处理该事件之间等待的最大时间是pipeline.batch.delay和pipeline.batch.size设置的乘积。

（７）. 流动计数:　logstash管道处理事件的总数由pipeline.workers和pipeline.batch.size设置的乘积确定，称为流动计数；　在调整pipeline.workers和pipeline.batch.size设置时，应考虑当接收事件总数过大时，保证管道需要足够的内存来处理这些尖峰。

２. 解决途径：  
　　延长管道接收事件等待事件，增大单个工作线程接收的批量处理的事件数，从而降低bulk-request的发送频率，防止网络io过载；  
　　同时在输出端使用flush\_size和idle\_flush\_time结合去控制批量写入es的数量和刷新频率；

３. 结果参数(参数配置需结合自身的生产环境，需自行去调优，这里仅供参考)：  
　　logstash.conf文件的output参数：  
　　　　flush\_size=>1000  
　　　　idle\_flush\_time=>15

logstash.yml文件的配置参数：  
　　　　pipeline.workers:10  
　　　　pipeline.output.workers:10  
　　　　pipeline.batch.size:3000  
　　　　pipeline.batch.delay:100