Add a New Parameter for a Test using Integration Console

This page appears when you have successfully added a new test using the Integration Console capability. Parameters refer to the arguments that a test needs to be configured with in order to run and collect performance statistics from a target.

By default, any test you add using the Integration Console, will take Test period and Host as its parameters. While the Test period represents the frequency with which the test is to be run, the Host indicates the host on which the test should run. If the test is a port-based test, then, it will additionally take the Port number as its parameter. You will not be able to view any of these default parameters, and hence will not be able to modify or delete them.

Some tests however, may support more parameters than the default Test period, Host, and Port. Such parameters can be user privileges that a test may require for connecting to targets, filter conditions, pattern specifications etc.  To add a parameter that should be associated with the test, click on the Add New Parameter button in the right top corner.

This will invoke the New Test Parameter pop up window where you are required to specify the following:

• Enter the parameter name in the Parameter text box.

• Then, specify the Default value of the parameter. Once a Default value is set, then every time the test runs, it will automatically use this default value for all servers on which it runs. Therefore, when setting a Default value, make sure that the value you provide does not have to be changed at run-time according to the target server/environment.

  If the value of the parameter varies with the target server/environment, then its best to leave the Default value as unconfigured. If this is done, then, once this test is mapped to a server and that server is managed in eG, the eG Enterprise system will explicitly prompt you to configure this parameter with a valid value before attempting to monitor that server. This way, you will be able to configure this parameter with the appropriate value at run-time and ensure that the test executes smoothly.

For example, the MsSqlNetTest will require a user name and password for the database administrator in order to obtain the statistics of interest. Hence, this test will take two parameters corresponding to the user name and password of the database administrator. The parameter name has to be specified in the Parameter text box. For each parameter being specified for a test, the default value has to be specified when adding the parameter. The default value can be a fixed value. For example if the default value is set to john, the MsSqlNetTest will expect to use this default value for all databases being monitored. If the user name varies from one database to another, it is preferable that the eG administrator be prompted to specify the user name whenever a new MS SQL server is added for monitoring. To allow this, the Integration Console allows the value of any parameter being specified to be set to the string unconfigured.

• The Add New Parameter button will not be available for tests of SNMP category . This is because, by default, SNMP-based tests take the following parameters: snmpPort, snmpCommunity, and snmpversion. Also, these parameters will take the default values, 161, public, and v1, respectively. No additional parameters can be defined for a test of this type, nor can you delete the existing parameters. To modify the default parameter, click on the Modify button. A Modify Parameter Details pop-up window will then appear, which will allow you to edit the Default value of the parameters.

• Default parameters are also available for tests of JMX Category. These default parameters and the default values they take have been discussed hereunder:

  • Jmx_Remote_port: By default, this parameter is set to unconfigured. This implies that while configuring a Jmx test created using IC for a target application in real-time, you should manually configure this parameter with the port number at which JMX listens for requests from remote hosts. During test configuration, ensure that you specify the same port that you configured in the management.properties file; by default, this file will be in the {JAVA_HOME}\jre\lib\management folder used by the target application.
  • Jndi_Name: The Jndiname is a lookup name for connecting to the JMX connector. By default, this is set to jmxrmi. If you have registered the JMX connector in the RMI registery using a different lookup name, then, while configuring a Jmx test created using IC for a target application in real-time, change this default value to reflect the change in the lookup name.
  • user and password: By default, both these parameters are set to none. However, if JMX requires authentication only (but no security), then, at the time of configuring this test for a target application in real-time, ensure that the user and password parameters are configured with the credentials of a user with read-write access to JMX. To know how to create such a user, please refer to the eG Customization Manual.

• Unlike SNMP tests, for JMX tests, this page will include a New Test Parameter button, using which additional parameters and their default values can be configured.

Note:

In addition to the default parameters bundled with every new test, eG Enterprise provides three ready-to-use parameters that can be, if required, configured for any new test added using the Integration Console. These parameters are, namely, executionTime, useMgrTime, and executeAtFixedTime.

• Typically, the executionTime parameter can be set for tests that need to execute at a specific time every day, or at the beginning of every hour. For instance, if you are adding a new test that should invoke a ‘database cleanup’ process at the end of every day and also monitor the process logs for errors, then such a test can take executionTime as one of its parameters, so that you can specify the exact time of the day at which the clean up process needs to begin. Similarly, if you want a test to execute at the beginning of every hour and report metrics, once again, you might want to use the executionTime parameter. While setting the Testperiod as 1 hour also ensures that the test runs once every hour, it does not guarantee that the test will run at the beginning of every hour. To add this parameter to a new test, specify executionTime in the Parameter text box in this page. Then set, unconfigured as its Default value, to indicate that the parameter expects user input.

• If the executionTime parameter has been added to any new IC test, then, depending on need, you may want to use the useMgrTime parameter along with it. By default, as soon as the eG agent starts, it synchronizes time with the eG manager, and proceeds to report measures at the manager's time. In MSP environments particularly, a single, central manager will be receiving performance data from managed customer environments across the globe - i.e., from agents operating in different time zones. By default, all these agents will run tests and report measurements at the manager's time. This means, if an executionTime has been specified for one/more tests executed by these agents, and key maintenance processes are being triggered by these tests, such processes will run at the manager's time and not the agent's, thereby causing confusion. Therefore, whenever there is a time difference between the agent and manager zones, you will have to make sure that the test that supports the executionTime parameter runs according to the agent's time and not the manager's. To ensure this, you will have to additionally configure a useMgrTime parameter for the test. To add this parameter to an IC-based test, specify useMgrTime in the Parameter text box, and set the Default Value to no. Also, note that the executionTime parameter can be added as a stand-alone parameter to any new IC-based test, but the useMgrTime parameter can only be used alongside the executionTime parameter.

• The executeAtFixedTime parameter can be used if a test needs to run at a fixed interval (in hours), starting from ‘midnight’ every day. For instance, you may have written a test to check whether/not a virus scanner runs at 12 AM and every 3 hours thereafter, every day. To make sure that the test runs at this exact frequency, first integrate the test into the eG Enterprise system via IC, and when doing so, specify executeAtFixedTime as a Parameter of the test; then, set Yes as its Default Value. Later, when configuring this test for a component, make sure that you set the Test Period as 3 hours. Typically, eG Enterprise computes a test's frequency based on when the eG agent executing that test was started. In the case of this test however, since the executeAtFixedTime parameter is set to Yes, the eG agent uses 12 AM (midnight) as the base for computing the test frequency, regardless of when it (i.e., the eG agent) was started. This ensures that the test runs every 3 hours from midnight - i.e., at 3 AM, 6 AM, 9 AM, 12 PM, 3 PM, 6 PM, 9 PM, 12 AM, and so on! Moreover, in this case, even if the eG agent is restarted in-between - say, at 2.30 PM - it will run the test at 3 PM as originally scheduled, and not at 5.30 PM (which is 3 hours from the time the eG agent was started). When using the executeAtFixedTime parameter however, make sure that the Test Period is only set in hours and is set to a number that is a factor of 24 - i.e., it can only be 1, 2, 3, 4, 6, 8, 12, or 24 hours. This is because, this parameter computes the test frequency using the ‘24-hour’ time format.