Merge branch 'main' into fix-syntax-rendering-errors

Author: colleenmcginnis

deploy-manage/tools/snapshot-and-restore/read-only-url-repository.md

@@ -42,7 +42,7 @@ PUT _snapshot/my_read_only_url_repository
 :   (Optional, Boolean) If `true`, metadata files, such as index mappings and settings, are compressed in snapshots. Data files are not compressed. Defaults to `true`.
 
 `max_number_of_snapshots`
-:   (Optional, integer) Maximum number of snapshots the repository can contain. Defaults to `Integer.MAX_VALUE`, which is `2^31-1` or `2147483647`.
+:   (Optional, integer) Maximum number of snapshots the repository can contain. Defaults to `Integer.MAX_VALUE`, which is `2`^`31`^`-1` or `2147483647`.
 
 `max_restore_bytes_per_sec`
 :   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Maximum snapshot restore rate per node. Defaults to unlimited. Note that restores are also throttled through [recovery settings](elasticsearch://reference/elasticsearch/configuration-reference/index-recovery-settings.md).

deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md

@@ -148,7 +148,7 @@ PUT _snapshot/my_fs_backup
 :   (Required, string) Location of the shared filesystem used to store and retrieve snapshots. This location must be registered in the `path.repo` setting on all master and data nodes in the cluster. Unlike `path.repo`, this setting supports only a single file path.
 
 `max_number_of_snapshots`
-:   (Optional, integer) Maximum number of snapshots the repository can contain. Defaults to `Integer.MAX_VALUE`, which is `2^31-1` or `2147483647`.
+:   (Optional, integer) Maximum number of snapshots the repository can contain. Defaults to `Integer.MAX_VALUE`, which is `2`^`31`^`-1` or `2147483647`.
 
 `max_restore_bytes_per_sec`
 :   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Maximum snapshot restore rate per node. Defaults to unlimited. Note that restores are also throttled through [recovery settings](elasticsearch://reference/elasticsearch/configuration-reference/index-recovery-settings.md).

deploy-manage/tools/snapshot-and-restore/source-only-repository.md

@@ -53,7 +53,7 @@ PUT _snapshot/my_src_only_repository
 
 
 `max_number_of_snapshots`
-:   (Optional, integer) Maximum number of snapshots the repository can contain. Defaults to `Integer.MAX_VALUE`, which is `2^31-1` or `2147483647`.
+:   (Optional, integer) Maximum number of snapshots the repository can contain. Defaults to `Integer.MAX_VALUE`, which is `2`^`31`^`-1` or `2147483647`.
 
 `max_restore_bytes_per_sec`
 :   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Maximum snapshot restore rate per node. Defaults to unlimited. Note that restores are also throttled through [recovery settings](elasticsearch://reference/elasticsearch/configuration-reference/index-recovery-settings.md).

explore-analyze/query-filter/aggregations.md

@@ -294,4 +294,4 @@ For faster responses, {{es}} caches the results of frequently run aggregations i
 
 ## Limits for `long` values [limits-for-long-values]
 
-When running aggregations, {{es}} uses [`double`](elasticsearch://reference/elasticsearch/mapping-reference/number.md) values to hold and represent numeric data. As a result, aggregations on [`long`](elasticsearch://reference/elasticsearch/mapping-reference/number.md) numbers greater than `253` are approximate.
+When running aggregations, {{es}} uses [`double`](elasticsearch://reference/elasticsearch/mapping-reference/number.md) values to hold and represent numeric data. As a result, aggregations on [`long`](elasticsearch://reference/elasticsearch/mapping-reference/number.md) numbers greater than `2`^`53`^ are approximate.

solutions/search/using-resolve-cluster-endpoint-before-cross-cluster-search.md

@@ -3,17 +3,19 @@ mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/_advantages_of_using_this_endpoint_before_a_cross_cluster_search.html
 applies_to:
   stack:
-  serverless:
+  serverless: unavailable
 ---
 
-# Advantages of using this endpoint before a {{ccs}} [_advantages_of_using_this_endpoint_before_a_ccs]
+# Resolve a cluster before {{ccs}} [_advantages_of_using_this_endpoint_before_a_ccs]
+
+You can use the [`_resolve/cluster`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-resolve-cluster) endpoint before cross-cluster search to identify clusters or indices to exclude from your search.
 
 You may want to exclude a cluster or index from a search when:
 
-1. A remote cluster could not be connected to and is configured with `skip_unavailable`=`false`. Executing a {{ccs}} under those conditions will cause [the entire search to fail](/solutions/search/cross-cluster-search.md#cross-cluster-search-failures).
-2. A cluster has no matching indices, aliases or data streams for the index expression (or your user does not have permissions to search them). For example, suppose your index expression is `logs*,remote1:logs*` and the `remote1` cluster has no indices, aliases or data streams that match `logs*`. In that case, that cluster will return no results from that cluster if you include it in a {{ccs}}.
-3. The index expression (combined with any query parameters you specify) will likely cause an exception to be thrown when you do the search. In these cases, the "error" field in the `_resolve/cluster` response will be present. (This is also where security/permission errors will be shown.)
-4. A remote cluster is an older version that does not support the feature you want to use in your search.
+1. A remote cluster is unavailable and configured with `skip_unavailable`=`false`. Executing a {{ccs}} under those conditions will cause [the entire search to fail](/solutions/search/cross-cluster-search.md#cross-cluster-search-failures).
+2. A cluster has no matching indices, aliases or data streams for the index expression, or your user does not have permissions to search them. For example, if your index expression is `logs*,remote1:logs*` and the `remote1` cluster has no matching indices, that cluster will return no results if included in a {{ccs}}.
+3. The index expression, combined with any query parameters you specify, might trigger exceptions. In these cases, the "error" field in the `_resolve/cluster` response will be present. This is also where security/permission errors will be shown.
+4. A remote cluster is running an older version that does not support features needed for your search.
 
 ## {{api-examples-title}} [resolve-cluster-api-example]
 

solutions/search/vector/knn.md

@@ -915,7 +915,7 @@ All forms of quantization will result in some accuracy loss and as the quantizat
 * `int4` requires some rescoring for higher accuracy and larger recall scenarios. Generally, oversampling by 1.5x-2x recovers most of the accuracy loss.
 * `bbq` requires rescoring except on exceptionally large indices or models specifically designed for quantization. We have found that between 3x-5x oversampling is generally sufficient. But for fewer dimensions or vectors that do not quantize well, higher oversampling may be required.
 
-You can use the `rescore_vector` [preview] option to automatically perform reranking. When a rescore `oversample` parameter is specified, the approximate kNN search will:
+You can use the [`rescore_vector` option](https://www.elastic.co/docs/api/doc/elasticsearch/v9/operation/operation-search#operation-search-body-application-json-knn-rescore_vector) to automatically perform reranking. When a rescore `oversample` parameter is specified, the approximate kNN search will:
 
 * Retrieve `num_candidates` candidates per shard.
 * From these candidates, the top `k * oversample` candidates per shard will be rescored using the original vectors.

troubleshoot/elasticsearch/all-shards-failed.md

@@ -0,0 +1,199 @@
+---
+applies_to:
+  stack: 
+  deployment:
+    eck: 
+    ess: 
+    ece: 
+    self: 
+navigation_title: "Error: All shards failed"
+---
+
+# Fix error: All shards failed [all-shards-failed]
+
+```console
+Error: all shards failed
+```
+
+The `all shards failed` error indicates that {{es}} couldn't get a successful response from any of the shards involved in the query. Possible causes include shard allocation issues, misconfiguration, insufficient resources, or unsupported operations such as aggregating on text fields. 
+
+##  Unsupported operations on text fields
+
+The `all shards failed` error can occur when you try to sort or aggregate on `text` fields. These fields are designed for full-text search and don't support exact-value operations like sorting and aggregation.
+
+To fix this issue, use a `.keyword` subfield:
+
+```console
+GET my-index/_search
+{
+  "aggs": {
+    "names": {
+      "terms": {
+        "field": "name.keyword"
+      }
+    }
+  }
+}
+```
+
+If no `.keyword` subfield exists, define a [multi-field](elasticsearch://reference/elasticsearch/mapping-reference/field-data-types.md#types-multi-fields) mapping:
+
+```console
+PUT my-index
+{
+  "mappings": {
+    "properties": {
+      "name": {
+        "type": "text",
+        "fields": {
+          "keyword": {
+            "type": "keyword"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+### Metric aggregations on text fields
+
+The `all shards failed` error can also occur when you use a metric aggregation on a text field. [Metric aggregations](elasticsearch://reference/aggregations/metrics.md) require numeric fields. 
+
+You can use a script to convert the text value to a number at query time:
+
+```console
+GET my-index/_search
+{
+  "aggs": {
+    "total_cost": {
+      "sum": {
+        "script": {
+          "source": "Integer.parseInt(doc.cost.value)"
+        }
+      }
+    }
+  }
+}
+```
+
+Or change the field mapping to a numeric type:
+
+```console
+PUT my-index
+{
+  "mappings": {
+    "properties": {
+      "cost": {
+        "type": "integer"
+      }
+    }
+  }
+}
+```
+
+## Failed shard recovery
+
+A shard failure during recovery can prevent successful queries.
+
+To identify the cause, check the cluster health:
+
+```console
+GET _cluster/health
+```
+
+As a last resort, you can delete the problematic index.
+
+## Misused global aggregation
+
+[Global aggregations](elasticsearch://reference/aggregations/search-aggregations-bucket-global-aggregation.md) must be defined at the top level of the aggregations object. Nesting can cause errors.
+
+To fix this issue, structure the query so that the `global` aggregation appears at the top level:
+
+```console
+GET my-index/_search
+{
+  "size": 0,
+  "aggs": {
+    "all_products": {
+      "global": {},
+      "aggs": {
+        "genres": {
+          "terms": {
+            "field": "cost"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+## Reverse_nested usage errors
+
+Using a [`reverse_nested`](elasticsearch://reference/aggregations/search-aggregations-bucket-reverse-nested-aggregation.md) aggregation outside of a `nested` context causes errors.
+
+To fix this issue, structure the query so that the `reverse_nested` aggregation is inside a `nested` aggregation:
+
+```console
+GET my-index/_search
+{
+  "aggs": {
+    "comments": {
+      "nested": {
+        "path": "comments"
+      },
+      "aggs": {
+        "top_usernames": {
+          "terms": {
+            "field": "comments.username"
+          },
+          "aggs": {
+            "comment_issue": {
+              "reverse_nested": {},
+              "aggs": {
+                "top_tags": {
+                  "terms": {
+                    "field": "tags"
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+## Further troubleshooting
+
+Use the `_cat/shards` API to view shard status and troubleshoot further.
+
+```console
+GET _cat/shards
+```
+
+For a specific index:
+
+```console
+GET _cat/shards/my-index
+```
+
+Example output:
+
+```console-result
+my-index 5 p STARTED    0  283b 127.0.0.1 ziap
+my-index 5 r UNASSIGNED
+my-index 2 p STARTED    1 3.7kb 127.0.0.1 ziap
+my-index 2 r UNASSIGNED
+my-index 3 p STARTED    3 7.2kb 127.0.0.1 ziap
+my-index 3 r UNASSIGNED
+my-index 1 p STARTED    1 3.7kb 127.0.0.1 ziap
+my-index 1 r UNASSIGNED
+my-index 4 p STARTED    2 3.8kb 127.0.0.1 ziap
+my-index 4 r UNASSIGNED
+my-index 0 p STARTED    0  283b 127.0.0.1 ziap
+my-index 0 r UNASSIGNED
+```

troubleshoot/elasticsearch/errors.md

@@ -0,0 +1,12 @@
+---
+navigation_title: Error reference
+---
+
+# Troubleshoot common errors in {{es}} 
+
+Use the topics in this section to troubleshoot common errors in {{es}} deployments.
+
+* [](/troubleshoot/elasticsearch/all-shards-failed.md)
+* [](/troubleshoot/elasticsearch/failed-to-parse-field-of-type.md)
+* [](/troubleshoot/elasticsearch/unable-to-retrieve-node-fs-stats.md)
+* [](/troubleshoot/elasticsearch/unable-to-parse-response-body.md)

troubleshoot/elasticsearch/failed-to-parse-field-of-type.md

@@ -0,0 +1,58 @@
+---
+applies_to:
+  stack: 
+  deployment:
+    eck: 
+    ess: 
+    ece: 
+    self: 
+navigation_title: "Error: Failed to parse field of type in document with id"
+---
+
+# Fix error: Failed to parse field [failed-to-parse-field-of-type]
+
+```console
+Error: failed to parse field [field] of type [type] in document with id [id]
+```
+
+This error occurs when you try to index a document, but one of the field values doesn't match the expected data type. {{es}} rejects the document when it encounters incompatible values, like a string in a numeric field or an invalid IP address.
+
+To fix this issue, make sure each field value matches the data type defined in the mapping.
+
+## Field types and mapping
+
+When no explicit mapping exists, {{es}} uses [dynamic mappings](../../manage-data/data-store/mapping/dynamic-field-mapping.md) to infer a field's type based on the **first value indexed**.
+
+For example, if you index:
+
+```console
+PUT test/_doc/1
+{
+  "ip_address": "179.152.62.82",
+  "boolean_field": "off"
+}
+```
+
+Without explicit mapping, {{es}} will treat `ip_address` and `boolean_field` as `text`, which might not be the intended result. 
+
+To avoid this, define the mapping explicitly:
+
+```console
+PUT test
+{
+  "mappings": {
+    "properties": {
+      "ip_address": { "type": "ip" },
+      "boolean_field": { "type": "boolean" }
+    }
+  }
+}
+```
+
+To check the data type of the field causing the error, first get the mapping:
+
+    ```console
+        GET your-index-name/_mapping
+    ```
+
+Make sure the incoming data matches the expected type. If not, you'll need to fix the data or update the mapping. If necessary, create a new index with the correct mapping and reindex your data.