我們在伺服器上運行 Logstash，該伺服器將日誌推送到 Elasticsearch 叢集中。在 Logstash 日誌中，我們看到它失去了與 Elasticsearch 伺服器的連接，並出現連接重置錯誤。我們在所有伺服器上的所有logstash 和elasticsearch 實例之間都看到了這一點。在這個例子中，我們看到logstash3 (192.168.1.133) 失去了與elasticsearch4 (192.168.1.88) 的連接
[2018-08-21T20:21:21,414][WARN ][logstash.outputs.elasticsearch] Marking url as dead. Last error: [LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError] Elasticsearch Unreachable: [http://elasticsearch4:9200/][Manticore::SocketException] Connection reset {:url=>http://elasticsearch4:9200/, :error_message=>"Elasticsearch Unreachable: [http://elasticsearch4:9200/][Manticore::SocketException] Connection reset", :error_class=>"LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError"}
查看系統日誌，我們可以看到 UFW 在幾秒鐘前阻塞了一個資料包：
Aug 21 20:21:03 logstash3 kernel: [1760565.386970] [UFW BLOCK] IN=enp0s31f6 OUT= MAC=90:1b:0e:cc:50:95:30:b6:4f:d8:05:51:08:00 SRC=192.168.1.88 DST=192.168.1.133 LEN=40 TOS=0x0 PREC=0x00 TTL=57 ID=442 DF PROTO=TCP SPT=9200 DPT=59338 WINDOW=0 RES=0x00 RST URGP=0
我們在 ufw 中製定了一條規則，允許這些伺服器之間的所有連線。最初我們只允許特定端口，但我將其開放給所有端口，以防出現問題。允許連線的規則是：
logstash3:~$ sudo ufw status | grep '\.88'
Anywhere ALLOW 192.168.1.88
如果我們重新啟動 Logstash，這些斷開的連線會消失一段時間（約 1 小時），但隨後會開始重複出現。
因為我們看到它在一段時間後開始發生，所以我傾向於認為這是一個隊列在某個地方填滿了。連接並沒有停止，我們只是開始偶爾丟失資料包。我認為這可能與連接追蹤有關，但我們沒有看到任何與此相關的日誌。我們conntrack_max之前已經增加了，因為我們認為這是一個問題，但在這種情況下它沒有幫助。
elasticsearch4:~$ cat /proc/sys/net/nf_conntrack_max
262144
沒有任何通用資料包遺失的證據：
logstash3:~$ ifconfig
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.133 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 2a01:4f8:121:53b7::2 prefixlen 64 scopeid 0x0<global>
inet6 fe80::921b:eff:fecc:5095 prefixlen 64 scopeid 0x20<link>
ether 90:1b:0e:cc:50:95 txqueuelen 1000 (Ethernet)
RX packets 7746452399 bytes 8566845158411 (8.5 TB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5792178105 bytes 5164493104253 (5.1 TB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xef000000-ef020000
根據 @Lenniey 的建議，我嘗試停用 UFW 並查看我們是否仍然在 Logstash 日誌中看到錯誤。我在許多伺服器上禁用了 ufw，發現我們仍然Connection reset在禁用 ufw 的伺服器之間的日誌中收到訊息，因此 syslog 中的 ufw 條目似乎可能是一種症狀，而不是原因。
sudo tcpdump -i enp0s31f6 -s 65535 -w logstash.pcap 'port 9200'當我們看到錯誤時，我產生了一個資料包擷取 ( )
[2018-08-23T07:20:11,108][WARN ][logstash.outputs.elasticsearch] Marking url as dead. Last error: [LogStash::Outputs::ElasticSearch::
HttpClient::Pool::HostUnreachableError] Elasticsearch 無法存取：[http://elasticsearch3:9200/][Manticore::Socket 異常] 連線重置 {:url=>http://elasticsearch3:9200/, :error_message=>"Elasticsearch 無法存取: [http://elasticsearch3:9200/][Manticore::SocketException] 連線重置", :error_class=>"LogStash::Outputs::ElasticSe arch::HttpClient::Pool ::主機無法存取錯誤”}
在資料包擷取中，我可以看到 elasticsearch 回應 400 錯誤：
HTTP/1.0 400 Bad Request
content-type: application/json; charset=UTF-8
content-length: 203
{
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "text is empty (possibly HTTP/0.9)"
}
],
"type": "illegal_argument_exception",
"reason": "text is empty (possibly HTTP/0.9)"
},
"status": 400
}
然後我看到 5 個從 Elasticsearch 到 Logstash 的 TCP RST 封包。最後一個 RST 封包位於07:20:11.107663，它與 Logstash 錯誤的時間 相符07:20:11,108。
我發現資料包捕獲有點令人困惑。我已將資料包捕獲過濾到有問題的 Logstash 和 ES 伺服器的 IP，以及我們看到 400 和 RST 的端口，但是在 400 之前似乎有一個_bulk正在進行的請求，然後是 414 響應在請求中間的請求期間_bulk，然後_bulk請求繼續，然後我們得到400：
Logstash -> ES
POST /_bulk HTTP/1.1
Connection: Keep-Alive
Content-Type: application/json
Content-Length: 167481062
Host: elasticsearch3.channelgrabber.com:9200
User-Agent: Manticore 0.6.1
Accept-Encoding: gzip,deflate
{ ... data ... }
ES -> Logstash
HTTP/1.1 413 Request Entity Too Large
content-length: 0
Logstash -> ES
{ ... data continues ... }
ES -> Logstash
HTTP/1.0 400 Bad Request
content-type: application/json; charset=UTF-8
content-length: 203
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"text is empty (possibly HTTP/0.9)"}],"type":"illegal_argument_exception","reason":"text is empty (possibly HTTP/0.9)"},"status":400}
有人對我還應該看什麼有什麼建議嗎？