eG Help

eG Administration

The Java Application Dashboard

The default layer model representation has many benefits - for starters, the model is consistent across applications, thus ensuring a shorter learning curve for the users. Secondly, from depicting the current state of an application to indicating the current issues related to that application, the layer model page serves as the most reliable platform for providing detailed, real-time information related to current application performance. Lastly, and most importantly, the layer model page automatically correlates the performance across all the layers of an application, and precisely indicates where the performance issues related to that application originated - at the host level? the network/TCP level? or the application level? - in short, from a correlation standpoint, the layer model is ideal.

On the flip side, though the layer model can accurately point to the 'problem layer', the actual 'problem' itself is hidden inside the tests, measures, and detailed diagnosis information mapped to the layer; getting to the root-cause of an issue using the layer model therefore, involves a little time and a few mouse clicks! Finally, while its true that the layer model page can clearly depict the current state of a component, it merely provides the means to launch those interfaces that reveal past performance/problems related to that component; this implies that when it comes to analyzing historical performance and deducing performance trends, problem patterns, and potential anomalies, the layer model page offers little help.

To eiliminate these shortcomings, eG Enterprise now offers specialized dashboards along with the unique monitoring model of every application that is monitored. Once the problem layer is indicated by the layer model, you can switch to one of these dashboards to receive in-depth insights into the performance of the problem layer(s), and thus troubleshoot the issue at hand better. Typically, these dashboards facilitate the following:

Serve as a single, central console that not only depict the current state of a layer, but also instantly indicate the root-cause of issues pertaining to that layer, thereby enabling administrators to go from problem effect to the problem source in no time!

Combine both raw and graphically represented data, and facilitate an in-depth analysis of not just live performance, but also the historical performance of a particular layer, thus shedding light on potential anomalies;

Aid administrators in effectively analyzing the past trends in the performance of a layer, so that they can easily forecast future performance;

Enable service level audits on-the-fly, and thus help administrators accurately determine when a layer slipped from the desired performance levels.

By default, the layer model representation of every application is accompanied by a System Dashboard and a Network Dashboard. In addition to these dashboards, a few selected applications are provided with an Application Dashboard as well.

In order to ascertain how well an application is/has been performing, analysis of the performance of the System and Network layers of that application alone might not suffice. A closer look at the health of the Applicaton Layers is also necessary, so as to promptly detect instantaneous operational issues with the target application, and also proactively identify persistent problems or a consistent performance degradation experienced by the application. To provide administrators with such in-depth insights into overall application performance and to enable them to accurately isolate the root-cause of any application-level slowdown, eG Enterprise offers the Application Dashboard. Each of the critical applications monitored by eG Enterprise is accompanied by an exclusive applicaton dashboard. The contents of the dashboard will therefore primarily vary depending upon the application being monitored.

In addition, like the System and Network dashboards, the contents of the Application dashboard too are further governed by the Subsystem chosen. By default, the Overview option is chosen from the Subsystem list. If need be, you can change this default setting by picking a different option from the Subsystem list. The sections that follow will discuss each of the Subsystems offered by the sample Java application dashboard shown.

Overview

As its name suggests, the Overview dashboard of a Java application provides an all-round view of the health of the Java application being monitored, and helps administrators pinpoint the problem areas. Using this dashboard therefore, you can determine the following quickly and easily:

Has the application encountered any issue currently? If so, what is the issue and how critical is it?
How problem-prone has the application been during the last 24 hours? Which application layer has been badly hit?
Has the administrative staff been able to resolve all past issues? On an average, how long do the administrative personnel take to resolve an issue?
Are all the key performance parameters of the application operating normally?
Is the JVM (of the application) utilizing CPU optimally or is the current CPU usage of the JVM very high? Did the CPU usage increase suddenly or gradually - i.e., over a period of time?
How many threads are currently live on the JVM? Which of these threads is currently consuming high CPU? Have any JVM threads been blocked? Which thread is it?
Are any threads deadlocked?
Which is the busiest garbage collector on the JVM?
Which garbage collector is taking too long to collect garbage?
Which JVM process is currently consuming CPU and memory excessively?
Which memory pool on the JVM is utilizing too much memory?

The contents of the Overview Dashboard have been elaborated on hereunder:

The Current Application Alerts section, reveals the number and type of issues currently affecting the performance of the Java application being monitored. To know more about the issues at hand, click on any cell against Distribution that represents the problem priority of interest to you; the details of the current problems of that priority will then appear.
If the pop-up window reveals too many problems, you can use the text boxes that have been provided at the end of each column to run quick searches on the contents of the corresponding columns, so that the alarm of interest to you can be easily located. For instance, to find the alarm with a specific description, you can provide the whole/part of the alarm description in the text box at the end of the Description column; this will result in the automatic display of all the alarms with descriptions that contain the specified search string.

To zoom into the exact layer, test, and measure that reported any of the listed problems, click on any of the alarms in the Alarms window. Doing so will introduce an Alarm Details section into the Alarms window, which provides the complete information related to the problem clicked on. These details include the Site affected by the problem for which the alarm was raised, the test that reported the problem, and a miniature graph indicating the Last Measures. Clicking on this miniature will, which reveals a time-of-day graph indicating the variations in the problem measure during the last 24 hours (by default). Using this graph, you can figure out whether the problem occurred suddenly or is the climax of a consistent performance deterioration.

While the list of current issues faced by the application serves as a good indicator of the current state of the application, to know how healthy/otherwise the application has been over time, a look at the problem history of the application is essential. Therefore, the dashboard provides the History of Events section; this section presents a bar chart, where every bar indicates the number of problems of a particular severity, which was experienced by the Java application during the last 1 hour (by default). Clicking on a bar here will lead you to a detailed history of problems of that priority. Alongside the bar chart, you will also find a table displaying the average and maximum duration for problem resolution; this table helps you determine the efficiency of your administrative staff.

If required, you can override the default time period of 1 hour of the event history, by following the steps below:

