Zabbix Documentation 4.4

3.04.05.0 (current)| In development:5.2 (devel)| Unsupported:1.82.02.22.43.23.44.24.4Guidelines

User Tools

Site Tools


manual:introduction:whatsnew440

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
manual:introduction:whatsnew440 [2019/10/04 06:29]
martins-v some rewording
manual:introduction:whatsnew440 [2020/05/13 12:02] (current)
martins-v adding internal link
Line 1: Line 1:
 ===== 5 What's new in Zabbix 4.4.0 ===== ===== 5 What's new in Zabbix 4.4.0 =====
  
-<note important>​Zabbix ​4.4.is not released yet.</note>+==== Zabbix ​agent 2 ==== 
 + 
 +A new-generation Zabbix agent has been developed called Zabbix agent 2Some of the goals set when developing the new agent 2 were to:  
 + 
 +  * reduce the number of TCP connections 
 +  * have greater check concurrency 
 +  * be easily extendible with plugins 
 +  * be a drop-in replacement for Zabbix agent (in that it supports all the previous functionality) 
 + 
 +Agent 2 is written in Go (with some C code of Zabbix agent reused)A configured Go version 1.12+ environment ​is required for building Zabbix agent 2. 
 + 
 +Zabbix agent 2 is available in pre-compiled Zabbix packages. To compile Zabbix agent 2 from sources you have to specify the ''​%%--enable-agent2%%''​ configure option. 
 + 
 +Agent 2 is currently supported for the Linux platform only; with support for a Windows agent on its way. Currently Agent 2 is in experimental status, with a production-ready status expected in the next major release. 
 + 
 +See also: [[:manual/concepts/​agent2|Zabbix agent 2]] 
 +==== Webhooks in alerting ==== 
 + 
 +In the new version you may write your own JavaScript code to extend Zabbix alerting capabilities. While in previous versions that could only be done by some external scripts, now all the alerting logic can be kept inside Zabbix, more specifically,​ using the new [[:​manual/​config/​notifications/​media/​webhook|Webhook]] media type. 
 + 
 +A webhook may be used for easy integration of Zabbix alerting with a third-party helpdesk system, chat, messenger, etc. Moreover, it is possible to return some data about created tickets that's then displayed in Zabbix.
  
 ==== TimescaleDB officially supported ==== ==== TimescaleDB officially supported ====
Line 25: Line 45:
 {{:​manual:​introduction:​aggregate_graph0.png?​600|}} {{:​manual:​introduction:​aggregate_graph0.png?​600|}}
  
