Previous Topic: ArchitectureNext Topic: File Encryption


Test Table Information

Useful state management of SRM requires the capability to monitor specific metrics and specify the severity of the associated monitors.

The SRM test table stores the following information:

Test Instance Name

(Optional) Specifies the Test Instance Name for the test. This name is used for state manager object information, resource instance information for performance data collection, and as an alternative to the random integer index as a primary key for tests which can change depending upon the templates delivered. It is optimal to have a non-NULL Test Name, but is mandatory only for file-based configuration when the configuration file has a version equal or greater than 3.0. SRM retains legacy support.

Note: This value is only writable during creation of the test. You cannot modify it afterwards, because it acts as a primary key for the table.

Service Context Info

Specifies a location to store any information a manager likes to store, such as UUID’s, flags, antecedent properties of this test object, and so on. SRM does not directly use this information for any functionality, but delivers this information as part of any manager notification. The manager, however, can use this information to direct results of this test to the appropriate monitored device. For example, a DNS test can be associated with the actual DNS device instead of the machine running the DNS test.

Test Class Name

(Optional) Specifies the Test Class Name for the test. This name is used for state manager object information, resource instance information for performance data collection, and for object information of monitors that are created upon the test.

Note: This value is only writable during creation of the test. You cannot modify it afterwards, because it acts as a primary key for the table.

Log Level

Specifies the log level for the code executing the test. The global SRM log level is used if this parameter has no value or if the value is invalid. Possible values are:

-1 - no logging

0 - log fatal level messages

1 - log also critical level messages

2 - log also warning level messages

3 - log also information level messages

4 - log also debug level messages

5 - log also debug1 level messages

6 - log also debug2 level messages

7 - log also debug3 level messages

Note: If high logging is enabled for HTTP monitors, the CPU usage can spike up. Setting low or medium log levels is recommended except for extreme circumstances.

Flags

(Optional) Specifies the following flags:

Default flag

Specifies the “best practices” solution.

0x0001 [cube_collect]

Indicates if this test collects data for historical performance analysis to support CA NSM Systems Performance reporting and analytics. If this flag is set SRM adds emphistory entries enabled for cube collection to monitor the SRM fixed set of metrics for this test. By default the entries are not added.For more information about emphistory, see the SystemEDGE User Guide.

0x0100 [run_once]

Indicates that this test only runs on request. It is not controlled by the poll interval scheduler.

The SystemEDGE monitor table contains monitors for SRM tests. The SystemEDGE monitor creation process supports the creation of SRM monitors through an SE-OID-helper functionality. This helper requires that the SE Class, Instance and Attribute are filled with TestType, TestInstance and TestMetric, for example, Class=Http, Instance=MyHomePage, Attribute=Overall Response Time. The helper detects the corresponding metric OID, inserts it into the SystemEDGE monitor OID attribute, and creates a monitor.

Note: For further information, see the SystemEDGE User Guide.