Upgrade Elastic Security to 8.15.0edit
Before you upgrade Elastic Security, take the necessary preparation steps, which will vary depending on what version you are upgrading to:
Rolling upgrades are unsupported in Elastic Security, which runs within the Kibana application. To upgrade, you must shut down all Kibana instances, install the new software, and restart Kibana. Upgrading while older Kibana instances are running can cause data loss or upgrade failures.
When required, Kibana automatically migrates saved objects.
In case of an upgrade failure, you can roll back to an
earlier version of Kibana. To roll back, you must have a
backup snapshot that includes the kibana feature
state. By default, snapshots include the kibana feature state.
Upgrading multiple Kibana instancesedit
When upgrading several Kibana instances connected to the same Elasticsearch cluster, ensure that all outdated instances are shut down before starting the upgrade.
Rolling upgrades are unsupported in Kibana. However, when outdated instances are shut down, you can start all upgraded instances in parallel, which allows all instances to participate in the upgrade migration in parallel.
For large deployments with more than 10 Kibana instances and more than 10,000 saved objects, you can reduce the upgrade downtime by bringing up a single Kibana instance and waiting for it to complete the upgrade migration before bringing up the remaining instances.
You can upgrade to pre-release versions for testing, but upgrading from a pre-release to the Generally Available version is unsupported. You should use pre-release versions only for testing in a temporary environment.
Support for Elastic prebuilt detection rule automatic updatesedit
Automatic updates of Elastic prebuilt detection rules are supported for the current Elastic Security version and the latest three previous minor releases. For example, if you’re upgrading to Elastic Security 8.10, you’ll be able to use the Rules UI to update your prebuilt rules until Elastic Security 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 Security version to receive automatic updates.
Preparing for migrationedit
Take these extra steps to ensure you are ready for migration.
Ensure your Elasticsearch cluster is healthyedit
Problems with your Elasticsearch cluster can prevent Kibana upgrades from succeeding.
During the upgrade process, Kibana creates new indices into which updated documents are written. If a cluster is approaching the low watermark, there’s a high risk of Kibana 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.
A healthy cluster has:
-
Enough free disk space, at least twice the amount of storage taken up by the
.kibanaand.kibana_task_managerindices - Sufficient heap size
- A "green" cluster status
Ensure that all Kibana instances are the sameedit
When you perform an upgrade migration of different Kibana versions, the migration can fail. Ensure that all Kibana instances are running the same version, configuration, and plugins.
Back up your dataedit
Be sure to have a snapshot of all your data before migrating, so that if something goes wrong during migration, you can restore from the snapshot and try again.
Review the common causes of Kibana upgrade failures and how to prevent them.
Upgrade from an earlier 8.x versionedit
-
Review the breaking changes for each product you use and make the necessary changes so your code is compatible with 8.15.0.
- If you use any Elasticsearch plugins, ensure each plugin has a version compatible with Elasticsearch version 8.15.0.
- Test the upgrade in an isolated environment before upgrading your production cluster.
-
Ensure you have a current snapshot before you start the upgrade.
You cannot downgrade Elasticsearch nodes after upgrading. If you cannot complete the upgrade process, you will need to restore from the snapshot.
- If you use a separate 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 Elastic 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.
Considerations when upgrading to 8.8edit
After you upgrade to 8.8 or later, frequency settings for 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).
Upgrade from 7.16 or earlier to an 8.x versionedit
To upgrade from 7.16.0 or earlier to 8.15.0, you must first upgrade your Elastic Stack and Elastic Agents to 7.17 (refer to Upgrade Fleet-managed Elastic Agents). This enables you to use the Upgrade Assistant to prepare for the upgrade. Before you upgrade, you must resolve all critical issues identified by the Upgrade Assistant. Afterwards, you can upgrade to 8.x.
Initially, Elastic Agents will be version 7.17. This is fine because Elastic Security 8.x supports the last minor release in 7.x (7.17) and any subsequent Elastic Endpoint versions in 8.x. After the Elastic Stack upgrade, you can decide whether to upgrade Elastic Agents to 8.x, which is recommended to ensure you get the latest features.
You do not need to shut down your Elastic Agents or endpoints to upgrade the Elastic Stack.