# How to index even on failed pipelines

**URL:** <https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122>\
**Category:** Elasticsearch\
**Created:** [November 22, 2019, 11:33pm UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122 "2019-11-22T23:33:37Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![micas](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@micas](https://discuss.elastic.co/u/micas)\
**Post date:** [November 22, 2019, 11:33pm UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122/1 "2019-11-22T23:33:37Z")

</div>

I have an ingest pipeline "filebeat-7.2.0-apache-access-default" and others, however when my document doesnt match something it doesnt get indexed. Is there any way that i can define that even if _any_ pipeline fails index the document anyway ?

preferrably a general setting for all

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [November 28, 2019, 9:24am UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122/2 "2019-11-28T09:24:23Z")

</div>

There are several options for this, see [https://www.elastic.co/guide/en/elasticsearch/reference/7.4/handling-failure-in-pipelines.html](https://www.elastic.co/guide/en/elasticsearch/reference/7.4/handling-failure-in-pipelines.html)

---

<div class="post-metadata">

**Author:** ![micas](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@micas](https://discuss.elastic.co/u/micas)\
**Post date:** [November 28, 2019, 11:56am UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122/3 "2019-11-28T11:56:48Z")

</div>

@spinscale since i have no control over these pipelines (they get created by filebeat etc...) what i am looking for is a way to not have to change them so that the "index even if it fails" mentality would be applied to all pipelines. is there anything of that kind ?

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [November 28, 2019, 12:37pm UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122/4 "2019-11-28T12:37:22Z")

</div>

do you care to explain your use-case a little bit further? Are you trying to manually index data or use another filebeat instance? What kind of data are you indexing? I'm curious where this starts to differ from the 'general' filebeat use-case or if there is an general issue on the filebeat/elasticsearch side of things.

Thanks for helping!

---

<div class="post-metadata">

**Author:** ![micas](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@micas](https://discuss.elastic.co/u/micas)\
**Post date:** [November 28, 2019, 12:41pm UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122/5 "2019-11-28T12:41:48Z")

</div>

@spinscale I'm using a typical ELK stack with beats (all OSS) and adding all the pipelines etc.. via the setup command. beats (filebeat for example) is collecting (via the apache module and others) and sending to logs to Logstash.

What i am verifying is that my apache logs are not passing the pipeline saying that some fields dont exist and therefore are not being indexed. I dont want this to happen, if it passes the pipeline, fine, if not then atleast they should be indexed that i dont lose them.

---

<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:** [December 26, 2019, 12:41pm UTC](https://discuss.elastic.co/t/how-to-index-even-on-failed-pipelines/209122/6 "2019-12-26T12:41:51Z")

</div>

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