etc在日志系統搭建起來后大半年一直沒有出現大的問題，在上個月的某段時間，我慢慢發現有這個問題的存在了，首先是自己遇到過，后面也有人反應這個問題。於是就開始對這個問題進行分析：
1.因為服務器是放在國外的（新加坡的），所以考慮到是不是網絡延時較大導致的，我通過新加坡的代理進行訪問還是會出現這個問題。我到新加坡代理的延遲不高，新加坡代理到ELK主機的延遲也不高。最后排除是網絡問題導致的，但是后期還是會對ELK主機在香港進行代理下，加快訪問速度。
2.考慮到是不是服務器進程較多，內存不足，IO讀寫阻塞。首先說下我們服務器的配置——4G運行內存，2CPU ，硬盤大小我不記得了（好像是100GB）。我們在這個主機上面搭建了
ELK的logstash +elasticsearch +kibana +nginx ，以及zabbix agent,file2ban等。我通過top查看CPU負載不高，很正常，IO也正常，但是我之前給elasticsearch 的JVM配置中只給了1G內存，因為我前期考慮到如果elasticsearch 中占有了太多內存，那么其他服務logstash或者是kibana容易由於內存不足進程被殺死。我覺得可能是這個問題導致的。elasticsearch 需要的內存不足。后面我將配置改為elasticsearch 的JVM配置為2G內存，發現這個問題消失了。
最后總結下：如果ELK出現這種問題的話我覺得有兩種解決方法：
1，如果機器的內存還是畢竟充足的話，那么就給elasticsearch多一點內存,配置文件/etc/elasticsearch/jvm.options
2,如果機器的內存不是那么的充足的話，我們可以改改后端彈性搜索的閾值。修改配置文件/etc/kibana/kibana.yml的第66行，將#去掉，然后將30000毫秒（也就是30s）
更改成40000(40秒)，這個根據實際情況進行修改。
以上就是關於這個問題的解決，在此記錄下，便於以后查詢。