en-us	# 1 Escaping special characters from LLD macro values in JSONPath  When low-level discovery macros are used in JSONPath preprocessing and their values are resolved, the following rules of escaping special characters are applied:  -   only backslash (\\) and double quote (") characters are considered     for escaping; -   if the resolved macro value contains these characters, each of them     is escaped with a backslash; -   if they are already escaped with a backslash, it is not considered     as escaping and both the backslash and the following special     characters are escaped once again.  For example:  |JSONPath|LLD macro value|After substitution| |--------|---------------|------------------| |$.\[?(@.value == "{\#MACRO}")\]|special "value"|$.\[?(@.value == "special \\"value\\"")\]| |^|c:\\temp|$.\[?(@.value == "c:\\\\temp")\]| |^|a\\\\b|$.\[?(@.value == "a\\\\\\\\b")\]|  When used in the expression, the macro that may have special characters should be enclosed in double quotes:  |JSONPath|LLD macro value|After substitution|Result| |--------|--------|--------|--------| |$.\[?(@.value == "{\#MACRO}")\]|special "value"|$.\[?(@.value == "special \\"value\\"")\]|OK| |$.\[?(@.value == {\#MACRO})\]|^|$.\[?(@.value == special \\"value\\")\]|**Bad JSONPath expression**|  When used in the path, the macro that may have special characters should be enclosed in square brackets **and** double quotes:  |JSONPath|LLD macro value|After substitution|Result| |--------|--------|--------|--------| |$.\["{\#MACRO}"\].value|c:\\temp|$.\["c:\\\\temp"\].value|OK| |$.{\#MACRO}.value|^|$.c:\\\\temp.value|**Bad JSONPath expression**|
kk	# 1 Escaping special characters from LLD macro values in JSONPath  When low-level discovery macros are used in JSONPath preprocessing and their values are resolved, the following rules of escaping special characters are applied:  -   only backslash (\\) and double quote (") characters are considered     for escaping; -   if the resolved macro value contains these characters, each of them     is escaped with a backslash; -   if they are already escaped with a backslash, it is not considered     as escaping and both the backslash and the following special     characters are escaped once again.  For example:  |JSONPath|LLD macro value|After substitution| |--------|---------------|------------------| |$.\[?(@.value == "{\#MACRO}")\]|special "value"|$.\[?(@.value == "special \\"value\\"")\]| |^|c:\\temp|$.\[?(@.value == "c:\\\\temp")\]| |^|a\\\\b|$.\[?(@.value == "a\\\\\\\\b")\]|  When used in the expression the macro that may have special characters should be enclosed in double quotes:  |JSONPath|LLD macro value|After substitution|Result| |--------|--------|--------|--------| |$.\[?(@.value == "{\#MACRO}")\]|special "value"|$.\[?(@.value == "special \\"value\\"")\]|OK| |$.\[?(@.value == {\#MACRO})\]|^|$.\[?(@.value == special \\"value\\")\]|**Bad JSONPath expression**|  When used in the path the macro that may have special characters should be enclosed in square brackets **and** double quotes:  |JSONPath|LLD macro value|After substitution|Result| |--------|--------|--------|--------| |$.\["{\#MACRO}"\].value|c:\\temp|$.\["c:\\\\temp"\].value|OK| |$.{\#MACRO}.value|^|$.c:\\\\temp.value|**Bad JSONPath expression**|

en-us	# 3 Database upgrade to primary keys
kk	# 3 Database upgrade to primary keys

en-us	# 3 Installation from sources  You can get the very latest version of Zabbix by compiling it from the sources.  A step-by-step tutorial for installing Zabbix from the sources is provided here.
kk	# 3 Installation from sources  You can get the very latest version of Zabbix by compiling it from the sources.  A step-by-step tutorial for installing Zabbix from the sources is provided here.

en-us	# 4 Installation from packages
kk	# 4 Installation from packages

en-us	# 5 Installation from containers
kk	# 5 Installation from containers

en-us	# 6 Web interface installation  This section provides step-by-step instructions for installing Zabbix web interface. Zabbix frontend is written in PHP, so to run it a PHP supported webserver is needed.
kk	# 6 Web interface installation  This section provides step-by-step instructions for installing Zabbix web interface. Zabbix frontend is written in PHP, so to run it a PHP supported webserver is needed.

en-us	# 7 Upgrade procedure
kk	# 7 Upgrade procedure

