# Elasticsearch Marvel Retention Period?

**URL:** https://discuss.elastic.co/t/elasticsearch-marvel-retention-period/48449
**Category:** Elasticsearch
**Tags:** elastic-stack-monitoring
**Created:** [April 26, 2016, 3:27pm UTC](https://discuss.elastic.co/t/elasticsearch-marvel-retention-period/48449 "2016-04-26T15:27:04Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![anhlqn](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/anhlqn/32/5454_2.png) [@anhlqn](https://discuss.elastic.co/u/anhlqn)
#### Post date: [April 26, 2016, 3:27pm UTC](https://discuss.elastic.co/t/elasticsearch-marvel-retention-period/48449/1 "2016-04-26T15:27:04Z")

</div>

> One of the top requests in Marvel came from the community asking for better management of daily indexes. “Marvel is too heavy,” we heard a number of times. In the current release, Marvel now has a default retention duration of 7 days. Beyond this period, the indices created by Marvel will be automatically deleted.

> There are subscription licenses available that enable configuration of longer and customized retention intervals. Learn more about Elastic’s subscriptions, which also grant access to security, alerting and the new graph plug-in.

Just got an email today about Marvel index retention.

To me this does not sound like a good reason to put an index retention as default in Marvel free and move the retention customization into subscriptions. They can just use Curator to delete whatever indexes they want. I would be very helpful to keep a history of cluster health for more than the default 7 days.

It's kinda odd to see people submitting for such weird requests.

---

<div class="post-metadata">

### Author: ![pickypg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pickypg/32/62409_2.png) [@pickypg](https://discuss.elastic.co/u/pickypg)
#### Post date: [April 26, 2016, 5:05pm UTC](https://discuss.elastic.co/t/elasticsearch-marvel-retention-period/48449/2 "2016-04-26T17:05:46Z")

</div>

It's simple to workaround this with the free license: use the `http` exporter. You can point it at the local cluster and it will behave in the same way.

The issue that we see all of the time is that users will run Marvel (1.x or 2.x) using the local exporter, but then do _not_ use something like Curator. As a result, the `.marvel-*` indices eventually blow up the cluster.

In fact, the best strategy is to point your Marvel exporters (`marvel-agent`) to an external monitoring cluster for a few reasons:

- Avoid impacting the production/monitored cluster
- Allow you to actually monitor the production/monitored cluster _even if it's gone_

It has the added benefit that it forces you to use the `http` exporter, which does not have any retention requirements.

---

<div class="post-metadata">

### Author: ![anhlqn](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/anhlqn/32/5454_2.png) [@anhlqn](https://discuss.elastic.co/u/anhlqn)
#### Post date: [April 26, 2016, 5:08pm UTC](https://discuss.elastic.co/t/elasticsearch-marvel-retention-period/48449/3 "2016-04-26T17:08:44Z")

</div>

Thank you for clarifying the changes.

---

<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: [July 6, 2017, 1:43pm UTC](https://discuss.elastic.co/t/elasticsearch-marvel-retention-period/48449/4 "2017-07-06T13:43:49Z")

</div>