Click the button at the top of the dashboard to invoke the Dashboard Settings window.
Select the Event History option from the Default timeline for list.
Set a different default timeline by selecting an option from the Timeline list.
Finally, click the Update button.

Back in the dashboard, you will find that the History of Events section is followed by an At-A-Glance section; this section, using pie charts, digital displays and gauge charts, reveals, at a single glance, the current status of some of the critical metrics and key components of the Java application. For instance, the Current Application Health pie chart indicates the current health of the application by representing the number of application-related metrics that are in various states. Clicking on a slice here will take you to a detailed problem history.

The dial and digital graphs that follow provide you with quick updates on the status of a pre-configured set of resource usage-related metrics pertaining to the JVM. If required, you can configure the dial graphs to display the threshold values of the corresponding measures along with their actual values, so that deviations can be easily detected. For this purpose, do the following:

Click the button at the top of the dashboard to invoke the Dashboard Settings window.
Set the Show Thresholds flag in the window to Yes.
Finally, click the Update button.

You can customize the At-A-Glance tab page further by overriding the default measure list for which dial/digital graphs are being displayed in that tab. To achieve this, do the following:

Click on the icon at the top of the Application Dashboard. In the Dashboard Settings window that appears, select Application from the Module list, and Overview from the Sub-System list.
To add measures for the dial graph, pick the Dial Graph option from the Add/Delete Measures for list. Upon selection of the Dial Graph option, the pre-configured measures for the dial graph will appear in the Existing Value(s) list. Similarly, to add a measure to the digital display, pick the Digital Graph option from the Add/Delete Measures for list. In this case, the Existing Value(s) list box will display all those measures for which digital displays pre-exist.
Next, select the Test that reports the said measure, pick the measure of interest from the Measures list, provide a Display name for the measure, and click the Add button to add the chosen measure to the Existing Value(s) list. Note that while configuring measures for a dial graph the 'Measures' list will display only those measures that report percentage values.
If you want to delete one/more measures from the dial/digital graphs, then, as soon as you choose the Dial Graph or Digital Graph option from the Add/Delete Measures for list, pick any of the displayed measures from the Existing Value(s) list, and click the Delete button.
Finally, click the Update button to register the changes.

Note:

Only users with Admin or Supermonitor privileges can enable/disable the system, network, and application dashboards, or can customize the contents of such dashboards using the Dashboard Settings window. Therefore, whenever a user without Admin or Supermonitor privileges logs into the monitoring console, the button will not appear.

Clicking on a dial/digital graph will lead you to the layer model page of the Java Application; this page will display the exact layer-test combination that reports the measure represented by the dial/digitial graph.

If your eG license enables the Configuration Management capability, then, an Application Configuration section will appear here providing the basic configuration of the application. You can configure the type of configuration data that is to be displayed in this section by following the steps below:

Click on the icon at the top of the Application Dashboard. In the Dashboard Settings window that appears, select Application from the Module list, and Overview from the Sub-System list.
To add more configuration information to this section, first, pick the Application Configuration option from the Add/Delete Measures for list. Upon selection of this option, all the configuration measures that pre-exist in the Configuration Management section will appear in the Existing Value(s) list.
Next, select the config Test that reports the said measure, pick the measure of interest from the Measures list, provide a Display name for the measure, and click the Add button to add the chosen measure to the Existing Value(s) list.
If you want to delete one/more measures from this section, then, as soon as you choose the Application Configuration option from the Add/Delete Measures for list, pick any of the displayed measures from the Existing Value(s) list, and click the Delete button.
Finally, click the Update button to register the changes.

Next to this section, you will find a pre-configured list of Key Performance Indicators of the Java application. Besides indicating the current state of and current value reported by a default collection of critical metrics, this section also reveals 'miniature' graphs of each metric, so that you can instantly study how that measure has behaved during the last 1 hour (by default) and thus determine whether the change in state of the measure was triggered by a sudden dip in performance or a consistent one. Clicking on a measure here will lead you to the layer and test that reports the measure.

You can, if required, override the default measure list in the Key Performance Indicators section by adding more critical measures to the list or by removing one/more existing ones from the list. For this, do the following:

Click on the icon at the top of the Application Dashboard. In the Dashboard Settings window that appears, select Application from the Module list, and Overview from the Sub-System list.
To add more metrics to the Key Performance Indicators section, first, pick the Performance Indicator option from the Add/Delete Measures for list. Upon selection of this option, all the measures that pre-exist in the Key Performance Indicators section will appear in the Existing Value(s) list.
Next, select the Test that reports the said measure, pick the measure of interest from the Measures list, provide a Display name for the measure, and click the Add button to add the chosen measure to the Existing Value(s) list.
If you want to delete one/more measures from this section, then, as soon as you choose the Key Performance Indicators option from the Add/Delete Measures for list, pick any of the displayed measures from the Existing Value(s) list, and click the Delete button.
Finally, click the Update button to register the changes.

Clicking on a 'miniature' graph that corresponds to a key performance indicator will enlarge the graph, so that you can view and analyze the measure behavior more clearly, and can also alter the Timeline and dimension (3D/2D) of the graph, if need be.

This way, the first few sections of the At-A-Glance tab page help understand what issues are currently affecting application health, and when they actually originated. To diagnose the root-cause of these issues however, you would have to take help from the remaining sections of the At-A-Glance tab page. For instance, the Key Performance Indicators section may indicate a sudden/steady increase in the CPU usage by a JVM. However, to determine whether the rise in CPU usage was a result of one/more high CPU threads executing on the JVM or a couple of resource-intensive Java processes, you need to focus on the JVM Thread Details section, JVM Memory Management - Summary section, and the Application Process - Summary section in the dashboard. The JVM Thread Details section for starters reveals the number of JVM threads that are in varying states of activity. With the help of this section therefore, you can quickly figure out whether there are currently any:

