manual:introduction:whatsnew240

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:whatsnew240 [2014/09/11 06:39]
martins-v IT services in pop-up windows are now sorted by name
manual:introduction:whatsnew240 [2016/04/11 12:00]
martins-v support for newlines and tabs in trigger expressions was added in 2.4
Line 1: Line 1:
-<note warning>​Zabbix 2.4.0 is not released yet.</​note>​ 
- 
 ===== -#5 What's new in Zabbix 2.4.0 ===== ===== -#5 What's new in Zabbix 2.4.0 =====
  
Line 7: Line 5:
 The filter section in low level discovery rule definition has been split out into a separate tab and, most importantly,​ allows to define several filters as well as to define the calculation rules between the filters. The filter section in low level discovery rule definition has been split out into a separate tab and, most importantly,​ allows to define several filters as well as to define the calculation rules between the filters.
  
-{{:2.4/manual/discovery/low_level_discovery/lld_rule_fs2.png?​570|}}+{{manual:discovery:low_level_discovery:lld_rule_fs2.png?​570|}}
  
-For more information,​ see [[:2.4/manual/discovery/low_level_discovery#​discovery_of_file_systems|low level discovery]] documentation.+For more information,​ see [[manual:discovery:low_level_discovery#​discovery_of_file_systems|low level discovery]] documentation.
  
 ==== - Node-based distributed monitoring removed ==== ==== - Node-based distributed monitoring removed ====
Line 19: Line 17:
 For the remaining node-based DM users, during an upgrade to Zabbix 2.4.0, each upgraded node will be switched to a standalone Zabbix server keeping all configuration and history information from the local node and from the child nodes as well. For the remaining node-based DM users, during an upgrade to Zabbix 2.4.0, each upgraded node will be switched to a standalone Zabbix server keeping all configuration and history information from the local node and from the child nodes as well.
  
-To maintain uniqueness of data from non-local nodes, all the fields will be prefixes ​with N<​nodeid>​_. If the length of the new value exceeds max field size, it will be trimmed. Highly unlikely, but if the new value already exists in the database, the situation will be caught by a check on duplicates. Global macros will be processed in a special way by adding N<​nodeid>​_ after the dollar sign, for example, {$N123_MACRO}.+To maintain uniqueness of data from non-local nodes, all the fields will be prefixed ​with N<​nodeid>​_. If the length of the new value exceeds max field size, it will be trimmed. Highly unlikely, but if the new value already exists in the database, the situation will be caught by a check on duplicates. Global macros will be processed in a special way by adding N<​nodeid>​_ after the dollar sign, for example, {$N123_MACRO}.
  
 ==== - Ad-hoc graphs for several items ==== ==== - Ad-hoc graphs for several items ====
Line 27: Line 25:
 While offering quite a bit of flexibility,​ creating custom graphs was not particularly quick or easy to maintain, especially, if you wanted to compare a handful of items where their respective hosts were created and then deleted after a while. To address this issue it has now been made possible in Zabbix to create ad-hoc graphs for several items in a very quick way. While offering quite a bit of flexibility,​ creating custom graphs was not particularly quick or easy to maintain, especially, if you wanted to compare a handful of items where their respective hosts were created and then deleted after a while. To address this issue it has now been made possible in Zabbix to create ad-hoc graphs for several items in a very quick way.
  
-For that, similarly as for accessing simple graphs, you go to //​Monitoring//​ -> //Latest data//​. ​This section has gained a larger filter offering ​the possibility to filter the exact set of items you want, and the items now also have checkboxes in the listing.+For that, similarly as for accessing simple graphs, you go to //​Monitoring//​ -> //Latest data//​. ​ 
 + 
 +The section ​no longer ​has the host and host group selection dropdowns. Instead, those two choices can be made within an expanded ​filter ​section, which can be used flexibly for displaying ​the exact set of items you want. Additonally, items now have checkboxes in the listing.
  
-{{:​2.4:​manual:​introduction:​group_graphs.png|}}+{{group_graphs.png|}}
  
 To get a quick graph at any time, select the desired items, choose //Display stacked graph// or //Display graph// in the dropdown below, click on //Go// and have the respective graph created instantly. To get a quick graph at any time, select the desired items, choose //Display stacked graph// or //Display graph// in the dropdown below, click on //Go// and have the respective graph created instantly.
  
-{{:​2.4:​manual:​introduction:​group_graphs_result_sm.png|}}+{{group_graphs_result_sm.png|}}
  
 Note that in the created graph window you have the time period selector available and the possibility to switch from the "​normal"​ line graph to a stacked one (and back). Note that in the created graph window you have the time period selector available and the possibility to switch from the "​normal"​ line graph to a stacked one (and back).
  
-{{:​2.4:​manual:​introduction:​group_graphs_result2_sm.png|}}+{{group_graphs_result2_sm.png|}}
  
 ==== - Custom calculation of action conditions ==== ==== - Custom calculation of action conditions ====
  
-While the previous ways of [[:2.4/manual/config/notifications/action/conditions#​type_of_calculation|calculating]] action conditions (And, Or, And/Or) offered some flexibility,​ there were clear limitations as well. In a simple case of using And/Or, if you had two groups of the same condition type, you could not use ''​AND''​ within one group and ''​OR''​ within the other.+While the previous ways of [[manual:config:notifications:action:conditions#​type_of_calculation|calculating]] action conditions (And, Or, And/Or) offered some flexibility,​ there were clear limitations as well. In a simple case of using And/Or, if you had two groups of the same condition type, you could not use ''​AND''​ within one group and ''​OR''​ within the other.
  
 To lift such limitations,​ action conditions now can be calculated using a completely **custom** formula, such as  To lift such limitations,​ action conditions now can be calculated using a completely **custom** formula, such as 
Line 50: Line 50:
 etc. etc.
  
-{{:​2.4:​manual:​introduction:​custom_expression.png|}}+{{custom_expression.png|}}
  
 The formula must include all conditions (represented as uppercase letters A, B, C, ...) and may include spaces, tabs, brackets ( ), **and** (case sensitive), **or** (case sensitive). The formula must include all conditions (represented as uppercase letters A, B, C, ...) and may include spaces, tabs, brackets ( ), **and** (case sensitive), **or** (case sensitive).
Line 70: Line 70:
   * ''​|''​ (logical OR) is now expressed with **or**   * ''​|''​ (logical OR) is now expressed with **or**
  
-Note that the old operators are no longer supported, so the new ones have to be used instead. Note also that the new **and**, **or**, **not** operators are case-sensitive and must be surrounded by spaces or parentheses. For more details, refer to the [[2.4/manual/config/triggers/expression#​operators|trigger operator]] section.+Note that the old operators are no longer supported, so the new ones have to be used instead. Note also that the new **and**, **or**, **not** operators are case-sensitive and must be surrounded by spaces or parentheses. For more details, refer to the [[manual:config:triggers:expression#​operators|trigger operator]] section
 + 
 +In a related development,​ the support for newlines and tabs in trigger expressions has been added.
  
 ==== - Web monitoring improvements ==== ==== - Web monitoring improvements ====
Line 78: Line 80:
 It is now possible to specify custom headers for HTTP requests in web monitoring: It is now possible to specify custom headers for HTTP requests in web monitoring:
  
-{{:​2.4:​manual:​introduction:​scenario_new.png|}}+{{scenario_new.png|}}
  
 Custom headers are available on both the web scenario and scenario step levels. You can also request a page header only and optionally disable follow redirect functionality on the scenario step level. ​ Custom headers are available on both the web scenario and scenario step levels. You can also request a page header only and optionally disable follow redirect functionality on the scenario step level. ​
Line 88: Line 90:
 A new //​Authentication//​ tab has been added to the web scenario configuration form holding the already familiar //​Authentication//​ dropdown and several new fields all related to SSL options: A new //​Authentication//​ tab has been added to the web scenario configuration form holding the already familiar //​Authentication//​ dropdown and several new fields all related to SSL options:
  
-{{:​2.4:​manual:​introduction:​new_ssl_options.png|}}+{{new_ssl_options.png|}}
  
 Two of these options help authenticate the server to the client: Two of these options help authenticate the server to the client:
Line 95: Line 97:
   * SSL verify host - will check that the server name actually matches the name in the certificate   * SSL verify host - will check that the server name actually matches the name in the certificate
  
-With the new [[:2.4/manual/appendix/config/zabbix_server|SSLCALocation]] server parameter Zabbix also provides an option of specifying a separate directory for the certificates,​ which, if set, will override the system-wide directory.+With the new [[manual:appendix:config:zabbix_server|SSLCALocation]] server parameter Zabbix also provides an option of specifying a separate directory for the certificates,​ which, if set, will override the system-wide directory.
  
 Using SSL certificates is also a way of authenticating the client to the server. For this purpose three new options are available: Using SSL certificates is also a way of authenticating the client to the server. For this purpose three new options are available:
Line 103: Line 105:
   * SSL key password - specify the client private key password if the key is encrypted   * SSL key password - specify the client private key password if the key is encrypted
  
-The new [[:2.4/manual/appendix/config/zabbix_server|SSLCertLocation]] and [[:2.4/manual/appendix/config/zabbix_server|SSLKeyLocation]] server parameters determine the path to client certificate and private key files.+The new [[manual:appendix:config:zabbix_server|SSLCertLocation]] and [[manual:appendix:config:zabbix_server|SSLKeyLocation]] server parameters determine the path to client certificate and private key files.
  
 === Clearing history and trend data === === Clearing history and trend data ===
Line 110: Line 112:
 ==== - Optional SNMP bulk requests ==== ==== - Optional SNMP bulk requests ====
  
-Bulk processing of SNMP requests was first introduced in Zabbix [[:​2.2/​manual/​introduction/​whatsnew223#​what_s_new_in_zabbix_223|2.2.3]]. While providing benefits in terms of reduced network traffic and load on SNMP devices, it also encountered problems with a number of devices that did not respond to these requests as expected.+Bulk processing of SNMP requests was first introduced in Zabbix [[https://​www.zabbix.com/​documentation/​2.2/​manual/​introduction/​whatsnew223#​what_s_new_in_zabbix_223|2.2.3]]. While providing benefits in terms of reduced network traffic and load on SNMP devices, it also encountered problems with a number of devices that did not respond to these requests as expected.
  
 As a result, SNMP bulk processing has been made optional in Zabbix 2.4.0. Enabled by default, it can be disabled per interface in host configuration by unchecking the respective option: As a result, SNMP bulk processing has been made optional in Zabbix 2.4.0. Enabled by default, it can be disabled per interface in host configuration by unchecking the respective option:
  
-{{:​2.4:​manual:​introduction:​snmp_bulk_request_option.png|}}+{{snmp_bulk_request_option.png|}}
  
 ==== - Graph prototypes supported in screens ==== ==== - Graph prototypes supported in screens ====
Line 125: Line 127:
 The //Graph prototype// resource is based on custom graph prototypes created in low-level discovery (LLD) rules. The //Graph prototype// resource is based on custom graph prototypes created in low-level discovery (LLD) rules.
  
-{{:​2.4:​manual:​introduction:​screens_graph_prototype.png|}}+{{screens_graph_prototype.png|}}
  
 In monitoring, the screen cell will display an LLD-generated graph as soon as it is generated. If the graph is not generated, nothing will be displayed. In monitoring, the screen cell will display an LLD-generated graph as soon as it is generated. If the graph is not generated, nothing will be displayed.
Line 131: Line 133:
 A //Simple graph prototype// is based on item prototypes in low-level discovery. In monitoring, the screen cell will display a graph created from an LLD-generated item. If the item is not generated, nothing will be displayed. A //Simple graph prototype// is based on item prototypes in low-level discovery. In monitoring, the screen cell will display a graph created from an LLD-generated item. If the item is not generated, nothing will be displayed.
  
-{{:​2.4:​manual:​introduction:​screens_simple_graph_prototype.png|}}+{{screens_simple_graph_prototype.png|}}
  
 The functionality is supported for host and template screens. With template screens, graph prototypes can be selected from the respective template only. The functionality is supported for host and template screens. With template screens, graph prototypes can be selected from the respective template only.
Line 140: Line 142:
  
 For example, you would export a template, then update it by removing some items and triggers from it. However, when importing the same template back, the removed items and triggers would again be there since they are still on the original template. For this situation, Zabbix 2.4 offers a new //Delete missing// option for deleting resources that are not in the imported XML file. This option is implemented for host and template import. For example, you would export a template, then update it by removing some items and triggers from it. However, when importing the same template back, the removed items and triggers would again be there since they are still on the original template. For this situation, Zabbix 2.4 offers a new //Delete missing// option for deleting resources that are not in the imported XML file. This option is implemented for host and template import.
 +
 +Note that the host/​template macros not present in the imported XML file will be deleted too.
  
 Additionally,​ the //Add missing// option has been renamed to //Create new//, to avoid confusion with the new option. Additionally,​ the //Add missing// option has been renamed to //Create new//, to avoid confusion with the new option.
Line 153: Line 157:
 In recent Zabbix versions, hosts and templates could only be searched for by their visible name. Now they can be searched by technical name as well. If a match is found for the technical name, it is displayed in parenthesis below the visible name. In recent Zabbix versions, hosts and templates could only be searched for by their visible name. Now they can be searched by technical name as well. If a match is found for the technical name, it is displayed in parenthesis below the visible name.
  
-{{:​2.4:​manual:​introduction:​global_search_new.png|}}+{{global_search_new.png|}}
  
 === - Application filter for maps === === - Application filter for maps ===
Line 159: Line 163:
 A new "​Application"​ filter has been added for host and host group map elements in maps.  A new "​Application"​ filter has been added for host and host group map elements in maps. 
  
-{{:​2.4:​manual:​introduction:​maps_application_field.png|}}+{{maps_application_field.png|}}
  
 The field can contain a name of an application and allows to only display problems of triggers that belong to the given application. The field can contain a name of an application and allows to only display problems of triggers that belong to the given application.
Line 165: Line 169:
 === - URL as dynamic screen element === === - URL as dynamic screen element ===
  
-In screens, URL now is a [[:2.4/manual/config/visualisation/screens#​dynamic_elements|dynamic]] screen element:+In screens, URL now is a [[manual:config:visualisation:screens#​dynamic_elements|dynamic]] screen element:
  
-{{:​2.4:​manual:​introduction:​screens_url_dynamic.png|}}+{{screens_url_dynamic.png|}}
  
 To support the new functionality,​ several macros are supported in the URL field: ''​{HOST.CONN}'',​ ''​{HOST.DNS}'',​ ''​{HOST.ID}'',​ ''​{HOST.IP}'',​ ''​{HOST.HOST}'',​ ''​{HOST.NAME}''​ and ''​{$MACRO}''​ user macro. To support the new functionality,​ several macros are supported in the URL field: ''​{HOST.CONN}'',​ ''​{HOST.DNS}'',​ ''​{HOST.ID}'',​ ''​{HOST.IP}'',​ ''​{HOST.HOST}'',​ ''​{HOST.NAME}''​ and ''​{$MACRO}''​ user macro.
Line 177: Line 181:
 Now the Action log/Action log screen element have gained a new **Action** column showing the name of the responsible action as well. Now the Action log/Action log screen element have gained a new **Action** column showing the name of the responsible action as well.
  
-{{:​2.4:​manual:​introduction:​action_log_new.png|}}+{{action_log_new.png|}}
  
 Other improvements include: Other improvements include:
Line 187: Line 191:
   * merging action operation //Status// and //Retries left// columns into one //Status// column. ​   * merging action operation //Status// and //Retries left// columns into one //Status// column. ​
    
-For more information,​ see the [[:2.4/manual/web_interface/frontend_sections/administration/audit|audit section]] documentation.+For more information,​ see the [[manual:web_interface:frontend_sections:administration:audit|audit section]] documentation.
  
 === - Description field added === === - Description field added ===
Line 193: Line 197:
 A new description field has been added to **host**, **template** and **proxy** configuration. The field may be used to provide details on how to install and use a template, have links to external resources, list user parameters, etc. A new description field has been added to **host**, **template** and **proxy** configuration. The field may be used to provide details on how to install and use a template, have links to external resources, list user parameters, etc.
  
-{{:​2.4:​manual:​introduction:​proxy_new.png|}}+{{proxy_new.png|}}
  
-For hosts, the description field content is also visible in host inventory [[:2.4/manual/web_interface/frontend_sections/inventory/hosts#​inventory_details|overview]].+For hosts, the description field content is also visible in host inventory [[manual:web_interface:frontend_sections:inventory:hosts#​inventory_details|overview]].
  
 === - Trigger dependencies shown as links === === - Trigger dependencies shown as links ===
  
-Trigger dependencies ​previosly ​were displayed as just plain text listing of trigger names. Now the trigger names are displayed as links leading to the trigger configuration. Links are green for enabled triggers, while red indicates that the trigger is disabled.+Trigger dependencies ​previously ​were displayed as just plain text listing of trigger names. Now the trigger names are displayed as links leading to the trigger configuration. Links are green for enabled triggers, while red indicates that the trigger is disabled.
  
-{{:​2.4:​manual:​introduction:​dependencies_new.png|}}+{{dependencies_new.png|}}
  
 Dependencies are also shown as links (in blue) in trigger configuration and mass update forms. Additionally,​ a comma separated host list is displayed there if a trigger belongs to multiple hosts. Dependencies are also shown as links (in blue) in trigger configuration and mass update forms. Additionally,​ a comma separated host list is displayed there if a trigger belongs to multiple hosts.
Line 211: Line 215:
 The second option meant that if many triggers were switching to OK simultaneously,​ it became difficult to spot triggers that still remained in problem status. To deal with this situation, a third specific filtering option is now available showing only those triggers that still remain in problem status - this option now is called //​Problem//​. The second option meant that if many triggers were switching to OK simultaneously,​ it became difficult to spot triggers that still remained in problem status. To deal with this situation, a third specific filtering option is now available showing only those triggers that still remain in problem status - this option now is called //​Problem//​.
  
-{{:​2.4:​manual:​introduction:​triggers_problems_only.png|}}+{{triggers_problems_only.png|}}
  
 The first two options remain in place, however, the one that used to be called //Problem// now is called //Recent problem//. The first two options remain in place, however, the one that used to be called //Problem// now is called //Recent problem//.
Line 222: Line 226:
   * //Filter by host inventory// (multiple values can be used)   * //Filter by host inventory// (multiple values can be used)
  
-{{:​2.4:​manual:​introduction:​triggers_filter_new.png|}}+{{triggers_filter_new.png|}}
  
 Additionally,​ the fairly large trigger filter now features in two frontend sections: Additionally,​ the fairly large trigger filter now features in two frontend sections:
Line 231: Line 235:
 Note that in //​Monitoring//​ -> //​Overview//,​ with //Data// selected in the Type dropdown, a small filter is displayed offering the possibility to filter data by application (an option, which was introduced in 2.2 version as an additional dropdown in the title bar). Note that in //​Monitoring//​ -> //​Overview//,​ with //Data// selected in the Type dropdown, a small filter is displayed offering the possibility to filter data by application (an option, which was introduced in 2.2 version as an additional dropdown in the title bar).
  
-{{:​2.4:​manual:​introduction:​overview_new.png|}}+{{overview_new.png|}}
  
 === - Maintenance period sorting === === - Maintenance period sorting ===
Line 237: Line 241:
 Maintenance periods can now be sorted by two new columns added to the list - //Active since// and //Active till//: Maintenance periods can now be sorted by two new columns added to the list - //Active since// and //Active till//:
  
-{{:​2.4:​manual:​introduction:​maintenance_periods_new.png?600|}}+{{maintenance_periods_new.png|}}
  
 === - Host menu changes === === - Host menu changes ===
Line 245: Line 249:
 The host menu has gained a new entry for quickly accessing host graphs. ​ The host menu has gained a new entry for quickly accessing host graphs. ​
  
-{{:​2.4:​manual:​introduction:​host_menu_new.png|}}+{{host_menu_new.png|}}
  
 == Unavailable links shown == == Unavailable links shown ==
Line 251: Line 255:
 Unavailable links that previously were hidden now are shown as disabled - meaning greyed out and not clickable. Unavailable links that previously were hidden now are shown as disabled - meaning greyed out and not clickable.
  
-{{:​2.4:​manual:​introduction:​host_menu_disabled.png|}}+{{host_menu_disabled.png|}}
  
 == Synchronized in maps == == Synchronized in maps ==
Line 257: Line 261:
 The menu available for hosts in //​Monitoring -> Maps// has been synchronized with other host menus to display the same selection of links. The menu available for hosts in //​Monitoring -> Maps// has been synchronized with other host menus to display the same selection of links.
  
-The host menu is accessible by clicking on a host in several frontend sections. See more details about the [[:2.4/manual/web_interface/frontend_sections/monitoring/dashboard#​host_menu|host menu]].+The host menu is accessible by clicking on a host in several frontend sections. See more details about the [[manual:web_interface:frontend_sections:monitoring:dashboard#​host_menu|host menu]].
  
 === - Regular expression validation === === - Regular expression validation ===
Line 267: Line 271:
 Previously, green status icons were displayed in the last //Error// column of the item and trigger listings, for error-free entries, which could be misunderstood as if, on the contrary, the entries had errors. Now the green icons are displayed no more and, additionally,​ the column is renamed to //Info//. Previously, green status icons were displayed in the last //Error// column of the item and trigger listings, for error-free entries, which could be misunderstood as if, on the contrary, the entries had errors. Now the green icons are displayed no more and, additionally,​ the column is renamed to //Info//.
  
-|{{:​2.4:​manual:​introduction:​items_old.png|}}|{{:​2.4:​manual:​introduction:​items_new.png|}}|+|{{items_old.png|}}|{{items_new.png|}}|
 |Before Zabbix 2.4.0. ​ |In Zabbix 2.4.0. ​ | |Before Zabbix 2.4.0. ​ |In Zabbix 2.4.0. ​ |
  
Line 278: Line 282:
 That could be potentially dangerous since an icon, used in a network map, could be changed to //​background//​ thus making the map unsaveable in the future. To avoid this situation, the option of changing image type has been removed and the image upload form has been separated into two forms - one for icon and one for background upload. ​ That could be potentially dangerous since an icon, used in a network map, could be changed to //​background//​ thus making the map unsaveable in the future. To avoid this situation, the option of changing image type has been removed and the image upload form has been separated into two forms - one for icon and one for background upload. ​
  
-{{:2.4:manual:​web_interface:​frontend_sections:​administration:​general_img_upload.png|}}+{{manual:​web_interface:​frontend_sections:​administration:​general_img_upload.png|}}
  
 This is also indicated by different names of the upload buttons - //Create icon// and //Create background//​. This is also indicated by different names of the upload buttons - //Create icon// and //Create background//​.
Line 291: Line 295:
   * More intuitive naming for the use of filter has been introduced. If previously //Filter// stood for both show and hide functions (with only very tiny icons indicating the direction), now separate //Show filter// and //Hide filter// names have been introduced.   * More intuitive naming for the use of filter has been introduced. If previously //Filter// stood for both show and hide functions (with only very tiny icons indicating the direction), now separate //Show filter// and //Hide filter// names have been introduced.
  
-|{{:​2.4:​manual:​introduction:​filter1_old.png|}} ​ |{{:​2.4:​manual:​introduction:​filter1_new.png|}} ​ | +|{{filter1_old.png|}} ​ |{{filter1_new.png|}} ​ | 
-|{{:​2.4:​manual:​introduction:​filter2_old.png|}} ​ |{{:​2.4:​manual:​introduction:​filter2_new.png|}} ​ |+|{{filter2_old.png|}} ​ |{{filter2_new.png|}} ​ |
 |Before Zabbix 2.4.0. ​ |In Zabbix 2.4.0. ​ | |Before Zabbix 2.4.0. ​ |In Zabbix 2.4.0. ​ |
  
   * Disabled input fields previously were not distinguished much, which could create confusion as to why they were not available for editing. Now these fields are distinguished with a grey background, for example, in host inventory, web scenario step or global script definition forms.   * Disabled input fields previously were not distinguished much, which could create confusion as to why they were not available for editing. Now these fields are distinguished with a grey background, for example, in host inventory, web scenario step or global script definition forms.
  
-|{{:​2.4:​manual:​introduction:​disabled_confirmation_old.png|}} ​ |Before Zabbix 2.4.0. ​ | +|{{disabled_confirmation_old.png|}} ​ |Before Zabbix 2.4.0. ​ | 
-|{{:​2.4:​manual:​introduction:​disabled_confirmation_new.png|}} ​ |In Zabbix 2.4.0. ​ |+|{{disabled_confirmation_new.png|}} ​ |In Zabbix 2.4.0. ​ |
  
-  * The //Rows per page// setting from [[:2.4/manual/web_interface/user_profile|User profile]] previously was not applied to the //​Availability report// section of the frontend, leading to difficulties when loading the page on installations with a lot of triggers. Now the setting is in force and can be used to limit the number of records displayed in one page.+  * The //Rows per page// setting from [[manual:web_interface:user_profile|User profile]] previously was not applied to the //​Availability report// section of the frontend, leading to difficulties when loading the page on installations with a lot of triggers. Now the setting is in force and can be used to limit the number of records displayed in one page.
   * Templates listed in the host configuration have been made clickable. Clicking on a template name opens the template configuration form.   * Templates listed in the host configuration have been made clickable. Clicking on a template name opens the template configuration form.
  
-{{:​2.4:​manual:​introduction:​templates_clickable.png|}}+{{templates_clickable.png|}}
  
   * Host groups listed in the //Web monitoring//​ widget of the frontend have been made clickable. The link leads to //​Monitoring//​ -> //Web// with scenarios of the respective host group selected.   * Host groups listed in the //Web monitoring//​ widget of the frontend have been made clickable. The link leads to //​Monitoring//​ -> //Web// with scenarios of the respective host group selected.
  
-{{:​2.4:​manual:​introduction:​webmon_groups_clickable.png|}}+{{webmon_groups_clickable.png|}}
  
   * Previously, only one host was listed in event details, even if the trigger expression contained several. Now, all hosts from the expression are listed.   * Previously, only one host was listed in event details, even if the trigger expression contained several. Now, all hosts from the expression are listed.
  
-|{{:​2.4:​manual:​introduction:​event_hostlist_old.png?​400|}}|Before Zabbix 2.4.0.| +|{{event_hostlist_old.png?​400|}}|Before Zabbix 2.4.0.| 
-|{{:​2.4:​manual:​introduction:​event_hostlist_new.png?​400|}}|In Zabbix 2.4.0.|+|{{event_hostlist_new.png?​400|}}|In Zabbix 2.4.0.|
  
   * //​Monitoring -> Latest data// filter option //Show items without data// is now enabled by default   * //​Monitoring -> Latest data// filter option //Show items without data// is now enabled by default
Line 318: Line 322:
   * In the user list, disabled groups in the //Group// column are now displayed in red   * In the user list, disabled groups in the //Group// column are now displayed in red
   * In the user group list, //Status// column has been moved to the end   * In the user group list, //Status// column has been moved to the end
 +  * The value of ''​Max count of elements to show inside table cell''​ from //​Administration//​ -> //General// -> //GUI// now also applies to templates listed in the host list, users listed in the user group list and user groups listed in the user list
   * When a trigger belongs to many hosts, hosts are now displayed in alphabetical order   * When a trigger belongs to many hosts, hosts are now displayed in alphabetical order
   * For numeric items with disabled history ('​history'​ and '​trends'​ set to 0), the //Graph// link is hidden from view in //​Monitoring//​ → //Latest data//. If history and trends are set to '​0'​ globally in //​Administration//​ -> //General// -> //​Housekeeping//,​ then all //​Graph/​History//​ links are hidden in //Latest data//.   * For numeric items with disabled history ('​history'​ and '​trends'​ set to 0), the //Graph// link is hidden from view in //​Monitoring//​ → //Latest data//. If history and trends are set to '​0'​ globally in //​Administration//​ -> //General// -> //​Housekeeping//,​ then all //​Graph/​History//​ links are hidden in //Latest data//.
Line 325: Line 330:
   * Saving global regular expressions with a leading space (like " 1") now works correctly. Moreover, spaces and tabs are dealt with correctly before, after and within expression text.   * Saving global regular expressions with a leading space (like " 1") now works correctly. Moreover, spaces and tabs are dealt with correctly before, after and within expression text.
   * A forward slash (/) in global regular expressions is treated literally, rather than a delimiter. This way it is possible to save expressions containing a slash, whereas previously it would produce an error.   * A forward slash (/) in global regular expressions is treated literally, rather than a delimiter. This way it is possible to save expressions containing a slash, whereas previously it would produce an error.
-  * Proxy name is now displayed as host prefix in the item [[:2.4/manual/web_interface/frontend_sections/administration/queue|queue details]] page.+  * Proxy name is now displayed as host prefix in the item [[manual:web_interface:frontend_sections:administration:queue|queue details]] page.
   * The trigger filter will no longer be reset when selecting all hosts on the //​Monitoring//​ -> //Events// page.   * The trigger filter will no longer be reset when selecting all hosts on the //​Monitoring//​ -> //Events// page.
   * IT services in pop-up windows are now sorted by name.   * IT services in pop-up windows are now sorted by name.
 +  * IT service dependencies in the configuration window are now sorted by name.
 ==== - Macro improvements ==== ==== - Macro improvements ====
  
Line 336: Line 342:
 Host level macros - ''​{HOST.HOST}'',​ ''​{HOST.NAME}'',​ ''​{HOST.IP}'',​ ''​{HOST.DNS}''​ and ''​{HOST.CONN}''​ along with user macros ''​{$MACRO}''​ are available in simple low-level discovery rule filter regexps. Host level macros - ''​{HOST.HOST}'',​ ''​{HOST.NAME}'',​ ''​{HOST.IP}'',​ ''​{HOST.DNS}''​ and ''​{HOST.CONN}''​ along with user macros ''​{$MACRO}''​ are available in simple low-level discovery rule filter regexps.
  
-For more details, see [[:2.4/manual/appendix/macros/supported_by_location|Macros supported by location]].+For more details, see [[manual:appendix:macros:supported_by_location|Macros supported by location]].
  
 ==== - Daemon improvements ==== ==== - Daemon improvements ====
Line 361: Line 367:
 A new configuration parameter (User) has been introduced for daemons which allows dropping privileges to the specified user if the daemon has been started by the root account. A new configuration parameter (User) has been introduced for daemons which allows dropping privileges to the specified user if the daemon has been started by the root account.
  
-When using the Include parameter in the agent [[:2.4/manual/appendix/config/zabbix_agentd_win|configuration file]] for Windows it is now possible to include all files from a directory.+When using the Include parameter in the agent [[manual:appendix:config:zabbix_agentd_win|configuration file]] for Windows it is now possible to include all files from a directory.
  
 Server and proxy now refuse to start if **StartPollersUnreachable** configuration parameter is 0, but regular, IPMI or Java pollers are started. Otherwise, hosts that become unreachable would never be checked again. Server and proxy now refuse to start if **StartPollersUnreachable** configuration parameter is 0, but regular, IPMI or Java pollers are started. Otherwise, hosts that become unreachable would never be checked again.
Line 384: Line 390:
 ** More details about unsupported agent items ** ** More details about unsupported agent items **
  
-Zabbix agents now provide detailed information on why items become not supported, instead of the generic "Not supported by Zabbix Agent"​. This was achieved by extending the passive agent and active agent protocols (see [[:2.4/manual/appendix/items/activepassive|protocol documentation]]). However, new agents are compatible with older server and proxy, except the error message for passive agents will not be visible in the frontend. Querying values with ''​zabbix_get'',​ testing with ''​zabbix_agentd -p''​ and ''​zabbix_agentd -t''​ now also provides a detailed error message.+Zabbix agents now provide detailed information on why items become not supported, instead of the generic "Not supported by Zabbix Agent"​. This was achieved by extending the passive agent and active agent protocols (see [[manual:appendix:items:activepassive|protocol documentation]]). However, new agents are compatible with older server and proxy, except the error message for passive agents will not be visible in the frontend. Querying values with ''​zabbix_get'',​ testing with ''​zabbix_agentd -p''​ and ''​zabbix_agentd -t''​ now also provides a detailed error message.
  
 As a result, in //​Configuration//​ -> //Hosts// -> //Items// of the frontend, when rolling the mouse over the error icon, you may expect to see more specific messages about why an item went unsuported. As a result, in //​Configuration//​ -> //Hosts// -> //Items// of the frontend, when rolling the mouse over the error icon, you may expect to see more specific messages about why an item went unsuported.
  
-|{{:​2.4:​manual:​introduction:​not_supported.png|}} ​ |{{:​2.4:​manual:​introduction:​not_supported_new2.png}}\\ {{:​2.4:​manual:​introduction:​not_supported_new1.png|}}\\ {{:​2.4:​manual:​introduction:​not_supported_new3.png|}}\\ ...  |+|{{not_supported.png|}} ​ |{{not_supported_new2.png}}\\ {{not_supported_new1.png|}}\\ {{not_supported_new3.png|}}\\ ...  |
 |A single message before Zabbix 2.4.0. ​ |More informative messages in Zabbix 2.4.0. ​ | |A single message before Zabbix 2.4.0. ​ |More informative messages in Zabbix 2.4.0. ​ |
  
Line 398: Line 404:
  
 A check that prevents starting the proxy with a server database and vice versa has been added. A check that prevents starting the proxy with a server database and vice versa has been added.
 +
 +Support for PHP mutexes has been removed on the server side due to licensing issues. While it was not recommended to use Zabbix server and frontend with SQLite3 database before, this change makes it even less recommended,​ because simultaneous database access with Zabbix server and frontend may now corrupt the database. Note that using Zabbix proxy with SQLite3 database is still a perfectly valid solution.
  
 ** Housekeeper changes ** ** Housekeeper changes **
Line 408: Line 416:
  
 Empty result is now allowed for ''​system.run[]''​ items configured with textual value type (character, log or text). Empty result is now allowed for ''​system.run[]''​ items configured with textual value type (character, log or text).
- 
  
 ** Log level change at runtime ** ** Log level change at runtime **
  
-Two additional runtime control options have been added on all Zabbix services - log_level_increase and log_level_decrease. Now, it is possible to change the log level of all or certain process(-es) without restarting a service. These two runtime control options accept parameters for target process selection. A target process can be selected by specifying PID or process type and process number.+Two additional runtime control options have been added on all Zabbix services - //log_level_increase// and //log_level_decrease//. Now, it is possible to change the log level of all or certain process(-es) without restarting a service. These two runtime control options accept parameters for target process selection. A target process can be selected by specifying PID or process type and process number.
 ==== - Item changes/​improvements ==== ==== - Item changes/​improvements ====