具體問題如下圖所示：
將 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 單獨遷移到各自小的集群上，剩下所有的其他日志仍然保留在現有集群上，從此以后各種問題得以解決。歸結起來就是一句話：有多大能力就干多大的事，不要超過其最大承受能力。