Threads that are blocking each other (deadlocked threads);
Threads that are being blocked by other threads;
Threads that are waiting for other threads to release a block;
Threads that are consuming high CPU resources, etc.

Say, you notice that too many threads are currently in a BLOCKED state. Immediately, you might want to know whether this is a sudden occurrence, or a situation that has become worse over time. To enable you to determine this, every thread count displayed in the JVM Thread Details section is accompanied by a 'miniature' graph, which tracks the changes in the corresponding thread count during the last 1 hour (by default). To enlarge the graph, click on it. The enlarged graph allows you to change the Timeline for analysis, and also the graph dimension.

To zoom into a particular thread-type and analyze its resource usage, click on the thread type in the JVM Thread Details section. For instance, to gain deeper insights into the performance and resource usage of the runnable threads, click on Runnable Threads in the JVM Thread Details section. A list of threads of the chosen type will be displayed, starting with the most CPU-intensive thread. To enable in-depth analysis of the resource usage of a thread, a pie chart depicting the percentage of time the thread used CPU and the percentage of time it was idle, is provided. If a thread is observed to have used CPU excessively, then, you can study the stack trace information available alongside the pie chart to zero-in on the exact line of code that the thread was executing when its CPU usage spiked.

The JVM Memory Management - Summary section reveals how well the JVM manages its memory resources by measuring and reporting the effectiveness of its garbage collection activity. For every garbage collector, this section reveals the number of garbage collections initiated by the collector, the time taken for the garbage collection, and the percentage of time spent on garbage collection. From this information, you can infer which garbage collector is spending too much time and resources on garbage collection. By default, the garbage collector list provided by this section is sorted in the alphabetical order of the names of the collectors. If need be, you can change the sort order so that the garbage collectors are arranged in, say, the descending order of values displayed in the Time taken for garbage collection column - this column displays the time taken by each collector to perform garbage collection. To achieve this, simply click on the column heading Time taken for garbage collection. Doing so tags the Time taken for garbage collection label with a down arrow icon - this icon indicates that the JVM Memory Management table is currently sorted in the descending order of the time taken by each garbage collector for collecting garbage. To change the sort order to 'ascending', all you need to do is just click again on the Time taken for garbage collection label or the down arrow icon. Similarly, you can sort the table based on any column available in it.

The Application Process - Summary section, on the other hand, traces the CPU and memory usage of each of the Java processes currently executing on the JVM of the target application, and thus leads you to the resource-intensive processes. By default, the process list provided by this section is sorted in the alphabetical order of the process names. If need be, you can change the sort order so that the processes are arranged in, say, the descending order of values displayed in the Instances column - this column displays the number of instances of each process that is in execution currently. To achieve this, simply click on the column heading - Instances. Doing so tags the Instances label with a down arrow icon - this icon indicates that the process list is currently sorted in the descending order of the instance count. To change the sort order to 'ascending', all you need to do is just click again on the Instances label or the down arrow icon. Similarly, you can sort the process list based on any column available in the Application Process - Summary section.

While the At-A-Glance tab page reveals the current state of the JVM threads and the overall resource usage of the JVM, to perform additional diagnosis on problem conditions highlighted by the At-A-Glance tab page and to accrately pinpoint their root-cause, you need to switch to the Details tab page by clicking on it. For instance, the At-A-Glance tab page may indicate the number of threads that are currently blocked, but to know which thread has been blocked for the longest time, you will have to use the Details tab page.

The Details tab page comprises of a default set of comparison bar graphs using which you can accurately determine the following:

How many threads are currently executing on the JVM? Which is the most CPU-intensive thread?
Have any threads been blocked? If so, which thread has been blocked for the maximum duration?
Are any threads in the WAITING state? If so, which thread has been waiting for the longest time?
Which memory pool on the JVM is consuming memory excessively?

If required, you can configure the Details tab page to include comparison graphs for more measures, or can even remove one/more existing graphs by removing the corresponding measures. To achieve this, do the following:

Click on the icon at the top of the Application Dashboard. In the Dashboard Settings window that appears, select Application from the Module list, and Overview from the Sub-System list.
To add measures for comparison graphs, first, pick the Comparison Graph option from the Add/Delete Measures for list. Upon selection of this option, the pre-configured measures for comparison graphs will appear in the Existing Value(s) list.
Next, select the Test that reports the said measure, pick the measure of interest from the Measures list, provide a Display name for the measure, and click the Add button to add the chosen measure to the Existing Value(s) list.
If you want to delete one/more measures for which comparison graphs pre-exist in the details tab page, then, as soon as you choose the Comparison Graph option from the Add/Delete Measures for list, pick any of the displayed measures from the Existing Value(s) list, and click the Delete button.
Finally, click the Update button to register the changes.

Note:

By default, the comparison bar graphs list the top-10 threads and memory pools only. To view the complete list of memory pools or threads, simply click on the corresponding graph. This enlarges the graph.

Though the enlarged graph lists all the memory pools or threads (as the case may be) by default, you can customize the enlarged graph to display the details of only a few of the best/worst-performing threads/memory pools by picking a TOP-N or LAST-N option from the Show list.

Another default aspect of the enlarged graph is that it pertains to the current period only. Sometimes however, you might want to know what occurred during a point of time in the past; for instance, while trying to understand the reason behind a sudden spike in memory usage on a particular day last week, you might want to first determine which memory pool is guilty of abnormal memory consumption on the same day. To figure this out, the enlarged graph allows you to compare the historical performance of memory pools or threads. For this purpose, click on the Compare History link and select the TimeLine of your choice.

Where detailed diagnosis is applicable, you can quickly view the detailed measures that correspond to a comparison graph by clicking on the icon at the right, top corner of the enlarged graph. This will invoke a window, using which you can arrive at the root-cause of a problem.

For detailed time-of-day / trend analysis of the historical performance of a Java application, use the History tab page. By default, this tab page provides time-of-day graphs of critical measures extracted from the target Java application, using which you can understand how performance has varied during the default period of 24 hours. In the event of a problem, these graphs will help you determine whether the problem occurred suddenly or grew with time. To alter the timeline of all the graphs simultaneously, click on the Timeline link at the right, top corner of the History tab page.

