Trend manager process Test
The eG Trend manager process uses the raw measurement data in the eG database to compute hourly, daily, weekly, and monthly summaries and performance averages, and stores these computations in trend tables. Users to the eG monitoring and reporting consoles can query the data in the trend tables to generate trend graphs and reports. These graphs/reports enable administrators to clearly understand the historical trends in performance, on the basis of which they can accurately predict future performance and effectively plan the future capacity of the environment. Using this test, you can understand how efficient the trend manager process is. The test reports the current status of this process, points you to trend computation failures and where they occurred, and reveals slowdowns in trend computation (if any).
Target of the test : The eG Manager
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for the eG manager 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. |
|
JMX Remote Port |
Here, specify the port at which the JMX listens for requests from remote hosts. In the <EG_MANAGER_INSTALL_DIR>\manager directory (on Windows; on Unix, this will be the /opt/egurkha/manager directory) of the eG manager, you will find a management.properties file. Set the port defined against the com.sun.management.jmxremote.port parameter of the file as the JMX Remote Port. |
|
User, Password, and Confirm Password |
By default, JMX requires no authentication or security. Therefore, the User, Password , and Confirm Password parameters are set to none by default. |
|
JNDIName |
The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registry using a different lookup name, then you can change this default value to reflect the same. |
|
JMX Provider |
This test uses a JMX Provider to access the MBean attributes of the eG manager and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol. |
|
Timeout |
Specify the duration (in seconds) for which this test should wait for a response from the eG manager. If there is no response from the eG manager beyond the configured duration, the test will timeout. By default, this is set to 240 seconds. |
|
Threshold Duration of Test |
This test reports a Successful trend tests measure, which indicates the number of tests for which the trend manager successfully computed hourly, daily, weekly, and monthly trends. The detailed diagnosis of this measure, if enabled, will by default list only the top-10 successful trend tests, arranged in the descending order of the time taken by the trend manager to compute trends on them. To arrive at this top-10 list, the test considers only those successful tests for which the trend manager took more than 1 minute (by default) for trend computation. This is why, the Threshold Duration of Test parameter is set to 1 (minute) by default. This default setting can be overridden by specifying a duration (in minutes) of your choice in the Threshold Duration of Test text box. For instance, if you specify 5 here, then, the detailed diagnosis will list the top-10 (by default) successful trend tests for which the trend manager took more than 5 minutes for trend computation. |
|
Top Time Taken Test |
As already mentioned, the detailed diagnosis of the Successful trend tests measure, by default, lists the top-10 successful trend tests, arranged in the descending order of the time taken by the trend manager to compute thresholds on them. This is why, the Top Time Taken Test is set to 10 by default. To view more or a less number of successful trend tests in the detailed diagnosis, specify a different value in the Top Time Taken Test box. For instance, if 20 is specified here, then the detailed diagnosis will list the top-20 successful trend tests. |
|
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
| Measurement | Description | Measurement Unit | Interpretation | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Trend manager status |
Indicates the current status of the trend manager process. |
|
The values that this measure reports and the numeric values that correspond to them have been discussed 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 trend manager process. The graph of this measure however, represents the same using the numeric equivalents only. |
||||||||||||
|
Time taken for trend computation |
Indicates the total time taken by the trend manager process to perform trend computations.
|
Minutes |
Ideally, the value of this measure should be low. A steady rise in this measure value is a cause for concern, as it indicates that the trend manager is taking too long to compute trends. This can happen if there are too many components, tests, and measurements for which trends need to be computed. |
||||||||||||
|
Successful trend tests |
Indicates the number of tests for which trends were computed successfully. |
Number |
You can use the detailed diagnosis of this measure to know the tests for which the trend data has been successfully computed. |
||||||||||||
|
Failed trend tests |
Indicates the number of tests for which trend computation failed. |
Number |
The value 0 is desired for this measure. Any non-zero value is indicative of a trending failure. In this case, you can use the detailed diagnosis of this measure to identify those tests for which trend computation failed and investigate the reason why. Without trend data, users may not be able to generate useful trend graphs and reports; in the absence of trend reports, capacity plans cannot be drawn accurately. |
||||||||||||
|
Time since last trend update |
Indicates the elapsed time since the last trend computation. |
Minutes |
Typically, trending is scheduled to take place at the end of every day. By carefully observing the values reported by this measure, you can easily find out when a scheduled trend computation cycle was missed. |
||||||||||||
|
Is trend manager a separate process? |
Indicates whether/not the trend manager is running as a separate process.
|
|
The eG manager runs as a Java process. The maximum heap memory that can be allocated to a 32-bit eG manager process is limited to 1.5 GB. The maximum heap memory allocation to a 64-bit eG manager process on the other hand, is limited to 3 GB. Even if the physical Even if the physical server on which the eG manager is installed has more memory, since it is a single Java process, the eG manager cannot exploit the additional memory available on the server. To overcome this limitation, in eG Enterprise, the critical eG manager functions such as email alert management, threshold computation, trending, and database cleanup activities can all be run as separate Java processes (i.e., in addition to the core eG manager process). Removing these key functions from the core eG manager process makes additional memory available for the core eG manager functions including data reception and analysis, alarm correlation, and web-based access and reporting. This reconfiguration of the eG manager into separate Java processes allows the eG manager to make better utilization of available server hardware resources and thereby offers enhanced scalability. In turn, this allows customers to get more leverage from their existing investment in the hardware that hosts the eG manager. If cleanup has been configured to run as a separate Java process, then the value of this measure will be Yes. If not, then this measure reports the value No. The numeric values that correspond to the measure values above are as follows:
Note: By default, this measure reports the Measure Values listed in the table above to indicate whether/not the trend manager runs as a separate Java process. The graph of this measure however, represents the same using the numeric equivalents only. |
||||||||||||
|
|
|
|
Typically, trending is scheduled to take place at the end of every day. If the value of this measure is Yes, it indicates that trend computation has been completed for today. On the other hand, if this measure reports the value No, it indicates that trend computation is yet to be completed for that day or the trend has not been computed at all. The numeric values that correspond to the current day's
Note: By default, this measure reports the Measure Values listed in the table above to indicate whether/not |
||||||||||||
|
Slow trend tests
|
Indicates the number of tests for which trend computation was slow. |
Number |
Use the detailed diagnosis of this measure to know for which tests trend computation was slow. |
||||||||||||
|
Days since trend last ran |
Indicates the number of days since the trend manager was started. |
Days |
|
||||||||||||
|
Time taken for computing historical state data |
Indicates the time taken by the trend manager to perform trend computations for reporter data. |
Minutes |
|
||||||||||||
|
Time taken for computing and sending schedule reports |
Indicates the total time taken by the trend manager to perform trend computations for schedule reports and send the same. |
Minutes |
|
