Zabbix Documentation 3.2

3.04.04.4 (current)| In development:5.0 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools


manual:introduction:whatsnew320

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:whatsnew320 [2016/09/01 07:28]
martins-v more verbose entry
manual:introduction:whatsnew320 [2019/02/12 06:41] (current)
martins-v linking to template changes
Line 1: Line 1:
 ===== - #5 What's new in Zabbix 3.2.0 ===== ===== - #5 What's new in Zabbix 3.2.0 =====
- 
-<note warning>​​Zabbix 3.2.0 is not released yet.</​note>​ 
  
 ==== - Event correlation ==== ==== - Event correlation ====
Line 48: Line 46:
 ==== - View problems more clearly ==== ==== - View problems more clearly ====
  
-The monitoring part of Zabbix frontend has gained ​an new dedicated "​Problems"​ view. This section is for displaying problems only and it follows immediately after //​Monitoring//​ -> //​Dashboard//​. The new section is intended to give users a much clearer view of problems in comparison to the two //​Monitoring//​ -> //​Triggers//​ and //​Monitoring//​ -> //Events// sections used for this purpose previously.+The monitoring part of Zabbix frontend has gained ​new dedicated "​Problems"​ view. This section is for displaying problems only and it follows immediately after //​Monitoring//​ -> //​Dashboard//​. The new section is intended to give users a much clearer view of problems in comparison to the two //​Monitoring//​ -> //​Triggers//​ and //​Monitoring//​ -> //Events// sections used for this purpose previously.
  
 {{:​manual:​introduction:​problems_new.png?​600|}} {{:​manual:​introduction:​problems_new.png?​600|}}
Line 73: Line 71:
 For more information see the [[:​manual/​config/​macros/​macro_functions|macro function]] section. For more information see the [[:​manual/​config/​macros/​macro_functions|macro function]] section.
  
-==== - Nested host groups ====+==== - Nested ​representation of host groups ====
  
-Nested ​host groups have been introduced to allow logical grouping ​of host groups ​that are related.+Having a built-in mechanism for a logical grouping of host groups is something that is very much required, especially in larger organizations. While the new Zabbix version does not support a full nesting of host groups where a higher-level host group would automatically inherit all hosts of a nested host group, first steps towards nested ​host groups have been taken by allowing a nested representation ​of host groups ​and aligning the permission schema to host group nesting.
  