You can even override the default timeline (of 24 hours) of the measure graphs, by following the steps below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select History Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

You can click on any of the graphs to enlarge it, and can change the Timeline of that graph in the enlarged mode.

In case of tests that support descriptors, the enlarged graph will, by default, plot the values for the TOP-10 descriptors alone. To configure the graph to plot the values of more or less number of descriptors, select a different TOP-N / LAST-N option from the Show list.

If you want to quickly perform service level audits on the Java application, then summary graphs may be more appropriate than the default measure graphs. For instance, a summary graph might come in handy if you want to determine the percentage of time during the last 24 hours the Java application consumed excessive CPU. Using such a graph, you can determine whether the CPU usage levels guaranteed by the Java application were met or not, and if not, how frequently did the application falter in this regard. To invoke such summary graphs, click on the icon at the right, top corner of the History tab page.

You can alter the timeline of all the summary graphs at one shot by clicking the Timeline link at the right, top corner of the History tab page. You can even alter the default timeline (of 24 hours) for these graphs, by following the steps given below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Summary Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

To change the timeline of a particular graph, click on it; this will enlarge the graph. In the enlarged mode, you can alter the Timeline of the graph. Also, though the graph plots hourly summary values by default, you can pick a different Duration for the graph in the enlarged mode, so that daily/monthly performance summaries can be analyzed.

To perform effective analysis of the past trends in performance, and to accurately predict future measure behavior, click on the icon at the right, top corner of the History tab page. These trend graphs typically show how well and how badly a measure has performed every hour during the last 24 hours (by default). For instance, the CPU usage trend graph of a Java application will help you figure out the maximum and minimum percentage of CPU that was consumed by the application every hour during the last 24 hours. If the gap between the minimum and maximum values is marginal, you can conclude that CPU usage has been more or less constant during the designated period; this implies that CPU usage has neither increased nor decreased steeply during the said timeline. On the other hand, a wide gap between the maximum and minimum values is indicative of erratic usage of CPU, and may necessitate further investigation. By carefully studying the trend graph, you can even determine the points of time at which CPU usage had been abnormally high during the stated timeline, and this knowledge can greatly aid further diagnosis.

To analyze trends over a broader time scale, click on the Timeline link at the right, top corner of the History tab page, and edit the Timeline of the trend graphs. Clicking on any of the miniature graphs in this tab page will enlarge that graph, so that you can view the plotted data more clearly and even change its Timeline.

To override the default timeline (of 24 hours) of the trend graphs, do the following:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Trend Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Besides the timeline, you can even change the Duration of the trend graph in the enlarged mode. By default, Hourly trends are plotted in the trend graph. By picking a different option from the Duration list, you can ensure that Daily or Monthly trends are plotted in the graph instead.

Also, by default, the trend graph only plots the minimum and maximum values registered by a measure. Accordingly, the Graph type is set to Min/Max in the enlarged mode. If need be, you can change the Graph type to Avg, so that the average trend values of a measure are plotted for the given Timeline. For instance, if an average trend graph is plotted for the Live threads measure, then the resulting graph will enable administrators to ascertain how many threads, on an average, were executing in the JVM during a specified timeline; such a graph serves as a good indicator of the growth in the workload of the JVM over time.

Likewise, you can also choose Sum as the Graph type to view a trend graph that plots the sum of the values of a chosen measure for a specified timeline. For instance, if you plot a 'sum of trends' graph for the measure that reports the CPU usage of the JVM, then, the resulting graph will enable you to analyze, on an hourly/daily/monthly basis (depending upon the Duration chosen), how CPU usage of the JVM has varied.

Note:

In case of descriptor-based tests, the Summary and Trend graphs displayed in the History tab page typically plot the values for a single descriptor alone. To view the graph for another descriptor, pick a descriptor from the drop-down list made available above the corresponding summary/trend graph.

At any point in time, you can switch to the measure graphs by clicking on the button.

Typically, the History tab page displays measure, summary, and trend graphs for a default set of measures. If you want to add graphs for more measures to this tab page or remove one/more measures for which graphs pre-exist in this tab page, then, do the following:

Click the button at the top of the dashboard.
The Dashboard Settings window then appears. From the Module list, pick Application, choose Overview as the Sub-System, and then, select History Graph from the Add/Delete Measures for list.
The measures for which graphs pre-exist in the History tab page will be automatically displayed in the Existing Value(s) list. To delete a measure, and in effect, its corresponding graph as well, select the measure from the Existing Value(s) list, click the Delete button, and then click the Update button.
To add a new graph, first, pick the Test that reports the measure for which a graph is to be generated.
Next, select the Measure of interest.
Provide a Display name for the measure. Then, click the Add button to add the measure to the Existing Values(s) list. Finally, click the Update button.
This will add a new measure, summary, and trend graph for the chosen measure, to the History tab page.

Note:

JVM Memory

If you want to assess how efficiently the JVM uses the memory resources available to it, and thus promptly detect memory-intensive pools, select the JVM Memory option from the Subsystem list. The contents of the JVM Memory dashboard that then appears are as follows:

The dashboard begins with a JVM Memory Usage - Summary section, which enables you to visually track the percentage of memory used by each of the memory pools on the JVM. Pools that are currently running short of memory resources can be instantly identified using the usage chart provided by this section.

The Comparison tab page that follows the JVM Memory Usage - Summary section, provides a series of top-10 charts, using which you can quickly isolate those memory pools that are leading the lot in the following default performance areas: overall memory consumption, amount of free memory, committed/available memory, and initial memory. This default list of performance areas (ie., measures) for top-n chart generation can be overridden by following the steps discussed below:

