Logstash Attempted tosend a bulk request to elasticsearch' but Elasticsearch appears to beunreachable or down! 故障修复

吐槽

先胡乱吐槽几句吧，好久没有更新博客了，原因很多。主要只自己工作越来越忙，偶尔深夜会思考，这么忙是为了什么？我的领导和我说“看看自己的银行卡余额”。现实却又是最真实的目标。

工作接手了一些之前不属于自己的工作，之前只能算是业余（虽然现在也是业余），但是得把这些事情做起来，所以得和自己的同事们处理好关系，而且和各个领导之前有了更多次，更频繁的交流，之前与领导的沟通是谨言慎行，自从看了《被拒绝的勇气》，发现没什么好谨言的，我们平等，只要我们内心对领导保持尊敬即可。可以服从，但是要保持自己的观点。

简介

一个生产项目，使用的是ELK+MQ的模式来实现日志存收集。

程序将日志推送到MQ中 Logstash消费MQ中的列队，将日志保存到 Elasticsearch中。

今天是通过Logstash报错日志看到 Attempted tosend a bulk request to elasticsearch’ but Elasticsearch appears to beunreachable or down! 报错信息。

其实ELK是很稳定的，而且在挂之前，kibana各种超时提示，有半个月，我们运维没有放到心上，所以导致了今天的ES宕机（清理了1年前的日志后很快就恢复了，^_^! 数据量太多导致ES太慢。），ES宕机到修复MQ消息队列积压了40W条队列。
报错内容：
Logstash报错信息

问题说明

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

解决方法

logstash.yml文件的配置参数：

# pipeline管道线程数，官方建议是等于CPU内核数；
pipeline.workers:10
# pipeline管道实际output时的线程数，一般小于或等于管道线程数，建议等于cpu内核数；
pipeline.output.workers:10
# 单个工作线程在尝试执行过滤器和输出之前收集的最大事件数，默认125；　 数值越大，处理则通常更高效，但增加了内存开销；　某些硬件配置要求通过设置LS_HEAP_SIZE变量来增加JVM堆大小，以避免使用此选项导致性能下降；　此参数的值超过最佳范围会导致由于频繁的垃圾回收或与内存不足异常相关的JVM崩溃而导致性能下降；　调整pipeline.batch.size设置大小可调整发送到Elasticsearch的批量请求的大小。
pipeline.batch.size:3000
# 此设置调整Logstash管道的延迟，默认5；　流水线批处理延迟是Logstash在当前管道工作线程中接收到事件后等待新消息的最大时间（毫秒）；　在此时间过后，Logstash开始执行过滤器和输出.Logstash在接收事件和在过滤器中处理该事件之间等待的最大时间是pipeline.batch.delay和pipeline.batch.size设置的乘积。
pipeline.batch.delay:100

jvm.options文件的配置参数：

1 2	-Xms16g -Xmx32g

conf配置文件参数修改

# 表示logstash的包数量达到20000个才批量提交到es.默认是500
flush_size => 20000
# 多长时间发送一次数据，flush_size和idle_flush_time以定时定量的方式发送，按照批次发送，可以减少logstash的网络IO请求
idle_flush_time => 10

Logstash.conf配置展示 ![Logstash.conf配置展示][2]

之后重启Logtash服务，不在报错。

备注：我的Logtash 为物理机器 48核心188G内存SSD硬盘。上面的配置参数只是我的配置，大家酌情修改。

ES清理索引，腾出空间

解决办法：

删除索引，清理空间，查看索引：curl http://10.10.0.38:9200/_cat/indices?v
删除旧索引：curl –connect-timeout 120 -XDELETE http://10.10.0.38:9200/*2019.10.1* 根据通配符自己删除

以上 End!