-Nesting ​is accomplished by using the '/'​ forward slash to separate logical levels.+Nested representation of host groups ​is accomplished by using the '/'​ forward slash to separate ​the logical levels ​of host groups.
  
 {{:​manual:​introduction:​host_groups_nested_new.png|}} {{:​manual:​introduction:​host_groups_nested_new.png|}}
 +
 +For more information see: [[:​manual/​config/​hosts/​host#​configuring_a_host_group|Configuring a host group]]
 +
 +Note that nested host group functionality is extended in [[:​manual/​introduction/​whatsnew322#​nested_host_group_support|Zabbix 3.2.2]].
  
 In a related development,​ the host group permission tab has been significantly reworked in user group and user configuration forms. In a related development,​ the host group permission tab has been significantly reworked in user group and user configuration forms.
Line 137: Line 139:
 The logic of delaying problem notifications during host maintenance has been changed. ​ The logic of delaying problem notifications during host maintenance has been changed. ​
  
-In previous Zabbix versions, it was possible to "​suppress" ​problem notifications during a host maintenance period (using the //​Maintenance status = not in "​maintenance"//​ action condition). Then, if the problem persisted, problem events were generated immediately after the maintenance. However, it was not always easy for users to understand what generated those events and why. Acknowledgement information of the original event was also lost.+In previous Zabbix versions, it was possible to skip problem notifications during a host maintenance period (using the //​Maintenance status = not in "​maintenance"//​ action condition). Then, if the problem persisted, problem events were generated immediately after the maintenance. However, since the original problem messages were suppressed, it was not always easy for users to understand what generated those events and why. Acknowledgement information of the original event was also lost.
  
-In the new version, the old mechanism is dropped. Instead there is an new option in action configuration,​ which allows to pause notifications in the host maintenance phase if you wish so. +In the new version, the old mechanism is dropped. Instead there is new option in action configuration,​ which allows to pause notifications in the host maintenance phase if you wish so. 
  
 {{:​manual:​introduction:​pause_escalations.png|}} {{:​manual:​introduction:​pause_escalations.png|}}
  
-If notifications are paused during maintenance,​ they get back on course ​after the maintenance,​ according to the escalation scenario. ​+If notifications are paused during maintenance,​ they get started ​after the maintenance,​ according to the escalation scenario. That means that no messages are skipped, simply delayed.
  
 See also: See also:
  
-  * [[:​manual/​maintenance|Maintenance]] 
-  * [[:​manual/​config/​notifications/​action/​escalations|Escalations]] 
   * [[:​manual/​installation/​upgrade_notes_320#​delaying_escalations_during_maintenance|Upgrade notes for 3.2]]   * [[:​manual/​installation/​upgrade_notes_320#​delaying_escalations_during_maintenance|Upgrade notes for 3.2]]
 +  * [[:​manual/​config/​notifications/​action/​operation#​configuring_an_operation|Action operations]]
  
 ==== - Viewable items, triggers, graphs created by LLD ==== ==== - Viewable items, triggers, graphs created by LLD ====
Line 167: Line 168:
  
 ==== - Frontend improvements ==== ==== - Frontend improvements ====
 +
 +=== - Acknowledgement of OK events removed ===
 +
 +A separate option for acknowledging OK events along with problem events has been removed from the acknowledgement screen. It is now possible to acknowledge problem events only, with the choice of acknowledging just one or all problem events of the trigger(s).
 +
 +{{:​manual:​introduction:​ack_new.png?​600|}}
  
 === - Several new filters === === - Several new filters ===
Line 192: Line 199:
   * //​Administration//​ -> //Media types//   * //​Administration//​ -> //Media types//
  
-{{:​manual:​introduction:​new_filters.png|}}+{{:​manual:​introduction:​new_filters.png?600|}}
  
 === - Updated translations === === - Updated translations ===
Line 213: Line 220:
   * Ukrainian   * Ukrainian
  
-==== - Daemon improvements ====+==== - Daemon ​changes/improvements ====
  
 === - Host availability,​ discovery, auto-registration and history data validation === === - Host availability,​ discovery, auto-registration and history data validation ===
  
 Zabbix server will validate host availability,​ discovery and auto-registration data received from proxy stricter and will reject the whole data packet in case it contains invalid entries. At the same time fewer but more informative messages will be written to the log file. Also, if passive proxy for example returns invalid host availability data, server will skip polling discovery, history and auto-registration data from that proxy. Apart from better messages processing of historical data from proxies and active agents is not affected. Log file messages containing name, IP address and error description will help troubleshooting misconfiguration issues such as proxypoller connecting server'​s trapper port or agent instead of proxy. Zabbix server will validate host availability,​ discovery and auto-registration data received from proxy stricter and will reject the whole data packet in case it contains invalid entries. At the same time fewer but more informative messages will be written to the log file. Also, if passive proxy for example returns invalid host availability data, server will skip polling discovery, history and auto-registration data from that proxy. Apart from better messages processing of historical data from proxies and active agents is not affected. Log file messages containing name, IP address and error description will help troubleshooting misconfiguration issues such as proxypoller connecting server'​s trapper port or agent instead of proxy.
 +
 +=== - Configuration parameters ===
 +
 +== Flexible item key parameters for alias in agent configuration ==
 +
 +Zabbix agent [[manual/​appendix/​config/​zabbix_agentd|configuration file]] parameter //Alias// now supports setting flexible key parameters. For instance, now it is possible to set an alias with wildcard as a parameter (''​alias[*]''​) and use it on item setup entering required valid key parameters as usual (e.g., ''​alias[all,​avg5]''​). The other benefit of such flexibility is that now it is possible to pass any parameters to a key which originally doesn'​t support parameters. In such case passed parameters will be ignored and original key processed. This may be used [[manual/​discovery/​low_level_discovery#​setting_up_multiple_lld_rules_for_the_same_item|setting up multiple low-level discovery rules]] for the same items.
  
 ==== - Item changes/​improvements ==== ==== - Item changes/​improvements ====
  
 **log.count** and **logrt.count** - two new items have been added along with a '​maxdelay'​ parameter for log monitoring. For more information see: [[#​Coping_with_fast-growing_log_files|Coping with fast-growing log files]]. **log.count** and **logrt.count** - two new items have been added along with a '​maxdelay'​ parameter for log monitoring. For more information see: [[#​Coping_with_fast-growing_log_files|Coping with fast-growing log files]].
 +
 +==== - VMware monitoring improvements ====
 +
 +Two new [[:​manual/​config/​items/​itemtypes/​simple_checks/​vmware_keys|item keys]] to read the datacenter name have been added for hypervisors and virtual machines:
 +  * ''​vmware.hv.datacenter.name[<​url>,<​uuid>​]''​
 +  * ''​vmware.vm.datacenter.name[<​url>,<​uuid>​]''​
 +
 +A ''​{#​DATACENTER.NAME}''​ field has been added to the hypervisor and virtual machine discovery item keys ''​vmware.hv.discovery''​ and ''​vmware.vm.discovery''​.
  
 ==== - Trigger functions ==== ==== - Trigger functions ====
Line 245: Line 266:
  
 Advantage - logical OR and AND expressions are evaluated, if possible, to known values. For example: Advantage - logical OR and AND expressions are evaluated, if possible, to known values. For example:
-  * '1 or Unsuported_item1.some_function()'​ is evaluated to 1 (True) +  * '1 or Unsuported_item1.some_function()'​ is evaluated to '1' ​(True) 
-  * '0 and Unsuported_item1.some_function()'​ is evaluated to 0 (False)+  * '0 and Unsuported_item1.some_function()'​ is evaluated to '0' ​(False)
  
 See [[:​manual/​config/​triggers/​expression#​expressions_with_unsupported_items_and_unknown_values|Expressions with unsupported items and unknown values]]. See [[:​manual/​config/​triggers/​expression#​expressions_with_unsupported_items_and_unknown_values|Expressions with unsupported items and unknown values]].
-==== - VMware monitoring improvements ==== 
- 
-Two new item keys to read the datacenter name have been added for hypervisors and virtual machines: 
-  * ''​vmware.hv.datacenter.name[<​url>,<​uuid>​]''​ 
-  * ''​vmware.vm.datacenter.name[<​url>,<​uuid>​]''​ 
- 
-A ''​{#​DATACENTER.NAME}''​ field has been added to the hypervisor and virtual machine discovery item keys ''​vmware.hv.discovery''​ and ''​vmware.vm.discovery''​. 
  
 ==== - Miscellaneous improvements ==== ==== - Miscellaneous improvements ====
Line 262: Line 276:
 The history_text.id and history_log.id fields were removed from the corresponding history tables. Those fields were redundant and removing them will simplify history table structures and will remove unnecessary overhead when inserting values. The history_text.id and history_log.id fields were removed from the corresponding history tables. Those fields were redundant and removing them will simplify history table structures and will remove unnecessary overhead when inserting values.
  
 +==== See also ====
 +
 +  * [[:​manual/​installation/​template_changes|Template changes]]