manual:introduction:whatsnew420

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
Next revision Both sides next revision
manual:introduction:whatsnew420 [2019/01/10 09:56]
martins-v how throttling can be applied to dependent items
manual:introduction:whatsnew420 [2019/02/21 07:53]
martins-v more details about filtering enhancements of items, triggers
Line 5: Line 5:
 This section introduces major new features of the new release. This section introduces major new features of the new release.
  
-==== Item value preprocessing ====+==== Extended item value preprocessing ====
  
-=== New validation ​and throttling rules ===+=== Javascript === 
 + 
 +It is now possible to apply preprocessing to item value or low-level discovery values using Javascript. 
 + 
 +{{:​manual:​introduction:​javascript_step1.png|}} 
 + 
 +The Javascript step accepts one parameter - a non-empty JavaScript code block. 
 + 
 +{{:​manual:​introduction:​javascript_step2.png|}} 
 + 
 +Clicking in the parameter field or on //Open// next to the parameter field will open a window for entering the code block. 
 + 
 +{{:​manual:​introduction:​javascript_step3.png|}} 
 + 
 +=== Validation ​and throttling rules ===
  
 New options have been added to item value preprocessing focusing on validation and throttling. New options have been added to item value preprocessing focusing on validation and throttling.
Line 15: Line 29:
 Extracting an error message provided in incoming data is another new feature. For example, a JSON object may contain a field %%"​%%error%%"​%%. If the field exists preprocessing is able to extract its value and set it as an error message for the item. Extracting an error message provided in incoming data is another new feature. For example, a JSON object may contain a field %%"​%%error%%"​%%. If the field exists preprocessing is able to extract its value and set it as an error message for the item.
  
-{{:​manual:​introduction:​preprocessing_new_steps.png|}}+{{:​manual:​introduction:​preprocessing_new_steps1.png|}}
  
 Throttling rules allow to process value only if it is changed, thus reducing the amount of incoming data when it's mostly static. For example, dependent items may be updated less frequently as the master item, provided there'​s no change to the values. If the master is updated every 10 seconds, a dependent item may be updated every minute. Throttling rules allow to process value only if it is changed, thus reducing the amount of incoming data when it's mostly static. For example, dependent items may be updated less frequently as the master item, provided there'​s no change to the values. If the master is updated every 10 seconds, a dependent item may be updated every minute.
  
