# Partial line reading when restarting Filebeat

**URL:** <https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [April 3, 2017, 2:43pm UTC](https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016 "2017-04-03T14:43:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![eclionast](https://avatars.discourse-cdn.com/v4/letter/e/ecb155/32.png) [@eclionast](https://discuss.elastic.co/u/eclionast)\
**Post date:** [April 3, 2017, 2:43pm UTC](https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016/1 "2017-04-03T14:43:58Z")

</div>

Hello,

Currently we have the following setup:  
Filebeat reads log files and sends the content to Kafka. One log-line results in one Kafka event.  
At the other side a Logstash reads the events from Kafka, parses them and sends the resulting document to Elasticsearch.  
Filebeat runs inside a Docker container and reads the log files from a Docker data container.  
We are using Filebeat 5.1.2 with Docker 1.11.2 .

The problem we are encountering is as follows:  
Although the offset in the Filebeat registry is pointing to the start of a new log-line, upon restart Filebeat starts reading somewhere in the middle of the previous log-line, resulting in sending a partial log-line to Kafka and thus having parsing errors in Logstash.

According to the documentation on "[How does Filebeat ensure At-Least-Once delivery ?](https://www.elastic.co/guide/en/beats/filebeat/5.1/how-filebeat-works.html#at-least-once-delivery)" Filebeat should just start reading from the offset upon restart.  
What could cause the behavior we are experiencing ?

Thank you

---

<div class="post-metadata">

**Author:** ![ruflin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ruflin/32/3116_2.png) [@ruflin](https://discuss.elastic.co/u/ruflin)\
**Post date:** [April 4, 2017, 2:49pm UTC](https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016/2 "2017-04-04T14:49:24Z")

</div>

First thing that pops to my mind is that this could have to do with encoding or special chars. But at the same time offset is in bytes, so it should not matter.

Can you share an example of the log files and registry where this is happen? Can you share your config?

---

<div class="post-metadata">

**Author:** ![eclionast](https://avatars.discourse-cdn.com/v4/letter/e/ecb155/32.png) [@eclionast](https://discuss.elastic.co/u/eclionast)\
**Post date:** [April 4, 2017, 3:09pm UTC](https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016/3 "2017-04-04T15:09:19Z")

</div>

Hello Ruflin,

If it was an encoding problem, then we should have seen scrambled content in Kafka, I think. And as long as Filebeat was not stopped, the pipeline processed everything well.

Eventually we found a solution by using `close_eof:true`, which works for us as the log files don't roll. Each file is written once and not updated over time.  
With that option turned on, restarting the docker container of Filebeat does not result in sending partial log lines to Kafka any more.

Thank you very much for your reply.

---

<div class="post-metadata">

**Author:** ![ruflin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ruflin/32/3116_2.png) [@ruflin](https://discuss.elastic.co/u/ruflin)\
**Post date:** [April 5, 2017, 1:58pm UTC](https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016/4 "2017-04-05T13:58:57Z")

</div>

Interesting, not sure why this solves the issue TBH. In case you see it again, ping me.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 3, 2017, 1:59pm UTC](https://discuss.elastic.co/t/partial-line-reading-when-restarting-filebeat/81016/5 "2017-05-03T13:59:02Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
