Import SiteScope templates

Administration > Monitoring > Policy Templates

Alternatively, click Policy Templates.

In SiteScope, monitors are tools that can retrieve specific availability and performance data from remote servers. Different types of monitors are available for monitoring different types of systems. When you want to use a particular type of monitor, you create a new instance of it. For each new instance of a monitor, you must specify the remote server that you want to monitor and values for any other settings that configure the monitor.

For example, SiteScope provides a monitor called CPU, which can monitor the level of CPU usage on a remote server. When you create an instance of the CPU monitor, you must specify the remote server that you want to monitor. You can also specify the frequency that you want to check the CPU usage on that server, and thresholds at which you want the monitor to report an error or warning.

You can use templates in SiteScope to create sets of monitors that you want to deploy together. When you add a monitor to a template, you can specify fixed values for the monitor's settings. In addition, you can add variables to a template so that you can set the values of some settings when you deploy the template.

For example, you could have a template that contains the monitors called CPU and Memory. You could configure some fixed settings that you always want to use for those monitors, but add variables called Remote Host and Monitoring Interval, for settings that you want to specify each time you deploy the template.

SiteScope variables can be classified as the variables that identify an object to be monitored and the variables that provide additional information about the object (dependent variables), for example: 

• Identifying variables providing the information on the database instance that needs to be monitored are DB HOST, DB INSTANCE, FILESYSTEM, TABLESPACENAME and so on.

• Dependent variables providing additional information about the instance are USER, PASSWORD, PORT and so on.

When you import SiteScope templates, OMi exports the templates from the SiteScope server and transforms them into the OMi policy templates. SiteScope variables are converted to parameters in the resulting policy templates. For more information on importing templates and important considerations that need to be taken into account, see How to Import Templates from a SiteScope Server and Considerations for Importing SiteScope Templates.

SiteScope templates contain information about the remote servers that they monitor. This information is usually stored in a variable that is replaced by the list of remote servers when the template is imported. The import tool must be able to identify the variable that contains the host information in order to create a corresponding instance parameter in the resulting policy template, otherwise, the import will fail.

Therefore, when importing a SiteScope template, you need to consider the following:

• To create the host instance parameter, the import tool chooses one of the SiteScope variables in the order described below:

  1. The variable with the display order number 0 (uiOrder=0) in the SiteScope template.

  2. The variable named host in the SiteScope template.

     Note If the variable host exists in a SiteScope template but does not have a value, the value will be set to %%HOST%% during the template import.

  3. The variable with the value %%HOST%% in the SiteScope template.

  If none of the above variables exist, the SiteScope template cannot be imported and an error is reported.

• The import tool assumes that all import variables belong together and they define one instance of an object to be monitored. The variable with the display order number 0 (uiOrder=0) and the hostname variable are always seen as identifying variables and the rest as dependent variables. Therefore, if the second identifying variable is present (for example, DB INSTANCE or FILESYSTEM), the tool cannot detect it unless the following workaround is applied:

  1. The variable with the display order number 0 (uiOrder=0) in the SiteScope template always identifies a monitored object. Therefore, avoid assigning this value to the host variable if the template has two identifying variables. Instead, assign the display order number 0 (uiOrder=0) to the second instance identifying variable. Note that if the host is the only instance identifier, it can be assigned uiOrder=0.

  2. Check that the hostname is assigned to the variable named host or the variable with the value %%HOST%% in the SiteScope template.

  This way, the import tool has information about both identifying variables and is able to create the host instance parameter during the template import. Refer to the following example:

  SiteScope template for database availability checking has the following variables: DB INSTANCE, DB HOST, USER, PASSWORD, PORT and FREQUENCY. The combination of DB INSTANCE and DB HOST identifies the instance to be monitored, while all other variables are dependent ones providing additional information about the instance. If the above conventions are followed, the import tool treats both DB INSTANCE and DB HOST as instance identifiers and correctly coverts all SiteScope variables to corresponding parameters in the resulting policy templates.

SiteScope policy templates must be assigned to the remote servers that you want to monitor with SiteScope. Before deploying the policy template, OMi replaces the value %%HOST%% with the list of remote servers to which the policy template is assigned. Based on the connected server configuration, OMi then selects the SiteScope server that qualifies for monitoring the remote servers and deploys the policy template to that server. The SiteScope server finally creates the corresponding monitors and starts monitoring the remote servers.

