# ES for logs -- field conflict hell 🔥

**URL:** <https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849>\
**Category:** Elasticsearch\
**Created:** [March 20, 2024, 8:51pm UTC](https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849 "2024-03-20T20:51:00Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![rsk0](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rsk0/32/124810_2.png) [@rsk0](https://discuss.elastic.co/u/rsk0)\
**Post date:** [March 29, 2024, 9:58pm UTC](https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849/17 "2024-03-29T21:58:50Z")

</div>

Oh, also,

- conserve fields
  - consider using multiple indices / streams to cope with large quantities of fields

For example, if you find your logs are eating up over a thousand fields, perhaps split them across multiple series/streams:

- `logs-all_logs-a.2024-03-29` or `logs-datastream-all_logs-a` gets 1000 fields
- `logs-all_logs-b.2024-03-29` or `logs-datastream-all_logs-b` gets the overage

Then query across both sets, a and b, using a single data view / index pattern.

I _think_ this should mitigate [the "too many fields" problem as mentioned in the mapping limit settings doc](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-settings-limit.html#mapping-settings-limit), but I'm not entirely sure and would love to have an elastician chime in.

[edit: You would also want to minimize as much as possible field conflicts between the series to avoid Kibana balking.]

[edit: Oh, apparently [this has already been suggested](https://discuss.elastic.co/t/approaches-to-deal-with-limit-of-total-fields-1000-in-index-has-been-exceeded/241039#split-your-index-3) by @warkolm! Thanks, Mark!]

---

_[View the full topic](https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849)._
