Table of Contents
- 10 Upgrade notes for 3.2.0
- Critical
- Informational
- See also
10 Upgrade notes for 3.2.0
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 functionalityInformational- 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.
Critical
Database upgrade
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.
Case-sensitive MySQL database
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.
Informational
Escalation changes
Delaying escalations during maintenance
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:
- removing the Maintenance status = not in "maintenance" condition
- making sure that Pause operations while in maintenance is selected in action configuration
Parallel escalation for each of multiple PROBLEM events
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
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:
- Recovery messages are moved to recovery operations;
- All trigger-based and internal actions having 'Or' or 'Custom expression' calculation type are disabled;
- Trigger-based actions that could handle both PROBLEM and OK events are disabled;
- Trigger-based actions that could handle OK events only, but have a recovery message or more than one escalation step are disabled;
- Internal actions that could handle any other event except those corresponding a single Item in “not supported” state, Low-level discovery rule in “not supported” state or Trigger in “unknown” state condition are disabled;
- "Trigger value" conditions for trigger events and "Event type" conditions for internal events - Item in “normal” state, Low-level discovery rule in “normal” state, Trigger in “normal” state are removed from the conditions - they are not supported any more.
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.
IBM DB2 connection encoding
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.
Host availability, discovery, auto-registration and history data validation
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.
Miscellaneous
- The customizable time period for displaying resolved problems/OK triggers and for blinking upon trigger status change has been limited to 86400 seconds (24 hours) in Administration → General → Trigger displaying options.
Logging changes
The messages printed to the log files about completion of the trend data synchronization have been changed.
The following messages were changed:
Item changes
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.
Changes in evaluating trigger and calculated item expressions
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.:
- '1 or Unsuported_item1.some_function()' is now evaluated to '1' (True)
- '0 and Unsuported_item1.some_function()' is now evaluated to '0' (False)
Additionally nodata(), date(), dayofmonth(), dayofweek(), now() and time() trigger functions are now calculated for unsupported items as well.
See Expressions with unsupported items and unknown values.
Changes in graphs after item data type is changed
When item property "Type of information" is changed, previous history and trend data will not be displayed in graphs.