Click on the icon at the top of the Application Dashboard. In the Dashboard Settings window that appears, select Application from the Module list, and JVM Memory from the Sub-System list.
To add new measures for which top-n graphs are to be displayed in the Comparison tab page, first, pick the Comparison Graph option from the Add/Delete Measures for list. Upon selection of this option, the pre-configured measures for comparison graphs will appear in the Existing Value(s) list.
Next, select the Test that reports the said measure, pick the measure of interest from the Measures list, provide a Display name for the measure, and click the Add button to add the chosen measure to the Existing Value(s) list.
If you want to delete one/more measures for which comparison graphs pre-exist in the Comparison tab page, then, as soon as you choose the Comparison Graph option from the Add/Delete Measures for list, pick any of the displayed measures from the Existing Value(s) list, and click the Delete button.
Finally, click the Update button to register the changes.

Note:

If an application slowdown can be attributed to the lack of adequate memory resources, then these top-10 bar charts can aid you in swiftly nailing the exact memory pool that could be serving as the source of this memory contention.

Typically, these bar charts depict the current usage data. Sometimes however, you might want to detect which memory pool was over-utilizing memory at some point of time in the past. In such a case, you will have to click on the corresponding graph in the Comparison tab page to enlarge it. In the enlarged mode, you can click on the Compare History link, so that you can alter the graph Timeline, and view which memory pool was the leading memory consumer during the specified timeline.

Also, though the enlarged graph displays the TOP-10 memory pools on the JVM by default, you can choose to view a more or a less number of memory pools by picking a TOP-N or LAST-N option from the Show list in the enlarged graph.

In contrast to the Comparison tab page, which, by default, reports the current memory usage levels of individual memory pools, the History tab page displays measure graphs that depict how each memory pool has been using the JVM memory over time. In the event of a memory contention, this time-bound analysis will help you easily differentiate between a sudden spike in memory usage and a consistent rise in the same.

By default, these historical graphs track the time-of-day variations in memory usage during the last 24 hours. You can override this default timeline by following the steps discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select History Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

To change the timeline of all the measure graphs at one shot, just click on the Timeline link at the right, top corner of the History tab page. To alter the timeline for a single graph, just click on that graph - this will enlarge the graph. You can change the Timeline of the graph in the enlarged mode.

Besides changing the timeline, you can also change the number of best/worst performers whose performance results are to be plotted in the graph. By default, the enlarged graph reveals the variations in the performance of the TOP-10 memory pools. If need be, you can pick a different TOP-N or LAST-N option from the Show list in the enlarged graph.

Instead of these measure graphs, you can, if required, view summary graphs of the memory-related measures in the History tab page. For this, click on the icon at the right, top corner of the History tab page. Summary graphs help you figure out the percentage of time during the last 24 hours (by default) the Java application was hogged by memory-related issues. While monitoring mission-critical applications that are governed by rigid service level agreements, summary graphs will help you determine whether the guaranteed memory usage levels were fulfilled or not, and if not, how often did the usage levels slip.

You can override the default timeline (of 24 hours) of the summary graphs by following the steps discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Summary Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Here again, you can change the Timeline of all the summary graphs by clicking on the Timeline link, or click on a graph, enlarge it, and change its Timeline in the enlarged mode. Also, though the graph plots hourly summary values by default, you can pick a different Duration for the graph in the enlarged mode, so that daily/monthly performance summaries can be analyzed.

You can click on the icon at the right, top corner of the History tab page to view trend graphs of the memory usage-related measures. By default, these trend graphs plot the maximum and minimum memory usage values for every hour of the last 24 hours (by default). The default timeline of 24 hours can be overridden by following the steps discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Trend Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Using these trend graphs, you can understand the variations in the memory usage of each pool during the last 24 hours (by default), deduce the future usage trends, and accordingly recommend changes to the memory pool size.

Here again, you can change the Timeline of all the trend graphs by clicking on the Timeline link, or click on a graph, enlarge it, and change its Timeline in the enlarged mode. Also, though the graph plots hourly trend values by default, you can pick a different Duration for the graph in the enlarged mode, so that daily/monthly performance trends can be analyzed.

Also, by default, the trend graph only plots the minimum and maximum values registered by a measure. Accordingly, the Graph type is set to Min/Max in the enlarged mode. If need be, you can change the Graph type to Avg, so that the average trend values of a measure are plotted for the given Timeline. Such a graph will enable you to assess whether the memory resources were utilized effectively or not, over time.

Likewise, you can also choose Sum as the Graph type to view a trend graph that plots the sum of the values of a chosen measure for a specified timeline. For instance, a 'sum of trends' JVM memory usage will enable you to analyze, on an hourly/daily/monthly basis (depending upon the Duration chosen), how memory usage of a chosen pool has varied during the specified timeline.

Note:

At any point in time, you can switch to the measure graphs by clicking on the button.

Typically, the History tab page displays measure, summary, and trend graphs for a default set of measures. If you want to add graphs for more measures to this tab page or remove one/more measures for which graphs pre-exist in this tab page, then, do the following:

Click the button at the top of the dashboard.
The Dashboard Settings window then appears. From the Module list, pick Application, choose JVM Memory as the Sub-System, and then, select History Graph from the Add/Delete Measures for list.
The measures for which graphs pre-exist in the History tab page will be automatically displayed in the Existing Value(s) list. To delete a measure, and in effect, its corresponding graph as well, select the measure from the Existing Value(s) list, click the Delete button, and then click the Update button.
To add a new graph, first, pick the Test that reports the measure for which a graph is to be generated.
Next, select the Measure of interest.
Provide a Display name for the measure. Then, click the Add button to add the measure to the Existing Values(s) list. Finally, click the Update button.
This will add a new measure, summary, and trend graph for the chosen measure to the History tab page.

Note:

JVM Thread

If you require an integrated dashboard for analyzing the present/past performance and problem information pertaining to the threads executing on the JVM, so that you can efficiently and accurately diagnose the root-cause of the thread-related abnormalies, select the JVM Thread option from the Subsystem list. Using this single, central dashboard, you can ascertain the following quickly and easily:

