Zabbix Documentation 4.4

2.23.04.04.2 (current)In development:4.4 (devel)Unsupported:1.82.02.43.23.4

User Tools

Site Tools


Sidebar

manual:introduction:whatsnew440

5 What's new in Zabbix 4.4.0

Zabbix 4.4.0 is not released yet.

Kerberos authentication

Kerberos authentication is now supported in:

Low-level discovery of block devices

Low-level discovery of block devices and their type is supported using a new built-in discovery key:

 vfs.dev.discovery

The discovery will return a JSON with the values of two macros - {#DEVNAME} and {#DEVTYPE}, identifying the block device name and type respectively.

These macros can be used to create item prototypes using the vfs.dev.read[] and vfs.dev.write[] agent items, i.e. vfs.dev.read[{#DEVNAME},sps]. See also: Discovery of block devices.

Extended item value preprocessing options

Custom error handling

Custom error handling is now also available for the following preprocessing steps:

  • Check for error in JSON
  • Check for error in XML
  • Check for error using regular expression

The Custom on fail checkbox is available in these preprocessing steps for regular items and item prototypes. For low-level discovery rules the Custom on fail checkbox is made available for 'Check for error in JSON' and 'Check for error in XML' preprocessing steps.

In a typical use case of custom error handling, data can be skipped if an error message is found.

XML Xpath and Check for error in XML preprocessing options have been added to low-level discovery rules.

Longer host names allowed in discovery

Maximum allowed length of a host name has been lifted from 64 characters to 128 characters in host discovery and active agent auto-registration.

Frontend

Instant editing for dashboard widgets

Dashboard widget editing can now be accessed with one mouse click.

Once the editing button is clicked, the widget editing form is opened and the whole dashboard goes into editing mode.

24 column grid in dashboard

The horizontal limit of allowed dashboard widgets has been raised from 12 to 24 columns.

Hiding widget headers

Widget headers can now be hidden allowing to display the widget content only and save space:

When a widget header is hidden it still can be viewed by positioning the mouse on the widget. On mouseover the widget header dynamically reappears.

The widget header can be hidden in the widget configuration, by unchecking the new Show header option.

Problems by severity widget extended

The Problems by severity widget has been extended with the option to show problem totals for multiple selected host groups and hosts:

The totals can be displayed in horizontally or vertically stacked blocks:

New host availability widget

A new Host availability widget has been added to available dashboard widgets. This widget is similar as the Host info screen element and displays high-level statistics of host availability based on the selected host groups.


Horizontal display.

Vertical display.

Monospaced fonts in trigger expression/command fields

For better readability, text area fonts have been changed to monospace in the following locations:

  • Trigger expression and recovery expression field
  • Executed script field of SSH/Telnet agent items
  • Formula field of calculated items
  • SQL query field of database monitor items
  • Command field of global scripts
  • Remote command field in action configuration

Longer input fields

Input fields that potentially may hold long names or values have been increased to 300 pixels and are also increasing dynamically to a new line when typing:

This change has been implemented in:

  • Host and template configuration forms (tags and macros)
  • Trigger and trigger prototype configuration forms (tags)
  • Host, template and trigger mass update forms (tags)
  • Low-level discovery rule configuration form (LLD macros)
  • AdministrationGeneralMacros
  • Item, item prototype and LLD rule configuration forms (test item preprocessing)

Changed host export format

The format of host and template export in XML/JSON has been changed in the way how triggers are exported. Previously all triggers were listed after the host information. Now, to achieve better readability, triggers that are based on one host item only in problem and recovery expression are listed within tags of the respective host item.

Note also how the expression of the triggers does not reference the host or item, but only the function ({last()}<>0 in the example):

    <hosts>
        <host>
            <host>Host</host>
            ...
            <items>
                <item>
                    <name>Item</name>
                    <type>0</type>
                    <snmp_community/>
                    <snmp_oid/>
                    <key>item.key</key>
                    ...
                    <triggers>
                        <trigger>
                            <expression>{last()}<>0</expression>
                            <recovery_mode>0</recovery_mode>
                            <recovery_expression/>
                            <name>Item value not 0</name>
                            <correlation_mode>0</correlation_mode>
                            <correlation_tag/>
                            <url/>
                            <status>0</status>
                            <priority>2</priority>
                            <description/>
                            <type>0</type>
                            <manual_close>0</manual_close>
                            <dependencies/>
                            <tags/>
                        </trigger>
                    </triggers>
                </item>
            </items>
        </host>
    </hosts>

The same change affects simple trigger prototypes that are placed under <item_prototype><trigger_prototypes>.

However, triggers that are more complex and contain several host items are listed within separate <triggers> tags, as before.

Miscellaneous

Performance

Items table split

The items table was previously used by both frontend and the server, resulting in undesirable locking of rows at times when, for example, the server would update fields related to 'log' items. To resolve this situation, realtime fields (lastlogsize, state, mtime, error) have been split into a separate table called item_rtdata.