en-us	##### Add a blank module to Zabbix frontend  1. Create a directory *MyAddress* in the *modules* directory of your Zabbix frontend installation (for example, *zabbix/ui/modules*).  2. Create a *manifest.json* file with basic module metadata (see the description of supported [parameters](../file_structure/manifest)).  **ui/modules/MyAddress/manifest.json**  ```json {     "manifest_version": 2.0,     "id": "my-address",     "name": "My IP Address",     "version": "1.0",     "namespace": "MyAddress",     "description": "My External IP Address." } ```  3. In Zabbix frontend, go to *Administration → General → Modules* section and click on the *Scan directory* button.  ![](../../../../assets/en/devel/modules/tutorials/widget/scan_dir.png)  4. Locate the new module *My IP Address* in the list and click on the "Disabled" hyperlink to change the module's status from "Disabled" to "Enabled".  ![](../../../../assets/en/devel/modules/tutorials/module/module_register.png){width="600"}  The module is now registered in the frontend. However, it is not visible yet, because you still need to define the module functionality. Once you add content to the module directory, you will immediately see the changes in Zabbix frontend upon refreshing the page.
kk	##### Add a blank module to Zabbix frontend  1. Create a directory *MyAddress* in the *modules* directory of your Zabbix frontend installation (for example, *zabbix/ui/modules*).  2. Create a *manifest.json* file with basic module metadata (see the description of supported [parameters](../file_structure/manifest)).  **ui/modules/MyAddress/manifest.json**  ```json {     "manifest_version": 2.0,     "id": "my-address",     "name": "My IP Address",     "version": "1.0",     "namespace": "MyAddress",     "description": "My External IP Address" } ```  3. In Zabbix frontend, go to *Administration → General → Modules* section and click on the *Scan directory* button.  ![](../../../../assets/en/devel/modules/tutorials/widget/scan_dir.png)  4. Locate the new module *My IP Address* in the list and click on the "Disabled" hyperlink to change the module's status from "Disabled" to "Enabled".  ![](../../../../assets/en/devel/modules/tutorials/module/module_register.png){width="600"}  The module is now registered in the frontend. However, it is not visible yet, because you still need to define the module functionality. Once you add content to the module directory, you will immediately see the changes in Zabbix frontend upon refreshing the page.

en-us	#### Configuration  To configure a CSV to JSON preprocessing step:  -   Go to the Preprocessing tab in     [item](/manual/config/items/preprocessing)/[discovery     rule](/manual/discovery/low_level_discovery#preprocessing)     configuration -   Click on *Add* -   Select the *CSV to JSON* option  ![](../../../../../assets/en/manual/appendix/csv_to_json_params.png){width="600"}  The first parameter allows to set a custom delimiter. Note that if the first line of CSV input starts with "Sep=" and is followed by a single UTF-8 character then that character will be used as the delimiter in case the first parameter is not set. If the first parameter is not set and a delimiter is not retrieved from the "Sep=" line, then a comma is used as a separator.  The second optional parameter allows to set a quotation symbol.  If the *With header row* checkbox is marked, the header line values will be interpreted as column names (see [Header processing](#csv_header_processing) for more information).  If the *Custom on fail* checkbox is marked, the item will not become unsupported in case of a failed preprocessing step. Additionally, custom error handling options may be set: discard the value, set a specified value or set a specified error message.
kk	#### Configuration  To configure a CSV to JSON preprocessing step:  -   Go to the Preprocessing tab in     [item](/manual/config/items/preprocessing)/[discovery     rule](/manual/discovery/low_level_discovery#preprocessing)     configuration -   Click on *Add* -   Select the *CSV to JSON* option  ![](../../../../../assets/en/manual/appendix/csv_to_json_params.png){width="600"}  The first parameter allows to set a custom delimiter. Note that if the first line of CSV input starts with "Sep=" and is followed by a single UTF-8 character then that character will be used as the delimiter in case the first parameter is not set. If the first parameter is not set and a delimiter is not retrieved from the "Sep=" line, then a comma is used as a separator.  The second optional parameter allows to set a quotation symbol.  If the *With header row* checkbox is marked, the header line values will be interpreted as column names (see [Header processing](#csv_header_processing) for more information).  If the *Custom on fail* checkbox is marked, the item will not become unsupported in case of a failed preprocessing step. Additionally custom error handling options may be set: discard the value, set a specified value or set a specified error message.