-See [[:​manual/​config/​items/​item#​item_value_preprocessing|item value preprocessing]] ​for more details.+For more details, see: [[:​manual/​config/​items/​item#​item_value_preprocessing|Item value preprocessing]].
  
 === Custom error handling === === Custom error handling ===
Line 44: Line 58:
   * set to a specified value   * set to a specified value
   * set a specified error message   * set a specified error message
 +
 +==== Low-level discovery ====
 +
 +=== Separate processing for low-level discovery ===
 +
 +Processing low-level discovery rules has been split from data gathering processes into its own processing.
 +
 +See: [[#​separate_processing_for_low-level_discovery1|Daemon improvements]].
 +
 +=== Expected format change in low-level discovery ===
 +
 +In order to support preprocessing of low-level discovery result and custom paths to low-level discovery (LLD) macro values in a JSON document, the format of JSON returned by low-level discovery rules has been changed. It is no longer expected that the JSON will contain the %%"​%%data%%"​%% object: ​
 +
 +<code java>
 +{
 +  "​data":​ [
 +    {<​discovery row>},
 +    {<​discovery row>}
 +  ]
 +}
 +</​code>​
 +
 +Low-level discovery will now accept a normal JSON containing an array. ​
 +
 +Built-in discovery keys have been updated to return an array of LLD rows at the root of JSON document. Zabbix will automatically extract a macro and value if an array field uses the {#MACRO} syntax as a key. Any new native discovery checks will use the new syntax without the %%"​%%data%%"​%% elements. When processing a low-level discovery value first the root is located (array at ''​$.''​ or ''​$.data''​). ​
 +
 +While the %%"​%%data%%"​%% element has been removed from all native items related to discovery, for backward compatibility Zabbix will still accept the JSON notation with a %%"​%%data%%"​%% element, though its use is discouraged. If the JSON contains an object with only one %%"​%%data%%"​%% array element, then it will automatically extract the content of the element using JSONPath ''​$.data''​.
 +
 +==== Preprocessing and custom macros in low-level discovery ====
 +
 +Low-level discovery configuration has gained additional options of preprocessing the discovery result and extracting custom macros from the preprocessed result. To better understand the changes in the discovery data flow, let's compare it with the previous versions:
 +
 +^Version^LLD data flow^
 +|Before Zabbix 4.2  |//​Discovery rule// -> //Discovery rule filter// ​ |
 +|In Zabbix 4.2  |//​Discovery rule// -> //​Preprocessing//​ -> //Custom macros// -> //Discovery rule filter// ​ |
 +
 +It's important to understand that this logic works in the order from left to right, the same as when defining the rule: first the discovery happens, then optionally preprocessing is applied to it, then custom macros may be extracted and then the filter conditions are applied to the result.
 +=== Preprocessing ===
 +
 +Low-level discovery rules now have a preprocessing step, containing the following options:
 +
 +  * Regular expression match
 +  * JSONPath (structured data)
 +  * Javascript
 +  * Does not match regular expression (validation)
 +  * Check for error in JSON (validation)
 +  * Discard unchanged with heartbeat (throttling)
 +
 +{{:​manual:​introduction:​lld_rule_preprocessing.png|}}
 +
 +For more details, see: [[:​manual/​discovery/​low_level_discovery#​preprocessing|Preprocessing]] in low-level discovery rules.
 +
 +=== LLD macro extraction with JSONPath ===
 +
 +Low-level discovery rules now also accept extracting user-defined low-level discovery (LLD) macro values using a custom path specified in JSONPath syntax.
 +
 +LLD macro = JSONPath mappings can now be defined where each macro is defined with a custom JSON path to the value location. The values pointed to by the defined JSON path are used to replace the macros in item, trigger, etc prototype fields. ​
 +
 +{{:​manual:​introduction:​lld_rule_macros.png|}}
 +
 +For more details, see: [[:​manual/​discovery/​low_level_discovery#​custom_macros|Custom macros]] in low-level discovery rules.
 +
 +==== TimescaleDB support ====
 +
 +In the new version Zabbix adds support of a time-series database in the form of **experimental** support of TimescaleDB,​ a PostgreSQL-based database solution of automatically partitioning data into time-based chunks to support faster performance at scale.
 +
 +A migration script is available to migrate from existing PostgreSQL tables to a TimescaleDB layout. For more details see: [[:​manual/​appendix/​install/​timescaledb|Migration to TimescaleDB]].
 +
 +<note warning>​Currently TimescaleDB is not supported by Zabbix proxy.</​note>​
 +
 +==== Template and host-level tags ====
 +
 +The possibility to tag events has been a feature of Zabbix since 3.2.0, however, previously, tagging was confined to individual triggers. In the new version tagging can be applied on template and host levels:
 +
 +  * On template level that means all problems of host triggers inherited from these templates will be tagged accordingly
 +  * On host level that means that all host problems will be tagged accordingly
 +
 +Tags can be defined in a new tab in template and host configuration forms, for example, for a template:
 +
 +{{:​manual:​introduction:​template_tags.png|}}
 +
 +In trigger configuration,​ tags are now also separated into their own tab. In addition the //Inherited and trigger tags// option allows to view tags defined on template level (but not on host level), if the trigger comes from that template:
 +
 +{{:​manual:​introduction:​trigger_tags.png?​600|}}
 +
 +An event when it happens inherits all tags from the whole chain of templates, hosts, triggers. Completely identical ''​tag:​value''​ combinations are merged into one rather than being duplicated, when marking the event.
 +
 +See more on [[:​manual/​config/​event_correlation/​trigger/​event_tags|tags]].
 +==== Remote monitoring of Zabbix stats ====
 +
 +It is now possible to make some internal metrics of Zabbix server and proxy accessible remotely by another Zabbix instance or a third party tool. This can be useful so that supporters/​service providers can monitor their client Zabbix servers/​proxies remotely or, in organizations where Zabbix is not the main monitoring tool, that Zabbix internal metrics can be monitored by a third party system in an umbrella-monitoring setup. ​
 +
 +Zabbix internal stats are exposed to a configurable set of addresses listed in the new '​StatsAllowedIP'​ [[:​manual/​appendix/​config/​zabbix_server|server]]/​[[:​manual/​appendix/​config/​zabbix_proxy|proxy]] parameter. Requests will be accepted only from these addresses.
 +
 +To configure querying of internal stats on another Zabbix instance, you may use two new items:
 +
 +  * ''​zabbix[stats,<​ip>,<​port>​]''​ internal item - for direct remote queries of Zabbix server/​proxy. <ip> and <​port>​ are used to identify the target instance.
 +  * ''​zabbix.stats[<​ip>,<​port>​]''​ agent item - for agent-based remote queries of Zabbix server/​proxy. <ip> and <​port>​ are used to identify the target instance.
 +
 +To make sure that the target instance allows querying it by the external instance, list the address of the external instance in the '​StatsAllowedIP'​ parameter on the target instance. ​
 +
 +These items gather statistics in bulk and return a JSON which can be used as the master item for dependent items that get their data from. A selected set of internal metrics (i.e. not all) is returned by either of these two items. ​
 +
 +There are also another two new items allowing to specifically remotely query internal queue stats:
 +
 +  * ''​zabbix[stats,<​ip>,<​port>,​queue,<​from>,<​to>​]''​ internal item - for direct internal queue queries to remote Zabbix server/​proxy
 +  * ''​zabbix.stats[<​ip>,<​port>,​queue,<​from>,<​to>​]''​ agent item - for agent-based internal queue queries to remote Zabbix server/​proxy
 +
 +For more details, see: 
 +  * [[:​manual/​appendix/​items/​remote_stats|Remote monitoring of Zabbix stats]]
 +  * [[:​manual/​config/​items/​itemtypes/​internal|Internal items]]
 +  * [[:​manual/​config/​items/​itemtypes/​zabbix_agent|Zabbix agent items]]
 +
 +== New templates ==
 +New templates are also available for remote Zabbix server or proxy internal metric monitoring:
 +
 +  * Template App Remote Zabbix server
 +  * Template App Remote Zabbix proxy
 +
 +Note that in order to use a template for remote monitoring of multiple external instances, a separate host is required for each external instance monitoring.
 +
 +==== More intuitive dashboard editing ====
 +
 +Several improvements have been made to the way widgets behave in dashboard editing mode:
 +
 +  * When a widget is made larger, it no longer "​throws down" other widgets. Instead the other widgets in any direction try to shrink accordingly using all the available space;
 +  * When a widget is moved down, the widgets below it try to take its place if possible, instead of being dragged along downwards;
 +  * When a widget is moved up, directly adjoining widgets below it are dragged up as well, instead of being left behind;
 +  * If previously it was possible to add a widget only at the end and only in its default size, now it is now possible to add a widget in any open slot and size. See [[:​manual/​web_interface/​frontend_sections/​monitoring/​dashboard#​adding_widgets|Adding widgets]] for details on the changes.
 +
 +==== Animated GIF support in maps ====
 +
 +It is now supported to upload animated GIF images to use in Zabbix maps. To support animated GIF upload, the required minimum GD library version is now 2.0.28.
  
 ==== HTML notifications ==== ==== HTML notifications ====
Line 84: Line 231:
  
 ==== Frontend ==== ==== Frontend ====
-This section introduces miscellaneous frontend improvements.+This section introduces miscellaneous frontend improvements:
  
 +=== Mass update ===
 +
 +== Mass update for item prototypes ==
 +
 +It is now possible to also mass update item prototypes used in [[:​manual/​discovery/​low_level_discovery#​item_prototypes|low-level discovery]] rules. To update properties of several item prototypes at once, mark the checkboxes before the items and click on //Mass update//:
 +
 +{{:​manual:​introduction:​item_prot_mass_update.png|}}
 +
 +Then update the properties you need in the mass [[:​manual/​config/​items/​itemupdate|update form]] that is identical to that of regular items.
 +
 +== Mass update for templates ==
 +
 +Mass update is now available in the [[:​manual/​config/​templates/​mass|list]] of templates.
 +
 +=== Filtering ===
 +
 +== Trigger filtering ==
 +
 +Several new options have been added to the filter in the trigger list. Importantly,​ it is now possible to specify multiple hosts and host groups in the filter allowing to view triggers of more than one host, greatly increasing the usability of such functions as mass update.
 +
 +{{:​manual:​introduction:​trigger_filter.png|}}
 +
 +== Item filtering ==
 +
 +It is now possible to specify multiple hosts and host groups in the item filter allowing to view items of more than one host, greatly increasing the usability of such functions as mass update.
 ==== Daemons ==== ==== Daemons ====
 This section introduces miscellaneous Zabbix daemon improvements. This section introduces miscellaneous Zabbix daemon improvements.
 +
 +=== Separate processing for low-level discovery ===
 +
 +Processing low-level discovery rules has been split from data gathering processes into its own processing, consisting of a configurable number of low-level discovery workers and a low-level discovery manager. This change greatly reduces low-level discovery impact on data gathering (poller, trapper processes) and proxy communications (trapper, proxypoller processes). Before data gathering could be delayed because the corresponding data gathering processes were busy with low-level discovery.
 +
 +See also: [[:​manual/​appendix/​config/​zabbix_server|StartLLDProcessors]] parameter
 +
 +==== See also ====
 +
 +  * [[:​manual/​installation/​template_changes|Template changes]]