# FileBeat Elasticsearch module not closing files after rollover

**URL:** <https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [February 27, 2019, 4:32am UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097 "2019-02-27T04:32:39Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![NerdSec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nerdsec/32/22056_2.png) [@NerdSec](https://discuss.elastic.co/u/NerdSec)\
**Post date:** [February 27, 2019, 4:32am UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097/1 "2019-02-27T04:32:39Z")

</div>

Hi,

I just had a strange issue, I had enabled the Elasticsearch module in FileBeat. Today, during a healthcheck, I saw that my coordinating node had over 90% disk utilization.

On logging on and validating with `du -sh` I could not add up the disk usage. I ran `lsof +L1` and found out that a lot of files were kept open by FileBeat even after they were rolled over by Elasticsearch.

I have now added the following lines to my `modules.d/elasticsearch.yml`:

```auto
- module: elasticsearch
  
  server:
    # Added now to remove old files #
    input:
        close_renamed: true
        close_timeout: 5m
    enabled: true
    #################################

    # Server log
    var.paths:
      - /var/log/elasticsearch/irmelk.log

```

Now I see that filebeat clears the file when its done with it and does not keep the context open. Is this the correct approach to solve the issue?

---

<div class="post-metadata">

**Author:** ![kvch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kvch/32/72058_2.png) [@kvch](https://discuss.elastic.co/u/kvch)\
**Post date:** [February 27, 2019, 8:36am UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097/2 "2019-02-27T08:36:13Z")

</div>

Yes, it is. 🙂

---

<div class="post-metadata">

**Author:** ![NerdSec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nerdsec/32/22056_2.png) [@NerdSec](https://discuss.elastic.co/u/NerdSec)\
**Post date:** [February 27, 2019, 10:49am UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097/3 "2019-02-27T10:49:06Z")

</div>

Thanks. Why can't this be the default config shipped?

Makes it a more plug and play kind of a solution, considering it is an in-house component I believe.

---

<div class="post-metadata">

**Author:** ![kvch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kvch/32/72058_2.png) [@kvch](https://discuss.elastic.co/u/kvch)\
**Post date:** [February 27, 2019, 12:55pm UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097/4 "2019-02-27T12:55:45Z")

</div>

The main reason is if `close_renamed` and `close_timeout` is set, data loss might occur. As Filebeat closes the file, it is possible that it misses events before the file is removed/renamed, if it cannot reopen the file in time due to the configured `scan_frequency`.

---

<div class="post-metadata">

**Author:** ![NerdSec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nerdsec/32/22056_2.png) [@NerdSec](https://discuss.elastic.co/u/NerdSec)\
**Post date:** [March 1, 2019, 4:11am UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097/5 "2019-03-01T04:11:13Z")

</div>

But in this scenario, is there a way to avoid this data loss? Or is it acceptable?

---

<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:** [March 29, 2019, 4:11am UTC](https://discuss.elastic.co/t/filebeat-elasticsearch-module-not-closing-files-after-rollover/170097/6 "2019-03-29T04:11:14Z")

</div>

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