manual:introduction:whatsnew220

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:whatsnew220 [2018/05/10 15:33]
martins-v consistent spelling fix: acknowledgement
manual:introduction:whatsnew220 [2021/11/13 16:57] (current)
Line 11: Line 11:
 {{templates_web.png|}} {{templates_web.png|}}
  
-In the frontend, web scenarios are now created in //​Configuration ​-> Templates// and //​Configuration ​-> Hosts// respectively,​ similarly to the way items, triggers etc. are created. A separate //​Configuration ​-> Web// menu exists no more.+In the frontend, web scenarios are now created in //​Configuration ​→ Templates// and //​Configuration ​→ Hosts// respectively,​ similarly to the way items, triggers etc. are created. A separate //​Configuration ​→ Web// menu exists no more.
  
 === - New configuration parameters === === - New configuration parameters ===
Line 85: Line 85:
 Additionally,​ LLD macros are supported in the parameters of an item key, making it possible to use a macro like {Cisco switch:​ifAlias[{#​SNMPINDEX}].last()} Additionally,​ LLD macros are supported in the parameters of an item key, making it possible to use a macro like {Cisco switch:​ifAlias[{#​SNMPINDEX}].last()}
  
-{HOST.HOST<​1-9>​} macro can be used to reference a host: {{HOST.HOST}:​ifAlias[{#​SNMPINDEX}].last()}. As the graph may contain items from several hosts, {HOST.HOST} and {HOST.HOST1} will refer to the first host, {HOST.HOST2} to the second and so on.+{HOST.HOST<​1-9>​} macro can be used to reference a host: ''​%%{{%%HOST.HOST}:​ifAlias[{#​SNMPINDEX}].last()}''​. As the graph may contain items from several hosts, {HOST.HOST} and {HOST.HOST1} will refer to the first host, {HOST.HOST2} to the second and so on.
  
 ==== - Notifications on unsupported items, unknown triggers ==== ==== - Notifications on unsupported items, unknown triggers ====
Line 98: Line 98:
  
 Value mapping in Zabbix 2.0 was available for numeric integer data types only. In 2.2.0, full support for character and numeric float types has been implemented. For example, a backup related value map could be: Value mapping in Zabbix 2.0 was available for numeric integer data types only. In 2.2.0, full support for character and numeric float types has been implemented. For example, a backup related value map could be:
-  * F -> Full +  * F → Full 
-  * D -> Differential +  * D → Differential 
-  * I -> Incremental+  * I → Incremental
  
-In //​Monitoring// ​-> //Latest data//, displayed values are shortened to 20 symbols. If value mapping is used, this shortening is not applied to the mapped value, but only to the raw value separately (displayed in parenthesis).+In //​Monitoring// ​→ //Latest data//, displayed values are shortened to 20 symbols. If value mapping is used, this shortening is not applied to the mapped value, but only to the raw value separately (displayed in parenthesis).
  
 Note that value mapping is not available for text or log data types. Note that value mapping is not available for text or log data types.
Line 126: Line 126:
 For example, only triggers starting with the //Warning// level can be displayed. //​Information//​ and //Not classified//​ level triggers will not be reflected in the map. For example, only triggers starting with the //Warning// level can be displayed. //​Information//​ and //Not classified//​ level triggers will not be reflected in the map.
  
-The level selected in map configuration can be optionally overwritten when viewing maps in //​Monitoring ​-> Maps//:+The level selected in map configuration can be optionally overwritten when viewing maps in //​Monitoring ​→ Maps//:
  
 {{map_severity.png|}} {{map_severity.png|}}
Line 141: Line 141:
 Previously the Zabbix housekeeper process could be completely disabled, using the DisableHousekeeping server configuration option. That was the recommended course of action if housekeeping encountered problems with, say, a large history table. That, however, also meant disabling all housekeeping tasks, while the real problem was only with one. Previously the Zabbix housekeeper process could be completely disabled, using the DisableHousekeeping server configuration option. That was the recommended course of action if housekeeping encountered problems with, say, a large history table. That, however, also meant disabling all housekeeping tasks, while the real problem was only with one.
  
-In Zabbix 2.2 a finer control over housekeeping tasks is introduced. The DisableHousekeeping parameter is not supported anymore. Instead, there is a fine-level control over housekeeping tasks in the frontend, in //​Administration ​-> General ​-> [[manual:​web_interface:​frontend_sections:​administration:​general|Housekeeper]]//,​ where housekeeping tasks can be enabled/​disabled on a per-task basis.+In Zabbix 2.2 a finer control over housekeeping tasks is introduced. The DisableHousekeeping parameter is not supported anymore. Instead, there is a fine-level control over housekeeping tasks in the frontend, in //​Administration ​→ General ​→ [[manual:​web_interface:​frontend_sections:​administration:​general|Housekeeper]]//,​ where housekeeping tasks can be enabled/​disabled on a per-task basis.
  
 ==== - Permission improvements ==== ==== - Permission improvements ====
Line 155: Line 155:
 ==== - Accessible history data for disabled hosts ==== ==== - Accessible history data for disabled hosts ====
  
-Disabled hosts are made available for host selection in //​Monitoring ​-> Latest data// as well as in //​Monitoring ​-> Graphs// and //​Monitoring ​-> Web//. Access to latest data includes access to graphs and item value lists for disabled hosts.+Disabled hosts are made available for host selection in //​Monitoring ​→ Latest data// as well as in //​Monitoring ​→ Graphs// and //​Monitoring ​→ Web//. Access to latest data includes access to graphs and item value lists for disabled hosts.
  
 Where access to disabled host information is available, they are highlighted in red in host dropdowns and lists: Where access to disabled host information is available, they are highlighted in red in host dropdowns and lists:
Line 363: Line 363:
 The set of macros previously supported in trigger names is now also supported in trigger descriptions:​ {HOST.HOST},​ {HOST.NAME},​ {HOST.CONN},​ {HOST.DNS}, {HOST.IP}, {ITEM.VALUE},​ {ITEM.LASTVALUE} and {$MACRO}. The set of macros previously supported in trigger names is now also supported in trigger descriptions:​ {HOST.HOST},​ {HOST.NAME},​ {HOST.CONN},​ {HOST.DNS}, {HOST.IP}, {ITEM.VALUE},​ {ITEM.LASTVALUE} and {$MACRO}.
  
-These macros will be expanded when viewing the trigger comment in //​Monitoring ​-> Triggers// and also inside the {TRIGGER.DESCRIPTION} macro when used in notifications.+These macros will be expanded when viewing the trigger comment in //​Monitoring ​→ Triggers// and also inside the {TRIGGER.DESCRIPTION} macro when used in notifications.
  
 === - Macros in global scripts === === - Macros in global scripts ===
Line 400: Line 400:
 === - Configuration options and monitoring data accessible from host inventory === === - Configuration options and monitoring data accessible from host inventory ===
  
-In [[manual:​config:​hosts:​inventory#​inventory_overview|host inventory details]] (accessible through //​Inventory ​-> Hosts//) there are two tabs now - //​Overview//​ and //​Details//​. While //​Details//,​ as before, present all inventory data maintained with the host, //​Overview//​ presents some useful general information about the host along with links to predefined scripts and various aspects of host configuration and monitoring data.+In [[manual:​config:​hosts:​inventory#​inventory_overview|host inventory details]] (accessible through //​Inventory ​→ Hosts//) there are two tabs now - //​Overview//​ and //​Details//​. While //​Details//,​ as before, present all inventory data maintained with the host, //​Overview//​ presents some useful general information about the host along with links to predefined scripts and various aspects of host configuration and monitoring data.
  
 {{inventory_overview.png|}} {{inventory_overview.png|}}
Line 428: Line 428:
   * acknowledgement and action details popup of the Dashboard //Last 20 issues// widget   * acknowledgement and action details popup of the Dashboard //Last 20 issues// widget
   * acknowledgement and action details popup of the //Host/host group issues// widget in screens   * acknowledgement and action details popup of the //Host/host group issues// widget in screens
-  * acknowlegdement details (accessible from Monitoring ​-> Triggers)+  * acknowlegdement details (accessible from Monitoring ​→ Triggers)
   * event details   * event details
   * user group member list   * user group member list
Line 437: Line 437:
 === - Ability to view acknowledgements in trigger status page === === - Ability to view acknowledgements in trigger status page ===
  
-Previously, when viewing triggers without events in //​Monitoring ​-> Triggers// page, it was possible to see that a trigger has been acknowledged,​ but there was no way to see the acknowledgement. The acknowledged status can now be clicked to view the details.+Previously, when viewing triggers without events in //​Monitoring ​→ Triggers// page, it was possible to see that a trigger has been acknowledged,​ but there was no way to see the acknowledgement. The acknowledged status can now be clicked to view the details.
  
 === - Overview filtered by application === === - Overview filtered by application ===
  
-The //​Monitoring ​-> Overview// section has gained an additional filtering-by-application option. ​+The //​Monitoring ​→ Overview// section has gained an additional filtering-by-application option. ​
  
 Previously, all items or all triggers would be displayed in the overview of hosts, which did not allow to focus on the information one was mostly interested in. Now the overview can be narrowed down by selecting a specific application and only displaying those items or triggers that are under the selected application. Previously, all items or all triggers would be displayed in the overview of hosts, which did not allow to focus on the information one was mostly interested in. Now the overview can be narrowed down by selecting a specific application and only displaying those items or triggers that are under the selected application.
Line 447: Line 447:
 {{overview_appl.png|}} {{overview_appl.png|}}
  
-The overview filtering option is also made available in //​Configuration ​-> Screens//. When configuring //Data overview// and //Trigger overview// [[manual:​config:​visualisation:​screens#​adding_elements|screen elements]], a new //​Application//​ field is available for entering the required application name:+The overview filtering option is also made available in //​Configuration ​→ Screens//. When configuring //Data overview// and //Trigger overview// [[manual:​config:​visualisation:​screens#​adding_elements|screen elements]], a new //​Application//​ field is available for entering the required application name:
  
 {{screen_element_appl.png|}} {{screen_element_appl.png|}}
  
-The result can be a very neat and concise screen element for viewing in //​Monitoring ​-> Screens//:+The result can be a very neat and concise screen element for viewing in //​Monitoring ​→ Screens//:
  
 {{screen_appl.png|}} {{screen_appl.png|}}