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.

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.

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.

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.