Are any threads currently executing on the JVM? Which of these threads are consuming CPU excessively and why? Has the CPU consumption of the thread been high always or is this a sudden occurrence?
Are any threads blocked currently? Have they been blocked for too long a time? Why did it happen?
Are any threads in a deadlock? If so, what caused the deadlock?
Have any threads been waiting for too long a time for other threads to release an object? If so, how long, and what caused the waiting?

The contents of this dashboard are discussed hereunder:

The Thread Analysis section, by default, displays the stack trace of each of the threads that are currently running on the JVM. Accordingly, the default selection in the Analysis By list is Runnable threads. To view the stack trace of those threads that are in a different state (say, Blocked, Waiting, Timed waiting, etc.), you will have to pick a different option from the Analysis By list.

A stack trace (also called stack backtrace or stack traceback) is a report of the active stack frames instantiated by the execution of a program. It is commonly used to determine what threads are currently active in the JVM, and which threads are in each of the different states - i.e., alive, blocked, waiting, timed waiting, etc.

Typically, when a Java application begins exhibiting erratic resource usage patterns, it often takes administrators hours, even days to figure out what is causing this anomaly - could it be owing to one/more resource-intensive threads being executed by the application? If so, what is causing the thread to erode resources? Is it an inefficient piece of code? In which case, which line of code could be the most likely cause for the spike in resource usage? To be able to answer these questions accurately, administrators need to know the complete list of threads that the application executes, view the stack trace of each thread, analyze each stack trace in a top-down manner, and trace where the problem originated.

The JVM Thread dashboard simplifies this seemingly laborious procedure by not only alerting administrators instantly to excessive resource usage by a thread, but also by providing the administrator with quick and easy access to the stack trace information of that thread; with the help of stack trace, administrators can effortlessly drill down to the exact line of code that requires optimization.

Regardless of the Analysis By option chosen, the thread list in the Thread Analysis section is sorted in the descending order of the percentage CPU time of the threads. We can thus conclude that the first thread for which stack trace is provided in this section is the top consumer of CPU. In the event of abnormally high CPU usage by this thread, you can use the stack trace to determine which line of code executed by this thread was causing the CPU usage to soar.

You will have to scroll down the Thread Analysis section to view the stack trace of the other threads. Alternatively, you can click on the icon next to the Analysis By list to invoke the Thread Analysis window using which you can quickly review the stack trace of each of the top CPU consumers.

Below the Thread Analysis section is the Comparison tab page that displays a series of top-10 charts. These charts, by default, aid the quick and accurate identification of the thread that is currently consuming the maximum CPU, the thread that has been blocked for the longest time, and the thread that has been in waiting for the longest time. You can override this default setting by including comparison graphs for more measures in the Comparison tab page, or by removing one/more existing graphs from this tab page. To achieve this, do the following:

Click on the icon at the top of the Application Dashboard. In the Dashboard Settings window that appears, select Application from the Module list, and JVM Thread from the Sub-System list.
To add new measures for which top-n graphs are to be displayed in the Comparison tab page, first, pick the Comparison Graph option from the Add/Delete Measures for list. Upon selection of this option, the pre-configured measures for comparison graphs will appear in the Existing Value(s) list.
Next, select the Test that reports the said measure, pick the measure of interest from the Measures list, provide a Display name for the measure, and click the Add button to add the chosen measure to the Existing Value(s) list.
If you want to delete one/more measures for which comparison graphs pre-exist in the Comparison tab page, then, as soon as you choose the Comparison Graph option from the Add/Delete Measures for list, pick any of the displayed measures from the Existing Value(s) list, and click the Delete button.
Finally, click the Update button to register the changes.

Note:

To view a comparison graph more clearly, click on it; this enlarges the comparison graph as depicted.

In the enlarged mode, you can pick a different TOP-N or LAST-N option from the Show list to focus on a more or a less number of JVM threads. Also, to perform a post-mortem on issues that occurred in the past and to zero-in on threads that may have contributed to this past problem, click on the Compare History link and provide a Timeline for this comparison. A comparison bar graph indicating the top-10 (by default) threads in a specific performance area during the specified timeline, will then appear.

For historically analyzing the state of the JVM threads, click on the History tab page. This tab page displays time-of-day graphs for all the thread-related measures for a default duration of 24 hours. You can override this default timeline (of 24 hours) by following the steps below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select History Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Say, you suddenly notice that the number of blocked threads has increased; in such a case, you can use these measure graphs to figure out when during the last 24 hours the block occurred. If required, you can even look beyond the last 24 hours - i.e., you can find out whether the anomaly originated much earlier. For this, you just need to click on the graph of interest to you. This will enlarge the graph; in the enlarged mode, you can alter the graph Timeline, so that the performance of that measure can be analyzed over a broader time window. In this mode, you can even change the graph dimension from 3D to 2D, or vice-versa.

To view summary graphs on thread state instead of the default measure graphs, just click on the icon at the right, top corner of the History tab page. The summary graphs will reveal the percentage of time during the last 24 hours (by default) the Java application has been affected by thread-related issues, and the type of issues (whether critical/major/minor) the application was experiencing. These graphs help determine whether the assured service levels were delivered or not. For instance, if the Java application assures its users of zero deadlock situations, then the summary graph will reveal whether the Java application did encounter any deadlock situation, and if so for how long - this way, while performing service level audits on the application, the auditor can understand whether the application delivered on its promise or has slipped. If service level slippages are detected, then the summary graphs will also reveal the extent of the slip - i.e., the percentage of time for which the desired service levels were not delivered.

The default duration (of 24 hours) of the summary graphs can be overridden by following the procedure discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Summary Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Use the Timeline link at the right, top corner of the tab page to change the timeline of all the summary graphs at one shot. For altering the timeline of a single graph, click on it; this will enlarge the graph. In the enlarged mode, you can change the Timeline of the summary graph and modify the dimension (3D/2D) of the graph. Also, by default, hourly summaries are plotted in the summary graph; you can configure these graphs to plot daily/monthly summaries instead by picking the relevant option from the Duration list in the enlarged mode.

