具体问题如下图所示：
将 INFO 信息打印大致如下所示：
[2018-03-05T16:26:08,711][INFO ][logstash.setting.writabledirectory] Creating directory {:setting=>"path.queue", :path=>"/usr/share/logstash/data/queue"}
[2018-03-05T16:26:08,727][INFO ][logstash.agent ] No persistent UUID file found. Generating new UUID {:uuid=>"f4d5f9a9-42ca-4765-b3fb-0f4566f440df", :path=>"/usr/share/logstash/data/uuid"}
[2018-03-05T16:26:09,175][INFO ][logstash.outputs.elasticsearch] Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s]}}
[2018-03-05T16:26:09,176][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working {:healthcheck_url=>http://logstash_system:xxxxxx@localhost:9200/, :path=>"/"}
[2018-03-05T16:26:09,262][WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. {:url=>#<URI::HTTP:0x59e42e4f URL:http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s>, :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [http://logstash_system:xxxxxx@localhost:9200/][Manticore::SocketException] Connection refused (Connection refused)"}
首先，从日志上看到发现可能是 es 被写死了，即无法再写入更多的数据，既然这样，那么很自然的就会想到限流 logstash 数据的写入，配置logstash-5.4.1/config/logstash.yml修改：
降低 pipeline 中的 workers 的量，由原来的 32 -> 16， batch size 修改 1000 -> 500， delay 修改 200 -> 1000， output.workers: 16 -> 8
修改完毕之后重启 logstash 发现过一段时间还会有相应的日志出现，找了半天终于 google 中找到有一个老外说的可能是 xpack 做的 helth check 影响的，我一看日志果然有对应每隔 1s 会对 es 做一次 helth check，于是就在 logstash.yml 中增加一行：
xpack.monitoring.enabled: false
即去除 xpack 的监控，再重新启动 logstash 后观察了一段时间果然不会再有任何的 WARN 和 ERROR 日志，问题得以解决。
总结
我猜测，这确实是 xpack 的问题，因为它每1s 去 ping es 状态，当集群繁忙时很容易导致 time out，此时 logstash 认为 es 不可达，就会一直轮询等待。去除掉 xpack 的helth check 等监控，由 logstash 自己写入时判断即可。
【2018-03-06 18:08:56 记录】
昨天修改完，今天查看发现仍然有上面提到的异常日志，于是继续查看。对应的logstash 以及 ElasticSearch 服务器对应的负载、cpu 都不是太高，初步怀疑可能是 io 的问题，即很频繁的进行 io 交互。
通过查看日志发现在很多的时间内，反复提示 ‘send a bulk request to elasticsearch’ 的错误，代表logstash在不断的，快速的给ES发送 bulk reuqest。我们查看logstash的配置发现，默认的配置是：
# How many events to retrieve from inputs
pipeline.batch.size: 125
# milliseconds
pipeline.batch.delay: 5
而我当前配置是：
pipeline:
workers: 32
batch:
size: 200
delay: 100
output:
workers: 8
unsafe_shutdown: false
queue:
type: persisted
page_capacity: 250mb
max_events: 10000
max_bytes: 1gb
checkpoint:
acks: 10000
writes: 10000
interval: 1000
这里的单位是milliseconds，即每个 logstash 的 instance，每 100 毫秒会发送 200 条 request 到ES集群，这个会导致ES集群的网络io过载。
那么，是不是说我们需要把每个 batch 之间的间隔增大，把每次batch的size调大？比如batch.size = 500, batch.delay = 500，就能防止出现以上的问题？
经过测试这样是可行的。
由于下面配置的 max_bytes 以及 max_events 的限制，修改后的配置如下（仅供参考）：
pipeline:
workers: 16
batch:
size: 500
delay: 200
output:
workers: 12
unsafe_shutdown: false
queue:
type: persisted
page_capacity: 250mb
max_events: 10000
max_bytes: 1gb
checkpoint:
acks: 10000
writes: 10000
interval: 1000
这样配置的目的有那么几个：
1. 尽量一次读出最大可能条数据，这样可以最大程度的降低与 ES 之间的 IO 交互。
2. 间隔时间不能太久，刚开始配置 1000，发现还是出现又降低到 500，错误变少了，分析发现应该是间隔时间长了，logstash 堵在队列中的数据就会增多，这样导致读取的频次永远不会降低，尤其是过了一段时间发现部分日质数量比较大的收集延迟变大。故综合考虑将延迟时间修改为 200。
3. 由于 CPU 核数比较高达到40多个，故将 output.workers 线程数增加，提升处理能力，减少数据拥堵，降低延迟度。
最后总结一句：以上报错信息其实并不影响整体日志收集，这个错误只是 logstash 自己认为可能不可达，是由于其中的组件导致的，查了下 github 上的说法，后续最新版本可能会解决这个误报问题，但是不是说我们就不管不顾了，而是要想办法将这个错误频次降低，尽最大可能使其运行良好。
【2018-05-06 10:18:56 记录】
在这期间将 ELK 收集日志丢失日志问题解决。最主要还是配置不合理导致的。问题原因是因为配置的 filebeat 中不可达等待最长时间为：3min，如果中途 logstash 拥堵比较严重，elasticsearch 负载又高，极大可能会造成 filebeat 休眠超过3min，看最新版本 filebeat 默认为 1天，其实配置是合理的，虽然有点大，但是总比丢数据要来的好。将其中的配置增大为 1h 后，再不会发生丢失日志的情况。
解决 ELK 收集日志延迟比较高的问题，尝试了很多优化发现无法从根本上解决，于是将最耗资源的 nginx_log 和 push_log 单独迁移到各自小的集群上，剩下所有的其他日志仍然保留在现有集群上，从此以后各种问题得以解决。归结起来就是一句话：有多大能力就干多大的事，不要超过其最大承受能力。