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/20 15:17]
asaveljevs [5.10 Delaying escalations during maintenance] fixed typo: "an new" -> "a new"
manual:introduction:whatsnew320 [2019/02/12 06:41]
martins-v linking to template changes
Line 80: Line 80:
  
 For more information see: [[:​manual/​config/​hosts/​host#​configuring_a_host_group|Configuring a host group]] 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 a 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 a new option in action configuration,​ which allows to pause notifications in the host maintenance phase if you wish so. 
Line 143: Line 145:
 {{:​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 219: 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 ====
Line 269: 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]]