-The options for aggregation have been added to the data set settings when [[:​manual/​web_interface/​frontend_sections/​monitoring/​dashboard/​widgets#​graph|configuring]] a graph widget.+Aggregation can be configured in the data set settings when [[:​manual/​web_interface/​frontend_sections/​monitoring/​dashboard/​widgets#​graph|configuring]] a graph widget.
  
 You may pick the aggregation function and the time interval. Since a data set may comprise several items, there is also another option allowing to show aggregated data for each item separately or for all data set items as one aggregated value: You may pick the aggregation function and the time interval. Since a data set may comprise several items, there is also another option allowing to show aggregated data for each item separately or for all data set items as one aggregated value:
Line 32: Line 52:
  
 See also: [[:​manual/​config/​visualisation/​graphs/​aggregate|Aggregation in graphs]] See also: [[:​manual/​config/​visualisation/​graphs/​aggregate|Aggregation in graphs]]
 +
 +==== Dependent item limit raised ====
 +
 +The maximum number of allowed [[:​manual/​config/​items/​itemtypes/​dependent_items|dependent items]] for one master item has been raised from 999 to 29999.
 +
 +==== Kerberos authentication ====
 +
 +Kerberos authentication is now supported in:
 +
 +  * [[:​manual/​web_monitoring#​configuring_authentication|Web monitoring]]
 +  * [[:​manual/​config/​items/​itemtypes/​http#​configuration|HTTP items]]
 +
 +{{:​manual:​introduction:​kerberos_auth.png|}}
 +
 +==== Live/​operational data of problems ====
 +
 +It is now possible to configure ways of displaying operational data for current problems, i.e. the latest item values as opposed to the item values at the time of the problem.
 +
 +Operational data display can be configured in the filter of //​Monitoring//​ -> //​Problems//​ or in the configuration of the respective [[:​manual/​web_interface/​frontend_sections/​monitoring/​dashboard/​widgets#​problems|dashboard widget]], by selecting one of the three options:
 +
 +  * //None// - no operational data is displayed
 +  * //​Separately//​ - operational data is displayed in a separate column (in this case it replaces the //Latest values// column from the previous version)
 +
 +{{:​manual:​introduction:​problem_live_data_b0.png?​600|}} ​
 +
 +  * //With problem name// - operational data is appended to the problem name and in parentheses
 +
 +{{:​manual:​introduction:​problem_live_data_a0.png?​600|}}
 +
 +The content of operational data can be configured with each [[:​manual/​config/​triggers/​trigger|trigger]] that now has a new //​Operational data// field. This field accepts an arbitrary string with macros, most importantly,​ the {ITEM.LASTVALUE<​1-9>​} macro.
 +
 +{{:​manual:​introduction:​operational_data_trigger0.png|}}
 +
 +Operational data can also be included in notifications using the new {EVENT.OPDATA} macro.
  
 ==== Database monitor may return multiple rows/​columns ==== ==== Database monitor may return multiple rows/​columns ====
Line 46: Line 100:
  
 Compared to the ''​db.odbc.discovery[]''​ item from previous versions, this item does not define low-level discovery macros in the returned JSON, however, these macros can be defined by the user as required, using the [[:​manual/​discovery/​low_level_discovery#​custom_macros|custom LLD macro]] functionality with JSONPath to point to the required values in the returned JSON. Compared to the ''​db.odbc.discovery[]''​ item from previous versions, this item does not define low-level discovery macros in the returned JSON, however, these macros can be defined by the user as required, using the [[:​manual/​discovery/​low_level_discovery#​custom_macros|custom LLD macro]] functionality with JSONPath to point to the required values in the returned JSON.
- 
-==== Dependent item limit raised ==== 
- 
-The maximum number of allowed [[:​manual/​config/​items/​itemtypes/​dependent_items|dependent items]] for one master item has been raised from 999 to 29999. 
- 
-==== Kerberos authentication ==== 
- 
-Kerberos authentication is now supported in: 
- 
-  * [[:​manual/​web_monitoring#​configuring_authentication|Web monitoring]] 
-  * [[:​manual/​config/​items/​itemtypes/​http#​configuration|HTTP items]] 
- 
-{{:​manual:​introduction:​kerberos_auth.png|}} 
  
 ==== Low-level discovery ==== ==== Low-level discovery ====
Line 78: Line 119:
    ​systemd.unit.discovery    ​systemd.unit.discovery
  
-<note important>​This item key is only supported in Zabbix agent 2.</​note>​+<note important>​This item key is only supported in Zabbix ​[[:​manual/​introduction/​whatsnew440#​zabbix_agent_2|agent 2]].</​note>​
  
 The discovery will return a JSON with the values of several macros, identifying various systemd unit properties. These macros can be used to create item prototypes using the new ''​systemd.unit.info[]''​ item key, for example ''​%%systemd.unit.info["​{#​UNIT.NAME}",​LoadState]%%''​. ​ The discovery will return a JSON with the values of several macros, identifying various systemd unit properties. These macros can be used to create item prototypes using the new ''​systemd.unit.info[]''​ item key, for example ''​%%systemd.unit.info["​{#​UNIT.NAME}",​LoadState]%%''​. ​
Line 124: Line 165:
 ==== Autoregistration with DNS name ==== ==== Autoregistration with DNS name ====
  
-It is now possible to specify that the host should be autoregistered with the DNS name as the default agent interface. To do that, the DNS name should be specified/​returned as the value of either '​HostInterface'​ or '​HostInterfaceItem'​ configuration parameters. Note that if the value of one of the two parameters changes, the autoregistered host interface is updated. So it is possible to update the default interface to another DNS name or an IP address. For the changes to take effect though, the agent has to be restarted. '​HostInterface'​ or '​HostInterfaceItem'​ configuration parameters are supported since Zabbix 4.4.+It is now possible to specify that the host should be autoregistered with the DNS name as the default agent interface. To do that, the DNS name should be specified/​returned as the value of either '​HostInterface'​ or '​HostInterfaceItem' ​[[:​manual/​appendix/​config/​zabbix_agentd|configuration parameters]]. Note that if the value of one of the two parameters changes, the autoregistered host interface is updated. So it is possible to update the default interface to another DNS name or an IP address. For the changes to take effect though, the agent has to be restarted. '​HostInterface'​ or '​HostInterfaceItem'​ configuration parameters are supported since Zabbix 4.4.
  
 ==== Longer host names allowed in discovery ==== ==== Longer host names allowed in discovery ====
Line 132: Line 173:
 ==== Extended item value preprocessing options ==== ==== Extended item value preprocessing options ====
  
 +=== CSV to JSON conversion ===
 +
 +It is now possible to convert CSV file data into JSON format.
 +
 +{{:​manual:​introduction:​csv_to_json0.png|}}
 +
 +See also: [[:​manual/​appendix/​preprocessing/​csv_to_json|CSV to JSON preprocessing]]
 === Custom error handling === === Custom error handling ===
  
Line 143: Line 191:
 In a typical use case of custom error handling, data can be skipped if an error message is found. In a typical use case of custom error handling, data can be skipped if an error message is found.
  
-=== XML-related preprocessing ​options ​added to LLD ===+=== More options ​for LLD rule preprocessing ​===
  
-//XML Xpath// and //Check for error in XML// preprocessing options have been added to [[:​manual/​discovery/​low_level_discovery#​preprocessing|low-level discovery rules]].+More preprocessing options have been added to [[:​manual/​discovery/​low_level_discovery#​preprocessing|low-level discovery rules]]
 + 
 +  * XML Xpath 
 +  * CSV to JSON (new in 4.4) 
 +  * Check for error in XML 
 + 
 +==== Host names included in real-time export ==== 
 + 
 +Host names are now included in the [[:​manual/​appendix/​install/​real_time_export|real-time export]] of events, item values and trends (previously only the visible host name was exported). Note that the [[:​manual/​appendix/​protocols/​real_time_export|export protocol]] has changed with host name information now an object, rather than a string/​array. 
 + 
 +==== Value types included in real-time export ==== 
 + 
 +Value types are now included in the [[:​manual/​appendix/​install/​real_time_export|real-time export]] of item values and trends. See the [[:​manual/​appendix/​protocols/​real_time_export|export protocol]] for more details.
  
 ==== New templates ==== ==== New templates ====
Line 155: Line 215:
 The new Linux monitoring templates come in three flavours: The new Linux monitoring templates come in three flavours:
  
-  * //Template OS Linux by Zabbix agent// - Linux monitored via Zabbix agent (modular) +  * //Template OS Linux by Zabbix agent//, //Template OS Linux by Zabbix agent active// - Linux monitored via Zabbix agent (modular) 
-    * depends ​on //Template Module Zabbix agent//, which should be imported/​updated first+    * depend ​on //Template Module Zabbix agent//, which should be imported/​updated first
   * //Template OS Linux by Prom// - Linux monitored via node exporter (monolithic)   * //Template OS Linux by Prom// - Linux monitored via node exporter (monolithic)
   * //Template OS Linux SNMPv2// - Linux monitored via SNMPv2 (modular)   * //Template OS Linux SNMPv2// - Linux monitored via SNMPv2 (modular)
Line 164: Line 224:
 === Windows === === Windows ===
  
-  * //Template OS Windows by Zabbix agent// - Windows monitored via Zabbix agent. ​This template is supported for Windows Server 2008/Vista and above. +  * //Template OS Windows by Zabbix agent//, //Template OS Windows by Zabbix agent active// - Windows monitored via Zabbix agent. ​These templates are supported for Windows Server 2008/Vista and above. 
-  * //​Template ​OS Windows ​SNMPv2// - Windows monitored via SNMPv2+ 
 +=== Cisco UCS server === 
 + 
 +  * //​Template ​Server Cisco UCS SNMPv2// - Cisco UCS server monitoring template
  
 === Nginx === === Nginx ===
Line 184: Line 247:
 === MySQL/​MariaDB === === MySQL/​MariaDB ===
  
-  * //Template DB MySQL// - see [[:​manual/​config/​templates_out_of_the_box/​requirements/​mysql#​steps|requirements for operating]] this template.+  * //Template DB MySQL by Zabbix agent// - see [[:​manual/​config/​templates_out_of_the_box/​requirements/​mysql#​steps|requirements for operating]] this template. 
  
 === PostgreSQL === === PostgreSQL ===
Line 193: Line 257:
  
   * In //​Configuration//​ -> //​Templates//​ in new installations;​   * In //​Configuration//​ -> //​Templates//​ in new installations;​
-  * If you are upgrading from previous versions, you can download ​these templates from [[https://​git.zabbix.com/​projects/​ZBX/​repos/​zabbix/​browse/​templates|GitHub]] or find them in the ''​templates''​ directory of the downloaded latest Zabbix version. Then, while in //​Configuration//​ -> //​Templates//​ you can import them manually into Zabbix. If templates with the same names already exist, the //Delete missing// options should be checked when importing to achieve a clean import. This way the old items that are no longer in the updated template will be removed (note that it will mean losing history of these old items).+  * If you are upgrading from previous versions, you can download ​the latest ​templates from the [[https://​git.zabbix.com/​projects/​ZBX/​repos/​zabbix/​browse/​templates?​at=refs%2Fheads%2Frelease%2F4.4|Zabbix Git repository]]. Then, while in //​Configuration//​ -> //​Templates//​ you can import them manually into Zabbix. If templates with the same names already exist, the //Delete missing// options should be checked when importing to achieve a clean import. This way the old items that are no longer in the updated template will be removed (note that it will mean losing history of these old items)
 + 
 +==== Internal knowledge base ==== 
 + 
 +Item and trigger descriptions allow to share knowledge in Zabbix across various users. These descriptions may explain what an item does or what the nature of the problem is. Now it is easier to notice and view this information in latest data and problem screens. 
 + 
 +=== Item description in latest data === 
 + 
 +Item description now can be viewed in the //Latest data// section.  
 + 
 +An icon with a question mark {{:​manual:​introduction:​item_description_icon.png|}} is displayed next to the item name for all items that have a description. If you position the mouse cursor on this icon, the item description is displayed as a tooltip. 
 + 
 +{{:​manual:​introduction:​l_data_item_descr.png|}} 
 + 
 +=== Trigger description for problems === 
 + 
 +An icon with a question mark {{:​manual:​introduction:​item_description_icon.png|}} is displayed next to the problem name for all problems that have a description. If you position the mouse cursor on this icon, the description of the underlying trigger is displayed as a tooltip. 
 + 
 +{{:​manual:​introduction:​problem_description.png?​600|}} 
 + 
 +Problem description is also available in event details.
  
 ==== Jabber, Ez Texting media types removed ==== ==== Jabber, Ez Texting media types removed ====
Line 200: Line 284:
  
 If these media types are present in your existing installation,​ during the upgrade they will be replaced by a script media type with all relevant parameters preserved. However, notifications via Jabber and Ez Texting will not work any more. If these media types are present in your existing installation,​ during the upgrade they will be replaced by a script media type with all relevant parameters preserved. However, notifications via Jabber and Ez Texting will not work any more.
 +
 +==== Export/​import ====
 +
 +=== Media type export ===
 +
 +For easier sharing of media types, including the new webhooks, media types can now be [[:​manual/​xml_export_import/​media|exported]] and imported.
 +
 +The export files support the new human-readable format (see below) implemented for host/​template export.
 +
 +=== Human-readable export files of hosts/​templates ===
 +
 +Previous implementation of XML/JSON import required the presence of all attributes, even if they were empty or irrelevant. That made the export files extremely long and hardly readable.
 +
 +In the new version much smaller and simpler export files are produced:
 +
 +  * There is a very limited number of mandatory attributes
 +  * Non-mandatory attributes are exported only if they have a value and the value is different from the default
 +  * Attribute values are now exported in a readable string format, replacing many integers
 +
 +|Now:\\ ''<​type>​TRAP</​type>'' ​ |
 +|Before:\\ ''<​type>​2</​type>'' ​ |
 +
 +See also:
 +  * [[:​manual/​xml_export_import/​templates#​export_format|Template export format]]
 +  * [[:​manual/​xml_export_import/​hosts#​export_format|Host export format]]
 +== Including triggers within host tags ==
 +
 +Previously all triggers in host/​template export 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 the tags of the respective host item.
 +
 +Additionally the expression tag of these triggers does not reference the host or item, but only the function (''​{last()}<>​0''​ in the example):
 +
 +<code xml>
 +    <​hosts>​
 +        <​host>​
 +            <​host>​Host</​host>​
 +            ...
 +            <​items>​
 +                <​item>​
 +                    <​name>​Item</​name>​
 +                    <​key>​item.key</​key>​
 +                    ...
 +                    <​triggers>​
 +                        <​trigger>​
 +                            <​expression>​{last()}<>​0</​expression>​
 +                            <​name>​Item value not 0</​name>​
 +                        </​trigger>​
 +                    </​triggers>​
 +                </​item>​
 +            </​items>​
 +        </​host>​
 +    </​hosts>​
 +</​code>​
 +
 +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.
  
 ==== Frontend ==== ==== Frontend ====
Line 229: Line 369:
  
 {{:​manual:​introduction:​graph_multiselect_field.png|}} {{:​manual:​introduction:​graph_multiselect_field.png|}}
- 
-=== Operational data of problems === 
- 
-{{:​manual:​introduction:​problem_op_data0.png?​600|}} 
- 
-A new //​Operational data// column has been added to //​Monitoring//​ -> //​[[:​manual/​web_interface/​frontend_sections/​monitoring/​problems|Problems]]//​ and the //​Problems//​ dashboard widget, next to the //Problem// column. It is available if //Show operational data// is selected in the filter or the widget configuration. 
- 
-This column is capable of displaying a live view of operational data based on the definition (arbitrary strings plus macros) given in the [[:​manual/​config/​triggers/​trigger#​configuration|trigger configuration]],​ which now has a new field //​Operational data//. 
- 
-{{:​manual:​introduction:​operational_data_trigger.png|}} 
- 
-Importantly this gives the opportunity to see the **latest values** of selected items from the trigger expression that caused the problem, using the {ITEM.LASTVALUE<​1-9>​} macro. Note that the //​Operational data// column replaces the //Latest values// column. 
- 
-//​Operational data// can also be included in notifications using the new {EVENT.OPDATA} macro. 
  
 === 24 column grid in dashboard === === 24 column grid in dashboard ===
Line 255: Line 381:
  
 Once the editing button is clicked, the widget editing form is opened and the whole dashboard goes into editing mode. Once the editing button is clicked, the widget editing form is opened and the whole dashboard goes into editing mode.
- 
-=== Improved dashboard editing === 
- 
-The dashboard editing experience has also been improved. Several fixes have been made related to better widget focusing while in the edit mode, more usable widget resizing and repositioning. 
  
 === Hiding widget headers ==== === Hiding widget headers ====
Line 265: Line 387:
  
 {{:​manual:​introduction:​widgets_no_headers0.png|}} {{:​manual:​introduction:​widgets_no_headers0.png|}}
 +
 +=== Dashboard usability ===
 +
 +  * The widget editing experience has been improved. Several fixes have been made related to better widget focusing while in the edit mode, more usable widget resizing and repositioning.
 +  * The last widget type is now remembered - when adding a new widget to the dashboard, its type is selected based on the widget that was last selected. ​
  
 === Problems by severity widget extended === === Problems by severity widget extended ===
Line 297: Line 424:
  
 {{:​manual:​introduction:​graph_prototype_new.png?​600|}} {{:​manual:​introduction:​graph_prototype_new.png?​600|}}
 +
 +=== Cannot support audio notification notice ===
 +
 +“Cannot support notification audio for this device.” message will be displayed when [[:​manual/​web_interface/​user_profile/​sound|notification sounds]] on the device cannot be played. ​
  
 === Monospaced fonts in trigger expression/​command fields === === Monospaced fonts in trigger expression/​command fields ===
Line 337: Line 468:
  
 {{:​manual:​introduction:​hosts_proxy.png|}} {{:​manual:​introduction:​hosts_proxy.png|}}
- 
-=== 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): 
- 
-<code xml> 
-    <​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>​ 
-</​code>​ 
- 
-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. 
  
 ==== Macros ==== ==== Macros ====
  
   * {EVENT.ID} is now supported in trigger URLs, allowing to construct complete URLs to problem details.   * {EVENT.ID} is now supported in trigger URLs, allowing to construct complete URLs to problem details.
 +  * It is now possible to add a description to user macros:
 +
 +{{:​manual:​introduction:​user_macro_description.png?​600|}}
  
 ==== Performance ==== ==== Performance ====