en-us	#### Create a new interface  Create a secondary IP agent interface on host "30052."  [Request](/manual/api#performing-requests):  ```json {     "jsonrpc": "2.0",     "method": "hostinterface.create",     "params": {         "hostid": "30052",         "main": "0",         "type": "1",         "useip": "1",         "ip": "127.0.0.1",         "dns": "",         "port": "10050"     },     "id": 1 } ```  Response:  ```json {     "jsonrpc": "2.0",     "result": {         "interfaceids": [             "30062"         ]     },     "id": 1 } ```
kk	#### Create a new interface  Create a secondary IP agent interface on host "30052."  [Request](/manual/api#performing-requests):  ```json {     "jsonrpc": "2.0",     "method": "hostinterface.create",     "params": {         "hostid": "30052",         "main": "0",         "type": "1",         "useip": "1",         "ip": "127.0.0.1",         "dns": "",         "port": "10050",     },     "id": 1 } ```  Response:  ```json {     "jsonrpc": "2.0",     "result": {         "interfaceids": [             "30062"         ]     },     "id": 1 } ```

en-us	#### Displaying options  The **Displaying options** tab allows to define history data selection:  ![](../../../../../../assets/en/manual/web_interface/frontend_sections/monitoring/graph_displaying_options.png)  |   |   | |--|--------| |*History data selection*|Set the source of graph data:<br>**Auto** - data are sourced according to the classic graph [algorithm](/manual/config/visualization/graphs/simple#generating_from_historytrends) (default);<br>**History** - data from history;<br>**Trends** - data from trends.| |*Simple triggers*|Mark the checkbox to show the trigger thresholds for simple triggers. The thresholds will be drawn as dashed lines using the trigger severity color.<br>A simple trigger is a trigger with one function (only `last`, `max`, `min`, `avg`) for one item in the expression.<br>A maximum of three triggers can be drawn. Note that the trigger has to be within the drawn range to be visible.| |*Working time*|Mark the checkbox to show working time on the graph. Working time (working days) is displayed in graphs as a white background, while non-working time is displayed in gray (with the *Original blue* default frontend theme).| |*Percentile line (left)*|Mark the checkbox and enter the percentile value to show the specified percentile as a line on the left Y-axis of the graph.<br>If, for example, a 95% percentile is set, then the percentile line will be at the level where 95 percent of the values fall under.| |*Percentile line (right)*|Mark the checkbox and enter the percentile value to show the specified percentile as a line on the right Y-axis of the graph.<br>If, for example, a 95% percentile is set, then the percentile line will be at the level where 95 percent of the values fall under.|
kk	#### Displaying options  The **Displaying options** tab allows to define history data selection:  ![](../../../../../../assets/en/manual/web_interface/frontend_sections/monitoring/graph_displaying_options.png)  |   |   | |--|--------| |*History data selection*|Set the source of graph data:<br>**Auto** - data are sourced according to the classic graph [algorithm](/manual/config/visualization/graphs/simple#generating_from_historytrends) (default)<br>**History** - data from history<br>**Trends** - data from trends| |*Simple triggers*|Mark the checkbox to show the trigger thresholds for simple triggers. The thresholds will be drawn as dashed lines using the trigger severity color.<br>A simple trigger is a trigger with one function (only `last`, `max`, `min`, `avg`) for one item in the expression.<br>A maximum of three triggers can be drawn. Note that the trigger has to be within the drawn range to be visible.| |*Working time*|Mark the checkbox to show working time on the graph. Working time (working days) is displayed in graphs as a white background, while non-working time is displayed in gray (with the *Original blue* default frontend theme).| |*Percentile line (left)*|Mark the checkbox and enter the percentile value to show the specified percentile as a line on the left Y-axis of the graph.<br>If, for example, a 95% percentile is set, then the percentile line will be at the level where 95 percent of the values fall under.| |*Percentile line (right)*|Mark the checkbox and enter the percentile value to show the specified percentile as a line on the right Y-axis of the graph.<br>If, for example, a 95% percentile is set, then the percentile line will be at the level where 95 percent of the values fall under.|

