eG Administration
 

Adding a New Test

This page explains the details of the inputs that have to be specified to add a new test using Integration Console. To do so, click on the Add New test button in the INTEGRATION CONSOLE - TEST page that appears when you follow the menu sequence Admin -> Integration Console -> Test in the Admin module of the eG Enterprise System.

  • Specify the type of the test that you wish to add from the Test type list. By default, Performance will be chosen from this list. If you wish to add a configuration test, then choose Configuration from this list.

  • The name of the test has to be specified in the Test name text box.

    Note:

    Ensure that the test name always ends with "_ex". Otherwise, users will not be permitted to add the test. If you wish to add a configuration test, then, ensure that the test name always ends with _cf_ex.

  • Once the test name is specified, you will have to indicate whether/not the test being added is a duplicate of an existing test. eG Enterprise allows users to duplicate an existing IC-based test, so that the complete configuration of the existing test (i.e., the test type, the test parameters, its measures, and all other test specifications except the test name) is automatically copied to the new test. This duplication is particularly useful when you want to create two/more tests with the same/similar functionality, and assign them to different layers or components.

  • If the test being added is a duplicate of an existing test, then set the Duplicate flag to Yes. From the Test to be duplicated list that then appears, pick the existing test that is to be duplicated. Upon selection of the test, the Test type of the chosen test will automatically apply to the new test. Now, click the Add button to add the new test.

    On the other hand, if you set the Duplicate flag to No, then you would have to explicitly provide the new test's details. Then proceed to specify the mode of Execution of the test. The Execution field governs whether the test is to be executed by an internal agent or by an external agent. As a rule of thumb, if the test relies on application counters, log files, etc., it must be executed by an internal agent. On the other hand, if the test uses the Simple Network Management Protocol (SNMP), HTTP, or emulates user requests it can be executed by an external agent. When adding a test, you also have to specify whether the test is Port based or not. In other words, you have to indicate whether the test corresponds to a server that is listening on a specific TCP/UDP port or not. Typically, if a new test is to be mapped to any of the bottom 3 layers of a component (i.e., host-specific layers), then such a test should be a non-port-based test only; accordingly, you should set the Port based parameter to No for such a test.

  • The user then needs to indicate the Test type of the new test, by selecting one of the following options from the list box:

    • Custom: Tests of this type offer complete flexibility to users in developing and integrating new monitoring functionality into the eG system. In order to develop a Custom test, a user must use eG's Java-based programming interface.

    • Script/Batch File: In some cases it may be easier to build new monitoring capabilities using simple shell scripts, VB scripts, or batch files. To support this capability, the Integration Console supports a Script/Batch File test. When choosing this type, the user provides the script/batch file to be used and the Integration Console takes care of integrating the script into the eG framework.

      Upon selecting this Test type, the user will be prompted to indicate whether the test is to be associated with a script or with a batch file. If the test is to be associated with a shell script, the user has to select the UNIX option. On the other hand, if the test is to be associated with a batch file or a VB script, the user has to select the Windows option.

    • Sql Query: Many a times critical statistics on an application are stored in a database. To make it possible to extract such statistics from the database without having to write elaborate programs, the Integration Console includes an SQL Query test type. Once the Sql Query test type is selected, the user will be prompted to choose the database on which the Sql query or the stored procedure is to be executed. If the query/procedure is to run on an Oracle database, select Oracle as the DB TYPE. If the query/procedure is to run on an MsSql database, then pick MsSql as the DB TYPE. Similarly, if the query/procedure is to run on a Sybase or MySql server, pick Sybase or Mysql as the DB TYPE.

    • Perfmon: Perfmon tests can operate only on Windows environments. This option provides a quick and easy way of building tests that interface with the Windows Perfmon capability to collect various metrics of interest.

    • Snmp: Tests of this type are typically executed on network devices such as routers, hubs, switches etc., so that performance statistics pertaining to the same can be obtained using the SNMP protocol.

    • Jmx: Java-based web servers and application servers (eg., Tomcat, JBoss, WebLogic, WebSphere, etc.) are common place in many IT infrastructures. Though eG Enterprise provides comprehensive monitoring models for most of these servers, some administrators might want to monitor certain additional server attributes that are not supported out-of-the-box by the eG agent. Likewise, in some other environments, custom Java applications may operate for which eG Enterprise may not provide out-of-the-box monitoring support. To enable administrators to extend the capabilities of the eG agent to report on additional attributes related to Java-based web and application servers, and to easily develop custom monitoring models for unsupported Java applications, eG Enterprise offers the Jmx test type. JMX (Java Management Extensions) is a Java technology that enables external programs like the eG agent to pull out performance metrics from a target Java application/server. By adding a test of type Jmx, you can easily equip the eG agent with the ability to leverage the JMX technology for connecting to any Java application/server, and reading the current values of those attributes of the target that interest you.

      Note:

      Prior to adding a new Jmx test, you need to enable the JMX support for the JRE of the target application. Please refer to the eG Customization Manual for the detailed steps to be followed in order to achieve this.

  • By clicking on the Add button, the user can add the new test to the eG Enterprise system.

  • When the test is successfully added, a response page indicating the test name and its properties will appear. Through this page, the administrator can also specify the parameters that this test will take in the NEW TEST PARAMETERS section.

    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.

    However, the NEW TEST PARAMETERS section will not be available for tests of type Snmp. 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.

    Default parameters are also available for tests of type Jmx. 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 provide a NEW PARAMETER DETAILS section, using which additional parameters and their default values can be configured.

    • Note:

    By default, every test added using the Integration Console automatically takes TEST PERIOD (i.e., the frequency with which the test needs to be executed) as its parameter. In addition, 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 &squo;lsquo;24-hour&r time format.

  • For non-Snmp-based tests, you can click on the Add button available in the NEW TEST PARAMETERS section to add the new parameter specification. 

  • You can even proceed to configure the measures for a test, by clicking the Configure "test_name" link at the right, top corner of this page.

    • The Back button enables the administrator to go back to the previous screen.

