Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally terminate connections after an idle period #505

Open
jsvd opened this issue Nov 7, 2024 · 1 comment
Open

Optionally terminate connections after an idle period #505

jsvd opened this issue Nov 7, 2024 · 1 comment

Comments

@jsvd
Copy link
Member

jsvd commented Nov 7, 2024

The beats input will send an Ack(0) whenever the writer is idle, which is handled by the IdleStateHandler.
This happens when Logstash can't send data downstream, and the Ack(0) is sent to keep the connection alive.

However when beats are sending data to multiple Logstashes it'd be best if beats were able to give up on writing a batch to a blocked Logstash and to try a different one. For this the connection must be terminated by either Logstash or Beats.

On the beats side elastic/beats#41534 (comment) was created to explore the termination of connections after a period of idleness.

This issue is to evaluate if the beats input should also have a setting to terminate the connection after an idle period.

Overall this responsibility should fall on the client as the server will provide the necessary information - Ack(0) - to the client, for it to make a decision to wether keep waiting or to give up and try again.
A couple of arguments to also implement it on the Logstash side are a) to have this feature on Logstash lumberjack to Logstash beats and b) to reduce the effort of a user to benefit from this reconnection, upgrading only a few Logstash instances and not having to upgrade a fleet of beats.
Neither of these is a very strong argument since Logstash to Logstash is moving to HTTP, and the effort argument is mostly a tactical solution and not a solid architectural solution.

That said, we can still implement this here as it would be low effort, so I'm looking for more arguments or opinions if anyone has them :)

@VihasMakwana
Copy link

I think we are going to implement this from the client side based on Craig's comment.

From the server side, it also makes sense for Logstash to close the connection after a period of inactivity. Fundamentally, neither side (client or server) should make assumptions and should simply do their best.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants