Kibana and Elasticsearch upgrade order: which component to upgrade first on a production cluster
0 reputation · 03 Jul 2024, 10:42 UTC
Upgrade sequencing decision
We run a Kibana instance connected to a self-managed Elasticsearch cluster, both currently on the same minor version of a recent 8.x release. Elastic's documentation states that Kibana and Elasticsearch are expected to run matching versions, with only narrow exceptions during rolling upgrades, and that Kibana newer than Elasticsearch is unsupported because of versioned saved-object metadata in the system indices.
That leaves an unresolved sequencing decision for our next minor upgrade. Upgrading Elasticsearch first means Kibana runs temporarily older than the cluster, which is described as transitional rather than a supported steady state. Upgrading Kibana first appears to risk startup compatibility-check failures or saved-object migration problems against the older cluster. Coordinating both at once implies a short full outage for dashboards.
Questions
- For a minor-version upgrade within the same major release, is Elasticsearch-first the documented and safer order, accepting a briefly older Kibana?
- What observable signals (startup logs, compatibility warnings, saved-object migration messages) should we treat as a hard stop versus a tolerable transitional warning?
- If Kibana migrates its saved objects and we must roll back, is there any supported path back to the older Kibana, given that snapshot/restore of the system indices across versions is not reliable?