Merge branch 'main' into best-practices-ingest-pipelines

Author: philippkahr

deploy-manage/cloud-organization/billing/billing-faq.md

@@ -17,8 +17,8 @@ This frequently-asked-questions list answers some of your more common questions
 
 * [Is there a way for me to estimate how much {{ecloud}} will cost?](#faq-cost)
 * [Where can I find a detailed view of my consumption?](#faq-consumption)
-* [How do I view previous receipts and billing history?](#faq-history)
-* [How can I change who receives receipts and billing notifications?](#faq-notify)
+* [How do I view previous invoices, statements, and billing history?](#faq-history)
+* [How can I change who receives invoices, statements, and billing notifications?](#faq-notify)
 * [What are the available payment methods on {{ecloud}}?](#faq-payment)
 * [Who can I contact for more information?](#faq-contact)
 * [Why is my credit card charged?](#faq-charge)
@@ -61,17 +61,17 @@ $$$faq-consumption$$$Where can I find a detailed view of my consumption?
     Additionally, on the {{ecloud}} [Usage](https://cloud.elastic.co/billing/usage?page=docs&placement=docs-body) page, the **Month-to-date usage** tile shows accrued costs and can help you to better estimate the next charge amount.
 
 
-$$$faq-history$$$How do I view previous receipts and billing history?
-:   Check the [billing history](https://cloud.elastic.co/billing/history?page=docs&placement=docs-body), where you can view and download receipts for all previous charges.
+$$$faq-history$$$How do I view previous invoices, statements, and billing history?
+:   Check the [billing history](https://cloud.elastic.co/billing/history?page=docs&placement=docs-body), where you can view and download invoices for all previous charges.
 
-$$$faq-notify$$$How can I change who receives receipts and billing notifications?
-:   The account owner can change who receives receipts and billing notifications by changing the [email details](https://cloud.elastic.co/account/contacts?page=docs&placement=docs-body).
+$$$faq-notify$$$How can I change who receives invoices, statements, and billing notifications?
+:   The account owner can change who receives invoices and billing notifications by changing the [email details](https://cloud.elastic.co/account/contacts?page=docs&placement=docs-body).
 
 $$$faq-payment$$$What are the available payment methods on {{ecloud}}?
 :   For month-to-month payments only credit cards are accepted. We also allow payments by bank transfer for annual subscriptions.
 
 $$$faq-contact$$$Who can I contact for more information?
-:   If you have any further questions about your credit card statement, billing, or receipts, send an email to `[email protected]` or open a [Support case](../../../troubleshoot/index.md) using the *Billing issue* category.
+:   If you have any further questions about your credit card statement, billing, or invoices, send an email to `[email protected]` or open a [Support case](../../../troubleshoot/index.md) using the *Billing issue* category.
 
 $$$faq-charge$$$Why is my credit card charged?
 :   If you are on a monthly plan, the charge is a recurring fee for using {{ecloud}}. The fee is normally charged at the start of each month, but it can also be charged at other times during the month. If a charge is unsuccessful, we will try to charge your card again at a later date.

deploy-manage/cloud-organization/billing/view-billing-history.md

@@ -13,7 +13,7 @@ products:
 
 # View your billing history [ec-billing-history]
 
-Information about outstanding payments and billing receipts is available from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+Information about outstanding payments, statements, and billing invoices is available from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
 
 To check your billing history:
 

deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md

@@ -39,8 +39,11 @@ When a deployment encrypted with a customer-managed key is deleted or terminated
 ## Prerequisites [ec_prerequisites_3]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 * Have permissions on AWS KMS to [create a symmetric AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks) and to configure AWS IAM roles.
 
   :::{tip}
@@ -51,6 +54,8 @@ When a deployment encrypted with a customer-managed key is deleted or terminated
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 * Have the following permissions on Azure:
 
     * Permissions to [create an RSA key](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#key-types-and-protection-methods) in the Azure Key Vault where you want to store your key.
@@ -67,6 +72,8 @@ When a deployment encrypted with a customer-managed key is deleted or terminated
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 * Consider the cloud regions where you need your deployment to live. Refer to the [list of available regions, deployment templates, and instance configurations](cloud://reference/cloud-hosted/ec-regions-templates-instances.md) supported by {{ecloud}}.
 * Have the following permissions in Google Cloud KMS:
 
@@ -93,8 +100,11 @@ At this time, the following features are not supported:
 ## Create an encryption key for your deployment [create-encryption-key]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 1. Create a symmetric [single-region key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) or [multi-region replica key](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-replicate.html). The key must be available in each region in which you have deployments to encrypt. You can use the same key to encrypt multiple deployments. Later, you will need to provide the Amazon Resource Name (ARN) of that key or key alias to {{ecloud}}.
 
     ::::{note}
@@ -135,6 +145,8 @@ At this time, the following features are not supported:
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 1. Create an RSA key in your Key Vault. The key must be available in each region in which you have deployments to encrypt. You can use the same key to encrypt multiple deployments.
 2. After the key is created, view the key and note the key identifier. It should look similar to the following:
 
@@ -150,6 +162,8 @@ Provide your key identifier without the key version identifier so {{ecloud}} can
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 1. [Create a new symmetric key](https://cloud.google.com/kms/docs/create-key) in Google Cloud KMS.
 
     The key must be in a key ring that’s in the same region as your deployment. Do not use key ring in a multi-region location.
@@ -166,8 +180,11 @@ Provide your key identifier without the key version identifier so {{ecloud}} can
 ## Create a deployment encrypted with your key [ec_create_a_deployment_encrypted_with_your_key]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 1. Create a new deployment. You can do it from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body), or from the API:
 
     * from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body):
@@ -211,6 +228,8 @@ The deployment is now created and encrypted using the specified key. Future snap
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 To create a new deployment with a customer-managed key in Azure, you need to perform actions in {{ecloud}} and in your Azure tenant.
 
 **Step 1: Create a service principal for {{ecloud}}**
@@ -285,6 +304,8 @@ The deployment is now created and encrypted using the specified key. Future snap
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 **Step 1: Grant service principals access to your key**
 
 {{ecloud}} uses two service principals to encrypt and decrypt data using your key. You must grant these services access to your key before you create your deployment.
@@ -313,9 +334,19 @@ The deployment is now created and encrypted using the specified key. Future snap
         * `cloudkms.cryptoKeyVersions.useToEncrypt`
 
 
-::::{tip}
-The user performing this action needs to belong to the **Owner** or **Cloud KMS Admin** role.
-::::
+    The user performing this action needs to belong to the **Owner** or **Cloud KMS Admin** role.
+
+
+    ::::{note}
+    If [domain restricted sharing](https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains) is enabled, then you might not be able to grant the service principals access to the key resource directly. Alternatively, you can grant access to a Google group that contains the relevant service accounts.
+
+    1. Create a new Google group within the allowed domain.
+    2. In the Google Workspace administrator panel, [turn off domain restriction for your newly created Google group](https://support.google.com/a/answer/167097).
+    3. Add the service principals to the Google group.
+    4. Grant the Google group the roles as listed.
+    
+    If you can't use Google Groups for your org, then [contact Elastic Support](https://www.elastic.co/support) for alternatives. 
+    ::::
 
 
 **Step 2: Create your deployment**
@@ -370,14 +401,19 @@ You can check that your hosted deployment is correctly encrypted with the key yo
 ## Rotate a customer-managed key [rotate-a-customer-managed-key]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 {{ecloud}} will automatically rotate the keys every 31 days as a security best practice.
 
 You can also trigger a manual rotation [in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html), which will take effect in {{ecloud}} within 30 minutes. **For manual rotations to work, you must use an alias when creating the deployment. We do not currently support [on-demand rotations](https://docs.aws.amazon.com/kms/latest/APIReference/API_RotateKeyOnDemand.html) but plan on supporting this in the future.**
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 To rotate your key, you can [update your key version](https://learn.microsoft.com/en-us/azure/container-registry/tutorial-rotate-revoke-customer-managed-keys) or [configure a key rotation policy](https://learn.microsoft.com/en-us/azure/key-vault/keys/how-to-configure-key-rotation) in Azure Key Vault. In both cases, the rotation will take effect in {{ecloud}} within a day.
 
 For rotations to work, you must provide your key identifier without the key version identifier when you create your deployment.
@@ -386,6 +422,8 @@ For rotations to work, you must provide your key identifier without the key vers
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 Key rotations are triggered in Google Cloud. You can rotate your key [manually](https://cloud.google.com/kms/docs/rotate-key#manual) or [automatically](https://cloud.google.com/kms/docs/rotate-key#automatic). In both cases, the rotation will take effect in {{ecloud}} within a day.
 ::::::
 

explore-analyze/alerts-cases/alerts/view-alerts.md

@@ -47,24 +47,38 @@ To get more information about a specific alert, open its action menu (…) and s
 
 If an alert is affected by a maintenance window, the alert details include its identifier. For more information about their impact on alert notifications, refer to [*Maintenance windows*](maintenance-windows.md).
 
-### Alert statuses [alert-status]
+## Alert statuses [alert-status]
 
-There are three common alert statuses:
+There are four common alert statuses:
 
 `active`
-:   The conditions for the rule are met and actions should be generated according to the notification settings.
+:   The conditions for the rule are met. If the rule has [actions](create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. 
 
-`recovered`
-:   The conditions for the rule are no longer met and recovery actions should be generated.
+`flapping`
 
-`untracked`
-:   Actions are no longer generated. For example, you can choose to move active alerts to this state when you disable or delete rules.
+:   The alert is switching repeatedly between active and recovered states. If the rule has actions that run when the alert status changes states, those actions are suppressed while the alert is flapping.
 
-::::{note}
-An alert can also be in a "flapping" state when it is switching repeatedly between active and recovered states. This state is possible only if you have enabled alert flapping detection in **{{stack-manage-app}} > {{rules-ui}} > Settings**. For each space, you can choose a look back window and threshold that are used to determine whether alerts are flapping. For example, you can specify that the alert must change status at least 6 times in the last 10 runs. If the rule has actions that run when the alert status changes, those actions are suppressed while the alert is flapping.
+::::{note}  
+
+Alert flapping is turned on by default. You can modify the criteria for changing an alert's status to the flapping state by configuring the **Alert flapping detection** settings. To do this, navigate to the **Alerts** page in the main menu, or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). Next, click **Manage Rules**, then **Settings** to open the global rule settings for the space. In the **Alert flapping detection** section, modify the rules' look back window and threshold for alert status changes. For example, you can specify that the alert must change its status at least 6 times in the last 10 runs for it to become a flapping alert. 
 
 ::::
 
+`recovered`
+:   The conditions for the rule are no longer met. If the rule has [recovery actions](create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one. 
+
+
+    An active alert changes to recovered if the conditions for the rule that generated it are no longer met. 
+
+    A flapping alert changes to recovered when the rule's conditions are unmet for a specific number of consecutive runs. This number is determined by the **Alert status change threshold** setting, which you can configure under the **Alert flapping detection** settings.
+
+    For example, if the threshold requires an alert to change status at least 6 times in the last 10 runs to be considered flapping, then to recover, the rule's conditions must remain unmet for 6 consecutive runs. If the rule's conditions are met at any point during this recovery period, the count of consecutive unmet runs will reset, requiring the alert to remain unmet for an additional 6 consecutive runs to finally be reported as recovered.
+
+    Once a flapping alert is recovered, it cannot be changed to flapping again. Only new alerts with repeated status changes are candidates for the flapping status. 
+
+`untracked`
+:   The rule is disabled, or you’ve marked the alert as untracked. To mark the alert as untracked, go to the **Alerts** table, click the {icon}`boxes_horizontal` icon to expand the **More actions** menu, and click **Mark as untracked**. When an alert is marked as untracked, actions are no longer generated. You can choose to move active alerts to this state when you disable or delete rules.
+
 ## Mute alerts [mute-alerts]
 
 If an alert is active or flapping, you can mute it to temporarily suppress future actions. In both **{{stack-manage-app}} > Alerts** and **{{rules-ui}}**, you can open the action menu (…) for the appropriate alert and select **Mute**. To permanently suppress actions for an alert, open the actions menu and select **Mark as untracked**.

extend/contribute/api-docs/organize-annotate.md

@@ -304,6 +304,11 @@ class FooRequest {
 
 This example shows the "later addition" scenario where `laterAddition` was added after the initial API release, requiring a parameter-level availability annotation with a later version than the API-level availability.
 
+:::::{important}
+The `since` field is only available for `stack`. If the API is introduced in multiple major versions (eg: `8.19.0` and `9.1.0`), use the appropriate value in each branch.
+:::::
+
+
 **Deprecation notices** use the `@deprecated` annotation:
 
 ```ts
@@ -449,4 +454,4 @@ The annotation system doesn't support "OR" relationships between privileges. Whe
 :::
 :::
 
-::::
+::::

manage-data/migrate.md

@@ -126,18 +126,23 @@ Restoring from a snapshot is often the fastest and most reliable way to migrate
 
 System indices can be restored by including their corresponding [feature states](/deploy-manage/tools/snapshot-and-restore.md#feature-state) in the restore operation, allowing you to retain internal configurations related to security, {{kib}}, or other stack features.
 
-This method is especially useful when you want to fully replicate the source cluster or when remote reindexing is not possible, for example if the source cluster is in a degraded or unreachable state.
+This method is especially useful when:
 
-To use this method, the new cluster must have access to the snapshot repository that contains the data from the old cluster. Also ensure that both clusters use [compatible versions](/deploy-manage/tools/snapshot-and-restore.md#snapshot-compatibility).
+* You want to fully replicate the source cluster or when remote reindexing is not possible, for example if the source cluster is in a degraded or unreachable state. 
+* Your old cluster contains mostly static data, allowing you to snapshot the source cluster, restore in the new cluster, and continue operations. 
 
-For more information, refer to [Restore into a different cluster](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#restore-different-cluster)
+When your source cluster is actively ingesting data, such as logs, metrics, or traces, and you need a seamless migration with minimal downtime, consider using the [minimal downtime migration](migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md).
+
+### Requirements [ec-restore-snapshots-requirements]
+* The new cluster must have access to the snapshot repository that contains the data from the old cluster.
+* Both clusters must use [compatible versions](/deploy-manage/tools/snapshot-and-restore.md#snapshot-compatibility).
+
+For more information, refer to [Restore into a different cluster](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#restore-different-cluster).
 
 ::::{note}
-For {{ece}} users, while it is most common to have Amazon S3 buckets, you should be able to restore from any addressable external storage that has your {{es}} snapshots.
+For {{ece}}, Amazon S3 us the most common snapshot storage, but you can restor from any accesible external storage that contains your {{es}} snapshots.
 ::::
 
-The following steps assume you already have a snapshot repository configured in the old cluster, with at least one valid snapshot containing the data you want to migrate.
-
 ### Step 1: Set up the repository in the new cluster [migrate-repo-setup]
 
 In this step, you’ll configure a snapshot repository in the new cluster that points to the storage location used by the old cluster. This allows the new cluster to access and restore snapshots created in the original environment.