Zabbix Documentation 2.2

• Minimum supported PHP version changed from 5.1.6 to 5.3.0
• Minimum supported MySQL version changed from 5.0.0 to 5.0.3
• Accepted data limit when using Zabbix protocol was changed from 128MB to 64MB.

There are no upgrade SQL scripts anymore - database upgrade is performed by the Zabbix server.

Zabbix now supports a signed 64-bit range for internal object IDs in a standalone, non-distributed setup. Thus the highest available number of one-type objects is 2⁶³ now.

Since Zabbix 2.2 “Read-write” permissions have precedence over “Read” permissions. Previously, if a user (through two different user groups) had both “Read” and “Read-write” permissions to a specific host, the host was only “Read” to them. Now it will be “Read-write”.

Previously, a maintenance period for every second/third/etc day would first occur on the second/third/etc day after the Active since day. Now the first occurence will take place on the Active since day and then every second/third/etc day.

EVENT.* macros, such as {EVENT.ID}, {EVENT.TIME}, {EVENT.DATE}, {EVENT.AGE}, {EVENT.ACK.HISTORY}, {EVENT.ACK.STATUS}, will behave differently in recovery notifications starting with Zabbix 2.2.

Previously, when used in recovery messages they would return information of the recovery event. In Zabbix 2.2 they will return information of the original problem event.

To return information about the recovery event, separate recovery (EVENT.RECOVERY.* ) macros are introduced - {EVENT.RECOVERY.ID}, {EVENT.RECOVERY.TIME}, etc. For more information see Macros supported by location.

The logic of displaying testing results of regular expressions has been improved. Results are shown after applying the condition, not before.

API version has been bumped to 2.2.0 and will match Zabbix version from now on.

The “mysqli” PHP extension is required instead of “mysql”.

Latest data page now sends data for all entries, including collapsed ones. This may considerably increase page size in some instances.

The DisableHousekeeping server configuration option is supported no more. Instead, finer controls are located in the frontend, in Administration → General → Housekeeper, allowing to selectively enable/disable housekeeping processes for specific tables.

Previously, slightly incorrect JSON might be accepted by the Zabbix server. Since Zabbix 2.2, syntax validation will be performed. If custom LLD rules have been used with incorrect JSON syntax, they might stop working. In such case custom rules should be fixed to return properly formatted JSON.

Zabbix server and proxy daemons will now correctly use the Timeout configuration parameter when performing SNMP checks. Additionally now the daemons will not perform retries after single unsuccessful (the timeout/wrong credentials) SNMP request. Previously the SNMP library default timeout and retries values (1 second and 5 retries respectively) were actually used.

Since 2.2 Zabbix agent will return ZBX_NOTSUPPORTED in case of invalid timeout or count values of net.dns check. Previously there was no validation and default or 0 values were used. From now on zero value will be also treated as an error.

The zabbix[items] internal check will now return the number of monitored items instead of the total number of items in database.

Internal checks of the hosts monitored by proxies are now processed by the proxies.

Several items that used to return EOF upon failure - vfs.file.contents, vfs.file.regexp, web.page.get and web.page.regexp - now return an empty string.

Daemon configuration parameter validation has been changed to disallow non-UTF-8 characters.

Logging out will now require a valid SID to be passed in the URL.

In Windows eventlog items, the source filter option is changed to support regular expressions.

The database upgrade will automatically convert the fourth parameter of eventlog item keys into a regular expression (adding ^ and $ symbols at the start and end of the fourth parameter respectively for all existing eventlog item keys).

Before all ODBC parameters were stored in the item additional parameter field in the following format:

DSN=<data source name>
user=<user name>
password=<password>
sql=<query>

In Zabbix 2.2.0, ODBC parameter storage is changed:

• <data source name> is stored as the second parameter in the item key
• <user name> is stored in the item username field
• <password> is stored in the item password field
• <query> is stored in the item additional parameter field

The database upgrade will automatically convert database monitor items into the new format. The only exception is items that exceed the following limits:

• Length of <data source name> plus length of item key must be less than 255 symbols.
• Length of <user name> must be less than 65 bytes
• Length of <password> must be less than 65 bytes

If an item can't be converted because of the above limits, then it will be left unchanged and a warning message will be written to the log file. Such items must be converted manually (shortening the problematic parameters so that they fit the new limits):

1. add <data source name> to item key as the second parameter
2. move <user name>, <password> into respective Username, Password fields
3. leave only <query> in the <SQL query> field

Item conversion failure warning message examples:

 25208:20130807:103348.467 Failed to convert host "dbmonitor" db monitoring item because key "db.odbc.select[query4__123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789]" is too long. See upgrade notes for manual database monitor item conversion.
 25208:20130807:103348.467 Failed to convert host "dbmonitor" db monitoring item because ODBC username "123456789_123456789_123456789_123456789_123456789_123456789_123456789_" is too long. See upgrade notes for manual database monitor item conversion.
 25208:20130807:103348.467 Failed to convert host "dbmonitor" db monitoring item because ODBC password "123456789_123456789_123456789_123456789_123456789_123456789_123456789_" is too long. See upgrade notes for manual database monitor item conversion.

Zabbix supported unixODBC and iODBC for direct database monitoring. iODBC is not actively maintained and there were no known users of it with Zabbix, thus support for iODBC has been removed in 2.2. For database monitoring unixODBC should be used.

Previously, if one escalation step resulted in multiple messages being generated, the value of {ESC.HISTORY} macro would differ for different recipients. Now {ESC.HISTORY} creates the same message content within the same escalation step when notification is sent to multiple recipients.

Status of host triggers and Status of host group triggers screen elements have been renamed to Host issues and Host group issues respectively.

Previously, triggers without events would not be displayed in these two widgets, nor in the Last 20 issues widget. Now triggers wothout events are displayed as well in all three places.

After upgrade to 2.2, custom dashboard layouts will be lost. This is caused by the dashboard widget positions, previously saved in a cookie, now being saved in the database.

After the upgrade, browsers may have a dashboard cookie that is not used anymore, because in the new version there is no functionality for working with them.

Before Zabbix 2.2.0, a trapper response to the values sent by an active agent/sender contained an info field in the following format:

Processed <N> Failed <N> Total <N> Seconds spent <N>

Starting with Zabbix 2.2.0, the formatting of the info field was changed to be more readable:

processed: <N>; failed: <N>; total: <N>; seconds spent: <N>

Starting with Zabbix 2.2.0 the Zabbix sender will finish with exit status 0 only if all of the values were sent and processed successfully. If processing of at least one of values failed the exit status will be 2. If data sending failed the exit status will be 1. Additionally if no arguments or server are specified the exit status will be 1 and for -h and -V options the exit status will be 0 (before Zabbix 2.2.0 exit status in the listed situations was 255).

Column order for alerts table will be different after upgrade as compared to a fresh install (Oracle only). This is caused by inability to change column type from varchar to nclob and insert a column in a specific place on Oracle. It should not cause any functional differences.

The standard item keys that were previously stored in the help_items table are now defined in the PHP CHelpItems class in frontends/php/include/classes/items/CHelpItems.php. The help_items table has been dropped.