# Filebeat send events to kafka repeatly **URL:** \ **Category:** Beats\ **Tags:** filebeat\ **Created:** [November 30, 2016, 1:07pm UTC](https://discuss.elastic.co/t/filebeat-send-events-to-kafka-repeatly/67615 "2016-11-30T13:07:13Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![vin](https://avatars.discourse-cdn.com/v4/letter/v/a87d85/32.png) [@vin](https://discuss.elastic.co/u/vin)\ **Post date:** [November 30, 2016, 1:07pm UTC](https://discuss.elastic.co/t/filebeat-send-events-to-kafka-repeatly/67615/1 "2016-11-30T13:07:13Z")
Filebeat version : 5.0.2 OS : CentOS7 Filebeat Config: > filebeat.prospectors: > > - input\_type: log > paths: > - /terminallogs/jhw/step/step.log\* > document\_type: 'jhw-terminal-steplog' > multiline.pattern: '^[' > multiline.negate: true > multiline.match: after > ignore\_older: 6h #must be greater than close\_inactive. > close\_inactive: 5m > clean\_inactive: 7h #must be greater than ignore\_older + scan\_frequenc > harvester\_limit: 30 #in combination with the close\_\* > > - input\_type: log > paths: > - /terminallogs/jhw/exception/exception.log\* > document\_type: 'jhw-terminal-exceptionlog' > multiline.pattern: '^[' > multiline.negate: true > multiline.match: after > ignore\_older: 6h #must be greater than close\_inactive. > close\_inactive: 5m > clean\_inactive: 7h #must be greater than ignore\_older + scan\_frequenc > harvester\_limit: 30 #in combination with the close\_\* > output.kafka: > hosts: ["10.18.207.121:9092","10.18.207.122:9092"] > topic: 'filebeat-%{[type]}' > version: 0.9.0.1 > #required\_acks: 1 > > # The number of concurrent load-balanced Kafka output workers. > > #worker: 3 > logging.level: debug Logs: /var/log/filebeat/filebeat > 2016-11-30T20:49:23+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 state change to [**retrying-17**] > 2016-11-30T20:49:23+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 abandoning broker 1 > 2016-11-30T20:49:23+08:00 WARN producer/broker/1 shut down > 2016-11-30T20:49:23+08:00 WARN client/metadata fetching metadata for [filebeat-jhw-terminal-exceptionlog] from broker 10.18.207.121:9092 > 2016-11-30T20:49:23+08:00 WARN producer/broker/1 starting up > 2016-11-30T20:49:23+08:00 WARN producer/broker/1 state change to [open] on filebeat-jhw-terminal-exceptionlog/0 > 2016-11-30T20:49:23+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 selected broker 1 > 2016-11-30T20:49:23+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 state change to [flushing-17] > 2016-11-30T20:49:23+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 state change to [normal] > 2016-11-30T20:49:23+08:00 WARN Connected to broker at 10.18.207.122:9092 (registered as #1) > 2016-11-30T20:49:24+08:00 WARN **producer/broker/1 state change to [closing] because read tcp 10.18.210.84:34445-\>10.18.207.122:9092: read: connection reset by peer** > 2016-11-30T20:49:24+08:00 WARN Closed connection to broker 10.18.207.122:9092 > 2016-11-30T20:49:24+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 state change to [**retrying-18**] > 2016-11-30T20:49:24+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 abandoning broker 1 > 2016-11-30T20:49:24+08:00 WARN producer/broker/1 shut down > 2016-11-30T20:49:24+08:00 WARN client/metadata fetching metadata for [filebeat-jhw-terminal-exceptionlog] from broker 10.18.207.121:9092 > 2016-11-30T20:49:24+08:00 WARN producer/broker/1 starting up > 2016-11-30T20:49:24+08:00 WARN producer/broker/1 state change to [open] on filebeat-jhw-terminal-exceptionlog/0 > 2016-11-30T20:49:24+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 selected broker 1 > 2016-11-30T20:49:24+08:00 WARN producer/leader/filebeat-jhw-terminal-exceptionlog/0 state change to [flushing-18] It seems like because of tcp connections to a kafka broker was reset by peer , filebeat keep retrying all the time , and indeed, kafka received lots repeatful events. ---
**Author:** ![vin](https://avatars.discourse-cdn.com/v4/letter/v/a87d85/32.png) [@vin](https://discuss.elastic.co/u/vin)\ **Post date:** [December 1, 2016, 2:08am UTC](https://discuss.elastic.co/t/filebeat-send-events-to-kafka-repeatly/67615/2 "2016-12-01T02:08:40Z")
It turns out that because required\_acks is default 1, which means wait for local commit, and in case that filebeat cannot get TCP ACK response, so filebeat keep retrying. Filebeat ignore the max\_retries setting and retry until all events are published. ---
**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\ **Post date:** [December 5, 2016, 3:18pm UTC](https://discuss.elastic.co/t/filebeat-send-events-to-kafka-repeatly/67615/3 "2016-12-05T15:18:05Z")
Well, the connection has been reset by peer. That is, being closed by kafka or on behalf of kafka (e.g. firewall). Filebeat uses send-at-least-once semantics and therefore has to retry. Anything in kafka logs? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [January 2, 2017, 3:18pm UTC](https://discuss.elastic.co/t/filebeat-send-events-to-kafka-repeatly/67615/4 "2017-01-02T15:18:12Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.