To be able to assign and deploy a SiteScope policy template, the SiteScope server must be set up as a connected server in OMi and a node CI must exist for the system in Monitored Nodes. In addition, the remote systems that SiteScope monitors must be represented as node CIs in the RTSM. Note that if a set up SiteScope connected server is not active, it cannot be used for deployment until it is activated in the Connected Servers UI.

What to avoid:

• Do not assign SiteScope policy templates to the SiteScope server itself. The policy templates must always be assigned to the remote servers that will be monitored by SiteScope.

• Do not use the hostname of the CI to be monitored as value of the instance parameter representing the hosts to be monitored. For example, do not enter ora.example.com as an instance parameter value. Instead, use the symbolic value %%HOST%% or set the parameter value based on the CI attribute PrimaryDNSName. The symbolic values are automatically resolved during deployment to the monitored CIs.

On the OMi server, open a command prompt and run the ConfigExchangeSIS command-line interface to import templates from a SiteScope server.

For example, the following command loads the templates that are in the template container called "Template Examples" from sitescope1.example.com:

<OMi_HOME>\opr\bin\ConfigExchangeSIS.bat -sis_group_container "Template Examples" -sis_hostname sitescope1.example.com -sis_user integrationViewer -sis_passwd password -bsm_hostname bsm1.example.com -bsm_user admin -bsm_passwd password -bsm_port 80

For more information on importing SiteScope templates, see ConfigExchangeSIS Command-Line Interface.

1. Assign the SiteScope policy template to the remote servers (that is to the node CIs) that you want to monitor. Do not assign the template to the SiteScope server itself. For information about assigning a policy template, aspect, or management template to a CI, see Assignments and Tuning.

2. Every SiteScope policy template typically includes a hostname parameter that resolves to the remote server to be monitored. If this value is not already set, edit the value of this parameter during the assignment and enter the symbolic value %%HOST%%.

   Alternatively, set the CI attribute PrimaryDNSName as the default value of this parameter on the aspect or management template level.

   Before deploying the policy template, OMi replaces the value %%HOST%% with the list of remote servers to which the policy template is assigned.

   Tip Set %%HOST% or the CI attribute PrimaryDNSName already in the template in SiteScope before importing it to OMi. If the host instance parameter is already set at policy template level, you do not need to provide a value when assigning the policy template (aspect or management template) to a CI.

To combine the SiteScope policy template and the agent-based policy template into one aspect or management template, proceed as follows:

1. Prerequisites. Make sure the steps described in Configuring and deploying SiteScope monitors from OMi in the Integrate section have been performed before you start this task.

2. Using the Management Templates and Aspects manager, combine the SiteScope policy template and the agent-based policy template into one aspect or management template and assign it to the CI you want to monitor. Do not assign the template to the SiteScope server itself.

   When creating aspects or management templates, you can group parameters from the imported SiteScope templates on the aspect or management template level. SiteScope templates always have one parameter that defines the instance to be monitored (typically the host-parameter), and a number of dependent parameters (like user and password). The host-parameter is automatically filled by the RTSM.

   When combining two templates, consider how to group the parameters from the SiteScope policy template and the agent-based policy template, for example:

   The policy DBmonAgentBased (type Measurement Threshold) has an instance parameter named database_instance with the dependent parameters user, password and port=1521. The policy DBmonAgentLess (type SiteScope) has an instance parameter INSTANCE with the dependent parameters HOST=%%HOST%%, USER, PASSWORD, PORT=1521. Both policies must be combined into one aspect called DBmon with only one instance parameter on an aspect level.

   To combine the parameters:

   1. Group the database_instance and INSTANCE parameters together and name the group, for example, DBinstance.

   2. Group the remaining parameters: user and USER into DBUser, password and PASSWORD into DBpassword, portand PORT into DBport.

   3. Make a group named DBhost consisting of HOST=%%HOST%% and make it hidden, the reason for this being that displaying the combined hostname parameter can lead to cosmetic issues and therefore should not be visible to the user. Moreover, this parameter is redundant, since the Measurement Threshold policy template does not require it and the hostname is already defined through the assignment target.