Logstash perdendo conexão para nós do Elasticsearch

Question

Estamos executando o Logstash em um servidor que está enviando logs para um cluster do Elasticsearch. Nos logs do Logstash, vemos a perda de conexão com os servidores do Elasticsearch com um erro de redefinição de conexão. Nós vemos isso entre todas as nossas instâncias de logstash e elasticsearch em todos os servidores. Neste exemplo, vemos logstash3 (192.168.1.133) perdendo conexão para 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 apenas permitindo portas específicas, mas abri-lo em 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 (~ 1 hora), mas, em seguida, começarão a ser recorrentes.

Porque nós vemos que isso começa a acontecer depois de um tempo eu estou inclinado a pensar que é uma fila enchendo-se em algum lugar. A conexão não pára, nós apenas começamos a perder o pacote ocasional. Eu pensei que isso pode estar relacionado ao rastreamento de conexão, mas não estamos vendo nenhum log desse efeito. Aumentamos conntrack_max anteriormente, já que vimos isso como um problema, mas não está ajudando nesse caso.

elasticsearch4:~$ cat /proc/sys/net/nf_conntrack_max
262144

Nenhuma evidência de qualquer pacote genérico cai:

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 do @Lenniey, tentei desabilitar o UFW e ver se ainda víamos os erros nos logs do logstash. Desativei o ufw em vários servidores e vi que ainda estávamos recebendo Connection reset messages nos logs para servidores com o ufw desativado, portanto, parece que as entradas do ufw no syslog podem ser um sintoma em vez de uma causa.

Eu produzi uma captura de pacote ( sudo tcpdump -i enp0s31f6 -s 65535 -w logstash.pcap 'port 9200' ) enquanto estávamos vendo 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: [ link Exceção] Conexão redefinida {: url = > link ,: error_message = > "Elasticsearch Inacessível: [http: // elasticsearch3: 9200 /] [Manticore :: SocketException] Redefinição da conexão ",: error_class = >" LogStash :: Outputs :: ElasticSe arch :: HttpClient :: Pool :: HostUnreachableError "}

Na captura de pacotes, vejo 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
}

Eu vejo então 5 pacotes TCP RST do elasticsearch para o logstash. O último pacote RST estava em 07:20:11.107663 , que corresponde ao tempo do erro do logstash, 07:20:11,108 .

Eu estou achando a captura de pacotes um pouco confusa. Filtramos a captura de pacotes para os IPs do servidor de logstash e ES em questão e para as portas nas quais vemos os 400 e os RSTs. No entanto, antes do 400, parece haver uma solicitação _bulk em andamento. uma resposta 414 durante a solicitação no meio da solicitação _bulk , então a solicitação _bulk continua e, em seguida, obtemos a 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 estar olhando?