Enhance mapping explosion documentation in Elasticsearch

troubleshoot/elasticsearch/mapping-explosion.md

@@ -10,17 +10,21 @@
 
 # Mapping explosion [mapping-explosion]
 
-{{es}}'s search and [{{kib}}'s discover](../../explore-analyze/discover.md) Javascript rendering are dependent on the search’s backing indices total amount of [mapped fields](elasticsearch://reference/elasticsearch/mapping-reference/field-data-types.md), of all mapping depths. When this total amount is too high or is exponentially climbing, we refer to it as experiencing mapping explosion. Field counts going this high are uncommon and usually suggest an upstream document formatting issue as [shown in this blog](https://www.elastic.co/blog/found-crash-elasticsearch#mapping-explosion).
+In Elasticsearch, a mapping or [mapped field](elasticsearch://reference/elasticsearch/mapping-reference/field-data-types.md) defines the fields in an index and their data types, such as text for full-text search, keyword for exact filtering, or boolean for true/false values. Think of it as a schema that tells Elasticsearch how to interpret and store each piece of data. When the total number of mapped fields across an index grows excessively large, the cluster can experience performance degradation such as slower searches, high heap usage, and prolonged startup times. 
+
+To protect itself, Elasticsearch enforces a default field limit of `1000` and can reject ingestion for that specific index once the threshold is reached. This condition of runaway field growth is called a mapping explosion, and it typically signals an upstream data formatting issue that should be addressed at the source as [described in this blog](https://www.elastic.co/blog/3-ways-to-prevent-mapping-explosion-in-elasticsearch).
 
 Mapping explosion may surface as the following performance symptoms:
 
 * [CAT nodes](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cat-nodes) reporting high heap or CPU on the main node and/or nodes hosting the indices shards. This may potentially escalate to temporary node unresponsiveness and/or main overwhelm.
 * [CAT tasks](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cat-tasks) reporting long search durations only related to this index or indices, even on simple searches.
 * [CAT tasks](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cat-tasks) reporting long index durations only related to this index or indices. This usually relates to [pending tasks](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-pending-tasks) reporting that the coordinating node is waiting for all other nodes to confirm they are on mapping update request.
+* [CAT pending tasks](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cat-pending-tasks) reporting a task queue backlog with a lot of `put-mapping [MY_INDEX_NAME/MY_INDEX_UUID]` messages.
 * Discover’s **Fields for wildcard** page-loading API command or [Dev Tools](../../explore-analyze/query-filter/tools/console.md) page-refreshing Autocomplete API commands are taking a long time (more than 10 seconds) or timing out in the browser’s Developer Tools Network tab. For more information, refer to our [walkthrough on troubleshooting Discover](https://www.elastic.co/blog/troubleshooting-guide-common-issues-kibana-discover-load).
 * Discover’s **Available fields** taking a long time to compile Javascript in the browser’s Developer Tools Performance tab. This may potentially escalate to temporary browser page unresponsiveness.
 * Kibana’s [alerting](../../explore-analyze/alerts-cases/alerts.md) or [security rules](../../solutions/security/detect-and-alert.md) may error `The content length (X) is bigger than the maximum allowed string (Y)` where `X` is attempted payload and `Y` is {{kib}}'s [`server-maxPayload`](kibana://reference/configuration-reference/general-settings.md#server-maxpayload).
 * Long {{es}} start-up durations.
+* Kibana Javascript erring within browser while loading a Dashboard or Discover with message `Maximum call stack size exceeded`.
 
 
 ## Prevent or prepare [prevent]
@@ -40,7 +44,8 @@
 
 To confirm the field totals of an index to check for mapping explosion:
 
-* Check {{es}} cluster logs for errors `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 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 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.
+* Review the elected-master node logs for a flood of INFO logs. You might see a large amount of `[elasticsearch.server][INFO] update_mapping [_doc]` messages. If they time out, a large amount of `org.elasticsearch.cluster.metadata.ProcessClusterEventTimeoutException: failed to process cluster event (put-mapping [<INDEX_NAME>/<INDEX_UUID>]) within 30s` messages display as well.
 * For top-level fields, poll [field capabilities](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-field-caps) for `fields=*`.
 * Search the output of [get mapping](../../manage-data/data-store/mapping.md) for `"type"`.
 * If you’re inclined to use the [third-party tool JQ](https://stedolan.github.io/jq), you can process the [get mapping](../../manage-data/data-store/mapping.md) `mapping.json` output.