# Filebeat skipping log lines in windows

**URL:** <https://discuss.elastic.co/t/filebeat-skipping-log-lines-in-windows/195783>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [August 19, 2019, 4:57pm UTC](https://discuss.elastic.co/t/filebeat-skipping-log-lines-in-windows/195783 "2019-08-19T16:57:03Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Skyy](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@Skyy](https://discuss.elastic.co/u/Skyy)\
**Post date:** [August 19, 2019, 4:57pm UTC](https://discuss.elastic.co/t/filebeat-skipping-log-lines-in-windows/195783/1 "2019-08-19T16:57:03Z")

</div>

> [@Single Event Not Parsed Correctly](https://discuss.elastic.co/t/single-event-not-parsed-correctly/117505/8):
>
> I just checked the inode, and it seems to be changing with each pull (tested manually), with the exception of a couple recent pulls, where it appears to keep going back and forth between two different inodes (2895/3098) However, even if I explicitly delete the file, then run the script to replace the file, I still get the same old inode of 2895. I'm wondering if clean\_inactive could help here. Thanks, Cappy

So i have a similar issue outlined here and im pretty sure the problem is the same:  
Our log writing process is custom and replaces the old log file entirely on update. The issue is when filebeat reads logs realtime and this occurs it is messing with the offset and clipping one or two lines. Im curious to know what filebeat uses on windows to identify files, is it also the inode?  
I know its a problem that only occurs when reading realtime as it works flawlessly when ingesting older files.

Before I go through updating filebeat (and subsequent apps to keep them all playing nice), I have tried setting scan frequency to 5m. This works but not really... if the scan kicks off _right_ as a new log file comes in i have the same issue. Is there a way to tell filebeat to ignore a file newer than 5 min (similar to ignore\_older). That would fix my problem entirely.

---

<div class="post-metadata">

**Author:** ![faec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/faec/32/46988_2.png) [@faec](https://discuss.elastic.co/u/faec)\
**Post date:** [August 20, 2019, 8:29pm UTC](https://discuss.elastic.co/t/filebeat-skipping-log-lines-in-windows/195783/2 "2019-08-20T20:29:37Z")

</div>

This is a tricky case, especially on windows... when your log file swap happens, does it replace the log file with entirely new data, or is the beginning of the file unchanged? In the former case you'd want to re-ingest the whole file, in the latter it would be ok if it kept the previous offset. I'm not clear on what sequence is happening here that loses only one or two lines (if it's trying to resume in a totally different file then i'd expect it to lose more than that).

A setting you might find helpful is `close_inactive`, see the [docs here](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html#filebeat-input-log-close-inactive). If your log files are updated atomically at known intervals then that should let you make sure filebeat isn't reading from them when the swap happens.

---

<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:** [September 17, 2019, 10:29pm UTC](https://discuss.elastic.co/t/filebeat-skipping-log-lines-in-windows/195783/3 "2019-09-17T22:29:40Z")

</div>

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