Skip to content

Zabbix 3.2 Has Arrived – And It’s Awesome!

Zabbix 3.2.0 ReleasedThe next major release version of Zabbix is now available! Zabbix 3.2 brings both new features and many UI and performance improvements along with it.

This release introduces many improvements and added functionality. Detailed release notes are available here: Zabbix 3.2.0 Release Notes

Zabbix 3.2 – Highlights

  • Event tags for greater flexibility
    • Custom tags for events are introduced in the new version. Custom event tags are implemented as a pair of the tag name and value. You can use only the name or pair it with a value. After the tags are defined on the trigger level, corresponding events get marked with tag data. The tags can be use to implement service-centric approach to management of notifications and displaying of problems. For more information check out event tags.
  • Ability to manually close problems
    • Some problems, if allowed on trigger level, can now be closed manually from Zabbix UI.
  • Independent escalation for each problem event
    • Zabbix will process and escalate individually each problem generated by trigger having problem event generation mode set to ‘multiple’.
  • Ability to customize macro values
    • Sometimes a macro may resolve to a value that is not necessarily easy to work with. It may be long or contain a specific sub-string of interest that you would like to extract. For these purposes, the new version comes with a new concept of macro functions.
  • Coping with fast-growing log files
    • More advanced options are available for dealing with fast-growing log files. An optional maxdelay parameter for log monitoring items, which can be used to set a time bracket that log records must be analyzed within – if it’s impossible to analyze all records within the set time, older lines are skipped in favor of analyzing the more recent ones. Also, two new agent items log.count and logrt.count that count the number of matched lines and return that number instead of the lines themselves.
  • Easier trigger hysteresis
    • A much easier way of defining trigger hysteresis is introduced by an optional second trigger expression called ‘recovery expression’ where you can separately define the conditions that have to be met for the trigger to return back to the OK state. There is also more control over how OK events are generated. You can use the problem expression as basis (then it works the same way as before), the recovery expression as basis, or even select ‘None’ in which case the trigger will always remain in problem state if it goes into it.
  • Viewable items, triggers, graphs created by LLD
    • Now entities created by low-level discovery are shown in a much more user-friendly way. It is possible to view the details of these items, triggers and graphs. Check-boxes are enabled to apply mass operations to them. Thus it is possible to enable/disable/delete them.

Upgrade – The safe way

  1. Read the upgrade notes! Depending on what version you’re currently on, read up on important notes regarding upgrades.
    Zabbix 2.4 Upgrade Notes
    Zabbix 3.0 Upgrade Notes
    Zabbix 3.2 Upgrade Notes
  2. Grab two backups of your Zabbix database. One that only contains the Zabbix configuration and a full database dump. Assuming you use MySQL, the configuration backup can be performed using this script.
  3. Setup an appropriately sized VM or server, and test the upgrade. Start out with the database containing only configuration data and see how things play out. Now, move on to test a full upgrade with the database dump.
  4. If all is well, schedule some downtime and then upgrade your production environment. Remember that your Zabbix Server and Zabbix Proxy instances must be running the same major release version.

Upgrading can take quite a while. Test the upgrade thoroughly before moving on to upgrading your environment. Taking down your production monitoring system for an extended period of time is rarely a good idea!

Note that Zabbix 3.2 changes the structure of your history_text and history_log tables. Depending on their size in your environment, you’ll have to be patient when upgrading. Our production history_log table is roughly 7GB, and a table structure change means moving 7GB of data to a temp table and back again. How long that takes is entirely dependent on your hardware and setup.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.