diff --git a/docs/en/install-upgrade/upgrade-on-ece.asciidoc b/docs/en/install-upgrade/upgrade-on-ece.asciidoc index 14b719846..c6aaba002 100644 --- a/docs/en/install-upgrade/upgrade-on-ece.asciidoc +++ b/docs/en/install-upgrade/upgrade-on-ece.asciidoc @@ -42,5 +42,6 @@ After you're done upgrading, upgrade your ingest components in the following ord . {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] . {beats}: {beats-ref}/upgrading.html[upgrade instructions] . {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions] -. {apm-agent}s: {observability-guide}/apm-upgrade.html[upgrade instructions] +. {apm-agents-ref}/index.html[{apm-agent}s] +. Custom clients diff --git a/docs/en/install-upgrade/upgrade-on-eck.asciidoc b/docs/en/install-upgrade/upgrade-on-eck.asciidoc index 310d3e196..69e1b240f 100644 --- a/docs/en/install-upgrade/upgrade-on-eck.asciidoc +++ b/docs/en/install-upgrade/upgrade-on-eck.asciidoc @@ -140,4 +140,5 @@ Next, upgrade your ingest components in the following order: . {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] . {beats}: {beats-ref}/upgrading.html[upgrade instructions] . {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions] -. {apm-agent}s: {observability-guide}/apm-upgrade.html[upgrade instructions] \ No newline at end of file +. {apm-agents-ref}/index.html[{apm-agent}s] +. Custom clients \ No newline at end of file diff --git a/docs/en/install-upgrade/upgrading-stack-cloud.asciidoc b/docs/en/install-upgrade/upgrading-stack-cloud.asciidoc index 448a34e92..a1f31ccf5 100644 --- a/docs/en/install-upgrade/upgrading-stack-cloud.asciidoc +++ b/docs/en/install-upgrade/upgrading-stack-cloud.asciidoc @@ -111,4 +111,5 @@ Once you have upgraded from 8.18, you need to update your ingest components in t . {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] . {beats}: {beats-ref}/upgrading.html[upgrade instructions] . {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions] -. {apm-agent}s: {observability-guide}/apm-upgrade.html[upgrade instructions] \ No newline at end of file +. {apm-agents-ref}/index.html[{apm-agent}s] +. Custom clients \ No newline at end of file diff --git a/docs/en/install-upgrade/upgrading-stack-on-prem.asciidoc b/docs/en/install-upgrade/upgrading-stack-on-prem.asciidoc index 883a1144c..a5f6d4598 100644 --- a/docs/en/install-upgrade/upgrading-stack-on-prem.asciidoc +++ b/docs/en/install-upgrade/upgrading-stack-on-prem.asciidoc @@ -1,28 +1,24 @@ [[upgrading-elastic-stack-on-prem]] == Upgrade Elastic on self-managed infrastructure -When you are <>, +Once you're <>, you will need to upgrade each of your Elastic components individually. -. Consider closing {ml} jobs before you start the upgrade process. While {ml} -jobs can continue to run during a rolling upgrade, it increases the overhead -on the cluster during the upgrade process. - -. Upgrade the components of your {stack} in this order: -+ +Upgrade the components of your {stack} in this order: //.. {es} Hadoop: {hadoop-ref}/install.html[install instructions] -.. {es}: <> -.. {kib}: <> +. {es}: <> +. {kib}: <> //.. Java API Client: {java-api-client}/installation.html#maven[dependency configuration] -.. {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] (See note below) -.. {beats}: {beats-ref}/upgrading.html[upgrade instructions] -.. {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions] -.. {apm-agent}s {observability-guide}/apm-upgrade.html[upgrade instructions] +. {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] (See note below) +. {beats}: {beats-ref}/upgrading.html[upgrade instructions] +. {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions] +. {apm-agents-ref}/index.html[{apm-agent}s] +. Custom clients [NOTE] -- If you are using {ls} and the {logstash-ref}/plugins-filters-elastic_integration.html[`logstash-filter-elastic_integration`] plugin to extend Elastic integrations, upgrade {ls} (or the `logstash-filter-elastic_integration` plugin specifically) _before_ you upgrade {kib}. -The {es}-{ls}-{kib} installation order for this specific plugin ensures the best experience with {agent}-managed pipelines, and embeds functionality from a version of {es} Ingest Node that is compatible with the plugin version (`major`.`minor`). +The {es} -> {ls} -> {kib} installation order for this specific plugin ensures the best experience with {agent}-managed pipelines, and embeds functionality from a version of {es} Ingest Node that is compatible with the plugin version (`major`.`minor`). -- diff --git a/docs/en/install-upgrade/upgrading-stack.asciidoc b/docs/en/install-upgrade/upgrading-stack.asciidoc index 38d75c64d..3b06dbcc7 100644 --- a/docs/en/install-upgrade/upgrading-stack.asciidoc +++ b/docs/en/install-upgrade/upgrading-stack.asciidoc @@ -76,10 +76,10 @@ If you’re running the {stack} on your own self-managed infrastructure, you’l Before you upgrade to {version}, it's important to take some preparation steps. Unless noted, these following recommendations are best practices regardless of deployment method. -IMPORTANT: Upgrading from a release candidate build, such as 9.0.0-rc1 or 9.0.0-rc2, is not supported. Pre-releases should only be used for testing in a temporary environment. +IMPORTANT: Upgrading from a release candidate build, such as 9.0.0-rc1, is not supported. Pre-releases should only be used for testing in a temporary environment. To upgrade to {version} from 8.17 or earlier, **you must first upgrade to the latest patch version of 8.18**. This enables you to use the **Upgrade Assistant** to identify and resolve issues, -reindex indices created before 8.0, and then perform a rolling upgrade. +reindex indices created before 8.0 or mark them as read-only, and perform a rolling upgrade. *Upgrading to 8.18 before upgrading to {version} is required even if you opt to do a full-cluster restart of your {es} cluster.* @@ -87,7 +87,7 @@ even if you opt to do a full-cluster restart of your {es} cluster.* Alternatively, you can create a new {version} deployment and reindex from remote. For more information, refer to <>. -{beats} and {ls} 8.17 are compatible with {es} {version} +{beats} and {ls} 8.18 are compatible with {es} {version} to give you flexibility in scheduling the upgrade. .Remote cluster compatibility @@ -130,10 +130,13 @@ For more information, see {ref}/rest-api-compatibility.html[REST API compatibili IMPORTANT: You cannot downgrade {es} nodes after upgrading. If you cannot complete the upgrade process, you will need to {ref}/snapshots-restore-snapshot.html[restore from the snapshot]. + . If you use a separate {ref}/monitoring-production.html[monitoring cluster], you should upgrade the monitoring cluster before the production cluster. In general, the monitoring cluster and the clusters being monitored should be running the same version of the stack. A monitoring cluster cannot monitor production clusters running newer versions of the stack. If necessary, the monitoring cluster can monitor production clusters running the latest release of the previous major version. +. To reduce overhead on the cluster during the upgrade, close {ml} jobs. Although {ml} jobs can run during a rolling upgrade, doing so increases the cluster workload. +. If you have `.ml-anomalies-*` anomaly detection result indices created in Elasticsearch 7.x, reindex, mark as read-only, or delete them before you upgrade to {version}. For more information, refer to <>. +. If you have transform destination indices created in Elasticsearch 7.x, reset, reindex, or delete them before you upgrade to {version}. For more information, refer to <>. [discrete] [[anomaly-detection-results-migration]] -=== Anomaly detection results migration +=== Migrate anomaly detection results The {anomaly-detect} result indices `.ml-anomalies-*` created in {es} 7.x must be either reindexed, marked read-only, or deleted before upgrading to 9.x. @@ -464,7 +467,7 @@ The {transform} destination indices created in {es} 7.x must be either reset, re **Reindexing**: You can reindex the destination index and then update the {transform} to write to the new destination index. This is useful if there are results that you want to retain that may not exist in the source index. To prevent the {transform} and reindex tasks from conflicting with one another, you can either pause the {transform} while the reindex runs, or you can write to the new destination index while the reindex backfills old results. -**Deleting**: You can delete any {transform} that are no longer being used. Once the {transform} is deleted, you can either delete the destination index or make it read-only. +**Deleting**: You can delete any {transforms} that are no longer being used. Once the {transform} is deleted, you can either delete the destination index or make it read-only. .Which indices require attention? [%collapsible]