Zabbix Documentation 2.2

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: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
Last revision Both sides next revision
manual:introduction:whatsnew220 [2014/09/25 14:40]
sasha Page moved from 2.2:manual:introduction:whatsnew220 to manual:introduction:whatsnew220
manual:introduction:whatsnew220 [2018/05/10 15:33]
martins-v consistent spelling fix: acknowledgement
Line 9: Line 9:
 Starting with Zabbix 2.2.0 web scenarios can be template members in the same way as items, triggers, graphs, screens and low level discovery rules. If a template is applied to several hosts, all hosts will inherit the web scenarios in the template. Starting with Zabbix 2.2.0 web scenarios can be template members in the same way as items, triggers, graphs, screens and low level discovery rules. If a template is applied to several hosts, all hosts will inherit the web scenarios in the template.
  
-{{:​2.2:​manual:​introduction:​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.
Line 17: Line 17:
 The web scenario configuration form has gained new parameters. The web scenario configuration form has gained new parameters.
  
-{{:​2.2:​manual:​introduction:​web_new_param.png|}}+{{web_new_param.png|}}
  
 == Retries of web scenario steps === == Retries of web scenario steps ===
Line 25: Line 25:
 == Use of HTTP proxy === == Use of HTTP proxy ===
  
-The use of an HTTP proxy can now be specified directly in the web scenario [[:2.2/manual/web_monitoring#​configuring_a_web_scenario|configuration]] form.+The use of an HTTP proxy can now be specified directly in the web scenario [[manual:web_monitoring#​configuring_a_web_scenario|configuration]] form.
  
 === - More options with variables === === - More options with variables ===
Line 43: Line 43:
 Variables can now be defined not only on a scenario level, but on a step level as well. A step-level variable overrides a scenario-level variable or the variables of the previous step. Variables can now be defined not only on a scenario level, but on a step level as well. A step-level variable overrides a scenario-level variable or the variables of the previous step.
  
-{{:​2.2:​manual:​introduction:​variables_step.png?​570|}}+{{variables_step.png?​570|}}
  
 === - Improved error logging === === - Improved error logging ===
Line 62: Line 62:
 A new feature in Zabbix 2.2.0 is VMware virtual machine monitoring. It allows to monitor VMware vCenter and vSphere installations for various VMware hypervisor and virtual machine properties and statistics. ​ A new feature in Zabbix 2.2.0 is VMware virtual machine monitoring. It allows to monitor VMware vCenter and vSphere installations for various VMware hypervisor and virtual machine properties and statistics. ​
  
-Zabbix can use low-level discovery rules to automatically discover VMware hypervisors and virtual machines and create hosts to monitor them, based on pre-defined host prototypes. See [[:2.2/manual/vm_monitoring|Virtual machine monitoring]] for more detailed information.+Zabbix can use low-level discovery rules to automatically discover VMware hypervisors and virtual machines and create hosts to monitor them, based on pre-defined host prototypes. See [[manual:vm_monitoring|Virtual machine monitoring]] for more detailed information.
  
 ==== - Support for IPMI discrete sensors ==== ==== - Support for IPMI discrete sensors ====
  
-Previously Zabbix supported reading only IPMI threshold (analog) sensors. Zabbix 2.2.0 adds reading states of [[:2.2/manual/config/items/itemtypes/ipmi#​notes_on_ipmi_discrete_sensors|IPMI discrete sensors]].+Previously Zabbix supported reading only IPMI threshold (analog) sensors. Zabbix 2.2.0 adds reading states of [[manual:config:items:itemtypes:ipmi#​notes_on_ipmi_discrete_sensors|IPMI discrete sensors]].
 A new function [[#​logical_functions_for_testing_bits|band()]] (bitwise AND) and an improved function [[#​logical_functions_for_testing_bits|count()]] can be used for testing state of bits of discrete sensors. A new function [[#​logical_functions_for_testing_bits|band()]] (bitwise AND) and an improved function [[#​logical_functions_for_testing_bits|count()]] can be used for testing state of bits of discrete sensors.
  
Line 73: Line 73:
 Loadable modules, new in Zabbix 2.2, offer a way of extending Zabbix functionality that is more performance-minded than the user parameter option or external checks. In addition to greater performance and the ability to implement any logic, modules have the potential to be developed and shared within the Zabbix community. Loadable modules, new in Zabbix 2.2, offer a way of extending Zabbix functionality that is more performance-minded than the user parameter option or external checks. In addition to greater performance and the ability to implement any logic, modules have the potential to be developed and shared within the Zabbix community.
  
-Supported for Unix-like systems, a loadable module is basically a shared library used by Zabbix server or agent and loaded on startup. To deal with the modules, Zabbix server and agent support two new configuration parameters: ''​LoadModulePath''​ and ''​LoadModule''​. The modules must be located in a directory specified by ''​LoadModulePath''​. It is allowed to include multiple ''​LoadModule''​ parameters.+Supported for Unix-like systems, a loadable module is basically a shared library used by Zabbix server, proxy or agent and loaded on startup. To deal with the modules, Zabbix server, proxy and agent support two new configuration parameters: ''​LoadModulePath''​ and ''​LoadModule''​. The modules must be located in a directory specified by ''​LoadModulePath''​. It is allowed to include multiple ''​LoadModule''​ parameters.
  
-A sample module written in C is included in Zabbix 2.2 under src/​modules/​dummy. It can be used as a template for your own modules. To learn more about the loadable module option, visit the respective documentation [[:2.2/manual/config/items/loadablemodules|section]].+A sample module written in C is included in Zabbix 2.2 under src/​modules/​dummy. It can be used as a template for your own modules. To learn more about the loadable module option, visit the respective documentation [[manual:config:items:loadablemodules|section]].
  
 ==== - Referencing item values in graph names ==== ==== - Referencing item values in graph names ====
Line 83: Line 83:
 Similarly to map labels, only **avg()**, **last()**, **max()** and **min()** functions with seconds as parameter are supported within this macro in graph names. Value mapping is supported as well. Similarly to map labels, only **avg()**, **last()**, **max()** and **min()** functions with seconds as parameter are supported within this macro in graph names. Value mapping is supported as well.
  
-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(0)}+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(0)}. 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 91: Line 91:
 In previous Zabbix versions it was not possible to be notified on unsupported items. If some item turned unsupported (and stopped gathering data) it could stay unnoticed for a long period of time. The only way of spotting an unsupported item was to look at the list of items all the time, which was rather impractical. In previous Zabbix versions it was not possible to be notified on unsupported items. If some item turned unsupported (and stopped gathering data) it could stay unnoticed for a long period of time. The only way of spotting an unsupported item was to look at the list of items all the time, which was rather impractical.
  
-Starting with Zabbix 2.2 a new concept of [[:2.2/manual/config/events/sources#​internal_events|internal events]] is introduced. Internal events happen not only when items become unsupported,​ but also when a low-level discovery rule becomes unsupported or a trigger goes into an unknown state.+Starting with Zabbix 2.2 a new concept of [[manual:config:events:sources#​internal_events|internal events]] is introduced. Internal events happen not only when items become unsupported,​ but also when a low-level discovery rule becomes unsupported or a trigger goes into an unknown state.
  
-The benefit of having internal events is that users can configure actions based on these events, similarly to actions based on trigger events, and receive notifications for unsupported items (unsupported LLD rules, unknown triggers). For more information,​ see a [[:2.2/manual/config/notifications/unsupported_item|how-to section]] for configuring notifications on unsupported items.+The benefit of having internal events is that users can configure actions based on these events, similarly to actions based on trigger events, and receive notifications for unsupported items (unsupported LLD rules, unknown triggers). For more information,​ see a [[manual:config:notifications:unsupported_item|how-to section]] for configuring notifications on unsupported items.
  
 ==== - Value mapping for string and float type data ==== ==== - Value mapping for string and float type data ====
Line 122: Line 122:
 Map configuration has gained the option of defining the lowest trigger severity. This way only triggers on the defined level and above will be displayed in the map, and triggers below the defined severity will not be displayed. Map configuration has gained the option of defining the lowest trigger severity. This way only triggers on the defined level and above will be displayed in the map, and triggers below the defined severity will not be displayed.
  
-{{:​2.2:​manual:​introduction:​map_config_new.png|}}+{{map_config_new.png|}}
  
 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.
Line 128: Line 128:
 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//:
  
-{{:​2.2:​manual:​introduction:​map_severity.png|}}+{{map_severity.png|}}
  
 === - Map label length limit increased === === - Map label length limit increased ===
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 -> [[:2.2/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 159: Line 159:
 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:
  
-{{:​2.2:​manual:​introduction:​disabled_host_latest.png|}}+{{disabled_host_latest.png|}}
  
 ==== - Changed maintenance period logic ==== ==== - Changed maintenance period logic ====
Line 167: Line 167:
 ==== - SNMPv3 monitoring ==== ==== - SNMPv3 monitoring ====
  
-{{:​2.2:​manual:​introduction:​snmpv3_check.png|}}+{{snmpv3_check.png|}}
  
 === - Context name support === === - Context name support ===
Line 206: Line 206:
   * ''​vfs.file.regmatch[]''​ has gained the //<start line>// and //<end line>// parameters   * ''​vfs.file.regmatch[]''​ has gained the //<start line>// and //<end line>// parameters
  
-See also Zabbix agent [[:2.2/manual/config/items/itemtypes/zabbix_agent|item documentation]].+See also Zabbix agent [[manual:config:items:itemtypes:zabbix_agent|item documentation]].
  
 ==== - Support of internal checks for proxies ==== ==== - Support of internal checks for proxies ====
Line 227: Line 227:
   * **zabbix[wcache,<​cache>,<​mode>​]** ​ (trends cache is not supported by proxies)   * **zabbix[wcache,<​cache>,<​mode>​]** ​ (trends cache is not supported by proxies)
  
-See detailed specifications in [[:2.2/manual/config/items/itemtypes/internal|internal checks documentation]].+See detailed specifications in [[manual:config:items:itemtypes:internal|internal checks documentation]].
  
 ==== - Templates ==== ==== - Templates ====
Line 237: Line 237:
 Various services from the agentless template have been split out in individual templates. Various services from the agentless template have been split out in individual templates.
  
-All triggers in //Template App Zabbix Server// and //Template App Zabbix Proxy// have been updated to be less sensitive and use [[:2.2/manual/config/triggers/expression#​hysteresis|hysteresis]]. ​+All triggers in //Template App Zabbix Server// and //Template App Zabbix Proxy// have been updated to be less sensitive and use [[manual:config:triggers:expression#​hysteresis|hysteresis]]. ​
  
-All templates have been updated to use [[:2.2/manual/config/triggers/suffixes#​time_unit_suffixes|suffixes]] and [[:2.2/manual/appendix/triggers/functions|aggregate functions]].+All templates have been updated to use [[manual:config:triggers:suffixes#​time_unit_suffixes|suffixes]] and [[manual:appendix:triggers:functions|aggregate functions]].
  
 All OS templates have been updated to include memory graph. All OS templates have been updated to include memory graph.
Line 250: Line 250:
 === - Database monitoring is now official === === - Database monitoring is now official ===
  
-ODBC monitoring has been around in Zabbix for quite some time, but so far it has lacked proper documentation and has had the status of an unofficial feature. Now the item is finally [[:2.2/manual/config/items/itemtypes/odbc_checks|documented]] and can boast the status of an official feature.+ODBC monitoring has been around in Zabbix for quite some time, but so far it has lacked proper documentation and has had the status of an unofficial feature. Now the item is finally [[manual:config:items:itemtypes:odbc_checks|documented]] and can boast the status of an official feature.
  
 Also, item configuration for database monitoring in the frontend is improved. Previously, several parameters - DSN, username, password and SQL query were entered into a single field. Now the DSN is moved to the second parameter of the item key, while username and password get their own separate fields and only the SQL query is left in the original field, allowing to enter a multiline query with better readability. Also, item configuration for database monitoring in the frontend is improved. Previously, several parameters - DSN, username, password and SQL query were entered into a single field. Now the DSN is moved to the second parameter of the item key, while username and password get their own separate fields and only the SQL query is left in the original field, allowing to enter a multiline query with better readability.
Line 336: Line 336:
   * **{LLDRULE.ID},​ {LLDRULE.NAME},​ {LLDRULE.KEY},​ {LLDRULE.DESCRIPTION},​ {LLDRULE.STATE}** - return the ID/​name/​key/​description or verbal state of the low-level discovery rule that caused a notification.   * **{LLDRULE.ID},​ {LLDRULE.NAME},​ {LLDRULE.KEY},​ {LLDRULE.DESCRIPTION},​ {LLDRULE.STATE}** - return the ID/​name/​key/​description or verbal state of the low-level discovery rule that caused a notification.
  
-For more details, see [[2.2:manual:​appendix:​macros:​supported_by_location#​overview|macros supported by location]].+For more details, see [[manual:​appendix:​macros:​supported_by_location#​overview|macros supported by location]].
  
 === - Support of LLD macros in trigger expressions === === - Support of LLD macros in trigger expressions ===
Line 352: Line 352:
 can be used in the following trigger prototype: can be used in the following trigger prototype:
  
-  {Template_OS_Linux:​vfs.fs.size[{#​FSNAME},​pused].last(0)}>​{#​MY_CUSTOM_MACRO} ​+  {Template_OS_Linux:​vfs.fs.size[{#​FSNAME},​pused].last()}>​{#​MY_CUSTOM_MACRO} ​
  
 To be expanded correctly, the macro must return a numeric value. If the macro value is not numeric or no value is found, a real trigger will not be created. To be expanded correctly, the macro must return a numeric value. If the macro value is not numeric or no value is found, a real trigger will not be created.
  
 +=== - Support of LLD macros in item and trigger descriptions ===
 +
 +Low-level discovery macros can now be used in trigger and item descriptions.
 === - Macros in trigger descriptions === === - Macros in trigger descriptions ===
  
Line 364: Line 367:
 === - Macros in global scripts === === - Macros in global scripts ===
  
-User macros are now supported in [[:2.2/manual/web_interface/frontend_sections/administration/scripts|global script]] commands and confirmation texts.+User macros are now supported in [[manual:web_interface:frontend_sections:administration:scripts|global script]] commands and confirmation texts.
  
 The confirmation text for global scripts will now also expand host name macros - {HOST.HOST},​ {HOST.NAME} and host connection macros - {HOST.IP}, {HOST.DNS}, {HOST.CONN}. The confirmation text for global scripts will now also expand host name macros - {HOST.HOST},​ {HOST.NAME} and host connection macros - {HOST.IP}, {HOST.DNS}, {HOST.CONN}.
Line 370: Line 373:
 === - User macros in allowed hosts === === - User macros in allowed hosts ===
  
-User macros are now supported in the //Allowed hosts// field of [[:2.2/manual/config/items/itemtypes/trapper|trapper]] items.+User macros are now supported in the //Allowed hosts// field of [[manual:config:items:itemtypes:trapper|trapper]] items.
  
 ==== - Frontend improvements ==== ==== - Frontend improvements ====
Line 378: Line 381:
 With the redesign of Zabbix 2.0, some frontend pages did not look very satisfactory at a more narrow browser window size (or on small form factor devices). Significant improvements have been made for Zabbix 2.2, and now most of the pages should scale down much better. For example, the general frontend setting page at the same width before and after the redesign looks quite differently:​ With the redesign of Zabbix 2.0, some frontend pages did not look very satisfactory at a more narrow browser window size (or on small form factor devices). Significant improvements have been made for Zabbix 2.2, and now most of the pages should scale down much better. For example, the general frontend setting page at the same width before and after the redesign looks quite differently:​
  
-|{{:​2.2:​manual:​introduction:​layout_before.png|}}|{{:​2.2:​manual:​introduction:​layout_after.png|}}|+|{{layout_before.png|}}|{{layout_after.png|}}|
 |Before the redesign. ​ |After the redesign. ​ | |Before the redesign. ​ |After the redesign. ​ |
  
Line 391: Line 394:
 The filter has a new //Show details// option. If used, it allows to extend displayable information on the items by such details as refresh interval, history and trends settings, item type and item errors (fine/​unsupported). ​ The filter has a new //Show details// option. If used, it allows to extend displayable information on the items by such details as refresh interval, history and trends settings, item type and item errors (fine/​unsupported). ​
  
-{{:​2.2/​manual/​introduction/​latest_filter.png?​600|}}+{{latest_filter.png?​600|}}
  
 A direct link to item configuration is also available allowing to quickly tweak an item from the monitoring section. A direct link to item configuration is also available allowing to quickly tweak an item from the monitoring section.
Line 397: Line 400:
 === - Configuration options and monitoring data accessible from host inventory === === - Configuration options and monitoring data accessible from host inventory ===
  
-In [[:2.2/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.
  
-{{:​2.2/​manual/​introduction/​inventory_overview.png|}}+{{inventory_overview.png|}}
  
 === - More flexible dashboard filter === === - More flexible dashboard filter ===
Line 407: Line 410:
 For example, we may have hosts 001, 002, 003 in Group A and hosts 002, 003 in Group B as well. If we select to show Group A and hide Group B at the same time, only data from host 001 will be displayed in the Dashboard. For example, we may have hosts 001, 002, 003 in Group A and hosts 002, 003 in Group B as well. If we select to show Group A and hide Group B at the same time, only data from host 001 will be displayed in the Dashboard.
  
-{{:​2.2:​manual:​introduction:​dashboard_filter_showhide.png|}}+{{dashboard_filter_showhide.png|}}
  
 To enable the show/hide functionality,​ two new fields are introduced in the dashboard filter form for when //​Selected//​ is chosen in Host groups field. //Show selected groups// and //Hide selected groups// both are auto-complete so starting to type the name of a group will offer a dropdown of the matching groups. To enable the show/hide functionality,​ two new fields are introduced in the dashboard filter form for when //​Selected//​ is chosen in Host groups field. //Show selected groups// and //Hide selected groups// both are auto-complete so starting to type the name of a group will offer a dropdown of the matching groups.
Line 413: Line 416:
 If nothing is selected in //Show selected groups//, then all groups will be displayed, except the ones chosen to hide in the //Hide selected groups// field. If nothing is selected in //Show selected groups//, then all groups will be displayed, except the ones chosen to hide in the //Hide selected groups// field.
  
-=== - Displaying name and surname with acknowledgments ​===+=== - Displaying name and surname with acknowledgements ​===
  
 Previously, only user alias was displayed with acknowledged events - that sometimes did not provide sufficient information,​ especially in systems with many system users. ​ Previously, only user alias was displayed with acknowledged events - that sometimes did not provide sufficient information,​ especially in systems with many system users. ​
  
-To make acknowledgment ​information more informative,​ now a name and surname is also displayed, in the 'alias (name surname)'​ format. The name and surname are taken from the respective (now optional) user configuration fields.+To make acknowledgement ​information more informative,​ now a name and surname is also displayed, in the 'alias (name surname)'​ format. The name and surname are taken from the respective (now optional) user configuration fields.
  
-{{:​2.2:​manual:​introduction:​ack_dashboard.png|}}+{{ack_dashboard.png|}}
  
 Name and surname now appears in: Name and surname now appears in:
  
-  * acknowledgment ​and action details popup of the Dashboard //Last 20 issues// widget +  * acknowledgement ​and action details popup of the Dashboard //Last 20 issues// widget 
-  * acknowledgment ​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 
-  * acknowlegdment ​details (accessible from Monitoring -> Triggers)+  * acknowlegdement ​details (accessible from Monitoring -> Triggers)
   * event details   * event details
   * user group member list   * user group member list
Line 442: Line 445:
 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.
  
-{{:​2.2:​manual:​introduction:​overview_appl.png|}}+{{overview_appl.png|}}
  
-The overview filtering option is also made available in //​Configuration -> Screens//. When configuring //Data overview// and //Trigger overview// [[:2.2/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:
  
-{{:​2.2:​manual:​introduction:​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//:
  
-{{:​2.2:​manual:​introduction:​screen_appl.png|}}+{{screen_appl.png|}}
  
 === - Ability to append host groups, item applications on mass update === === - Ability to append host groups, item applications on mass update ===
  
-Previously, when using mass update for [[:2.2/manual/config/hosts/hostupdate|hosts]] or [[:2.2/manual/config/items/itemupdate|items]],​ it was possible to replace host groups and replace item applications. The previous host groups/​applications were unlinked and replaced with the specified ones.+Previously, when using mass update for [[manual:config:hosts:hostupdate|hosts]] or [[manual:config:items:itemupdate|items]],​ it was possible to replace host groups and replace item applications. The previous host groups/​applications were unlinked and replaced with the specified ones.
  
 Now, while the replace function is still available, the mass update forms have gained an additional field for **adding** host groups or item applications. Using this field, both existing host groups/​applications as well as completely new ones can be added. Now, while the replace function is still available, the mass update forms have gained an additional field for **adding** host groups or item applications. Using this field, both existing host groups/​applications as well as completely new ones can be added.
  
-{{:​2.2:​manual:​introduction:​applications_mass_update.png|}}+{{applications_mass_update.png|}}
  
 This additional field is auto-complete and starting to type in it offers a dropdown of the matching host groups/​applications. If the host group/​application is new, it also appears in the dropdown and is indicated by //(new)// after the string. Just scroll down to select. ​ This additional field is auto-complete and starting to type in it offers a dropdown of the matching host groups/​applications. If the host group/​application is new, it also appears in the dropdown and is indicated by //(new)// after the string. Just scroll down to select. ​
Line 466: Line 469:
 //Status of host triggers// and //Status of host group triggers// screen elements have been renamed to //Host issues// and //Host group issues// respectively. ​ //Status of host triggers// and //Status of host group triggers// screen elements have been renamed to //Host issues// and //Host group issues// respectively. ​
  
-Previously, triggers without events would not be displayed in these two widgets, nor in the //Last 20 issues// widget. ​Now triggers ​wothout ​events are displayed as well in all three places.+Previously, triggers without events would not be displayed in these two widgets, nor in the //Last 20 issues// widget. ​As a result, sometimes problem ​triggers ​would disappear from the widgets when their events got deleted by the housekeeper. To fix this, now triggers without ​events are displayed as well.
  
 === - Hierarchy in global scripts === === - Hierarchy in global scripts ===
Line 472: Line 475:
 Global scripts can be put into categories now. To put a script into a category, prefix it with a desired path, for example, ''​Default/'',​ when configuring the script name. Global scripts can be put into categories now. To put a script into a category, prefix it with a desired path, for example, ''​Default/'',​ when configuring the script name.
  
-{{:​2.2:​manual:​introduction:​script_category.png|}}+{{script_category.png|}}
  
 When accessing scripts through the menu in monitoring sections, they will be organized according to the given categories: When accessing scripts through the menu in monitoring sections, they will be organized according to the given categories:
  
-{{:​2.2:​manual:​introduction:​script_category_display.png|}}+{{script_category_display.png|}}
  
 === - Editable discovery checks === === - Editable discovery checks ===
Line 482: Line 485:
 Previously discovery checks within a discovery rule could only be created and deleted. To edit an existing check it had to be deleted first and a new one created, which could be quite cumbersome with a check having several parameters. In Zabbix 2.2, discovery checks can be edited directly. Previously discovery checks within a discovery rule could only be created and deleted. To edit an existing check it had to be deleted first and a new one created, which could be quite cumbersome with a check having several parameters. In Zabbix 2.2, discovery checks can be edited directly.
  
-|{{:​2.2:​manual:​introduction:​drule_checks_old.png|}}\\ \\ Discovery check editing form before Zabbix 2.2.  | +|{{drule_checks_old.png|}}\\ \\ Discovery check editing form before Zabbix 2.2.  | 
-|{{:​2.2:​manual:​introduction:​drule_checks_new.png|}}\\ \\ In Zabbix 2.2 a new **Edit** link is available in the discovery check editing form, allowing to update the check properties directly.|+|{{drule_checks_new.png|}}\\ \\ In Zabbix 2.2 a new **Edit** link is available in the discovery check editing form, allowing to update the check properties directly.|
  
 === - Improved host, template, host group selection === === - Improved host, template, host group selection ===
Line 489: Line 492:
 Host, template and host group selection fields have been improved in several locations in the frontend. Where previously a popup was displayed for selection, now an auto-complete field is available. ​ Host, template and host group selection fields have been improved in several locations in the frontend. Where previously a popup was displayed for selection, now an auto-complete field is available. ​
  
-{{:​2.2/​manual/​introduction/​host_selection.png|}}+{{host_selection.png|}}
  
 Starting to type in it offers a dropdown of the matching entities. Starting to type in it offers a dropdown of the matching entities.
  
-{{:​2.2/​manual/​introduction/​host_selection2.png|}}+{{host_selection2.png|}}
  
 The new selection fields are implemented in:  The new selection fields are implemented in: 
Line 512: Line 515:
 Now, for host/​template/​trigger/​host group conditions in trigger based actions, a multi-select field is available, where several values can be selected and then added in one go. The same improvement is available for host/​template/​host group conditions in internal event based actions. Now, for host/​template/​trigger/​host group conditions in trigger based actions, a multi-select field is available, where several values can be selected and then added in one go. The same improvement is available for host/​template/​host group conditions in internal event based actions.
  
-{{:​2.2/​manual/​introduction/​condition_multiselect.png|}}+{{condition_multiselect.png|}}
  
 The selection field is auto-complete,​ so starting to type in it offers a dropdown of all the matching values. Just scroll down to select. The selection field is auto-complete,​ so starting to type in it offers a dropdown of all the matching values. Just scroll down to select.
Line 527: Line 530:
   * web scenario configuration (for hosts and templates)   * web scenario configuration (for hosts and templates)
  
-{{:​2.2:​manual:​introduction:​search_results_2-2.png?​600|}} ​+{{search_results_2-2.png?​600|}} ​
  
 === - Miscellaneous improvements === === - Miscellaneous improvements ===
  
-Host [[:2.2/manual/config/hosts/hostupdate|mass update]] form has been improved by making it more similar to host properties. Introduction of tabs allows to easier find the desired controls, and options like inventory fields now are much easier to distinguish from other fields.+Host [[manual:config:hosts:hostupdate|mass update]] form has been improved by making it more similar to host properties. Introduction of tabs allows to easier find the desired controls, and options like inventory fields now are much easier to distinguish from other fields.
  
 Regular expression editing form has been redesigned. Regular expression editing form has been redesigned.
Line 537: Line 540:
   * The logic of displaying testing results has been improved. Results are shown after applying the condition, not before:   * The logic of displaying testing results has been improved. Results are shown after applying the condition, not before:
  
-|{{:​2.2:​manual:​introduction:​regexp_test_old.png?​300|}} ​ |{{:​2.2:​manual:​introduction:​regexp_test_new.png?​280|}} ​ |+|{{regexp_test_old.png?​300|}} ​ |{{regexp_test_new.png?​280|}} ​ |
 |Previously,​ the result of comparison would be displayed immediately,​ disregarding a possibly negative condition, such as //Result is FALSE//​. ​  |Now the result is displayed after taking into account both comparison and the condition and the result is displayed correctly. ​ | |Previously,​ the result of comparison would be displayed immediately,​ disregarding a possibly negative condition, such as //Result is FALSE//​. ​  |Now the result is displayed after taking into account both comparison and the condition and the result is displayed correctly. ​ |
  
Line 548: Line 551:
 The list of **actions** will now display what media type is used when sending notifications. ​ The list of **actions** will now display what media type is used when sending notifications. ​
  
-|{{:​2.2:​manual:​introduction:​operations_old.png|}} ​ |{{:​2.2:​manual:​introduction:​operations_new.png|}} ​ |+|{{operations_old.png|}} ​ |{{operations_new.png|}} ​ |
 |Previously two operations with the same recipient looked the same even if they were using different media. ​ |Now the difference is clear by seeing the media type used.  | |Previously two operations with the same recipient looked the same even if they were using different media. ​ |Now the difference is clear by seeing the media type used.  |
  
 Also, when displaying a system user that the message is sent to, the name and surname of the user (as configured in user configuration) is displayed in parentheses after the alias. Also, when displaying a system user that the message is sent to, the name and surname of the user (as configured in user configuration) is displayed in parentheses after the alias.
  
-|{{:​2.2:​manual:​introduction:​operations_old2.png|}} ​ |{{:​2.2:​manual:​introduction:​operations_new2.png|}} ​ |+|{{operations_old2.png|}} ​ |{{operations_new2.png|}} ​ |
 |Before Zabbix 2.2.  |In Zabbix 2.2.  | |Before Zabbix 2.2.  |In Zabbix 2.2.  |
  
 Previously, if **time selection** fields were used, for instance, to set a maintenance period, the current time was always displayed by default. Now, 0 hours and 0 minutes are displayed instead. Previously, if **time selection** fields were used, for instance, to set a maintenance period, the current time was always displayed by default. Now, 0 hours and 0 minutes are displayed instead.
  
-|{{:​2.2:​manual:​introduction:​time_selection_old.png|}} ​ |{{:​2.2:​manual:​introduction:​time_selection_new.png|}} ​ |+|{{time_selection_old.png|}} ​ |{{time_selection_new.png|}} ​ |
 |Before Zabbix 2.2.  |In Zabbix 2.2.  | |Before Zabbix 2.2.  |In Zabbix 2.2.  |
  
Line 567: Line 570:
 Previously, when the flexible interval limit for an item was reached, Zabbix did not allow to add more intervals, but did not indicate the reason to the user. Since Zabbix 2.2.0, after adding 7 flexible intervals to an item, the message "​Maximum number of flexible intervals added" is shown: Previously, when the flexible interval limit for an item was reached, Zabbix did not allow to add more intervals, but did not indicate the reason to the user. Since Zabbix 2.2.0, after adding 7 flexible intervals to an item, the message "​Maximum number of flexible intervals added" is shown:
  
-{{:​2.2:​manual:​introduction:​flexible_interval_limit.png|}}+{{flexible_interval_limit.png|}}
  
 //Send to// field length in user media properties was increased to allow easier entering of long e-mail addresses. //Send to// field length in user media properties was increased to allow easier entering of long e-mail addresses.
Line 588: Line 591:
  
 "​All"​ has been removed as a choice from the trigger severity filter in the frontend, being a redundant duplicate of the "Not classified"​ option. The show_severity=-1 GET parameter, previously returning "​All",​ now defaults to the "Not classified"​ selection. "​All"​ has been removed as a choice from the trigger severity filter in the frontend, being a redundant duplicate of the "Not classified"​ option. The show_severity=-1 GET parameter, previously returning "​All",​ now defaults to the "Not classified"​ selection.
 +
 +=== - Antialiasing in generated graphics ===
 +
 +From now on generated graphs are easier to comprehend due to antialiasing. The change includes support of normal and bold anti-aliased lines lines for graphs, map connectors as well as graph X/Y axis triangles. ​
 +
 +|{{:​manual:​introduction:​graphbefore2.png|}}|{{:​manual:​introduction:​graphafter2.png|}}|
 +|Before the redesign. ​ |After the redesign. ​ |
 +
 ==== - Daemon improvements ==== ==== - Daemon improvements ====
  
Line 616: Line 627:
 === - Value cache for faster access to history data === === - Value cache for faster access to history data ===
  
-To make the calculation of triggers ​expressions,​ calculated/​aggregate items and some macros much faster, a new value cache option is supported by the Zabbix server. ​+To make the calculation of trigger ​expressions,​ calculated/​aggregate items and some macros much faster, a new value cache option is supported by the Zabbix server. ​
  
 This in-memory cache can be used for accessing historical data, instead of making direct SQL calls to the database. If historical values are not present in the cache, the missing values are requested from the database and the cache updated accordingly. This in-memory cache can be used for accessing historical data, instead of making direct SQL calls to the database. If historical values are not present in the cache, the missing values are requested from the database and the cache updated accordingly.
  
-To enable the new functionality,​ a new optional **ValueCacheSize** parameter is supported by the Zabbix server [[:2.2/manual/appendix/config/zabbix_server|configuration]] file.+To enable the new functionality,​ a new optional **ValueCacheSize** parameter is supported by the Zabbix server [[manual:appendix:config:zabbix_server|configuration]] file.
  
-Two new internal items are supported for monitoring the value cache: **zabbix[vcache,​buffer,<​mode>​]** and **zabbix[vcache,​cache,<​parameter>​]**. See more details with [[:2.2/manual/config/items/itemtypes/internal|internal items]].+Two new internal items are supported for monitoring the value cache: **zabbix[vcache,​buffer,<​mode>​]** and **zabbix[vcache,​cache,<​parameter>​]**. See more details with [[manual:config:items:itemtypes:internal|internal items]].
  
 === - Reducing update operations in item table === === - Reducing update operations in item table ===
Line 642: Line 653:
 === - Multiple timer processes === === - Multiple timer processes ===
  
-Zabbix server daemon will support parallel processing of time-based functions. A user can specify the number of timer processes in the new **StartTimers** [[:2.2/manual/appendix/config/zabbix_server|configuration]] parameter.+Zabbix server daemon will support parallel processing of time-based functions. A user can specify the number of timer processes in the new **StartTimers** [[manual:appendix:config:zabbix_server|configuration]] parameter.
  
 === - Logging the used configuration file name === === - Logging the used configuration file name ===
Line 656: Line 667:
 === - Host metadata for host auto-registration === === - Host metadata for host auto-registration ===
  
-Previously it was only possible to use a hostname to differentiate hosts when using [[2.2:manual:​discovery:​auto_registration|active agent auto-registration]]. In some cases (for example, Amazon cloud nodes) it would be great to keep the original hostname while also use other information sent by the agent for auto-registration purposes.+Previously it was only possible to use a hostname to differentiate hosts when using [[manual:​discovery:​auto_registration|active agent auto-registration]]. In some cases (for example, Amazon cloud nodes) it would be great to keep the original hostname while also use other information sent by the agent for auto-registration purposes.
  
 To make such extra information available, support for 2 new agent configuration parameters was added: To make such extra information available, support for 2 new agent configuration parameters was added:
Line 683: Line 694:
 The commandline of the main process is shown unchanged (in previous versions it was displaying "main process"​ on BSD platforms) The commandline of the main process is shown unchanged (in previous versions it was displaying "main process"​ on BSD platforms)
  
-See also [[2.2:manual:​appendix:​performance_tuning?&#​viewing_zabbix_process_performance_with_ps_and_top|Viewing Zabbix process performance with "​ps"​ and "​top"​]].+See also [[manual:​appendix:​performance_tuning?&#​viewing_zabbix_process_performance_with_ps_and_top|Viewing Zabbix process performance with "​ps"​ and "​top"​]].
  
 === - Miscellaneous daemon improvements === === - Miscellaneous daemon improvements ===
Line 692: Line 703:
   * Zabbix server and proxy daemons now correctly use the //Timeout// configuration parameter when performing SNMP checks. Additionally now the daemons do not perform retries after a single unsuccessful (the timeout/​wrong credentials) SNMP request. Previously the SNMP library default timeout and retry values (1 second and 5 retries respectively) were actually used.    * Zabbix server and proxy daemons now correctly use the //Timeout// configuration parameter when performing SNMP checks. Additionally now the daemons do not perform retries after a single unsuccessful (the timeout/​wrong credentials) SNMP request. Previously the SNMP library default timeout and retry values (1 second and 5 retries respectively) were actually used. 
   * Spaces are now allowed in the **Server** parameter in the agent daemon configuration file.   * Spaces are now allowed in the **Server** parameter in the agent daemon configuration file.
-  * Spaces are now allowed in the **Allowed hosts** field for [[:2.2/manual/config/items/itemtypes/trapper|Zabbix trapper items]]. +  * Spaces are now allowed in the **Allowed hosts** field for [[manual:config:items:itemtypes:trapper|Zabbix trapper items]]. 
-  * IP address comparison (for example, for checking incoming connections in Zabbix agent or for Zabbix trapper items) ​will be more efficient if the daemon has been built without IPv6 support. Now it should be on the same performance level as with IPv6 support enabled.+  * IP address comparison (for example, for checking incoming connections in Zabbix agent or for Zabbix trapper items) ​was more efficient if the daemon has been built without IPv6 support. Now it should be on the same performance level as with IPv6 support enabled.
   * Zabbix proxies previously sent availability data for templates when they first started up. While harmless, this was not required. Since 2.2.0, availability data is sent for monitored hosts only, reducing network traffic slightly.   * Zabbix proxies previously sent availability data for templates when they first started up. While harmless, this was not required. Since 2.2.0, availability data is sent for monitored hosts only, reducing network traffic slightly.
-  * Zabbix server previously did not respond to proxy configuration and heartbeat requests that had incorrect ​an proxy name. Starting with 2.2, failure response is returned.+  * Zabbix server previously did not respond to proxy configuration and heartbeat requests that had incorrect proxy name. Starting with 2.2, failure response is returned.
   * Zabbix server now logs response to global script request at **DebugLevel** 4.   * Zabbix server now logs response to global script request at **DebugLevel** 4.
   * Zabbix server previously discarded non-numeric characters in global script request values, and silently closed the connection if any of the required parameters were missing. Since 2.2, non-numeric characters and missing required values result in an error message being returned.   * Zabbix server previously discarded non-numeric characters in global script request values, and silently closed the connection if any of the required parameters were missing. Since 2.2, non-numeric characters and missing required values result in an error message being returned.
-  * [[:2.2/manual/config/notifications/media/email#​configuration|Setting display name]] for //From// and //To// addresses for outgoing e-mails is now supported. For example, entering "//<​nowiki>​Zabbix Riga <​[email protected]></​nowiki>//"​ is supported. +  * [[manual:config:notifications:media:email#​configuration|Setting display name]] for //From// and //To// addresses for outgoing e-mails is now supported. For example, entering "//<​nowiki>​Zabbix Riga <​[email protected]></​nowiki>//"​ is supported. 
-  * Zabbix agent now also prints the Aliases and PerfCounters specified in the agent [[2.2/manual/appendix/config/zabbix_agentd|configuration file]] when run with a [[:2.2/manual/concepts/agent|-p parameter]] .+  * Zabbix agent now also prints the Aliases and PerfCounters specified in the agent [[manual:appendix:config:zabbix_agentd|configuration file]] when run with a [[manual:concepts:agent|-p parameter]] .
   * Zabbix agent now returns ZBX_NOTSUPPORTED in case of invalid //timeout// or //count// values of a //net.dns// check.   * Zabbix agent now returns ZBX_NOTSUPPORTED in case of invalid //timeout// or //count// values of a //net.dns// check.
   * Zabbix agent previously returned 0 in case of successful exit and 255 in case of failure. Starting from version 2.2.0 Zabbix agent returns 0 in case of successful exit and 1 in case of failure.   * Zabbix agent previously returned 0 in case of successful exit and 255 in case of failure. Starting from version 2.2.0 Zabbix agent returns 0 in case of successful exit and 1 in case of failure.
Line 737: Line 748:
 ** Even more changes and bug fixes ** ** Even more changes and bug fixes **
  
-For a fully detailed list of changes and bug fixes see the [[:2.2/manual/api/changes_2.0_-_2.2|API changelog]].+For a fully detailed list of changes and bug fixes see the [[manual:api:changes_2.0_-_2.2|API changelog]].
  
 ==== - Miscellaneous ==== ==== - Miscellaneous ====
Line 761: Line 772:
 **Dynamic link library with Zabbix sender functionality on Windows** **Dynamic link library with Zabbix sender functionality on Windows**
  
-A dynamic link library with basic Zabbix sender functionality is available on the Windows platform. It allows sending data to server/​proxy without having to launch the Zabbix sender process. See the [[:2.2/manual/appendix/zabbix_sender_dll|documentation]] for detailed information.+A dynamic link library with basic Zabbix sender functionality is available on the Windows platform. It allows sending data to server/​proxy without having to launch the Zabbix sender process. See the [[manual:appendix:zabbix_sender_dll|documentation]] for detailed information.
  
 **Zabbix sender exit status changes** **Zabbix sender exit status changes**