If you want to view the past trends in thread performance, click on the icon at the right, top corner of the History tab page. Using the trend graphs displayed, you can better assess the current capacity of your application and can accordingly plan its future capacity. By default, these trend graphs plot the maximum and minimum values registered by every thread-related measure during every hour of the last 24 hours. From this data, you can clearly figure out when during the last 24 hours the application performance has peaked and when it has been below-normal.

The default duration (of 24 hours) of the trend graphs can be overridden by following the procedure discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Trend Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Use the Timeline link at the right, top corner of the tab page to change the timeline of all the trend graphs at one shot. For altering the timeline of a single graph, click on it; this will enlarge the graph. In the enlarged mode, you can change the Timeline of the trend graph and modify the dimension (3D/2D) of the graph. Also, by default, hourly trends are plotted in the trend graph; you can configure these graphs to plot daily/monthly trend values intead by picking the relevant option from the Duration list in the enlarged mode. Moreover, by default, the trend grahs plot only the minimum and maximum values registered by a measure during the specified timeline - this graph wil enable you to isolate those times at which performance of that measure had peaked and the times it had fared poorly. For instance, using the default trend graph for the Blocked threads measure, you can clearly identify when too many threads were blocked and when blocked threads were minimum. If need be, you can select the Avg option from the Graph type list in the enlarged mode to make sure that the trend graph plots the average trend values for the specified timeline - in the case of the above example, such a graph will help you understand how the blocked threads count has varied during the set timeline. Alternatively, you can select the Sum option from the Graph type list to have the trend graph plot the sum of trends for the specified timeline.

Note:

At any point in time, you can switch to the measure graphs by clicking on the button.

Typically, the History tab page displays measure, summary, and trend graphs for a default set of measures. If you want to add graphs for more measures to this tab page or remove one/more measures for which graphs pre-exist in this tab page, then, do the following:

Click the button at the top of the dashboard.
The Dashboard Settings window then appears. From the Module list, pick Application, choose JVM Thread as the Sub-System, and then, select History Graph from the Add/Delete Measures for list.
The measures for which graphs pre-exist in the History tab page will be automatically displayed in the Existing Value(s) list. To delete a measure, and in effect, its corresponding graph as well, select the measure from the Existing Value(s) list, click the Delete button, and then click the Update button.
To add a new graph, first, pick the Test that reports the measure for which a graph is to be generated.
Next, select the Measure of interest.
Provide a Display name for the measure. Then, click the Add button to add the measure to the Existing Values(s) list. Finally, click the Update button.
This will add a new measure, summary, and trend graph for the chosen measure to the History tab page.

Note:

JVM Classes

Select the JVM Classes option from the Subsystem list to know how efficiently the class loader used by the Java application is and has been loading/unloading classes onto memory.

The contents of this dashboard are as follows:

The JVM Classes section indicates the current health of the class loader by providing a pie chart that graphically depicts the number of classes currently loaded and unloaded by the application.

The History tab page below, by default, provides a series of measure graphs that reveal how the class loader has been performing over the default duration of the last 24 hours. If the number of classes loaded/unloaded dramatically decreases, it could indicate that the class loader is experiencing issues with loading/unloading. In such a case, a look at these measure graphs will help you figure out when exactly the bottleneck surfaced - did it happen suddenly or is it a condition that has become worse with time?

The default duration of 24 hours can be overridden using the procedure discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select History Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Note:

If need be, you can even alter the timeline of all these measure graphs so that you can analyze performance across days and weeks; for this, simply click the Timeline link at the right, top corner of the History tab page and change the timeline for the graphs using the calendar that pops out. To change the timeline of a single graph alone, simply click on that graph to enlarge it, and then modify the Timeline of the graph in the enlarged mode.

In the enlarged mode, you can even change the dimension fo the measure graph (3D / 2D).

To determine the service level achievements / slippages of the class loader, you need to view summary graphs of the measures and not the default measure graphs. For this, just click on the icon at the right, top corner of the History tab page.

The summary graphs displayed, reveal the percentage of time the Java application experienced problems in loading/unloading classes on to the memory. Besides revealing the efficiency of your administrative staff in recognizing bottlenecks and mitigating them, these summary graphs also indicate whether the class loader has been able to maintain the assured performance levels during the default duration of 24 hours.

To override this default duration, follow the steps below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Summary Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

In case of the summary graphs too, you can change the Timeline of all graphs by clicking on the Timeline link at the right, top corner of the History tab page. To alter the timeline of a single graph, here again, you will have to click on that graph, enlarge it, and modify the timeline. Also, by default, hourly summaries are plotted in the summary graph; you can configure these graphs to plot daily/monthly summaries instead by picking the relevant option from the Duration list in the enlarged mode.

To analyze past trends in the loading/unloading of classes, click on the icon at the right, top corner of the History tab page.

These trend graphs, by default, plot the minimum and maximum values that every measure registered during each hour of the last 24 hours (by default). Using such graphs, you can accurately point to the time windows in which the class loader was actively loading/unloading classes, and the times at which there was a lull. By carefully observing these past trends, you can effectively gauge the workload that the application has been imposing on the class loader, predict future workloads accordingly, and suggest measures to enhance the efficiency of the loader. Here again, you can change the timeline of all graphs using the Timeline link, or just a particular graph by clicking on it and enlarging it.

For changing the default duration (of 24 hours) of the trend graphs, do the following:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Trend Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

In addition, when a trend graph is enlarged, it is not just the Timeline that you can modify. The Duration of the graph can also be altered. By default, trend graphs reveal only the hourly trends in performance. By picking the relevant option from the Duration list, you can ensure that the trend graph in question plots daily/monthly trend values instead. Also, in the enlarged mode, the Graph type can also be modified. Since the default Graph type is Min/Max, the trend graph, by default, reveals the minimum and maximum values registered by a measure. If need be, you can select the Avg or Sum option from the Graph type list to plot average trend values of a measure or sum of trends (as the case may be) in the graph.