en-us	#### Header processing  The CSV file header line can be processed in two different ways:  -   If the *With header row* checkbox is marked - header line values are     interpreted as column names. In this case the column names must be     unique and the data row should not contain more columns than the     header row. -   If the *With header row* checkbox is not marked - the header line is     interpreted as data. Column names are generated automatically     (1,2,3,4...).  CSV file example:      Nr,Item name,Key,Qty     1,active agent item,agent.hostname,33     "2","passive agent item","agent.version","44"     3,"active,passive agent items",agent.ping,55  ::: noteclassic A quotation character within a quoted field in the input must be escaped by preceding it with another quotation character. :::  **Processing header line**  JSON output when a header line is expected:  ``` {.json} [    {       "Nr":"1",       "Item name":"active agent item",       "Key":"agent.hostname",       "Qty":"33"    },    {       "Nr":"2",       "Item name":"passive agent item",       "Key":"agent.version",       "Qty":"44"    },    {       "Nr":"3",       "Item name":"active,passive agent items",       "Key":"agent.ping",       "Qty":"55"    } ] ```  **No header line processing**  JSON output when a header line is not expected:  ``` {.json} [    {       "1":"Nr",       "2":"Item name",       "3":"Key"       "4":"Qty"    },    {       "1":"1",       "2":"active agent item",       "3":"agent.hostname"       "4":"33"    },    {       "1":"2",       "2":"passive agent item",       "3":"agent.version"       "4":"44"    },    {       "1":"3",       "2":"active,passive agent items",       "3":"agent.ping"       "4":"55"    } ] ```
kk	#### Header processing  The CSV file header line can be processed in two different ways:  -   If the *With header row* checkbox is marked - header line values are     interpreted as column names. In this case the column names must be     unique and the data row should not contain more columns than the     header row; -   If the *With header row* checkbox is not marked - the header line is     interpreted as data. Column names are generated automatically     (1,2,3,4...)  CSV file example:      Nr,Item name,Key,Qty     1,active agent item,agent.hostname,33     "2","passive agent item","agent.version","44"     3,"active,passive agent items",agent.ping,55  ::: noteclassic A quotation character within a quoted field in the input must be escaped by preceding it with another quotation character. :::  **Processing header line**  JSON output when a header line is expected:  ``` {.json} [    {       "Nr":"1",       "Item name":"active agent item",       "Key":"agent.hostname",       "Qty":"33"    },    {       "Nr":"2",       "Item name":"passive agent item",       "Key":"agent.version",       "Qty":"44"    },    {       "Nr":"3",       "Item name":"active,passive agent items",       "Key":"agent.ping",       "Qty":"55"    } ] ```  **No header line processing**  JSON output when a header line is not expected:  ``` {.json} [    {       "1":"Nr",       "2":"Item name",       "3":"Key"       "4":"Qty"    },    {       "1":"1",       "2":"active agent item",       "3":"agent.hostname"       "4":"33"    },    {       "1":"2",       "2":"passive agent item",       "3":"agent.version"       "4":"44"    },    {       "1":"3",       "2":"active,passive agent items",       "3":"agent.ping"       "4":"55"    } ] ```

en-us	**If the webhook test is successful:**  -   *"Media type test successful."* message is displayed. -   Server response appears in the gray *Response* field. -   Response type (JSON or String) is specified below the *Response*     field.
kk	**If the webhook test is successful:**  -   *"Media type test successful."* message is displayed -   Server response appears in the gray *Response* field -   Response type (JSON or String) is specified below the *Response*     field

en-us	#### Item value preprocessing  Data preprocessing is performed in the following steps:  -   The item value is passed to the preprocessing manager using a UNIX socket-based IPC mechanism. -   If the item has neither preprocessing nor dependent items, its value is either added to the history cache or sent to the LLD manager. Otherwise:     -   A preprocessing task is created and added to the queue and preprocessing workers are notified about the new task.     -   At this point the data flow stops until there is at least one unoccupied (i.e., not executing any tasks) preprocessing worker.     -   When a preprocessing worker is available, it takes the next task from the queue.     -   After the preprocessing is done (both failed and successful execution of preprocessing steps), the preprocessed value is added to the finished task queue and the manager is notified about a new finished task.     -   The preprocessing manager converts the result to desired format (defined by item value type) and either adds it to the history cache or sends to the LLD manager.     -   If there are dependent items for the processed item, then dependent items are added to the preprocessing queue with the preprocessed master item value. Dependent items are enqueued bypassing the normal value preprocessing requests, but only for master items with the value set and not in a NOT SUPPORTED state.  ![](../../../assets/en/diagrams/value_preprocessing.png){width="600"}  Note that in the diagram the master item preprocessing is slightly simplified by skipping the preprocessing caching.
kk	#### Item value preprocessing  Data preprocessing is performed in the following steps:  -   The item value is passed to the preprocessing manager using a UNIX socket-based IPC mechanism. -   If the item has neither preprocessing nor dependent items, its value is either added to the history cache or sent to the LLD manager. Otherwise:     -   A preprocessing task is created and added to the queue and preprocessing workers are notified about the new task.     -   At this point the data flow stops until there is at least one unoccupied (i.e. not executing any tasks) preprocessing worker.     -   When a preprocessing worker is available it takes the next task from the queue.     -   After the preprocessing is done (both failed and successful execution of preprocessing steps), the preprocessed value is added to the finished task queue and the manager is notified about a new finished task.     -   The preprocessing manager converts the result to desired format (defined by item value type) and either adds it to the history cache or sends to the LLD manager.     -   If there are dependent items for the processed item, then dependent items are added to the preprocessing queue with the preprocessed master item value. Dependent items are enqueued bypassing the normal value preprocessing requests, but only for master items with the value set and not in a NOT SUPPORTED state.  ![](../../../assets/en/diagrams/value_preprocessing.png){width="600"}  Note that in the diagram the master item preprocessing is slightly simplified by skipping the preprocessing caching.

