This is an old revision of the document!
This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)
These notes are for upgrading from Zabbix 3.0.x to Zabbix 3.2.0.
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 logic of delaying problem notifications during host maintenance has been changed.
In previous Zabbix versions, problem notifications during a host maintenance period were “suppressed” if you were using the Maintenance status = not in “maintenance” action condition. In the new version, the old mechanism is dropped. Instead there is an new Pause operations while in maintenance option in action configuration, which allows to pause notifications in the host maintenance phase if you wish so.
To ensure that escalations using this functionality work properly after the upgrade you must reconfigure the relevant actions by:
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.
The history_text.id and history_log.id fields will be removed from the corresponding history tables during database upgrade. Depending on history table size this process can be slow.
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:
syncing trends data... -> syncing trend data... syncing trends data done -> syncing trend data done
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.