Metadata Service Test
Metadata service is responsible for querying and updating unpublished IBM® Cognos® Framework Manager models. If the Metadata service is unavailable or fails to service requests, then, the unpublished IBM® Cognos® Framework Manager models will not be updated and hence will remain outdated. To ensure that the unpublished IBM® Cognos® Framework Manager models are up to date, it is essential for the administrators to monitor the Metadata Service round the clock. The Metadata Service test helps administrators in this regard!
This test monitors the Metadata Service and reports the current status of the service. This test helps administrators identify the maximum number of processes that can be used by the dispatcher to handle requests. The maximum / minimum number of processes that were running at a give point in time since the service was last restarted helps administrators identify the load on the service. The request processing ability of the service is periodically monitored so that administrators can initiate troubleshooting at the earliest when there is a sudden / gradual increase in the count of failed requests.
Target of the test : An IBM Cognos Business Intelligence
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for the target IBM Cognos Business Intelligence suite being monitored
|
Parameter |
Description |
|---|---|
|
Test period |
How often should the test be executed . |
|
Host |
The host for which the test is to be configured. |
|
Port |
The port number at which the specified host listens. By default, this is NULL. |
|
JMX Remote Port |
Here, specify the port at which the JMX listens for requests from remote hosts. Ensure that you specify the same port that you configured in the p2pd.deploy_defaults.properties file available in the <IBM_COGNOS_BI_HOME>\webapps\p2pd\WEB-INF folder used by the target application server. |
|
JMX User, JMX Password, and Confirm Password |
By default, JMX requires no authentication or security (SSL). This is why, by default, the JMX User and JMX Password parameters are set to none. If JMX requires authentication only (but no security), then ensure that the JMX User and JMX Password parameters are configured with the credentials of an authorized user with access to JMX using the JMX Remote Port. Confirm the password by retyping it in the Confirm Password text box. |
| Measurement | Description | Measurement Unit | Interpretation | ||||||
|---|---|---|---|---|---|---|---|---|---|
|
Status |
Indicates the current status of the service. |
|
The values that this measure can report and their corresponding numeric values are listed in the table below:
Note: By default, this measure reports the Measure Values listed in the table above to indicate the current status of the service. In the graph of this measure however, the same is represented using the numeric equivalents only i.e., 0 or 100. |
||||||
|
Configured processes |
Indicates the maximum number of processes that the dispatcher can use to handle requests from the batch report service. |
Number |
There can be multiple report service and batch report service processes on each dispatcher. This measure displays the value that is configured against the following: Maximum number of processes for the <service_name> during peak period and Maximum number of processes for the <service_name> during non-peak period. Here, <service_name> corresponds to batch report service. |
||||||
|
Processes |
Indicates the number of processes that are currently running. |
Number |
A high value for this measure indicates that the service is overloaded. |
||||||
|
Processes high watermark |
Indicates the maximum number of processes that were running at a given point of time since the service was last restarted. |
Number |
A value close to Configured Processes measure indicates that there are few / no processes that can be used by the dispatcher to handle requests. |
||||||
|
Processes low watermark |
Indicates the minimum number of processes that were running at a given point of time since the service was last restarted. |
Number |
|
||||||
|
Processed requests |
Indicates the number of requests that were processed during the last measurement period. |
Number |
|
||||||
|
Successful requests |
Indicates the number of service requests that were successful during the last measurement period. |
Number |
A high value is desired for this measure. |
||||||
|
Percentage of successful requests |
Indicates the percentage of requests that were processed successfully during the last measurement period. |
Percent |
Ideally, the value of this measure should be close to 100. |
||||||
|
Failed requests |
Indicates the number of service requests that failed during the last measurement period. |
Number |
A high value is a cause of concern. Administrators can analyze the reason behind why the requests are failing frequently and can initiate troubleshooting at the earliest. |
||||||
|
Percentage of failed requests |
Indicates the percentage of requests that failed during the last measurement period. |
Percent |
A value close to 0 is desirable. A sudden / gradual increase in the value of this measure warrants administrators to initiate troubleshooting at the earliest. |
||||||
|
Successful requests per second |
Indicates the rate at which the requests were processed successfully during the last measurement period. |
Requests/sec |
|
