Merge branch 'main' of github.com:elastic/docs-content into kib-esql-818-updates

Author: florent-leborgne

deploy-manage/autoscaling/autoscaling-deciders.md

@@ -122,7 +122,7 @@ The [autoscaling](../../deploy-manage/autoscaling.md) {{ml}} decider (`ml`) calc
 The {{ml}} decider is enabled for policies governing `ml` nodes.
 
 ::::{note}
-For {{ml}} jobs to open when the cluster is not appropriately scaled, set `xpack.ml.max_lazy_ml_nodes` to the largest number of possible {{ml}} nodes (refer to [Advanced machine learning settings](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md#advanced-ml-settings) for more information). In {{ess}}, this is automatically set.
+For {{ml}} jobs to open when the cluster is not appropriately scaled, set `xpack.ml.max_lazy_ml_nodes` to the largest number of possible {{ml}} nodes (refer to [Advanced machine learning settings](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md#advanced-ml-settings) for more information). In {{ech}}, this is automatically set.
 ::::
 
 

deploy-manage/autoscaling/autoscaling-in-ece-and-ech.md

@@ -220,9 +220,8 @@ Note the following requirements when you run this API request:
 
 $$$ece-autoscaling-api-example-requirements-table$$$ 
 
-|     |     |     |     |
-| --- | --- | --- | --- |
 |  | `size` | `autoscaling_min` | `autoscaling_max` |
+| --- | --- | --- | --- |
 | data tier | ✓ | ✕ | ✓ |
 | machine learning node | ✕ | ✓ | ✓ |
 | coordinating and master nodes | ✓ | ✕ | ✕ |

deploy-manage/deploy/elastic-cloud.md

@@ -4,7 +4,7 @@ applies_to:
   deployment:
     ess: ga
 mapped_pages:
-  - https://www.elastic.co/guide/en/serverless/current/intro.html#general-what-is-serverless-elastic-differences-between-serverless-projects-and-hosted-deployments-on-ecloud
+  - https://www.elastic.co/guide/en/serverless/current/intro.html
 ---
 
 # Elastic Cloud [intro]
@@ -38,9 +38,8 @@ For more information, refer to [](/deploy-manage/cloud-organization.md).
 You can have multiple hosted deployments and serverless projects in the same {{ecloud}} organization, and each deployment type has its own specificities.
 
 
-|     |     |     |
-| --- | --- | --- |
 | Option | Serverless | Hosted |
+| --- | --- | --- |
 | **Cluster management** | Fully managed by Elastic. | You provision and manage your hosted clusters. Shared responsibility with Elastic. |
 | **Scaling** | Autoscales out of the box. | Manual scaling or autoscaling available for you to enable. |
 | **Upgrades** | Automatically performed by Elastic. | You choose when to upgrade. |

deploy-manage/deploy/elastic-cloud/azure-marketplace-pricing.md

@@ -23,9 +23,8 @@ The pricing plan update enables us to align with market trends and adapt to chan
 
 These pricing changes will apply to customers who are currently paying for Azure Marketplace services in non-USD currencies. If you are paying in USD, your pricing and billing will remain unchanged.
 
-|     |     |     |
-| --- | --- | --- |
 | Currency | Price | Elastic Billing Units for Azure† |
+| --- | --- | --- |
 | USD | 1.00 | $0.10 per 1000 units |
 | AUD | 1.60 | $0.16 per 1000 units |
 | BRL | 5.40 | R$0.54 per 1000 units |

deploy-manage/monitor/cloud-health-perf.md

@@ -45,7 +45,7 @@ You can also search and filter the table based on affected resources, such as in
 :alt: {{es}} Health page with details and troubleshooting
 :::
 
-For each issue you can either use a troubleshooting link or get a suggestion to contact support, in case you need help. The [troubleshooting documentation](/troubleshoot/elasticsearch/elasticsearch.md) for {{es}} provides more details on specific errors.
+For more information about specific errors, refer to [](/troubleshoot/elasticsearch.md). You can also [contact us](/troubleshoot/index.md#contact-us) if you need more help.
 
 ### Health warnings [ec-es-health-warnings]
 
@@ -74,7 +74,7 @@ deployment:
   ess:
 ```
 
-{{ess}} deployments offer an additional **Performance** page to get further information about your cluster performance. 
+{{ech}} deployments offer an additional **Performance** page to get further information about your cluster performance. 
 
 If you observe issues on search and ingest operations in terms of increased latency or throughput for queries, these might not be directly reported on the **Health** page, unless they are related to shard health or master node availability. 
 
@@ -131,23 +131,23 @@ If you need your cluster to be able to sustain a certain level of performance, y
 
 We’ve compiled some guidelines to help you ensure the health of your deployments over time. These can help you to better understand the available performance metrics, and to make decisions involving performance and high availability.
 
-[Why is my node(s) unavailable?](/troubleshoot/monitoring/unavailable-nodes.md)
+[](/troubleshoot/monitoring/unavailable-nodes.md)
 :   Learn about common symptoms and possible actions that you can take to resolve issues when one or more nodes become unhealthy or unavailable.
 
-[Why are my shards unavailable?](/troubleshoot/monitoring/unavailable-shards.md)
+[](/troubleshoot/monitoring/unavailable-shards.md)
 :   Provide instructions on how to troubleshoot issues related to unassigned shards.
 
-[Why is performance degrading over time?](/troubleshoot/monitoring/performance.md)
+[](/troubleshoot/monitoring/performance.md)
 :   Address performance degradation on a smaller size Elasticsearch cluster.
 
-[Is my cluster really highly available?](/troubleshoot/monitoring/high-availability.md)
+[](/troubleshoot/monitoring/high-availability.md)
 :   High availability involves more than setting multiple availability zones (although that’s really important!). Learn how to assess performance and workloads to determine if your deployment has adequate resources to mitigate a potential node failure.
 
-[How does high memory pressure affect performance?](/troubleshoot/monitoring/high-memory-pressure.md)
+[](/troubleshoot/monitoring/high-memory-pressure.md)
 :   Learn about typical memory usage patterns, how to assess when the deployment memory usage levels are problematic, how this impacts performance, and how to resolve memory-related issues.
 
-[Why are my cluster response times suddenly so much worse?](/troubleshoot/monitoring/cluster-response-time.md)
+[](/troubleshoot/monitoring/cluster-response-time.md)
 :   Learn about the common causes of increased query response times and decreased performance in your deployment.
 
-[Why did my node move to a different host?](/troubleshoot/monitoring/node-moves-outages.md)
+[](/troubleshoot/monitoring/node-moves-outages.md)
 :   Learn about why we may, from time to time, relocate your {{ech}} deployments across hosts.

deploy-manage/monitor/orchestrators/ece-proxy-log-fields.md

@@ -13,9 +13,8 @@ These fields *are* subject to change, though the vast majority of them are gener
 ::::
 
 
-|     |     |
-| --- | --- |
 | Field | Description |
+| --- | --- |
 | `proxy_ip` | the IP on the connection, i.e. a proxy IP if the request has been proxied |
 | `request_end` | the time the request was returned in ms since unix epoch |
 | `status_code` | the HTTP status returned to the client |

deploy-manage/production-guidance/optimize-performance/size-shards.md

@@ -5,8 +5,33 @@ mapped_pages:
 
 # Size your shards [size-your-shards]
 
-Each index in {{es}} is divided into one or more shards, each of which may be replicated across multiple nodes to protect against hardware failures. If you are using [Data streams](../../../manage-data/data-store/data-streams.md) then each data stream is backed by a sequence of indices. There is a limit to the amount of data you can store on a single node so you can increase the capacity of your cluster by adding nodes and increasing the number of indices and shards to match. However, each index and shard has some overhead and if you divide your data across too many shards then the overhead can become overwhelming. A cluster with too many indices or shards is said to suffer from *oversharding*. An oversharded cluster will be less efficient at responding to searches and in extreme cases it may even become unstable.
+## What is a shard? [what-is-a-shard]
 
+A shard is a basic unit of storage in {{es}}. Every index is divided into one or more shards to help distribute data and workload across nodes in a cluster. This division allows {{es}} to handle large datasets and perform operations like searches and indexing efficiently. For more detailed information on shards, see [this page](/deploy-manage/distributed-architecture/clusters-nodes-shards.md).
+
+## General guidelines [sizing-shard-guidelines]
+
+Balancing the number and size of your shards is important for the performance and stability of an {{es}} cluster:
+
+* Too many shards can degrade search performance and make the cluster unstable. This is referred to as _oversharding_.
+* Very large shards can slow down search operations and prolong recovery times after failures.
+
+To avoid either of these states, implement the following guidelines:
+
+### General sizing guidelines
+
+* Aim for shard sizes between 10GB and 50GB
+* Keep the number of documents on each shard below 200 million
+
+### Shard distribution guidelines
+
+To ensure that each node is working optimally, distribute shards evenly across nodes. Uneven distribution can cause some nodes to work harder than others, leading to performance degradation and instability. 
+
+While {{es}} automatically balances shards, you need to configure indices with an appropriate number of shards and replicas to allow for even distribution across nodes.
+
+If you are using [data streams](/manage-data/data-store/data-streams.md), each data stream is backed by a sequence of indices, each index potentially having multiple shards. 
+
+Despite these general guidelines, it is good to develop a tailored [sharding strategy](#create-a-sharding-strategy) that considers your specific infrastructure, use case, and performance expectations. 
 
 ## Create a sharding strategy [create-a-sharding-strategy]
 

deploy-manage/reference-architectures.md

@@ -25,9 +25,8 @@ These reference architectures are recommendations and should be adapted to fit y
 
 ## Architectures [reference-architectures-time-series]
 
-|     |     |
+| Architecture | When to use |
 | --- | --- |
-| **Architecture** | **When to use** |
 | [*Hot/Frozen - High Availability*](/deploy-manage/reference-architectures/hotfrozen-high-availability.md)<br>A high availability architecture that is cost optimized for large time-series datasets. | * Have a requirement for cost effective long term data storage (many months or years).<br>* Provide insights and alerts using logs, metrics, traces, or various event types to ensure optimal performance and quick issue resolution for applications.<br>* Apply Machine Learning and Search AI to assist in dealing with the large amount of data.<br>* Deploy an architecture model that allows for maximum flexibility between storage cost and performance.<br> |
 | Additional architectures are on the way.<br>Stay tuned for updates. |  |
 

deploy-manage/reference-architectures/hotfrozen-high-availability.md

@@ -62,9 +62,8 @@ In the links provided above, Elastic has performance tested hardware for each of
 
 This table shows our specific recommendations for nodes in a Hot/Frozen architecture.
 
-|     |     |     |     |     |
+| Type | AWS | Azure | GCP | Physical |
 | --- | --- | --- | --- | --- |
-| **Type** | **AWS** | **Azure** | **GCP** | **Physical** |
 | ![Hot data node](../../images/reference-architectures-hot.png "") | c6gd | f32sv2 | N2 | 16-32 vCPU<br>64 GB RAM<br>2-6 TB NVMe SSD |
 | ![Frozen data node](../../images/reference-architectures-frozen.png "") | i3en | e8dsv4 | N2 | 8 vCPU<br>64 GB RAM<br>6-20+ TB NVMe SSD<br>Depending on days cached |
 | ![Machine learning node](../../images/reference-architectures-machine-learning.png "") | m6gd | f16sv2 | N2 | 16 vCPU<br>64 GB RAM<br>256 GB SSD |

deploy-manage/security/elastic-cloud-static-ips.md

@@ -39,9 +39,8 @@ Not suitable usage of egress static IPs to introduce network controls:
 ## Supported Regions [ec-regions] 
 
 ::::{dropdown} AWS
-|     |     |     |
+| Region | Ingress Static IPs | Egress Static IPs |
 | --- | --- | --- |
-| **Region** | **Ingress Static IPs** | **Egress Static IPs** |
 | aws-af-south-1 | No | Yes |
 | aws-ap-east-1 | No | Yes |
 | aws-ap-northeast-1 | No | Yes |
@@ -67,9 +66,8 @@ Not suitable usage of egress static IPs to introduce network controls:
 
 
 ::::{dropdown} Azure
-|     |     |     |
+| Region | Ingress Static IPs | Egress Static IPs |
 | --- | --- | --- |
-| **Region** | **Ingress Static IPs** | **Egress Static IPs** |
 | azure-australiaeast | Yes | Yes |
 | azure-brazilsouth | Yes | Yes |
 | azure-canadacentral | Yes | Yes |
@@ -91,9 +89,8 @@ Not suitable usage of egress static IPs to introduce network controls:
 
 
 ::::{dropdown} GCP
-|     |     |     |
+| Region | Ingress Static IPs | Egress Static IPs |
 | --- | --- | --- |
-| **Region** | **Ingress Static IPs** | **Egress Static IPs** |
 | gcp-asia-east1 | Yes | No |
 | gcp-asia-northeast1 | Yes | No |
 | gcp-asia-northeast3 | Yes | No |