# Logstash output traffic significantly higher than input (minimal transformations) + TCP RST

**URL:** <https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868>\
**Category:** Logstash\
**Created:** [June 4, 2025, 1:26pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868 "2025-06-04T13:26:37Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 4, 2025, 1:26pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/1 "2025-06-04T13:26:37Z")

</div>

Hi,

I'm investigating a situation where **Logstash receives a certain amount of data** , but the **traffic sent from Logstash to Elasticsearch is significantly larger** , even though I perform **minimal transformations**.

## Setup

- Inputs from multiple Winlogbeat agents
- Output to Elasticsearch.
- Pipeline does basic operations
- Compression is **enabled** for the Elasticsearch output.

Logstash pipeline:

```ruby

input {
  beats {
    port => 15044
    ssl_enabled => true
    ssl_client_authentication => "optional"
    ssl_certificate_authorities => "/appl/logstashdata/certs/http_ca.crt"
    ssl_certificate => "/appl/logstashdata/certs/testlogstash1/testlogstash1.crt"
    ssl_key => "/appl/logstashdata/certs/testlogstash1/testlogstash1.key"
  }
}

filter {
  if [agent][version] =~ /^8\./ {
    mutate {
      replace => {
        "[data_stream][type]" => "logs"
        "[data_stream][dataset]" => "winlogbeat_8"
        "[data_stream][namespace]" => "default"
      }
    }
  } else if [agent][version] =~ /^9\./ {
    mutate {
      replace => {
        "[data_stream][type]" => "logs"
        "[data_stream][dataset]" => "winlogbeat_9"
        "[data_stream][namespace]" => "default"
      }
    }
  } else if [agent][version] =~ /^10\./ {
    mutate {
      replace => {
        "[data_stream][type]" => "logs"
        "[data_stream][dataset]" => "winlogbeat_10"
        "[data_stream][namespace]" => "default"
      }
    }
  } else {
    mutate {
      replace => {
        "[data_stream][type]" => "logs"
        "[data_stream][dataset]" => "winlogbeat_fallback"
        "[data_stream][namespace]" => "default"
      }
    }
  }

  mutate {
    lowercase => [
      "[log][level]",
      "[agent][hostname]",
      "[host][name]",
      "[winlog][computer_name]",
      "[winlog][event_data][SubjectDomainName]"
    ]
  }

  mutate {
    remove_field => [
      "[@version]",
      "[agent][id]",
      "[agent][name]",
      "[agent][type]",
      "[ecs][version]",
      "[winlog][event_data][Binary]",
      "[event][original]"
    ]
  }

}

output {
  elasticsearch {
    hosts => [
      "https://testelastic1:9200",
      "https://testelastic2:9200",
      "https://testelastic3:9200"
    ]

    api_key => "${ES_LOGSTASH_API_KEY}"

    ssl_enabled => true
    ssl_certificate_authorities => "/appl/logstashdata/certs/http_ca.crt"
    ssl_verification_mode => "full"

    data_stream => "true"

    compression_level => 7
  }
}

```

There is winlogbeat.yml configuration

```auto
winlogbeat.event_logs: 
  - name: Application 
    ignore_older: 24h 
  - name: System 
    ignore_older: 24h 
  - name: Security 
    ignore_older: 24h 
  - name: Windows PowerShell 
    ignore_older: 24h 
  - name: Microsoft-Windows-PowerShell/Operational 
    ignore_older: 24h 
  - name: Microsoft-Windows-Windows Defender/Operational 
    ignore_older: 24h
 
fields:
  project:
    name: "codera"
  env: "test"
fields_under_root: true

output.logstash:
  compression_level: 7
  bulk_max_size: 32
  loadbalance: true
  hosts:
    - "testlogstash1:15044"
    - "testlogstash2:15044"
  ssl:
    enabled: true
    ...
 
logging.level: warning
logging.to_eventlog: true
monitoring.enabled: false

```

## Observation

- Verified via `vnstat` and Packetbeat on the Logstash servers.

Screen from testlogstash1

 ![CleanShot 2025-06-04 at 15.19.41](https://us1.discourse-cdn.com/elastic/original/3X/3/6/36a75705faca23213633a8fb8d17106c9fa87c91.png)

- Input traffic (from Beats to Logstash) is noticeably smaller than output traffic (from Logstash to Elasticsearch), even with compression enabled.

- The difference is surprisingly large.

## Question

Why does Logstash generate so much more outbound traffic than it receives?

Could this be caused by:

- Metadata or structure overhead in the bulk API?

- Something else in how Logstash handles events?

---

<div class="post-metadata">

**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:** [June 4, 2025, 1:39pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/2 "2025-06-04T13:39:33Z")

</div>

Can you share both `logstash.yml` and `pipelines.yml` ? This is your only pipeline right?

What do you have in Logstash logs? Any error regarding retries?

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 7:34am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/3 "2025-06-05T07:34:13Z")

</div>

Hello @leandrojmp,

# Logstash Configuration & OS

## pipelines.yml

```auto
- pipeline.id: winlogbeat
  path.config: "/etc/logstash/pipelines/winlogbeat.conf"

```

## logstash.yml

```auto
path.data: /appl/logstashdata
path.logs: /appl/logstashlog
pipeline.workers: 2
queue.type: persisted
queue.max_bytes: 4096mb

```

## Logstash JVM bootstrap flags:

```auto
JVM bootstrap flags: [-Xms6g, -Xmx6g, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djruby.compile.invokedynamic=true, -XX:+HeapDumpOnOutOfMemoryError, -Djava.security.egd=file:/dev/urandom, -Dlog4j2.isThreadContextMapInheritable=true, -Dlogstash.jackson.stream-read-constraints.max-string-length=200000000, -Dlogstash.jackson.stream-read-constraints.max-number-length=10000, -Djruby.regexp.interruptible=true, -Djdk.io.File.enableADS=true, --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED, --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED, --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED, --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED, --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED, --add-opens=java.base/java.security=ALL-UNNAMED, --add-opens=java.base/java.io=ALL-UNNAMED, --add-opens=java.base/java.nio.channels=ALL-UNNAMED, --add-opens=java.base/sun.nio.ch=ALL-UNNAMED, --add-opens=java.management/sun.management=ALL-UNNAMED, -Dio.netty.allocator.maxOrder=11]

```

## OS

```auto
free -mh
               total used free shared buff/cache available
Mem: 15Gi 3.7Gi 6.1Gi 293Mi 6.3Gi 11Gi
Swap: 0B 0B 0B

```

```auto
nproc
2

```

`CPU is 97 % idle.`

# Log Inspecition

From the Winlogbeat agent logs, it appears that Logstash is unexpectedly closing the connection. Logs are being sent from around 35 Windows servers to two identical Logstash instances.

These two messages occur very frequently:

> Failed to publish events caused by: EOF

> failed to publish events: write tcp WINLOGBEAT\_IP:PORT-\>LOGSTASH\_IP:15044: wsasend: An existing connection was forcibly closed by the remote host

 ![CleanShot 2025-06-05 at 08.38.03](https://us1.discourse-cdn.com/elastic/original/3X/e/1/e19d53283bb757d7eed3d8ec4ab8620b3d400e4c.png)

I don’t see any information in the Logstash logs indicating that it’s closing the connection — no errors or warnings either.

## Running Logstash With Log Debug

So I ran Logstash with **log.level: debug**.

Out of thousands of events, I **selected two cases** where Winlogbeat (WINLOGBEAT\_IP:PORT) failed to send data to **Logstash (port 15044)** with the error:

> An existing connection was forcibly closed by the remote host

Logstash DEBUG logs show **no sign of closing the connection** — the last entries at **09:01:15** indicate normal communication.

### **Winlogbeat Logs – Connection Error**

 ![CleanShot 2025-06-05 at 09.08.26](https://us1.discourse-cdn.com/elastic/original/3X/d/4/d48748a4cf8ba34574b5dd120ff7785ed83c26a5.png)

### **Selected Logstash Logs – No Disconnect Logged**

 ![CleanShot 2025-06-05 at 09.24.28](https://us1.discourse-cdn.com/elastic/original/3X/0/4/0450a6e223458ae99152892cfed2a64784b1c979.jpeg)

But I don’t see any signs of retransmission in logs.  
I’ll take a look using **tcpdump** as well.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 8:12am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/4 "2025-06-05T08:12:11Z")

</div>

I’ve identified that **TCP retransmissions and duplicate ACKs are occurring on both sides** — between **Winlogbeat agents and Logstash** , as well as between **Logstash and Elasticsearch**.

However, based on system metrics and mtr results, the **network between Logstash and Elasticsearch shows 0% packet loss, minimal latency (~0.2 ms), and no jitter**. Both Logstash and Elasticsearch are reporting low CPU and memory usage.

Despite this, retransmissions are still observed in the packet captures on both segments of the pipeline.

> **Current Linux kernel TCP buffer settings on both the Logstash host and the Elasticsearch nodes:**  
> net.ipv4.tcp\_rmem = 4096 131072 6291456  
> net.ipv4.tcp\_wmem = 4096 16384 4194304  
> net.core.rmem\_max = 212992 # ≈208 kB hard ceiling  
> net.core.wmem\_max = 212992 # ≈208 kB hard ceiling

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 8:26am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/5 "2025-06-05T08:26:48Z")

</div>

Based on the screenshots, the Elasticsearch cluster appears to be healthy and performing well. CPU usage, JVM heap, indexing/search rates, and latencies are all within normal ranges. There are no alerts, and the cluster status is green, indicating no issues with performance or resource utilization.

 ![CleanShot 2025-06-05 at 10.25.33](https://us1.discourse-cdn.com/elastic/original/3X/9/4/947c8c805ca267213ae611b7c187fbebac0eeba5.png)  
 ![CleanShot 2025-06-05 at 10.26.04](https://us1.discourse-cdn.com/elastic/original/3X/9/c/9c6e8321800d99688870ad114a40d34cc822306c.jpeg)

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [June 5, 2025, 12:59pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/6 "2025-06-05T12:59:54Z")

</div>

> [@vasek](#):
>
> However, based on system metrics and mtr results, the **network between Logstash and Elasticsearch shows 0% packet loss, minimal latency (~0.2 ms), and no jitter**. [...]
> 
> Despite this, retransmissions are still observed in the packet captures on both segments of the pipeline.

You don't need packet loss to have retransmissions. If something is flipping the order of packets then the congestion window may be closed and that will severely restrict throughput, whilst also increasing retransmissions.

---

<div class="post-metadata">

**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:** [June 5, 2025, 1:04pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/7 "2025-06-05T13:04:41Z")

</div>

Do you normally collect anything from the Logstash machine or just configured an agent for this troubleshoot?

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 1:31pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/8 "2025-06-05T13:31:28Z")

</div>

From what I’ve seen, this doesn’t look like a packet reordering issue — no out\_of\_order packets show up in the captures ( _tcp.analysis.out\_of\_order in Wireshark_ ).

But the connection between Winlogbeat agents and Logstash is clearly unstable, probably due to delays or congestion. Here’s what’s actually happening:

- **Logstash sends TCP RST packets** , which means it’s force-closing connections instead of doing a proper TCP FIN handshake.
- **Winlogbeat agents send TCP retransmissions and spurious retransmissions** , suggesting they’re not getting ACKs in time and assume the packets were lost.
- **Logstash replies with TCP Duplicate ACKs** , basically saying “I’m still waiting for the same segment.”

To help with possible congestion, I bumped the TCP buffers and changed the congestion control algorithm:

```auto
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 262144 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 262144 16777216"
sysctl -w net.ipv4.tcp_congestion_control=bbr

```

I also considered the possibility that some intermediate network device might be terminating the connections between Winlogbeat agents and Logstash. To test this, I temporarily adjusted the TCP keepalive settings:

```auto
sysctl -w net.ipv4.tcp_keepalive_time=30
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=5

```

However, this didn’t resolve the issue either

Moreover based on the packet captures, it’s clear that **Logstash is reducing the TCP receive window size**.

Logstash still sends TCP RST packets.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 1:33pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/9 "2025-06-05T13:33:12Z")

</div>

No, I’m not collecting any additional logs from Logstash. Logstash is only receiving Windows logs from remote Winlogbeat agents.

---

<div class="post-metadata">

**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:** [June 5, 2025, 1:34pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/10 "2025-06-05T13:34:42Z")

</div>

> [@vasek](#):
>
> No, I’m not collecting any additional logs from Logstash. Logstash is only receiving Windows logs from remote Winlogbeat agents.

You shared a screenshot with Logstash logs on Elasticsearch, so how those logs are arriving there?

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 1:38pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/11 "2025-06-05T13:38:01Z")

</div>

Using **tcpdump** , I monitored traffic on Logstash on port 9200 too, and I observed **TCP RST packets being sent both from Logstash to Elasticsearch and from Elasticsearch back to Logstash**.

The **TCP window size** during these events was **63 or 128 bytes**.

The same applies to _tcp.analysis.duplicate\_ack_ (in Wireshark) — I’m seeing duplicate ACKs in both directions on that connection as well.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 1:42pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/12 "2025-06-05T13:42:46Z")

</div>

Ah, you’re right — I didn’t realize that. These logs are being sent **directly from Filebeat to the Elasticsearch cluster** , not through Logstash.

There is configuration filebeat.yml

```auto
filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false

setup.template.settings:
  index.number_of_shards: 1

setup.kibana:
  host: "https://<logstash-host>:5601"
  ssl.certificate_authorities: "/etc/filebeat/certs/<ca-cert>.crt"

output.elasticsearch:
  hosts: ['https://<es-node1>:9200', 'https://<es-node2>:9200', 'https://<es-node3>:9200']
  preset: balanced
  protocol: "https"
  api_key: "${ES_API_KEY}"
  ssl:
    enabled: true
    ca_trusted_fingerprint: "<fingerprint>"
  compression_level: 7

logging.level: warning

```

with logstash module **/etc/filebeat/modules.d/logstash.yml**

```auto
- module: logstash
  log:
    enabled: true
    var.paths:
      - /appl/logstashlog/logstash-plain.log

  slowlog:
    enabled: true
    var.paths:
      - /appl/logstashlog/logstash-slowlog-plain.log

```

So Filebeat is also collecting Logstash logs and sending them directly to Elasticsearch.  
There are no errors reported in the Filebeat logs.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 1:48pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/13 "2025-06-05T13:48:54Z")

</div>

Since I increased the timeout values in the Logstash configuration:

In the input section for Beats:

```auto
input {
  beats {
    port => 15044
    client_inactivity_timeout => 300
  }
}

```

And in the output section for Elasticsearch:

```auto
output {
  elasticsearch {
    timeout => 120
  }
}

```

the number of

> “wsasend: An existing connection was forcibly closed by the remote host”

messages from Winlogbeat agents has significantly decreased — see the attached screenshot.

 ![CleanShot 2025-06-05 at 15.46.38](https://us1.discourse-cdn.com/elastic/original/3X/8/f/8f84657d979cbd52813cc3544fd95f63190d67cd.png)

The current timeout values feel excessively high to me.  
**The link has a capacity of only 4 MB, but it’s not even utilized halfway.**

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 5, 2025, 2:00pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/14 "2025-06-05T14:00:59Z")

</div>

I’ve performed further analysis using TCPDUMP and Wireshark. The number of TCP Duplicate ACKs and retransmissions between Winlogbeats and Logstash is now minimal.

However, the situation between Logstash and the Elasticsearch cluster remains the same — there are still many TCP Duplicate ACKs and also RST packets being sent from Logstash to the Elasticsearch nodes.

---

<div class="post-metadata">

**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:** [June 5, 2025, 2:26pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/15 "2025-06-05T14:26:56Z")

</div>

> [@vasek](#):
>
> So Filebeat is also collecting Logstash logs and sending them directly to Elasticsearch.  
> There are no errors reported in the Filebeat logs.

So, if you have other things running on the same machine sending data to Elasticsearch as well, the amount of data sent will always be higher than the amount of data received.

For example, if you have logstash logs on DEBUG mode per default, this will send a lot of data as debug logs are noisy.

Same thing if you are collecting metrics with metricbeat or packetbeat, both generate a lot of data.

What exactly do you have running on this VM sending data to Elasticsearch?

---

<div class="post-metadata">

**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:** [June 5, 2025, 2:38pm UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/16 "2025-06-05T14:38:05Z")

</div>

> [@vasek](#):
>
> **Logstash sends TCP RST packets** , which means it’s force-closing connections instead of doing a proper TCP FIN handshake.

There was another thread about the RSTs recently. I posted some tcpdump analysis. It was related to channels which have no data (idle) for a given period. In that case it was filebeat \<—\> logstash. One side seemed to use a keepalive counter, the other (logstash) didn’t.

That other case, like this one, wasn’t impacting me, I was just curious. And there was a workaround.

But if you’d consider the RSTs from logstash rather than proper FINs a bug, either practically troublesome or just poor networking etiquette, you might wish to open a bug 🐛

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 9, 2025, 7:33am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/17 "2025-06-09T07:33:34Z")

</div>

This seems to be expected behavior from Logstash — it closes idle connections with a **TCP RST** when client\_inactivity\_timeout is reached. Technically it’s valid, but not very “clean” compared to a graceful **FIN/ACK close**.

In an ideal setup, Beats agents would send **TCP keepalives** during idle periods to keep the connection open. Since they don’t, **Logstash interprets the silence as inactivity and forcefully closes the connection**.

Not a critical issue, but it can cause confusion during traffic analysis or connection troubleshooting. Increasing the timeout helped in my case.

---

<div class="post-metadata">

**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:** [June 9, 2025, 10:24am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/18 "2025-06-09T10:24:04Z")

</div>

> [@vasek](#):
>
> In an ideal setup, Beats agents would send **TCP keepalives** during idle periods to keep the connection open. Since they don’t ….

IIRC filebeat _did_ send KeepAlives, every 15 seconds, and logstash ACKed them. But it kept no keepalive timer (can see with netstat) so effectively ignored them, then sent the RST.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [June 9, 2025, 11:31am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/19 "2025-06-09T11:31:20Z")

</div>

You’re right @RainTown — I checked it in Wireshark and confirmed that Winlogbeat sends a TCP Keep-Alive approximately every 15 seconds, and Logstash responds with a Keep-Alive ACK.

 ![CleanShot 2025-06-09 at 13.29.12](https://us1.discourse-cdn.com/elastic/original/3X/2/9/29080f35da286d3e42f7830297d0442ce9ba7a81.png)

**So it can be said that Logstash’s client\_inactivity\_timeout ignores TCP-level keep-alives and only considers application-level data as activity — meaning that even if the TCP connection is alive, Logstash may still close it if no logs are sent?**

---

<div class="post-metadata">

**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:** [June 9, 2025, 11:37am UTC](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868/20 "2025-06-09T11:37:19Z")

</div>

Yep, that was my conclusion too. so if you have a sometimes-quiet channel, you need set a large client\_inactivity\_timeout. Not ideal, but is that a bug given there _is_ a way to workaround it ? I know some network people dont really like long running TCP sessions if no real data is being exchanged. I don't really have a strong (informed) view.

[Next page](https://discuss.elastic.co/t/logstash-output-traffic-significantly-higher-than-input-minimal-transformations-tcp-rst/378868.md?page=2)