# Does Filebeat "churn" if input files are missing?

**URL:** <https://discuss.elastic.co/t/does-filebeat-churn-if-input-files-are-missing/163407>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [January 8, 2019, 4:54pm UTC](https://discuss.elastic.co/t/does-filebeat-churn-if-input-files-are-missing/163407 "2019-01-08T16:54:30Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![RussellBateman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/russellbateman/32/34928_2.png) [@RussellBateman](https://discuss.elastic.co/u/RussellBateman)\
**Post date:** [January 8, 2019, 4:54pm UTC](https://discuss.elastic.co/t/does-filebeat-churn-if-input-files-are-missing/163407/1 "2019-01-08T16:54:30Z")

</div>

If I have specified a number of logfiles from which to harvest entries, something like this:

```
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/messages
      - /var/log/secure
      - /var/log/syslog
      - /opt/someapp/logs/audit.log
      - /opt/someapp/logs/debug.log
      - /opt/otherapp/logs/audit.log
      - /opt/otherapp/logs/debug.log

```

...and, ultimately, no _otherapp_ is actually running on the host Filebeat is installed on, am I paying a penalty for this? I.e.: will Filebeat churn (waste cycles) looking over and over again for logs on the (unused) path _/opt/otherapp/logs/_ because I listed it? Is it a poor practice to "over-specify" logfile source paths?

I ask this because I want to (be lazy and) avoid having to write multiple versions of _filebeat.yml_ and be careful about which host I install which version on. In my case, I'll really have at least three potentially different versions of _filebeat.yml_, maybe more.

---

<div class="post-metadata">

**Author:** ![pierhugues](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pierhugues/32/48383_2.png) [@pierhugues](https://discuss.elastic.co/u/pierhugues)\
**Post date:** [January 9, 2019, 7:36pm UTC](https://discuss.elastic.co/t/does-filebeat-churn-if-input-files-are-missing/163407/2 "2019-01-09T19:36:50Z")

</div>

@RussellBateman It wont affect performance, we only look periodically at the presence of files matching any defined path and this is done in a separate routine. Also from what I see you could use recursive glob to define path.

```auto
A list of glob-based paths that will be crawled and fetched. All patterns supported by Go Glob are also supported here. For example, to fetch all files from a predefined level of subdirectories, the following pattern can be used: /var/log/*/*.log. This fetches all .log files from the subfolders of /var/log. It does not fetch log files from the /var/log folder itself. It is possible to recursively fetch all files in all subdirectories of a directory using the optional recursive_glob settings.

Filebeat starts a harvester for each file that it finds under the specified paths. You can specify one path per line. Each line begins with a dash (-).

```

[https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-input-log.html#input-paths](https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-input-log.html#input-paths)

---

<div class="post-metadata">

**Author:** ![RussellBateman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/russellbateman/32/34928_2.png) [@RussellBateman](https://discuss.elastic.co/u/RussellBateman)\
**Post date:** [January 9, 2019, 8:10pm UTC](https://discuss.elastic.co/t/does-filebeat-churn-if-input-files-are-missing/163407/3 "2019-01-09T20:10:04Z")

</div>

Yeah, I wrote the example verbosely in order to make it really clear what I was talking about. Thanks!

---

<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:** [February 6, 2019, 8:10pm UTC](https://discuss.elastic.co/t/does-filebeat-churn-if-input-files-are-missing/163407/4 "2019-02-06T20:10:09Z")

</div>

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