You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/upgrade/upgrade-7.17-8.x.asciidoc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -82,7 +82,7 @@ NOTE: If you're using Elastic Cloud Hosted or {ece}, this is already included in
82
82
... Ensure that the index and search rate are close to what they were before upgrading. Go to **Stack Monitoring** -> **{es}** -> **Overview**.
83
83
+
84
84
TIP: You can also check the index document count using the {ref}/cat-indices.html[cat index API].
85
-
... Verify that SLM is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history].
85
+
... Verify that {slm} SLM is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history].
86
86
... If you use {ml}, ensure that it is up and running.
87
87
.. For {kib}:
88
88
... Ensure that you and your users can successfully log in to {kib} and access desired pages.
@@ -92,11 +92,11 @@ TIP: You can also check the index document count using the {ref}/cat-indices.htm
92
92
93
93
. Upgrade your ingest components (such as {ls}, {fleet} and {agent}, {beats}, etc.). For details, refer to the {stack-ref}/upgrading-elastic-stack.html[Elastic Stack upgrade docs].
94
94
95
-
. Validate that Ingest is operating correctly.
95
+
. Validate that ingest is operating correctly.
96
96
.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume.
97
97
98
98
. Validate that {elastic-sec} is operating correctly.
99
-
.. Re-enable your desired SIEM detection rules (rule management), and ensure that enabled rules are running without errors or warnings (rule monitoring).
99
+
.. On the **Rules** page, re-enable your desired SIEM detection rules (**Rule Management** tab), and ensure that enabled rules are running without errors or warnings (**Rule Monitoring** tab).
100
100
.. Ensure that any SOAR workflows that consume alerts are working.
101
101
.. Verify that any custom dashboards your team has created are working properly, especially if they operate on alert documents.
Copy file name to clipboardExpand all lines: docs/upgrade/upgrade-security.asciidoc
+75-40Lines changed: 75 additions & 40 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,9 +2,9 @@
2
2
3
3
= Upgrade {elastic-sec} to {version}
4
4
5
-
Before you upgrade {elastic-sec}, take the necessary <<preventing-migration-failures, preparation steps>>, which will vary depending on what version you are upgrading to:
5
+
Before you upgrade {elastic-sec}, take the necessary preparation steps, which will vary depending on what version you are upgrading to:
6
6
7
-
* <<upgrade-8.x, Upgrade from an earlier 8.x version>>
7
+
* <<upgrade-8x-8x, Upgrade from an 8.x to an 8.x version>>
8
8
* <<upgrade-7.17-8x, Upgrade from 7.17 to an 8.x version>>
9
9
* <<upgrade-7.16-8.x, Upgrade from 7.16 or earlier to an 8.x version>>
10
10
@@ -21,7 +21,7 @@ state. By default, snapshots include the `kibana` feature state.
21
21
====
22
22
23
23
[float]
24
-
=== Upgrading multiple {kib} instances
24
+
== Upgrading multiple {kib} instances
25
25
When upgrading several {kib} instances connected to the same {es} cluster,
26
26
ensure that all outdated instances are shut down before starting the upgrade.
27
27
@@ -37,69 +37,104 @@ but upgrading from a pre-release to the Generally Available version is unsupport
37
37
You should use pre-release versions only for testing in a temporary environment.
38
38
39
39
[float]
40
-
=== Support for Elastic prebuilt detection rule automatic updates
40
+
=== Ensure that all {kib} instances are the same
41
+
When you perform an upgrade migration of different {kib} versions, the migration can fail.
42
+
Ensure that all {kib} instances are running the same version, configuration, and plugins.
43
+
44
+
[float]
45
+
== Support for Elastic prebuilt detection rule automatic updates
41
46
<<update-prebuilt-rules,Automatic updates of Elastic prebuilt detection rules>> are supported for the current {elastic-sec} version and the latest three previous minor releases. For example, if you’re upgrading to {elastic-sec} 8.10, you’ll be able to use the Rules UI to update your prebuilt rules until {elastic-sec} 8.14 is released. After that point, you can still manually download and install updated prebuilt rules, but you must upgrade to the latest {elastic-sec} version to receive automatic updates.
42
47
43
48
[float]
44
-
[[preventing-migration-failures]]
45
-
=== Preparing for migration
49
+
[[upgrade-8x-8x]]
50
+
== Upgrade from an 8.x to an 8.x version
46
51
47
-
Take these extra steps to ensure you are ready for migration.
52
+
Follow this guide to upgrade from an earlier 8.x version to a later 8.x version.
48
53
49
54
[float]
50
-
==== Ensure your {es} cluster is healthy
51
-
Problems with your {es} cluster can prevent {kib} upgrades from succeeding.
55
+
=== Plan for your upgrade
52
56
53
-
During the upgrade process, {kib} creates new indices into which updated documents are written. If a cluster is approaching the low watermark, there's a high risk of {kib} not being able to create these. Reading, transforming, and writing updated documents can be memory intensive, using more available heap than during routine operation. You must ensure that enough heap is available to prevent requests from timing out or throwing errors from circuit breaker exceptions. You should also ensure that all shards are replicated and assigned.
57
+
Before upgrading from an earlier 8.x version, consider the following recommendations:
54
58
55
-
A healthy cluster has:
59
+
* Plan for an appropriate amount of time to complete the upgrade. Depending on your configuration and the size of your cluster, the process can take up to a week to complete.
56
60
57
-
* Enough free disk space, at least twice the amount of storage taken up by the `.kibana` and `.kibana_task_manager` indices
58
-
* Sufficient heap size
59
-
* A "green" cluster status
61
+
* Open a https://support.elastic.co[support case] with Elastic to alert our Elastic Support team of your system change. If you need additional assistance, https://www.elastic.co/consulting[Elastic Consulting Services] provides the technical expertise and step-by-step approach for upgrading your Elastic deployment.
60
62
61
-
[float]
62
-
==== Ensure that all {kib} instances are the same
63
-
When you perform an upgrade migration of different {kib} versions, the migration can fail.
64
-
Ensure that all {kib} instances are running the same version, configuration, and plugins.
63
+
* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment.
64
+
65
+
* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate.
66
+
67
+
* Review your selected version's features, Elastic connectors, integrations, and detection rules to determine if you can replace any customized content with out-of-the-box functionality. This can help reduce your workload and the complexity of your upgrade.
68
+
69
+
* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}.
70
+
71
+
* Schedule a system maintenance window within your organization.
65
72
66
73
[float]
67
-
==== Back up your data
74
+
=== Pre-upgrade steps
68
75
69
-
Be sure to have a {ref}/snapshot-restore.html[snapshot] of all your data before migrating, so that if something goes wrong during migration, you can restore from the snapshot and try again.
76
+
To prepare for the upgrade process, follow these steps before you start:
70
77
71
-
Review the {kibana-ref}/resolve-migrations-failures.html[common causes of {kib} upgrade failures] and how to prevent them.
78
+
. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}.
72
79
80
+
. If you're not using {ref}/snapshots-take-snapshot.html#automate-snapshots-slm[{slm} (SLM)], you must set up and configure a policy, then run the policy to create at least one {ref}/snapshot-restore.html[snapshot]—a backup of indices taken from a running cluster. If you need to roll back during the upgrade process, use a recent snapshot to avoid data loss. Snapshots are {ref}/snapshot-restore.html#how-snapshots-work[incremental]—depending on the cluster size and the input/output rate, the initial snapshot may take several hours to complete. If you're using SLM, {ref}/snapshots-take-snapshot.html#check-slm-history[check the SLM history] to ensure that snapshots are completing successfully.
73
81
74
82
[float]
75
-
[[upgrade-8.x]]
76
-
== Upgrade from an earlier 8.x version
83
+
=== Perform an 8.x to 8.x upgrade on a deployment
77
84
78
-
. Review the breaking changes for each product you use and make the necessary changes so your code is compatible with {version}.
85
+
IMPORTANT: We strongly recommend performing the following steps on a non-production deployment first to address any potential issues before upgrading your production deployments. If you're using a cross-cluster search environment, upgrade your remote deployments first.
. If you use any {es} plugins, ensure each plugin has a version compatible with {es} version {version}.
87
+
. If you haven't already done so, back up your cluster data to a {ref}/snapshots-take-snapshot.html[snapshot].
88
88
89
-
. Test the upgrade in an isolated environment before upgrading your production
90
-
cluster.
89
+
. We recommend you <<rules-api-export, export all your custom detection rules>> in case there are issues with the detection engine after the upgrade.
91
90
92
-
. Ensure you have a current snapshot before you start the upgrade.
91
+
. Upgrade {es}.
92
+
** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions].
93
+
** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions].
94
+
** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions].
95
+
** If you're upgrading a self-orchestrated deployment, refer to {stack-ref}/upgrading-elasticsearch.html[these instructions] and upgrade the data nodes tier by tier in this order:
96
+
... Frozen tier
97
+
... Cold tier
98
+
... Warm tier
99
+
... Hot tier
100
+
... Any other nodes not in a tier
101
+
... All remaining nodes that are neither master-eligible nor data nodes
102
+
... Master-eligible nodes
103
+
104
+
. Upgrade {kib}. Refer to {stack-ref}/upgrading-kibana.html[these instructions].
93
105
+
94
-
IMPORTANT: You cannot downgrade {es} nodes after upgrading.
95
-
If you cannot complete the upgrade process,
96
-
you will need to restore from the snapshot.
106
+
NOTE: If you're using Elastic Cloud Hosted or {ece}, this is already included in the {es} upgrade.
107
+
108
+
. Validate that {es} and {kib} are operating as expected by completing the following checks:
109
+
.. For {es}:
110
+
... Check the status of your clusters and ensure that they're green by running a `GET _cat/health` API request. For more information, refer to the {ref}/cat-health.html[cat health API documentation].
111
+
... Ensure that the index and search rate are close to what they were before upgrading. Go to **Stack Monitoring** -> **{es}** -> **Overview**.
112
+
+
113
+
TIP: You can also check the index document count using the {ref}/cat-indices.html[cat index API].
114
+
... Verify that {slm} (SLM) is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history].
115
+
... If you use {ml}, ensure that it is up and running.
116
+
.. For {kib}:
117
+
... Ensure that you and your users can successfully log in to {kib} and access desired pages.
118
+
... Check {kibana-ref}/discover.html[Discover] and verify that the index patterns you typically use are available.
119
+
... Verify that your commonly used {kibana-ref}/dashboard.html[dashboards] are available and working properly.
120
+
... If you use any Watcher-based {kib} scheduled {kibana-ref}/reporting-getting-started.html[reporting], ensure that it's working properly.
121
+
122
+
. Upgrade your ingest components (such as {ls}, {fleet} and {agent}, {beats}, etc.). For details, refer to the {stack-ref}/upgrading-elastic-stack.html[Elastic Stack upgrade docs].
123
+
124
+
. Validate that ingest is operating correctly.
125
+
.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume.
126
+
127
+
. Validate that {elastic-sec} is operating correctly.
128
+
.. On the **Rules** page, re-enable your desired SIEM detection rules (**Rule Management** tab), and ensure that enabled rules are running without errors or warnings (**Rule Monitoring** tab).
129
+
.. Ensure that any SOAR workflows that consume alerts are working.
130
+
.. Verify that any custom dashboards your team has created are working properly, especially if they operate on alert documents.
97
131
98
-
. If you use a separate {ref}/monitoring-production.html[monitoring cluster], you should upgrade the monitoring cluster before the production cluster. Generally, the monitoring cluster and the clusters being monitored should be running the same {stack} version. A monitoring cluster cannot monitor production clusters running newer stack versions. If necessary, the monitoring cluster can monitor production clusters running the latest release of the previous major version.
132
+
. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments.
133
+
. Confirm with your appropriate stakeholders that the upgrade process has been successful.
99
134
100
135
[float]
101
136
[[upgrade-notes-8.8]]
102
-
=== Considerations when upgrading to 8.8
137
+
=== Considerations when upgrading to 8.8 or later
103
138
104
139
After you upgrade to 8.8 or later, frequency settings for <<rule-notifications,rule actions>> created in 8.7 or earlier are automatically moved from the rule level to the action level. The action schedules remain the same and will continue to run on their previously specified frequency (`On each rule execution`, `Hourly`, `Daily`, or `Weekly`).
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?v=4&size=40){kind=avatar}
0 commit comments