Enhance mapping explosion documentation in Elasticsearch

[ZachBrisson-Elastic]

• Expanded explanation of mapping explosion in Elasticsearch, including its causes, symptoms, and how to check for issues.
• Added details on the default field limit and its implications for performance.
• Replaced the intro to avoid the curse of knowledge (intro assumed customer's knew what mappings and field types were).

Summary

As part of @stefnestor 2026 Support KB alignment project took the latest information on mapping explosions and filled in to our existing troubleshooting documentation.

• Sources that were used as basis for changes:
  • https://support.elastic.dev/knowledge/view/008dd85e
  • https://support.elastic.dev/knowledge/view/f3c54c9b
  • https://www.elastic.co/blog/3-ways-to-prevent-mapping-explosion-in-elasticsearch
  • https://support.elastic.dev/knowledge/view/20475dc2
  • https://support.elastic.co/knowledge/ea3441cc

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes
• No

[github-actions]

Vale Linting Results

Summary: 4 suggestions found

💡 Suggestions (4)

File	Line	Rule	Message
troubleshoot/elasticsearch/mapping-explosion.md	15	Elastic.Acronyms	'JVM' has no definition.
troubleshoot/elasticsearch/mapping-explosion.md	17	Elastic.FutureTense	'will reject' might be in future tense. Write in the present tense to describe the state of the product as it is now.
troubleshoot/elasticsearch/mapping-explosion.md	23	Elastic.WordChoice	Consider using 'can, might' instead of 'may', unless the term is in the UI.
troubleshoot/elasticsearch/mapping-explosion.md	32	Elastic.Acronyms	'CAT' has no definition.

[github-actions]

🔍 Preview links for changed docs

• troubleshoot/elasticsearch/mapping-explosion.md

[yetanothertw]

Thank you for making these changes, they look great!

I've left a couple of small style suggestions for your consideration.

[yetanothertw]

LGTM, thank you! 🪴

[stefnestor]

1. IMO calling out Agent where Elastic-mainly controls the pipeline/integration suggests poor form of us pushing a product issue onto them.
2. We frequently use ingesting client-side for the correlated ingesting source log.
3. Also worth calling out here/above that this error also contains HTTP 400 and mapper_parsing_exception which is what users more commonly google.

[ZachBrisson-Elastic]

1. My apologies if that was the read. I was not intending to push a product issue on to the customer. Was trying to better describe where you would see the error.
2. The intent was to call out what the error would look like as the original "correlated ingesting source log" reference seemed a bit vague i.e. could we be saying their Kafka, in-house application, code client libraries, etc. would have that error message? So thought calling it out implicitly what products would have that message. Is there an in-house writer's bible I could read up on more of these nomenclatures, like client-side?

EDIT: doh meant explicitly instead of implicitly.

[stefnestor]

1. Totally no worries! Sorry, not trying to call you out vs I think our KBs do that widespread 🙂
2. I think the team's currently revamping this doc but am unsure where this glossary would be so was just FYI
3. (leaving placeholder)

Suggested change

* Check {{es}} cluster logs for errors similar to `Limit of total fields [X] in index [Y] has been exceeded` where `X` is the value of `index.mapping.total_fields.limit` and `Y` is your index. The correlated ingesting source log ({{beats}}, {{agent}}, or {{ls}} logs) error would be `Limit of total fields [X] has been exceeded while adding new fields [Z]` where `Z` is attempted new fields.

* Check {{es}} cluster logs for errors similar to `Limit of total fields [X] in index [Y] has been exceeded` where `X` is the value of `index.mapping.total_fields.limit` and `Y` is the index name. The correlated client-side ingesting source HTTP 400 `mapper_parsing_exception` log error would be `Limit of total fields [X] has been exceeded while adding new fields [Z]` where `Z` is attempted new fields.