en-us	#### Item value processing  To visualize the data flow from data source to the Zabbix database, we can use the following simplified diagram:  ![](../../../../../assets/en/manual/appendix/items/overall_pic.png)  The diagram above shows only processes, objects and actions related to item value processing in a **simplified** form. The diagram does not show conditional direction changes, error handling or loops. The local data cache of the preprocessing manager is not shown either because it doesn't affect the data flow directly. The aim of this diagram is to show processes involved in the item value processing and the way they interact.  -   Data gathering starts with raw data from a data source. At this     point, the data contains only ID, timestamp and value (can be multiple     values as well). -   No matter what type of data gatherer is used, the idea is the same     for active or passive checks, for trapper items, etc., as it only     changes the data format and the communication starter (either data     gatherer is waiting for a connection and data, or data gatherer     initiates the communication and requests the data). The raw data is     validated, the item configuration is retrieved from the configuration cache     (data is enriched with the configuration data). -   A socket-based IPC mechanism is used to pass data from data gatherers     to the preprocessing manager. At this point the data gatherer continues to     gather data without waiting for the response from preprocessing     manager. -   Data preprocessing is performed. This includes the execution of     preprocessing steps and dependent item processing.  ::: noteclassic An item can change its state to NOT SUPPORTED while preprocessing is performed  if any of preprocessing steps fail. :::  -   The history data from the local data cache of the preprocessing manager is being     flushed into the history cache. -   At this point the data flow stops until the next synchronization of     history cache (when the history syncer process performs data     synchronization). -   The synchronization process starts with data normalization before storing data     in Zabbix database. The data normalization performs conversions to the     desired item type (type defined in item configuration), including     truncation of textual data based on predefined sizes allowed for     those types (HISTORY\_STR\_VALUE\_LEN for string,     HISTORY\_TEXT\_VALUE\_LEN for text and HISTORY\_LOG\_VALUE\_LEN for     log values). The data is being sent to the Zabbix database after     the normalization is done.  ::: noteclassic An item can change its state to NOT SUPPORTED if data normalization fails  (for example, when a textual value cannot be converted to number). :::  -   The gathered data is being processed - triggers are checked, the item     configuration is updated if item becomes NOT SUPPORTED, etc. -   This is considered the end of data flow from the point of view of     item value processing.
kk	#### Item value processing  To visualize the data flow from data source to the Zabbix database, we can use the following simplified diagram:  ![](../../../../../assets/en/manual/appendix/items/overall_pic.png)  The diagram above shows only processes, objects and actions related to item value processing in a **simplified** form. The diagram does not show conditional direction changes, error handling or loops. The local data cache of the preprocessing manager is not shown either because it doesn't affect the data flow directly. The aim of this diagram is to show processes involved in the item value processing and the way they interact.  -   Data gathering starts with raw data from a data source. At this     point, the data contains only ID, timestamp and value (can be multiple     values as well) -   No matter what type of data gatherer is used, the idea is the same     for active or passive checks, for trapper items, etc, as it only     changes the data format and the communication starter (either data     gatherer is waiting for a connection and data, or data gatherer     initiates the communication and requests the data). The raw data is     validated, the item configuration is retrieved from the configuration cache     (data is enriched with the configuration data). -   A socket-based IPC mechanism is used to pass data from data gatherers     to the preprocessing manager. At this point the data gatherer continues to     gather data without waiting for the response from preprocessing     manager. -   Data preprocessing is performed. This includes the execution of     preprocessing steps and dependent item processing.  ::: noteclassic An item can change its state to NOT SUPPORTED while preprocessing is performed  if any of preprocessing steps fail. :::  -   The history data from the local data cache of the preprocessing manager is being     flushed into the history cache. -   At this point the data flow stops until the next synchronization of     history cache (when the history syncer process performs data     synchronization). -   The synchronization process starts with data normalization before storing data     in Zabbix database. The data normalization performs conversions to the     desired item type (type defined in item configuration), including     truncation of textual data based on predefined sizes allowed for     those types (HISTORY\_STR\_VALUE\_LEN for string,     HISTORY\_TEXT\_VALUE\_LEN for text and HISTORY\_LOG\_VALUE\_LEN for     log values). The data is being sent to the Zabbix database after     the normalization is done.  ::: noteclassic An item can change its state to NOT SUPPORTED if data normalization fails  (for example, when a textual value cannot be converted to number). :::  -   The gathered data is being processed - triggers are checked, the item     configuration is updated if item becomes NOT SUPPORTED, etc. -   This is considered the end of data flow from the point of view of     item value processing.