Modifying an Existing Test

To modify an existing test, click on the Modify button against the test name in the page listing the tests. All the details of the test will then be made available to the user, for modification.

  • The Test name and Test type will be displayed, but cannot be changed. Likewise once you set the Duplicate flag during the time of adding the new test, you will not be allowed to modify the same.

  • The user can alter the selected Execution mode of the test (i.e. whether the test is to be executed by an Internal or an External agent).

  • Similarly, while adding the test, the user would have specified whether the test is Port based or not. This specification can also be reset. Typically, if a new test is to be mapped to any of the bottom 3 layers of a component (i.e., host-specific layers), then such a test should be a non-port-based test only; accordingly, you should set the Port based parameter to No for such a test.

  • If the test type chosen during test creation is Script/Batch File, then the OS (whether UNIX or Windows) chosen by the user will appear. The user can choose a different OS while modifying the test.

  • If the test type chosen during test creation is Sql Query, then the DB type selected will appear. The user can opt for a different DB type while modifying the test.

  • To update the changes to the test details, click on the Modify button in this page.

  • Through this page, the administrator can also specify more parameters required for this test in the NEW TEST PARAMETERS section.

  • Similarly, existing parameters can be modified by clicking the Modify button against the parameter name in this page. 

  • Previously added parameters can be deleted using the Delete button that appears beside every parameter added. However, while users have the option to modify the default SNMPPORT, SNMPCOMMUNITY and SNMPVERSION parameters of a test of type Snmp, these parameters cannot be deleted. Neither can additional parameters be added for an Snmp test.

  • Clicking on the Add button available in the NEW TEST PARAMETERS section will result in the addition of the new parameter.

  • You can even proceed to configure the measures for a test, by clicking the Configure ”test_name“ link at the right, top corner of this page.

    The Back button enables the administrator to go back to the previous screen.