These notes are for upgrading from Zabbix 5.4.x to Zabbix 6.0.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 6.0.0 from versions before Zabbix 5.4.0. See the upgrade procedure section for all relevant information about upgrading from previous Zabbix versions.
To create the optimal user experience and ensure the best Zabbix performance in various production environments, the support of some older database releases has been dropped. This primarily applies to the database versions that are nearing their end of service life point and versions with unfixed issues that may interfere with normal performance.
Starting from Zabbix 6.0, the following database versions are officially supported:
By default, Zabbix server and proxy will not start if an unsupported database version is detected. It is now possible, though not recommended, to turn off DB version check by modifying AllowUnsupportedDBVersions configuration parameter for the server or proxy.
Primary keys are now used for all tables, including history tables, in new installations.
There is no automatic upgrade to primary keys for existing installations. Instructions for a manual upgrade of history tables to primary keys in pre-existing installations are available for MySQL/MariaDB, PostgreSQL, TimescaleDB v1 and v2, and Oracle.
Support for PCRE2 has been added. PCRE is still supported, but Zabbix can only be compiled with one of the libraries PCRE or PCRE2, both cannot be used at the same time.
The following Zabbix installation packages have been updated and now use PCRE2: - RHEL 7 and newer - SLES (all versions) - Debian 9 and newer - Ubuntu 16.04 and newer
Please note that after switching to PCRE2, you may need to update some regular expressions. In particular, the pattern
^[\w-\.] needs to be changed to
^[-\\w\\.] to continue working correctly - see Known issues for a more detailed explanation.
ODBC checks processing is now performed by separate server/proxy processes odbc pollers. Previously, ODBC checks were performed by regular pollers, which also work with Zabbix agent items, SSH checks, etc.
A new configuration parameter StartODBCPollers has been added to Zabbix server and proxy configuration files with the default value 1. This parameter may need to be adjusted based on the number of ODBC checks performed by the server or proxy. You may also want to reduce the number of regular pollers set by the StartPollers parameter accordingly.
Internal item zabbix[process,<type>] can be used to monitor ODBC pollers load.
In order to improve audit logging in Zabbix and make the Audit log complete and reliable, the previously existing database structure had to be reworked. During an upgrade DB tables
auditlog_details will be replaced by the new table
auditlog with a different format. Old audit records will not be preserved.
New section Audit log has been added to the Administration→General menu allowing to enable (default) or disable audit logging. Housekeeping settings for audit, previously located under the Housekeeper menu section, have also been moved to the new Audit log section. Existing housekeeping settings will be saved.
See the list of API changes in Zabbix 6.0.0.
The Overview section in the Monitoring menu has been removed completely. The same functionality can be still accessed by using the Data overview and Trigger overview dashboard widgets.
The possibility to change dependencies for triggers inherited from a template is now disabled. The reason is that upon updating the dependencies of a template trigger, the dependencies of inherited triggers are overwritten. Thus it is more reliable always to set trigger dependencies only on the root template level.
The support for positional macros in item name ($1, $2...$9), deprecated since Zabbix 4.0, has been fully removed.
The support for user macros in item names (including discovery rule names), deprecated since Zabbix 4.0, has been fully removed.
The functionality of simple macros has been transferred to expression macros. The existing simple macros will be converted to expression macros during the upgrade. Macros that can not be converted without exceeding the length limit will not be converted with a warning printed in the log file.
The following internal items are now deprecated and will be removed in a future major release:
Each Zabbix agent 2 plugin now has a separate configuration file. By default, these files are located in the
./zabbix_agent2.d/plugins.d/ directory. The path is specified in the
Include parameter of the agent 2 configuration file and can be relative to the zabbix_agent2.conf or zabbix_agent2.win.conf file location.
Previously, spaces in user passwords have been automatically trimmed in both the User configuration form and the Login form. After the introduction of configurable password complexity requirements, spaces in passwords are no longer trimmed. So users, who thought that they had spaces in their passwords, will not be able to log in as usual and will have to enter their 'old' password without spaces. To continue using passwords with spaces, they will need to recreate their passwords.
As bulk processing of dependent items has been introduced in the preprocessing queue for Prometheus metrics, dependent items will no longer be processed in parallel and that may have an affect on how fast they are processed.
Zabbix server and proxy runtime commands are now sent via socket instead of Unix signals. This change allows to improve user experience working with runtime control options:
It is no longer possible to add custom graphs to favorites in Monitoring -> Hosts -> Graphs. After the upgrade any existing custom graphs will be removed from favorites.
Several major updates related to service monitoring functionality have been made. An existing service tree configuration will be changed during an upgrade in the following way:
Trigger-based dependencies between problems and services are replaced by tag-based mapping of services to problems. Triggers that have been linked to a service will get a new tag
<trigger ID>:<trigger name> (tag value will be truncated to 32 characters). Linked services will get the same problem tag.
Hard and soft dependencies no longer exist. Instead, a service will have multiple parent services.
The 'Status calculation algorithm' will be upgraded using the following rules:
SLA is no longer a service attribute, but a separate entity which can be assigned to multiple services. During an upgrade, identical SLAs will be grouped and one SLA per each group will be created. Services will get a new service tag
<ID> for matching.