# Filebeat isn\`t collecting logs of short living containers like cronjobs

**URL:** <https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [November 10, 2020, 10:26pm UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984 "2020-11-10T22:26:30Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Patrick\_Erber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/patrick_erber/32/78648_2.png) [@Patrick\_Erber](https://discuss.elastic.co/u/Patrick_Erber)\
**Post date:** [November 10, 2020, 10:26pm UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/1 "2020-11-10T22:26:30Z")

</div>

Hello,

Filebeat isn`t collecting logs of short living containers like cronjobs.  
We are using filebeat version 7.9.3 and also kubernetes autodiscovery.

I've created a cronjob which prints just one line and exits afterwards.

My assumption:  
It looks like filebeat receives first an kubernetes pending event (No action is taken if a pending event is coming in, read from source code and logs) and the second time it receives the PodSucceeded (stop event gets emitted, read from source code and logs) event.  
Therefore the registry gets cleaned before filebeat is reading the file and the log entry never appears in Kibana.

If I pause the container for 2 seconds before shutting down, the log appears in Kibana.

Do you have any workaround for this kind of issue?

---

<div class="post-metadata">

**Author:** ![mtojek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mtojek/32/63863_2.png) [@mtojek](https://discuss.elastic.co/u/mtojek)\
**Post date:** [November 12, 2020, 9:17am UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/2 "2020-11-12T09:17:43Z")

</div>

Not sure if there is a good idea to solve this issue this way as due to time it will be always an issue. You may take a look at the logging driver and solve it a bit differently (see: [https://github.com/elastic/beats/issues/918#issuecomment-372000328](https://github.com/elastic/beats/issues/918#issuecomment-372000328))

---

<div class="post-metadata">

**Author:** ![Patrick\_Erber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/patrick_erber/32/78648_2.png) [@Patrick\_Erber](https://discuss.elastic.co/u/Patrick_Erber)\
**Post date:** [November 12, 2020, 9:57am UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/3 "2020-11-12T09:57:59Z")

</div>

Thank you Marcin.  
I wont use autodiscovery any longer and will try to use filebeat inputs with add\_kubernetes\_metadata\_processor.  
This seems as a solution so far.

I also think not that the solution should be to add a sleep cmd at the end.

I will update this thread in a few days to give feedback if my workaround is working properly.

---

<div class="post-metadata">

**Author:** ![malcolm666](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/malcolm666/32/69835_2.png) [@malcolm666](https://discuss.elastic.co/u/malcolm666)\
**Post date:** [December 7, 2020, 1:29pm UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/4 "2020-12-07T13:29:58Z")

</div>

I got the similar issue but in my situation I can't get any event with and without sleep ☹  
Could you update this thread?

---

<div class="post-metadata">

**Author:** ![Patrick\_Erber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/patrick_erber/32/78648_2.png) [@Patrick\_Erber](https://discuss.elastic.co/u/Patrick_Erber)\
**Post date:** [December 7, 2020, 2:37pm UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/5 "2020-12-07T14:37:43Z")

</div>

Hey,

I got all logs now. What still happens is that add\_kubernetes\_metadata is sometimes not able to add kubernetes information. Therefore our developers have to add the applicationname to there logs.

Sometimes, if logs do not appear it could also be a mapping conflict or something else.

In Kibana I saw mapping errors with following query: kubernetes.namespace: "filebeat" and log.level: "warn"

---

<div class="post-metadata">

**Author:** ![malcolm666](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/malcolm666/32/69835_2.png) [@malcolm666](https://discuss.elastic.co/u/malcolm666)\
**Post date:** [December 8, 2020, 10:20am UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/6 "2020-12-08T10:20:10Z")

</div>

In my environment it still doesn't work. I am using autodiscover and I think that it's a bad idea not using autodiscover because it works good.  
So, I noticed that sometimes cronjob output is logged to elasticsearch but not for all pods of cronjob ☹

---

<div class="post-metadata">

**Author:** ![jsoriano](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jsoriano/32/27920_2.png) [@jsoriano](https://discuss.elastic.co/u/jsoriano)\
**Post date:** [December 8, 2020, 6:12pm UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/7 "2020-12-08T18:12:31Z")

</div>

This is probably related to this issue: [https://github.com/elastic/beats/issues/22718](https://github.com/elastic/beats/issues/22718)

---

<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:** [January 5, 2021, 8:12pm UTC](https://discuss.elastic.co/t/filebeat-isn-t-collecting-logs-of-short-living-containers-like-cronjobs/254984/8 "2021-01-05T20:12:36Z")

</div>

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