Note:

At any point in time, you can switch to the measure graphs by clicking on the button.

Typically, the History tab page displays measure, summary, and trend graphs for a default set of measures. If you want to add graphs for more measures to this tab page or remove one/more measures for which graphs pre-exist in this tab page, then, do the following:

Click the button at the top of the dashboard.
The Dashboard Settings window then appears. From the Module list, pick Application, choose JVM Classes as the Sub-System, and then, select History Graph from the Add/Delete Measures for list.
The measures for which graphs pre-exist in the History tab page will be automatically displayed in the Existing Value(s) list. To delete a measure, and in effect, its corresponding graph as well, select the measure from the Existing Value(s) list, click the Delete button, and then click the Update button.
To add a new graph, first, pick the Test that reports the measure for which a graph is to be generated.
Next, select the Measure of interest.
Provide a Display name for the measure. Then, click the Add button to add the measure to the Existing Values(s) list. Finally, click the Update button.
This will add a new measure, summary, and trend graph for the chosen measure to the History tab page.

Note:

JVM Uptime

To investigate issues with availability and uptime of the JVM, select JVM Uptime as the Subsystem.

The contents of the uptime dashboard are as follows:

From the JVM Uptime section, you can determine the total duration for which the JVM has been up and running since its startup. If the JVM was started two days ago, but the uptime indicated by this section spans only a day, it is a clear indication that the JVM was unavailable for a while in-between; a possible reason for this could be a scheduled/unscheduled reboot of the Java application.

The History tab page, by default, displays time-of-day graphs revealing the uptime statistics for a default period of 24 hours. If the eG agent reports that the JVM is down, these graphs will help determine when exactly in the last 24 hours the anomaly occurred. This default duration of 24 hours can be overridden using the following steps:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select History Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

Note:

A careful study of this graph over time periods longer than 24 hours, can reveal intermittent breaks (if any) in JVM availability and failure of scheduled JVM reboots (if any). To ensure that all graphs plot values for longer time periods, click on the Timeline link at the right, top corner of the History tab page, and then change the timeline using the calendar that pops out. To modify the timeline for a particular graph alone, click on the graph to enlarge it, and alter the timeline in the enlarged mode. Besides the timeline, you can even change the graph dimension (3D / 2D) in the enlarged mode.

Sometimes, you might have to periodically determine the percentage of time for which certain critical Java applications have been up and running, so that you know whether/not the application has been able to maintain the desired uptime levels. To run such uptime checks, summary graphs of the uptime measures are useful. To view summary graphs in the History tab page, click on the icon at the right, top corner of the History tab page.

The graphs reveal the percentage of time during the last 24 hours (by default) the JVM has experienced issues related to uptime. To override this default timeline, do the following:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Summary Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

To perform the summary analysis over a broader time window, click on the Timeline link at the right, top corner of the History tab page and change the timeline; this will alter the timeline for all the graphs. To change the timeline of a particular graph alone, click on the graph to enlarge it, and then alter its timeline. Also, by default, hourly summaries are plotted in the summary graph; you can configure these graphs to plot daily/monthly summaries instead by picking the relevant option from the Duration list in the enlarged mode. Here again, the graph dimension (3D / 2D) can be altered.

Similarly, you can analyze uptime trends by viewing trend graphs in the History tab page. For this, click on the icon at the right, top corner of the tab page.

These trend graphs, by default, plot the minimum and maximum values registered by every uptime-related measure during every hour for the last 24 hours. Using these graphs, you can ascertain when during the last 24 hours uptime was very high, and when it was low. The default duration of 24 hours can be overridden using the procedure discussed below:

Click on the icon at the top of the Application Dashboard.
In the Dashboard Settings window that appears, select Summary Graph from the Default Timeline for list.
Then, choose a Timeline for the graph.
Finally, click the Update button.

To perform trend analysis over a longer time span, click on the Timeline link at the right, top corner of the History tab page and change the timeline; this will alter the timeline for all the graphs. To change the timeline of a particular graph alone, click on the graph to enlarge it, and then alter its timeline. In addition to the timeline, the graph dimension (3D / 2D), the graph Duration, and the Graph type can also be changed in the enlarged mode. By default, the graph Duration is Hourly, indicating that trend graphs plot hourly trend values by default. To ensure that these graphs plot the daily/monthly trend values instead, select the relevant option from the Duration list. Similarly, as already mentioned, trend graphs plot only the minimum and maximum values registered by a measure during the specified timeline. Accordingly, the Graph type is set to Min/Max by default in the enlarged mode. If you want the trend graph to plot the average trend values instead, set the Graph type to Avg. On the other hand, to configure the trend graph to plot the sum of trends set the Graph type to Sum.

Note:

At any point in time, you can switch to the measure graphs by clicking on the button.

Typically, the History tab page displays measure, summary, and trend graphs for a default set of measures. If you want to add graphs for more measures to this tab page or remove one/more measures for which graphs pre-exist in this tab page, then, do the following:

Click the button at the top of the dashboard.
The Dashboard Settings window then appears. From the Module list, pick Application, choose JVM Uptime as the Sub-System, and then, select History Graph from the Add/Delete Measures for list.
The measures for which graphs pre-exist in the History tab page will be automatically displayed in the Existing Value(s) list. To delete a measure, and in effect, its corresponding graph as well, select the measure from the Existing Value(s) list, click the Delete button, and then click the Update button.
To add a new graph, first, pick the Test that reports the measure for which a graph is to be generated.
Next, select the Measure of interest.
Provide a Display name for the measure. Then, click the Add button to add the measure to the Existing Values(s) list. Finally, click the Update button.
This will add a new measure, summary, and trend graph for the chosen measure to the History tab page.

Note: