Estamos executando o Logstash em um servidor que envia logs para um cluster Elasticsearch. Nos logs do Logstash, vemos a perda de conexão com os servidores Elasticsearch com um erro de redefinição de conexão. Vemos isso entre todas as nossas instâncias logstash e elasticsearch em todos os servidores. Neste exemplo, vemos logstash3 (192.168.1.133) perdendo conexão com 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"}
Olhando no syslog podemos ver que o UFW está bloqueando um pacote alguns segundos antes:
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
Temos uma regra em vigor no ufw para permitir todas as conexões entre esses servidores. Inicialmente estávamos permitindo apenas portas específicas, mas abri para todas as portas caso esse fosse o problema. A regra que permite conexões é:
logstash3:~$ sudo ufw status | grep '\.88'
Anywhere ALLOW 192.168.1.88
Se reiniciarmos o logstash, essas conexões perdidas desaparecerão por um tempo (cerca de 1 hora), mas depois começarão a ser recorrentes.
Como vemos que isso começa a acontecer depois de um tempo, estou inclinado a pensar que é uma fila se enchendo em algum lugar. A conexão não para, apenas começamos a perder pacotes ocasionais. Achei que poderia estar relacionado ao rastreamento de conexão, mas não estamos vendo nenhum registro nesse sentido. Aumentamos conntrack_maxanteriormente porque vimos isso como um problema, mas não está ajudando neste caso.
elasticsearch4:~$ cat /proc/sys/net/nf_conntrack_max
262144
Nenhuma evidência de queda de pacote genérico:
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
Seguindo o conselho de @Lenniey, tentei desabilitar o UFW e ver se ainda víamos erros nos logs do logstash. Desativei o ufw em vários servidores e vi que ainda recebíamos Connection resetmensagens nos logs entre servidores com o ufw desativado, então parece que as entradas do ufw no syslog podem ser um sintoma e não uma causa.
Produzi uma captura de pacote ( sudo tcpdump -i enp0s31f6 -s 65535 -w logstash.pcap 'port 9200') enquanto víamos o erro
[2018-08-23T07:20:11,108][WARN ][logstash.outputs.elasticsearch] Marking url as dead. Last error: [LogStash::Outputs::ElasticSearch::
HttpClient::Pool::HostUnreachableError] Elasticsearch inacessível: [http://elasticsearch3:9200/][Manticore::Socket Exceção] Redefinição de conexão {:url=>http://elasticsearch3:9200/, :error_message=>"Elasticsearch inacessível: [http: //elasticsearch3:9200/][Manticore::SocketException] Redefinição de conexão", :error_class=>"LogStash::Outputs::ElasticSe arch::HttpClient::Pool:: HostUnreachableError"}
Na captura de pacotes posso ver o elasticsearch responder com um erro 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
}
Vejo então 5 pacotes TCP RST do elasticsearch para o logstash. O último pacote RST foi às 07:20:11.107663, que corresponde à hora do erro do logstash, 07:20:11,108.
Estou achando a captura de pacotes um pouco confusa. Filtramos a captura de pacotes para os IPs do logstash e do servidor ES em questão, e para as portas onde vemos os 400 e os RSTs, no entanto, antes do 400, parece haver uma _bulksolicitação em andamento e, em seguida, uma resposta 414 durante a requisição no meio da _bulkrequisição, então a _bulkrequisição continua, então obtemos o 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}
Alguém tem alguma sugestão sobre o que mais eu deveria olhar?