Sidebar

manual:installation:upgrade_notes_540

10 Upgrade notes for 5.4.0

These notes are for upgrading from Zabbix 5.2.x to Zabbix 5.4.0. All notes are grouped into:

  • Critical - the most critical information related to the upgrade process and the changes in Zabbix functionality
  • Informational - all remaining information describing the changes in Zabbix functionality

It is possible to upgrade to Zabbix 5.4.0 from versions before Zabbix 5.2.0. See the upgrade procedure section for all relevant information about upgrading from previous Zabbix versions.

Critical

Supported database versions

To create the optimal user experience and ensure the best Zabbix performance in various production environments, support of some older database releases has been dropped. Additionally, an upper limit for the supported DB versions has been introduced for all databases. Though Zabbix may still work with newer releases, the maximum supported DB version indicates the latest version Zabbix has been tested with and provided stable performance.

See the list of changes in software requirements in the table below.

SoftwareBefore Zabbix 5.0Zabbix 5.0; 5.2Since Zabbix 5.4
MySQL/Percona 5.0.3 - 8.0.x 5.5.62 - 8.0.x 5.7.28 - 8.0.X
MariaDB 10.0.37 or later 10.0.37 or later 10.0.37 -10.5.X
PostgreSQL8.1.X or later 9.2.24 or later 10.9.X - 13.X.X
Oracle 10g or later 11.2 or later 12.1.0.2 - 19c
TimescaleDB 1.0 or later 1.0 or later 1.5 - 2.1
SQLite (proxy only) 3.3.5 or later 3.3.5 or later 3.3.5 - 3.34.X

See Software requirements page for additional information.

Central location for scripts

Global scripts are now the central place for maintaining scripts in Zabbix. All action operation scripts will no longer be maintained in actions.

Existing action operation scripts will be moved to global scripts during the database upgrade. In this process:

  • {HOST.*} macros from these scripts, designed to resolve on the basis of the trigger expression that caused the event, are replaced by a new set of {HOST.TARGET.*} macros, set to resolve to the parameters of the target host;
  • Identical scripts (same commands, username, password, public key, private key, type, port, authentication method, “Execute on”) are converted into a single global script. All such scripts receive a 'Script N' naming, where N is the incrementing counter (1,2,3,…). It is recommended to give these scripts better naming after the upgrade manually.

Existing global script names during the database upgrade will be stripped from their menu paths (if any). Menu paths are now stored as a separate field. As a result, the remaining script name (now without a menu path) has to be unique. In case of non-unique names, uniqueness is achieved by adding numerical suffixes.

New trigger syntax

Trigger expressions now support a new syntax aimed at resolving the known limitations of the former syntax. During the upgrade it will be attempted to convert all existing expressions to the new syntax.

Note that with the new syntax after the upgrade trigger synchronization to configuration cache may take slightly more time than before the upgrade.

Aggregate items removed as separate type

The new trigger syntax has also been unified between triggers, calculated items and aggregated items. As a result, it is no longer required to have a separate aggregate item type. Aggregate calculations are now possible in calculated items, thus aggregate items have been removed.

Informational

Dashboards have replaced screens/slideshows

The “old” functionality of screens and slideshows in Zabbix has been removed, based on the advances in the functionality of Zabbix dashboards.

During the upgrade, each existing screen will be converted into a dashboard and each slideshow into a multi-page dashboard. Note that dashboards have a limitation of 50 pages, therefore slideshows containing more slides will be truncated.

It is also no longer possible to import screens from previous versions into Zabbix. The screen import will be ignored.

Item tags have replaced "applications"

Applications, previously used as a means of grouping related items, have been replaced by item tagging. During the database upgrade:

  • Existing applications in items will be transformed into item tags in the format Application:<Application name> where Application is the tag name and <Application name> is the tag value based on the previous application name
  • Existing application prototypes in item prototypes will be transformed into item prototype tags in the format Application:<Application prototype name> where Application is the tag name and <Application prototype name> is the tag value based on the previous application prototype name
  • Applications without items will be dismissed

Scheduled PDF reports

Information from a dashboard can now be emailed as PDF reports, which can be scheduled to be automatically sent on a daily, weekly, monthly, or yearly basis.

Two new options have been added to user role permissions:

  • Scheduled reports - added to the Access to UI elements block; allows to view scheduled reports. During an upgrade this UI element will be automatically enabled for all Admin and Super admin level user roles with Default access to new UI elements option checked.
  • Manage scheduled reports - added to the Access to actions block; allows to create and edit scheduled reports. During an upgrade this action will be automatically enabled for all Admin and Super admin level user roles with Default access to new actions option checked.

A new Zabbix web service process should be installed to enable generation of scheduled reports. An official zabbix-web-service package is available for RHEL/CentOS 8, SLES 15, Debian 10, Ubuntu 18.04, Ubuntu 20.04 in the Zabbix repository. To compile Zabbix web service from sources, during the upgrade run the ./configure script with –enable-web-service option (see Installing Zabbix web service for additional details).

Value mapping on template/host level

As value mapping has been moved to template/host level, there is no global value mapping anymore. During the upgrade, all global value maps that are used in items will be copied to the respective template or host.

Host availability data

All data about host availability have been moved from the host level to the level of individual interfaces. During database upgrade all previous host availability data will be lost. New interface availability initially will be set to 'unknown' and then updated after some time.

Note that the server-proxy data exchange protocol has also been changed.

Direct connections to database removed from pollers

Calculated, aggregated and internal checks are now performed by the new history poller process. The StartHistoryPollers value should be increased if history pollers are too busy, but should be kept low if possible to avoid unnecessary connections to database.

New availability manager process has been introduced. All processes queue host availability updates to the availability manager and that queue is flushed by the availability manager to the database every 5 seconds.

You can monitor the new processes using the zabbix[process,<type>] internal item.

Naming in JavaScript objects

Naming in additional JavaScript objects has been changed.

Hidden PSK data for hosts and proxies

PSK identity and PSK fields in host and proxy configuration are now write-only. Once saved, these values cannot be viewed again in the frontend or retrieved through API but can be replaced with new values. For hosts, PSK identity and PSK will no longer be exported.

Deprecated macros

{USER.ALIAS} is now deprecated. Use the new macro {USER.USERNAME} instead.

See also: Supported macros

Template import

It is now possible to rename a template, change trigger expression, or update other template elements by importing an updated version of the template. Templates themselves and template elements such as items, triggers, discovery rules, dashboards, etc. have been assigned unique IDs.

During the upgrade all elements with the same unique identifiers (such as template name for a template, or item key for an item) will receive the same UUIDs across all installations. This is done to allow future updates of templates from the same source installations. The same UUIDs will be assigned to elements when importing templates from older versions.

After the upgrade, any element created on 5.4.0rc1 version or later will have a unique UUID assigned to it and these UUIDs will be different across the installations. Upon linkage of a template all elements, that become inherited will loose their UUIDs. Upon unlinkage without clear, all now independent elements will receive newly generated UUIDs.

API changes

See the list of API changes in Zabbix 5.4.0.