# Filebeat clients unable to publish events to logstash **URL:** \ **Category:** Beats\ **Tags:** filebeat\ **Created:** [May 27, 2025, 1:44pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592 "2025-05-27T13:44:13Z")\ **Posts on this page:** 12\ **Page:** 2
**Author:** ![Rios](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rios/32/95745_2.png) [@Rios](https://discuss.elastic.co/u/Rios)\ **Post date:** [May 29, 2025, 3:06pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/21 "2025-05-29T15:06:23Z")
Hm.... the bundled version setup own user&group logstash and the service. AFAIK other then that, should be the same. Can you try to set client\_inactivity\_timeout? Check [this](https://discuss.elastic.co/t/solved-filebeat-logstash-connection-reset-by-peer/87012) topic. Edit: Just want to suggest, please increase and test. ---
**Author:** ![MajorNickle](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@MajorNickle](https://discuss.elastic.co/u/MajorNickle)\ **Post date:** [May 29, 2025, 3:11pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/22 "2025-05-29T15:11:01Z")
Will do .. tho I'm not sure what's the best value here. I think what tricked me here into not looking into the `client_inactivity_timeout` option before is that the `connection reset by peer` message only appears on a new message send and not right after the connection has been reset by logstash. I thought that filebeat would know about the connection reset before attempting another send to logstash but looks like I'm in the wrong here haha. My logs can sometimes populate new messages on a per second basis but also sometimes have no new messages for a few hours up to a few days at most. So I think as long as I'm receiving log messages I can ignore the reset by peer messages as it's an expected behaviour. ---
**Author:** ![MajorNickle](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@MajorNickle](https://discuss.elastic.co/u/MajorNickle)\ **Post date:** [May 29, 2025, 3:47pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/23 "2025-05-29T15:47:29Z")
@Rios@stephenb @RainTown you mentioned that the `ttl` on the filebeat logstash output is currently not supported when the `pipelining` option is used. How could I utilize the `ttl` option but at the same time ensure that messages are send in their correct order as they appear in the logs? I was hoping I could use `pipelining 1` to ensure there's only one batch of events send at once. Any suggestions? ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [May 29, 2025, 3:59pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/24 "2025-05-29T15:59:36Z")
You have just one Logstash instance right? In this case I don't think that setting `ttl` and `pipelining` will make any difference here. Those settings are most used when you have multiple logstash instances or a load balancer in front of your logstash. I believe that you should remove both from the configuration and use the defaults. ---
**Author:** ![MajorNickle](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@MajorNickle](https://discuss.elastic.co/u/MajorNickle)\ **Post date:** [May 29, 2025, 4:06pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/25 "2025-05-29T16:06:08Z")
Correct. At the moment I only have one logstash instance but I might end up adding 1 or 2 down the line if needed. ---
**Author:** ![Rios](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rios/32/95745_2.png) [@Rios](https://discuss.elastic.co/u/Rios)\ **Post date:** [May 29, 2025, 4:06pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/26 "2025-05-29T16:06:30Z")
> The "ttl" option is not yet supported on an async Logstash client (one with the "pipelining" option set). - from the [documentation](https://www.elastic.co/docs/reference/beats/filebeat/logstash-output) ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [May 30, 2025, 2:01am UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/27 "2025-05-30T02:01:31Z")
I was able to "reproduce" the `Connection reset` messages, but without it causing an issue. also used Rocky Linux 9.5. Firewall on/off did not _appear_ to make any difference. The slightly strange thing is the 2 sides disagree on keepalive timer status. I do see the TCP keepalive _packets_ (and ACKs) with tcodump on both hosts. But logstash end seems to ignore them. And sometime after 3x 15 second countdowns I see at filebeat end, it (logstash) sends a RSET The filebeat end shows this in netstat output: ```auto $ sudo netstat -no | fgrep EST | fgrep 5044 tcp 0 0 192.168.178.67:45842 192.168.178.66:5044 ESTABLISHED keepalive (0.73/0/0) ``` But logstash end show this: (note the "off") ```auto $ sudo netstat -no | fgrep EST | fgrep 5044 tcp6 0 0 192.168.178.66:5044 192.168.178.67:45842 ESTABLISHED off (0.00/0/0) ``` As long as the "pipe" is kept busy it's a non issue. I didn't see any lost logs, tested for just a little while of course. If it's not busy, sure the RSET happens, but a new TCP connection is setup when required. Below is the Wireshark view, the .66 is logstash and the .67 is filebeat (for the eagle eyed, my Wireshark source port / destination port columns are the wrong way round!) The packet with length 754 is the actual log being sent from filebeat to logstash, the only one in that time window. ![Screenshot 2025-05-30 at 03.54.08](https://us1.discourse-cdn.com/elastic/original/3X/4/2/42b9df9df9ae258d1bd88a8489ea4e089a2f86dc.jpeg) network experts might wish to weigh in. ---
**Author:** ![MajorNickle](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@MajorNickle](https://discuss.elastic.co/u/MajorNickle)\ **Post date:** [May 30, 2025, 8:31pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/28 "2025-05-30T20:31:23Z")
That's interesting and sort of confirms what I'm seeing too on not so busy logs where connections do reset. Thanks for taking the time to reproduce this on your end. I think I chased the wrong end at first cause I somehow was expecting the `connection reset` messages to be thrown when the connection is actually being reset by logstash and not on new message send attempts. Adjusting the output.logstash.timeout to a slightly higher value has fixed the `java.net.SocketException: Connection reset` I saw on my remote filebeat nodes and I have logstash now receiving events successfully. ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [May 30, 2025, 9:52pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/29 "2025-05-30T21:52:27Z")
> [@MajorNickle](#): > > I think I chased the wrong end at first cause I somehow was expecting the `connection reset` messages to be thrown when the connection is actually being reset by logstash and not on new message send attempts. I am glad you found a fix, but maybe _my_ wording was not clear (t was late!) so let me rephrase. What I found was that a TCP connection was setup, initiated by filebeat, some data transferred and ACKed, filebeat also sent a 6 bytes of "data" inside another TCP packet which always contained the same data - 32 41 00 00 00 01 (those are hex) - which was also ACKed by logstash. Then, assuming no more logs to send, filebeat sent 3 keepalives, around 15 seconds apart, which logstash ACK-ed but seemed to just ignore (no timer showing on the netstat output). And the TCP session was RST by logstash almost precisely 60 seconds after the last "real data" was exchanged. Note this 60 second had (in my tests) nothing to do with the `timeout: 60` setting under filebeat's output.logstash section, I changed to both less than AND more than 60 and it made no difference for me - RST still came 60s after last "real data" packet. As soon as new data was to be sent to logstash a new TCP session is established, using different TCP port at filebeat end and obviously 5044 at logstash end. ---
**Author:** ![MajorNickle](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@MajorNickle](https://discuss.elastic.co/u/MajorNickle)\ **Post date:** [June 3, 2025, 8:25pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/30 "2025-06-03T20:25:46Z")
Gotcha. Thanks for the more detailed explanation. I did do a tcpdump as well but am not that good with Wireshark and analyzing what's going on exactly so I appreciate your post! I'll try setting the `client_inactivity_timeout` value to something higher and lower then the default and see if that matches when the RST comes up. ---
**Author:** ![MajorNickle](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@MajorNickle](https://discuss.elastic.co/u/MajorNickle)\ **Post date:** [June 3, 2025, 8:34pm UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/31 "2025-06-03T20:34:34Z")
To anyone interested the below is my working config now. conf.d/to\_confluent.conf ```auto input { beats { port => 5044 client_inactivity_timeout => 300 } } ``` filebeat.yml ```auto filebeat.inputs: - type: filestream id: access-logs enabled: true paths: - /mnt/*/log/access.log prospector.scanner.fingerprint: enabled: true offset: 0 length: 64 file_identity.fingerprint: ~ clean_removed: false processors: - add_host_metadata: when.not.contains.tags: forwarded output.logstash: hosts: ["xxx.xxx.xxx.xxx:5044"] bulk_max_size: 1 timeout: 300 pipelining: 0 ``` ---
**Author:** ![itbill](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/itbill/32/146522_2.png) [@itbill](https://discuss.elastic.co/u/itbill)\ **Post date:** [December 31, 2025, 2:42am UTC](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592/32 "2025-12-31T02:42:21Z")
A bit of explanation here… In logstash, the default beats input has an idle timeout of 60s. If the beats source does not send any event to logstash, logstash will kill the connection. [https://www.elastic.co/docs/reference/logstash/plugins/plugins-inputs-beats#plugins-inputs-beats-client\_inactivity\_timeout](https://www.elastic.co/docs/reference/logstash/plugins/plugins-inputs-beats#plugins-inputs-beats-client_inactivity_timeout) However, in beats, the default logstash output will never terminate an established connection. [https://www.elastic.co/docs/reference/beats/filebeat/logstash-output#\_ttl](https://www.elastic.co/docs/reference/beats/filebeat/logstash-output#_ttl) When the connection is terminated by logstash, the error will be fired. This happens when the beats source does not send any event within the logstash’s idle timeout period. The solution suggests tuning the beats config, to force reconnecting every 300s itself proactively rather than waiting for the connection to be terminated by the logstash server. But this setting requires disabling the pipelining feature, so the “pipelining: 0” directive is also essential. To prevent logstash to terminate network connection prematurely, the setting in the logstash server side also needs to be set to longer than the ttl duration described above. [Previous page](https://discuss.elastic.co/t/filebeat-clients-unable-to-publish-events-to-logstash/378592.md?page=1)