elastic · thekofimensah · Mar 10, 2025 · Mar 11, 2025 · Mar 10, 2025 · Mar 10, 2025
@@ -32,6 +32,7 @@ The available resources of self-managed deployments are static, so trained model
 {{serverless-full}} Security and Observability projects are only charged for data ingestion and retention. They are not charged for processing power (VCU usage), which is used for more complex operations, like running advanced search models. For example, in Search projects, models such as ELSER require significant processing power to provide more accurate search results.
 
 ## Enabling autoscaling through APIs - adaptive allocations [enabling-autoscaling-through-apis-adaptive-allocations]
+
 $$$nlp-model-adaptive-resources$$$
 
 Model allocations are independent units of work for NLP tasks. If you set the numbers of threads and allocations for a model manually, they remain constant even when not all the available resources are fully used or when the load on the model requires more resources. Instead of setting the number of allocations manually, you can enable adaptive allocations to set the number of allocations based on the load on the process. This can help you to manage performance and cost more easily. (Refer to the [pricing calculator](https://cloud.elastic.co/pricing) to learn more about the possible costs.)
@@ -55,6 +56,7 @@ When you create inference endpoints on {{serverless-short}} using Kibana, adapti
 :::
 
 ### Optimizing for typical use cases [optimizing-for-typical-use-cases]
+
 You can optimize your model deployment for typical use cases, such as search and ingest. When you optimize for ingest, the throughput will be higher, which increases the number of {{infer}} requests that can be performed in parallel. When you optimize for search, the latency will be lower during search processes.
 
 * If you want to optimize for ingest, set the number of threads to `1` (`"threads_per_allocation": 1`).
@@ -86,6 +88,11 @@ The used resources for trained model deployments depend on three factors:
 * the use case you optimize the model deployment for (ingest or search)
 * whether model autoscaling is enabled with adaptive allocations/resources to have dynamic resources, or disabled for static resources
 
+::::{note}
+On {{serverless-short}}, VCUs for {{ml}} are based on the amount of vCPU and memory consumed. For {{ml}}, `1` VCU equals `0.125` of vCPU and `1GB` of memory, where vCPUs are measured by allocations multiplied by threads, and where memory is the amount consumed by trained models or {{ml}} jobs.
+As a math formula, `VCUs = 8 * allocations * threads`, or `1` VCU for every `1GB` of memory consumed, whichever is greater.
+::::
+
 If you use a self-managed cluster or ECK, vCPUs level ranges are derived from the `total_ml_processors` and `max_single_ml_node_processors` values. Use the [get {{ml}} info API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-ml-info) to check these values. 
 
 The following tables show you the number of allocations, threads, and vCPUs available in ECE and ECH when adaptive resources are enabled or disabled.

@@ -33,7 +33,7 @@ Other sections of the documentation describe important ECE features to consider:
 * [Configure allocator affinity](configure-allocator-affinity.md) - Determine how ECE distributes your Elastic Stack deployments across allocators.
 * [Change allocator disconnect timeout](change-allocator-disconnect-timeout.md) - Configure how long ECE waits before considering allocators to be disconnected.
 * [Migrate ECE to Podman hosts](./migrate-ece-to-podman-hosts.md) - If you are running a Docker based installation and you need to migrate to Podman.
-* [Migrate ECE on Podman hosts to SELinux in enforcing mode](migrate-ece-on-podman-hosts-to-selinux-enforce.md) - Migrate ECE to SELinux in `enforcing` mode using Podman.
+* [Migrate ECE on Podman hosts to SELinux in enforcing mode](../../security/secure-your-elastic-cloud-enterprise-installation/migrate-ece-on-podman-hosts-to-selinux-enforce.md) - Migrate ECE to SELinux in `enforcing` mode using Podman.
 
 ## Maintenance activities
 

@@ -52,5 +52,5 @@ To start orchestrating your {{es}} clusters, refer to [](./working-with-deployme
 The following tasks are only needed on certain circumstances:
 
 * [Migrate ECE to Podman hosts](./migrate-ece-to-podman-hosts.md)
-* [Migrate ECE on Podman hosts to SELinux enforce](./migrate-ece-on-podman-hosts-to-selinux-enforce.md)
+* [Migrate ECE on Podman hosts to SELinux enforce](./../../security/secure-your-elastic-cloud-enterprise-installation/migrate-ece-on-podman-hosts-to-selinux-enforce.md)
 * [Change allocator disconnect timeout](./change-allocator-disconnect-timeout.md)
@@ -29,6 +29,7 @@ After installing or upgrading to version 2.10 or later:
     * For Kibana, the certificate needs to allow for ***.kb.<your-domain>**
     * For APM, the certificate needs to allow for ***.apm.<your-domain>**
     * For Fleet, the certificate needs to allow for ***.fleet.<your-domain>**
+    * For Universal Profiling, the certificate needs to allow for ***.profiling.<your-domain>** and ***.symbols.<your-domain>**
 
 3. In the **Platform** menu, select **Settings**.
 4. Under the **Enable custom endpoint alias naming**, toggle the setting to allow platform administrators and deployment managers to choose a simplified, unique URL for the endpoint.

@@ -80,11 +80,11 @@ Alpha, beta, and stable API versions follow the same [conventions used by Kubern
 
 ECK is compatible with the following Elastic Stack applications:
 
-* Elasticsearch, Kibana, APM Server: 6.8+, 7.1+, 8+
-* Enterprise Search: 7.7+, 8+
-* Beats: 7.0+, 8+
-* Elastic Agent: 7.10+ (standalone), 7.14+ (Fleet), 8+
-* Elastic Maps Server: 7.11+, 8+
+* Elasticsearch, Kibana, APM Server: 7.17+, 8+
+* Enterprise Search: 7.17+, 8+
+* Beats: 7.17+, 8+
+* Elastic Agent: 7.10+ (standalone), 7.17+ (Fleet), 8+
+* Elastic Maps Server: 7.17+, 8+
 * Logstash: 8.7+
 
 Elastic Stack application images for the OpenShift-certified Elasticsearch (ECK) Operator are only available from version 7.10 and later.

@@ -12,7 +12,7 @@ mapped_pages:
 This page explains the various methods for configuring and applying ECK settings.
 
 ::::{tip}
-For a detailed list and description of all available settings in ECK, refer to [ECK configuration flags](asciidocalypse://docs/cloud-on-k8s/docs/reference/eck-configuration-flags.md).
+For a detailed list and description of all available settings in ECK, refer to [ECK configuration flags](cloud-on-k8s://reference/eck-configuration-flags.md).
 ::::
 
 By default, the ECK installation includes a [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) with an `eck.yaml` key where you can add, remove, or update configuration settings. This ConfigMap is mounted into the operator’s container as a file, and provided to the application through the `--config` flag.
@@ -56,7 +56,7 @@ If you installed ECK using the manifests and the commands listed in [Deploy ECK]
 
 You can update the ConfigMap directly using the command `kubectl edit configmap elastic-operator -n elastic-operator` or modify the installation manifests and reapply them with `kubectl apply -f <your-manifest-file.yaml>`.
 
-The following shows the default `elastic-operator` ConfigMap, for reference purposes. Refer to [ECK configuration flags](asciidocalypse://docs/cloud-on-k8s/docs/reference/eck-configuration-flags.md) for a complete list of available settings.
+The following shows the default `elastic-operator` ConfigMap, for reference purposes. Refer to [ECK configuration flags](cloud-on-k8s://reference/eck-configuration-flags.md) for a complete list of available settings.
 
 ```yaml
 apiVersion: v1

@@ -44,7 +44,7 @@ The cluster that you deployed in this quickstart guide only allocates a persiste
 ::::
 
 
-For a full description of each `CustomResourceDefinition` (CRD), refer to the [*API Reference*](asciidocalypse://docs/cloud-on-k8s/docs/reference/k8s-api-reference.md) or view the CRD files in the [project repository](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/crds). You can also retrieve information about a CRD from the cluster. For example, describe the {{es}} CRD specification with [`describe`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_describe/):
+For a full description of each `CustomResourceDefinition` (CRD), refer to the [*API Reference*](cloud-on-k8s://reference/api-docs.md) or view the CRD files in the [project repository](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/crds). You can also retrieve information about a CRD from the cluster. For example, describe the {{es}} CRD specification with [`describe`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_describe/):
 
 ```sh
 kubectl describe crd elasticsearch

@@ -43,7 +43,7 @@ kubectl annotate namespace elastic-stack linkerd.io/inject=enabled
 
 Any Elasticsearch, Kibana, or APM Server resources deployed to a namespace with the above annotation will automatically join the mesh.
 
-Alternatively, if you only want specific resources to join the mesh, add the `linkerd.io/inject: enabled` annotation to the `podTemplate` (check [API documentation](asciidocalypse://docs/cloud-on-k8s/docs/reference/k8s-api-reference.md)) of the resource as follows:
+Alternatively, if you only want specific resources to join the mesh, add the `linkerd.io/inject: enabled` annotation to the `podTemplate` (check [API documentation](cloud-on-k8s://reference/api-docs.md)) of the resource as follows:
 
 ```yaml
 podTemplate:

@@ -66,7 +66,7 @@ To deploy a simple [{{kib}}](/get-started/the-stack.md#stack-components-kibana)
     ```
 
 
-For a full description of each `CustomResourceDefinition` (CRD), refer to the [*API Reference*](asciidocalypse://docs/cloud-on-k8s/docs/reference/k8s-api-reference.md) or view the CRD files in the [project repository](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/crds). You can also retrieve information about a CRD from the instance. For example, describe the {{kib}} CRD specification with [`describe`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_describe/):
+For a full description of each `CustomResourceDefinition` (CRD), refer to the [*API Reference*](cloud-on-k8s://reference/api-docs.md) or view the CRD files in the [project repository](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/crds). You can also retrieve information about a CRD from the instance. For example, describe the {{kib}} CRD specification with [`describe`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_describe/):
 
 ```sh
 kubectl describe crd kibana

@@ -12,7 +12,7 @@ For more details about feature availability in Serverless, check [](elastic-clou
 | [Security configurations](/deploy-manage/security.md) | Full control | Limited control | Limited control |
 | [Authentication realms](/deploy-manage/users-roles.md) | Available | Available | Available, through Elastic Cloud only |
 | [Custom roles](/deploy-manage/users-roles.md) | Available | Available | Available |
-| [Audit logging](/deploy-manage/monitor/logging-configuration/configuring-audit-logs.md) | Available | Available | No |
+| [Audit logging](/deploy-manage/security/logging-configuration/security-event-audit-logging.md) | Available | Available | No |
 
 ## Infrastructure and cluster management
 

@@ -16,11 +16,11 @@ Plugins extend the core functionality of {{es}}. There are many suitable plugins
 * Analysis plugins, to provide analyzers targeted at languages other than English.
 * Scripting plugins, to provide additional scripting languages.
 
-Plugins can come from different sources: the official ones created or at least maintained by Elastic, community-sourced plugins from other users, and plugins that you provide. Some of the official plugins are always provided with our service, and can be [enabled per deployment](elasticsearch://reference/elasticsearch-plugins/cloud/ec-adding-elastic-plugins.md).
+Plugins can come from different sources: the official ones created or at least maintained by Elastic, community-sourced plugins from other users, and plugins that you provide. Some of the official plugins are always provided with our service, and can be [enabled per deployment](elasticsearch://reference/elasticsearch-plugins/plugin-management.md).
 
 There are two ways to add plugins to a hosted deployment in {{ecloud}}:
 
-* [Enable one of the official plugins already available in {{ecloud}}](elasticsearch://reference/elasticsearch-plugins/cloud/ec-adding-elastic-plugins.md).
+* [Enable one of the official plugins already available in {{ecloud}}](elasticsearch://reference/elasticsearch-plugins/plugin-management.md).
 * [Upload a custom plugin and then enable it per deployment](upload-custom-plugins-bundles.md).
 
 Custom plugins can include the official {{es}} plugins not provided with {{ecloud}}, any of the community-sourced plugins, or [plugins that you write yourself](elasticsearch://extend/index.md). Uploading custom plugins is available only to Gold, Platinum, and Enterprise subscriptions. For more information, check [Upload custom plugins and bundles](upload-custom-plugins-bundles.md).

@@ -12,7 +12,7 @@ A region is the geographic area where the data center of the cloud provider that
 Elastic Cloud Serverless handles all hosting details for you. You are unable to change the region after you create a project.
 
 ::::{note} 
-Currently, a limited number of Amazon Web Services (AWS) and Microsoft Azure regions are available. More regions for AWS and Azure, as well as Google Cloud Platform (GCP), will be added in the future.
+Currently, a limited number of Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) regions are available. More regions for AWS, Azure, and GCP, will be added in the future.
 
 ::::
 
@@ -39,4 +39,16 @@ The following Azure regions are currently available:
 
 | Region | Name |
 | :--- | :--- |
-| eastus | East US |
+| eastus | East US |
+
+## Google Cloud Platform (GCP) regions [regions-gcp-regions]
+
+```yaml {applies_to}
+serverless: preview
+```
+
+The following GCP regions are currently available:
+
+| Region | Name |
+| :--- | :--- |
+| us-central1 | Iowa |
@@ -27,7 +27,7 @@ If you’re using {{agent}}, do not deploy {{filebeat}} for log collection. Inst
 
 2. Identify which logs you want to monitor.
 
-    The {{filebeat}} {{es}} module can handle [audit logs](../logging-configuration/logfile-audit-output.md), [deprecation logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md#deprecation-logging), [gc logs](elasticsearch://reference/elasticsearch/jvm-settings.md#gc-logging), [server logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md), and [slow logs](elasticsearch://reference/elasticsearch/index-settings/slow-log.md). For more information about the location of your {{es}} logs, see the [path.logs](../../deploy/self-managed/important-settings-configuration.md#path-settings) setting.
+    The {{filebeat}} {{es}} module can handle [audit logs](../../security/logging-configuration/logfile-audit-output.md), [deprecation logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md#deprecation-logging), [gc logs](elasticsearch://reference/elasticsearch/jvm-settings.md#gc-logging), [server logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md), and [slow logs](elasticsearch://reference/elasticsearch/index-settings/slow-log.md). For more information about the location of your {{es}} logs, see the [path.logs](../../deploy/self-managed/important-settings-configuration.md#path-settings) setting.
 
     ::::{important}
     If there are both structured (`*.json`) and unstructured (plain text) versions of the logs, you must use the structured logs. Otherwise, they might not appear in the appropriate context in {{kib}}.

@@ -181,7 +181,7 @@ When shipping logs to a monitoring deployment there are more logging features av
 
 #### For {{es}}: [ece-extra-logging-features-elasticsearch]
 
-* [Audit logging](../logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
+* [Audit logging](../../security/logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
 * [Slow query and index logging](elasticsearch://reference/elasticsearch/index-settings/slow-log.md) - helps find and debug slow queries and indexing
 * Verbose logging - helps debug stack issues by increasing component logs
 
@@ -190,7 +190,7 @@ After you’ve enabled log delivery on your deployment, you can [add the Elastic
 
 #### For Kibana: [ece-extra-logging-features-kibana]
 
-* [Audit logging](../logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
+* [Audit logging](../../security/logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
 
 After you’ve enabled log delivery on your deployment, you can [add the Kibana user settings](../../deploy/cloud-enterprise/edit-stack-settings.md) to enable this feature.
 

@@ -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]
-Original file line number
+Diff line change
@@ Expand Up @@
     ::::
-    For a full description of each `CustomResourceDefinition` (CRD), refer to the [*API Reference*](asciidocalypse://docs/cloud-on-k8s/docs/reference/k8s-api-reference.md) or view the CRD files in the [project repository](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/crds). You can also retrieve information about a CRD from the cluster. For example, describe the {{es}} CRD specification with [`describe`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_describe/):
+    For a full description of each `CustomResourceDefinition` (CRD), refer to the [*API Reference*](cloud-on-k8s://reference/api-docs.md) or view the CRD files in the [project repository](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/crds). You can also retrieve information about a CRD from the cluster. For example, describe the {{es}} CRD specification with [`describe`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_describe/):
     ```sh
     kubectl describe crd elasticsearch
@@ Expand Down @@