These notes are for upgrading from Zabbix 3.0.x to Zabbix 3.2.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 3.2.0 from versions before Zabbix 3.0.0. See the upgrade procedure section for all relevant information about upgrading from previous Zabbix versions.
The history_text.id and history_log.id fields will be removed from the corresponding history tables during database upgrade. Depending on the history table size this process can be slow.
A case-sensitive MySQL database is required for proper server work. It is recommended to create a case-sensitive MySQL database during new installations. If you created a MySQL database with the utf8 character set previously, in order to support case sensitiveness of stored data, you need to convert the charset to utf8_bin.
The logic of delaying problem notifications during host maintenance has been changed.
In previous Zabbix versions, problem notifications during a host maintenance period were skipped if you were using the Maintenance status = not in "maintenance" action condition. In the new version, the old mechanism is dropped. Instead there is a new Pause operations while in maintenance option in action configuration, which allows to pause notifications during a maintenance if you wish so.
To ensure that escalations using this functionality work properly after the upgrade you must reconfigure the relevant actions by:
Before Zabbix 3.2 every new PROBLEM event would abort the escalation of an earlier PROBLEM event, i.e. only one active escalation could run for a trigger with multiple event generation. Now escalation procedures for all these events are processed in parallel. This change and newly introduced event correlation and event tags enable more flexible approach to multiple PROBLEM event resolution. For example, depending on configuration now OK event may either stop escalation for the particular PROBLEM event, for numerous events or for all of them.
Recovery operations are a new unified way of executing scripts or getting notified on resolved problems. Before the only way to execute a script when problem triggers went OK was to configure an action to start an escalation on the 'Trigger value = OK' condition. This is not supported any more - an action with recovery operations must be used instead.
During database upgrade actions with simple conditions are updated automatically while actions having complex conditions are disabled with a corresponding log message. The disabled actions must be updated manually.
The action upgrade steps performed automatically are:
After database upgrade Zabbix server log must be checked if there are any actions that must be updated manually. It's recommended to check also other actions.
Recovery operations also get a dedicated tab in the action configuration form, while the condition tab has been dropped and conditions now can be set in the general action property tab.
When connecting to IBM DB2 database Zabbix server, proxy and frontend will now ensure that database server anticipates UTF-8 encoded text. Previously the way IBM DB2 server interpreted text information from Zabbix was fully determined by Zabbix server/proxy or web server locale settings (LC_ALL, LANG, LC_CTYPE and other environment variables). If the latter were not configured properly text containing non-ASCII characters was saved in the database incorrectly. In such situations after upgrade non-ASCII characters will be displayed in Zabbix incorrectly. The problem could easily not manifest itself if locale was identically misconfigured for Zabbix server and for web server running Zabbix frontend and the number of non-ASCII characters was too low to cause "Value too long..." errors. Please check the database contents before upgrading.
When Zabbix server had received invalid host availability, discovery or auto-registration data it used to write a warning to the log file for every invalid entry. Now in the case of invalid entries it will reject the whole data packet and log a single line like proxy "<proxy name>" at "<proxy IP>" returned invalid host availability data[: <detailed error message>] (for passive proxies) or received invalid host availability data from proxy "<proxy name>" at "<proxy IP>": <detailed error message> (for active proxies). Also, if passive proxy for example returns invalid host availability data, server will skip polling discovery, history and auto-registration data from that proxy. Like before, Zabbix will try to process as much historical data from proxies and active agents as it can and will silently ignore invalid entries. If the whole packet is invalid a message containing name, IP address and error description will be logged. This will help tracking down misconfiguration issues when proxypoller connects server's trapper port or agent instead of proxy.
The messages printed to the log files about completion of the trend data synchronization have been changed.
The following messages were changed:
system.sw.os[name] item might have different value on Linux systems. Now the PRETTY_NAME parameter from /etc/os-release file is used by default. Only if os-release is not supported by the system the /etc/issue.net file is used to obtain system name.
Previously any unsupported item in trigger expression or error in function evaluation immediately rendered the whole expression value to Unknown.
In the new version unsupported items and errors in function evaluation continue to take part in expression evaluation as unknown values.
These unknown values may turn into "known" values in logical operations, e.g.:
Additionally nodata(), date(), dayofmonth(), dayofweek(), now() and time() trigger functions are now calculated for unsupported items as well.
When item property "Type of information" is changed, previous history and trend data will not be displayed in graphs.