en-us	#### Overview  Geomap widget displays hosts as markers on a geographical map using open-source JavaScript interactive maps library Leaflet.  ::: noteclassic  Zabbix offers multiple predefined map tile service providers and an option to add a custom tile service provider or even host tiles themselves (configurable in the *Administration → General → Geographical maps* [menu section](/manual/web_interface/frontend_sections/administration/general#geographical_maps)). :::
kk	#### Overview  Geomap widget displays hosts as markers on a geographical map using open-source JavaScript interactive maps library Leaflet.  ::: noteclassic  Zabbix offers multiple predefined map tile service providers and an option to add a custom tile service provider or even host tiles themselves (configurable in the *Administration → General → Geographical maps* [menu section](/manual/web_interface/frontend_sections/administration/general#geographical_maps)).  :::

en-us	#### Overview  To create an item in Zabbix frontend, do the following:  -   Go to: *Data collection* → *Hosts* -   Click on *Items* in the row of the host -   Click on *Create item* in the upper right corner of the screen -   Enter parameters of the item in the form  You can also create an item by opening an existing one, pressing the *Clone* button and then saving under a different name.
kk	#### Overview  To create an item in Zabbix frontend, do the following:  -   Go to: *Data collection* → *Hosts* -   Click on *Items* in the row of the host -   Click on *Create item* in the upper right corner of the screen -   Enter parameters of the item in the form  You can also create an item by opening an existing one, pressing the *Clone* button and then saving under a different name.

en-us	#### Preprocessing queue  The preprocessing queue is organized as:  *   the list of pending tasks:     *   tasks created directly from value preprocessing requests in the order they were received  *   the list of immediate tasks (processed before pending tasks):     *   testing tasks (created in response to item/preprocessing testing requests by the frontend)     *   dependent item tasks     *   sequence tasks (tasks that must be executed in a strict order):         *   having preprocessing steps using the last value:             *   change             *   throttling             *   JavaScript (bytecode caching)         *   dependent item preprocessing caching  *   the list of finished tasks
kk	#### Preprocessing queue  The preprocessing queue is organized as:  *   the list of pending tasks:     *   tasks created directly from value preprocessing requests in the order they were received.  *   the list of immediate tasks (processed before pending tasks):     *   testing tasks (created in response to item/preprocessing testing requests by the frontend)     *   dependent item tasks     *   sequence tasks (tasks that must be executed in a strict order):         *   having preprocessing steps using the last value:             *   change             *   throttling             *   JavaScript (bytecode caching)         *   dependent item preprocessing caching  *   the list of finished tasks

