Having several instances of logstash, how to make lumberjacks reconnect? about logstash-forwarder HOT 10 CLOSED

Same issue here, connected to https://logstash.jira.com/browse/LOGSTASH-1253

from logstash-forwarder.

A random server is chosen every time a new connection is needed, and you can specify a list of addresses and/or use DNS to provide this 'list of servers'.

As far as I can tell, your request, "make lumberjack reconnect so that they are shipping to a randomly picked logstash" is already implemented and has been for some time.

from logstash-forwarder.

Seeing the same issue, lumberjacks are connected. We TERM logstash (target server). The lumberjacks detect that the connection is dead. When we restart logstash, they show re-connected (logstash pipeline is still not up yet), once it is up the lumberjacks still continually disconnect and reconnect. No events are sent.

I restart the agents, same thing

2013/11/21 15:20:08.851457 Read error looking for ack: read tcp 192.168.166.62:5043: i/o timeout
2013/11/21 15:20:08.851604 Loading client ssl certificate: ./lumberjack.crt and ./lumberjack.key
2013/11/21 15:20:09.151422 Setting trusted CA from file: ./lumberjack.crt
2013/11/21 15:20:09.151827 Connecting to 192.168.166.62:5043 (10.6.166.62)
2013/11/21 15:20:09.215137 Connected to 192.168.166.62

from logstash-forwarder.

The FIX:

If we create an iptables rule to block inbound 5043 (on logstash server), and let logstash fully boot up until the pipeline is logged as ready. When we then remove the iptables rule, then the agents correctly connect and send events….. It seems to me that logstash (lumberjack input) should NOT start listening on the declared port, until AFTER logstash is fully booted up and ready.

from logstash-forwarder.

The iptables workarround works (thx bitsofinfo), but this is kinda ugly.

This behaviour still exists in LS 1.4.0.

Any dev following this thread ?

from logstash-forwarder.

Hi,

Its a protocol issue. Because log stash pipeline not up, it fills immediately on first receive of events, then next receive it blocks waiting - thus eventually a timeout.

I fixed it in PR. It separates the connections from the pipeline, so the connections can do "keep-alives" while it waits for the pipeline to start moving again / initialise.
#180

My fork has it merged in and should work OK. It requires a change to the jls-lumberjack gem on the Logstash side though.

@alphazero-es is now working on the project here as we speak so maybe he'll get around to looking at protocol related issues like this soon :)

Jason

from logstash-forwarder.

Hi - I suppose it's worth adding that #180 might not completely fix it - sometimes I've seen with slow initialise it can still timeout.

It makes LogStash aim to respond within a maximum of 5 seconds. Logstash forwarder times out by default after 15 seconds.

So just increase the network timeout value in forwarder. You could probably even ignore my PR completely and just increase the network timeout. To be fair my PR was to solve slow or stalled pipeline, as opposed to starting up.

from logstash-forwarder.

When I tried to increase the timeout to 60s, it didn't solve the issue completly, and some LF could never connect to LS.

Thx for the tip though. :)

from logstash-forwarder.

Is this still an issue?

from logstash-forwarder.

Closing I'm not sure this is still a problem. Please open a new ticket if so.

from logstash-forwarder.