en-us	#### Recovery operation details  ![](../../../../../assets/en/manual/config/recovery_operation_details.png){width="600"}  Three operation types are available for recovery events:  -   **Send message** - send recovery message to specified user; -   **Notify all involved** - send recovery message to all users who were notified on the problem event; -   **<remote command name>** - execute a remote command. Commands are available for execution if previously defined in [global scripts](/manual/web_interface/frontend_sections/alerts/scripts#configuring_a_global_script) with *Action operation* selected as its scope.  Parameters for each operation type are described below. All mandatory input fields are marked with a red asterisk. When done, click on *Add* to add operation to the list of *Recovery operations*.  ::: noteclassic Note that if the same recipient is defined in several operation types without specified *Custom message*, duplicate notifications are not sent. :::
kk	#### Recovery operation details  ![](../../../../../assets/en/manual/config/recovery_operation_details.png){width="600"}  Three operation types are available for recovery events:  -   **Send message** - send recovery message to specified user. -   **Notify all involved** - send recovery message to all users who were notified on the problem event. -   **<remote command name>** - execute a remote command. Commands are available for execution if previously defined in [global scripts](/manual/web_interface/frontend_sections/alerts/scripts#configuring_a_global_script) with *Action operation* selected as its scope.  Parameters for each operation type are described below. All mandatory input fields are marked with a red asterisk. When done, click on *Add* to add operation to the list of *Recovery operations*.  ::: noteclassic Note that if the same recipient is defined in several operation types without specified *Custom message*, duplicate notifications are not sent. :::

en-us	##### Serialization rules  XML to JSON conversion will be processed according to the following rules (for JSON to XML conversions reversed rules are applied):  1\. XML attributes will be converted to keys that have their names prepended with '@'.  Example:  *Input:*       <xml foo="FOO">        <bar>          <baz>BAZ</baz>        </bar>      </xml>  *Output:*  ```json  {    "xml": {      "@foo": "FOO",      "bar": {        "baz": "BAZ"      }    }  } ```  2\. Self-closing elements (<foo/>) will be converted as having 'null' value.  Example:  *Input:*      <xml>       <foo/>     </xml>  *Output:*  ```json {   "xml": {     "foo": null   } } ```  3\. Empty attributes (with "" value) will be converted as having empty string ('') value.  Example:  *Input:*      <xml>       <foo bar="" />     </xml>  *Output:*  ```json {   "xml": {     "foo": {       "@bar": ""     }   } } ```  4\. Multiple child nodes with the same element name will be converted to a single key that has an array of values as its value.  Example:  *Input:*      <xml>       <foo>BAR</foo>       <foo>BAZ</foo>       <foo>QUX</foo>     </xml>  *Output:*  ```json {   "xml": {     "foo": ["BAR", "BAZ", "QUX"]   } } ```  5\. If a text element has no attributes and no children, it will be converted as a string.  Example:  *Input:*      <xml>         <foo>BAZ</foo>     </xml>  *Output:*  ```json {   "xml": {     "foo": "BAZ"    } } ```  6\. If a text element has no children but has attributes, text content will be converted to an element with the key '\#text' and content as a value; attributes will be converted as described in the serialization rule 1.  Example:  *Input:*      <xml>       <foo bar="BAR">         BAZ       </foo>     </xml>  *Output:*  ```json {   "xml": {     "foo": {       "@bar": "BAR",       "#text": "BAZ"     }   } } ```
kk	##### Serialization rules  XML to JSON conversion will be processed according to the following rules (for JSON to XML conversions reversed rules are applied):  1\. XML attributes will be converted to keys that have their names prepended with '@'.  Example:  *Input:*       <xml foo="FOO">        <bar>          <baz>BAZ</baz>        </bar>      </xml>  *Output:*  ```json  {    "xml": {      "@foo": "FOO",      "bar": {        "baz": "BAZ"      }    }  } ```  2\. Self-closing elements (<foo/>) will be converted as having 'null' value.  Example:  *Input:*      <xml>       <foo/>     </xml>  *Output:*  ```json {   "xml": {     "foo": null   } } ```  3\. Empty attributes (with "" value) will be converted as having empty string ('') value.  Example:  *Input:*      <xml>       <foo bar="" />     </xml>  *Output:*  ```json {   "xml": {     "foo": {       "@bar": ""     }   } } ```  4\. Multiple child nodes with the same element name will be converted to a single key that has an array of values as its value.  Example:  *Input:*      <xml>       <foo>BAR</foo>       <foo>BAZ</foo>       <foo>QUX</foo>     </xml>  *Output:*  ```json {   "xml": {     "foo": ["BAR", "BAZ", "QUX"]   } } ```  5\. If a text element has no attributes and no children, it will be converted as a string.  Example:  *Input:*      <xml>         <foo>BAZ</foo>     </xml>  *Output:*  ```json {   "xml": {     "foo": "BAZ"    } } ```  6\. If a text element has no children, but has attributes: text content will be converted to an element with the key '\#text' and content as a value; attributes will be converted as described in the serialization rule 1.  Example:  *Input:*      <xml>       <foo bar="BAR">         BAZ       </foo>     </xml>  *Output:*  ```json {   "xml": {     "foo": {       "@bar": "BAR",       "#text": "BAZ"     }   } } ```

en-us	 #### Structure  The header consists of four fields. All numbers in the header are formatted as little-endian.  |Field|Size|Size<br>(large packet)|Description| |--|-|-|------| |`<PROTOCOL>`|4|4|`"ZBXD"` or `5A 42 58 44`| |`<FLAGS>`|1|1|Protocol flags:<br>`0x01` - Zabbix communications protocol<br>`0x02` - compression<br>`0x04` - large packet| |`<DATALEN>`|4|8|Data length.| |`<RESERVED>`|4|8|When compression is used (`0x02` flag) - the length of uncompressed data<br>When compression is not used - `00 00 00 00`|
kk	 #### Structure  The header consists of four fields. All numbers in the header are formatted as little-endian.  |Field|Size|Size<br>(large packet)|Description| |--|-|-|------| |`<PROTOCOL>`|4|4|`"ZBXD"` or `5A 42 58 44`| |`<FLAGS>`|1|1|Protocol flags:<br>`0x01` - Zabbix communications protocol<br>`0x02` - compression<br>`0x04` - large packet| |`<DATALEN>`|4|8|Data length.| |`<RESERVED>`|4|8|When compression is used (`0x02` flag) - the length of uncompressed data<br>When compression is not used - `00 00 00 00`|

en-us	##### Using macros in scripts  It is possible to use user macros in JavaScript code. If a script contains user macros, these macros are resolved by server/proxy before executing specific preprocessing steps. Note that when testing preprocessing steps in the frontend, macro values will not be pulled and need to be entered manually.  ::: noteclassic  Context is ignored when a macro is replaced with its value. Macro value is inserted in the code as is, it is not possible to add additional escaping before placing the value in the JavaScript code. Please be advised that this can cause JavaScript errors in some cases. :::  In an example below, if received value exceeds a {$THRESHOLD} macro value, the threshold value (if present) will be returned instead:  ```javascript var threshold = '{$THRESHOLD}'; return (!isNaN(threshold) && value > threshold) ? threshold : value; ```
kk	##### Using macros in scripts  It is possible to use user macros in JavaScript code. If a script contains user macros, these macros are resolved by server/proxy before executing specific preprocessing steps. Note that when testing preprocessing steps in the frontend, macro values will not be pulled and need to be entered manually.  ::: noteclassic  Context is ignored when a macro is replaced with its value. Macro value is inserted in the code as is, it is not possible to add additional escaping before placing the value in the JavaScript code. Please be advised, that this can cause JavaScript errors in some cases. :::  In an example below, if received value exceeds a {$THRESHOLD} macro value, the threshold value (if present) will be returned instead:  ```javascript var threshold = '{$THRESHOLD}'; return (!isNaN(threshold) && value > threshold) ? threshold : value; ```

en-us	 Zabbix server or proxy will try to pool requests to a single JMX target together as much as possible (affected by item intervals) and send them to the Java gateway in a single connection for better performance.  It is suggested to have **StartJavaPollers** less than or equal to **START\_POLLERS**, otherwise there might be situations when no threads are available in the Java gateway to service incoming requests; in such a case Java gateway uses ThreadPoolExecutor.CallerRunsPolicy, meaning that the main thread will service the incoming request and will not accept  any new requests temporarily.  If you are trying to monitor Wildfly-based Java applications with Zabbix Java gateway, please install the latest jboss-client.jar available on the [Wildfly download page](https://www.wildfly.org/downloads/).
kk	Zabbix server or proxy will try to pool requests to a single JMX target together as much as possible (affected by item intervals) and send them to the Java gateway in a single connection for better performance.  It is suggested to have **StartJavaPollers** less than or equal to **START\_POLLERS**, otherwise there might be situations when no threads are available in the Java gateway to service incoming requests; in such a case Java gateway uses ThreadPoolExecutor.CallerRunsPolicy, meaning that the main thread will service the incoming request and will not accept  any new requests temporarily.  If you are trying to monitor Wildfly-based Java applications with Zabbix Java gateway, please install the latest jboss-client.jar available on the [Wildfly download page](https://www.wildfly.org/downloads/).